New to PiHole need assistance with accessing admin page from remote machine

Help
1

Hi everyone

I am new to this, so please go easy on me!

I have installed PiHole on an Unbuntu 19.10 image through Hyper-V VM. This VM is on a Windows 10 machine and looks to be running correctly.

I am able to access the admin dashboard from the VM, but unable to access it through the host machine or any others on my network, and it does not look like Pihole is protecting the other machines on the network either.

I have not made any changes to my router. It is an ISP provided one so it is fairly rigid and locked down. As can be seen from the screenshot below, it is currently set as the DHCP server, but I am nervous to make any changes without some guiding help!

image
image1031×454 18.4 KB

From what I understand, I need to do either of the following:

  1. Change the DNS server ip address on the router to that of the Pi-Hole installation (if this is the case what ip address do I use? (The Pi-Hole IPv4 address is set to 172.18.46.118/28, is it this one?)

or

  1. Disable the DHCP server on the router and tick the DHCP Server enabled box in Pi-Hole.

Is this correct? Is there anything else I can/should do?

Thanks in advance.

2

Doubt you want to modify the DHCP settings for your network.
try posting ifconfig on the VMguest and ipconfig on the VMhost and ip route on the VMguest and route print on the VMhost

Harry

3

Hey Harry

Thanks for the response. I have a basic understanding of if/ipconfig but am unsure of what you mean by posting, ip route and route print.

Any tips?

4

All are command lines, linux speak, iproute or iproute -n list the routing table for the device Windows speak route print does the same. There are other probably better options but my windows fu is very lacking these days.

Linux speak ifconfig, windows speak ipconfig list the properties of the interfaces.

so if you run those commands, which give text reports, copy and paste them into this thread, I'll see if I can see why at least some addresses in your VMguest are unreachable.
harry

5

Thanks Harry.

I've attached both outputs from the Windows and Linux machines. The iproute command did not work, so I used ip ro instead.

Let me know if I've missed anything and thanks for your help!

ifconfig.txt (1.1 KB) ipconfig.txt (7.1 KB)

9

Based on what little insights your router config screenshot conveys, it seems like your router resides at 10.0.0.138 and is handing out itself as local DNS server in its DHCP Settings.

Hence, it would be sufficient to replace DNS server with your Pi-hole's IP address.
However, your Pi-hole has to be issued with an IP address on the 10.0.0.0/24 subnet, which is currently not the case :thinking:

While your windows 10 machine resides at 10.0.0.88, it seems you have completely isolated your VM's network, with it's outside IP being 192.168.137.1 while using 172.18.46.118 internally.

You have to either find a way to assign an IP address within the 10.0.0.0/24 range to your Pi-hole, or to define a respective route to the current outside address.

Two possible caveats (forgive me if you are aware of them already):

Once your router hands out Pi-hole as your local DNS server, you have to ensure that your VM is running 24/7 at all times (click for more)

Otherwise, DHCP configured clients on your network won't be able to resolve any host name when your Pi-hole is down or disconnected, which will seemingly disconnect you from the internet (technically, you are still connected and would be able to access sites if you happen to know their IP address).

Depending on how you manage to integrate Pi-hole into your network, you may not be able to see individual clients in Pi-hole's Query Log.

This would be the case if e.g. you route DNS traffic through your Win10 machine to your VM - Pi-hole will see all DNS requests as originating from your Win10 machine then.

I am not familiar with configuring Win10 VMs, so you have to consult your manuals or maybe find another forum on how to configure that specific VM.

@shoka may happen to know a good place to start, giving his background as network engineer (though his self-assessment on Windows is 'very out of date'), or maybe he's got a network config trick up his sleeve straight away :wink:

10

Before you make any changes to the DNS setup, we need to verify that your VMclient can connect to devices on the main network.

From the files you sent the client is on ip 172.18.46.118 and has a default route via 172.18.46.113
That says it is in a little 16 host network of its own, ip range 172.18.46.112/28.
assuming the router on 172.18.46.113 is functional, it should be able to connect out.

And indeed your VMhost has a virtual Ethernet adapter with that address.

Your VMhost also has a route
172.18.46.112 255.255.255.240 On-link 172.18.46.113 5256
172.18.46.113 255.255.255.255 On-link 172.18.46.113 5256
which will send traffic back into the little client network.

So within your VMhost everything works (thus why you can reach the pihole from the windows host)

However, your windows VMhost is not a router, running a routing protocol to announce the existence of that 172.18.46.112/28 network to the rest of your network, so outside the VMhost, nobody knows how to find that network.

You could run a routing protocol on that VMhost, but that is rather a sledgehammer to crack a walnut.

I don't know the details of your real router, but most have a provision for adding static routes.

If you configure a static route on the "real" router with a destination of 172.18.46.112/28 (or 172.18.46.112 255.255.255.240 if it uses that notation), and nexthop 10.0.0.88 (the ip address bound to the "real" Ethernet NIC on your VMhost, the rest of your network will send requests for your VMclient to their default gateway (your real router) which will know from the static route to forward that traffic to the VMhost, which knows how to send on into the virtual networK.

There are nasty things call firewalls however, which can get in the way. So test..

Test from the VMhost with:
ping 172.18.46.118
tracert 172.18.46.118

If nothing is being stupid (Windows 10 is stupid by default, Ubuntu is not usually) those requests should complete from the VMhost with or without the static route, but will fail from everywhere else.

after you configure the static route, they should work from any device on your network.

final tests:

From your VMguest
ping 10.0.0.138
traceroute 10.0.0.138

should also now work.

also

ping 8.8.8.8 (google DNS)
traceroute 10.0.0.138

ergo you have access to the internet.

Get to this point, and we can start considering how to integrate pihole into your DNS setup.

11

Re reading your post, you seem to have an issue getting to your VMguest by IP even with the routing in place. You need a function known as IP forwarding so that Windows will pass traffic for other IP's.

As I said I've long forgotten most of the windows fu I ever had.

From a hint on the internet

make sure the Routing and Remote Access service is enabled and started. In windows 10 it is disabled by default.

Harry

12

The reason you had problems with the iproute command, is you missed a space. It's ip route.
but anyway the command gets expanded, so ip ro, ip rou, ip rout and ip route are all equivalent.

route on its own or route -n also lists the route table in another, arguably clearer format. The commands are subtly different, ip route is asking the ip subsystem for its routes, route is asking the kernel ip routes.

13

Thanks Shoka and Bucking_Horn

Looking at what you have both advised, I think the issue maybe with the way that I have bridged the network adapter on the VM. I set it up as an 'Internal' virtual switch, where I think it should have been done as an 'External'.

If I delete the virtual switch and create a new one as an 'External' switch will this will cause any issues with my current network settings? I attempted to do this and get the following warning so I backed out:

image

As you can probably tell, I have very limited networking skills...

14

Not sure what that will change. It may rebuild the networking for the VM using addresses from your real network, but it may do something else entirely. Can you check the status of the Routing and Remote Access service and if its stopped, start it? I think that may be all you need to do to progress. I rather like your pihole on its own network, that you can switch off from your real network with just a route change/start stop of the service.

15

Hi Shoka

I've enabled the Routing and Remote Access service on the host machine. Is there anything I can do to test if this change worked?

16

Yes try the tests in my earlier post...
particularly can you now access the pihole gui from the VMhost?

17

Thank you. It's 0200hrs here. I will test this in the morning and let you know how it goes.

18

Whoops, its a lazy mid afternoon bank holiday here.
When you can, sorry to be pushy.
Harry

19

Hi @shoka!

I have performed those tests you recommended after enabling the Routing and Remote Access service on the host machine and I am now getting responses (ignore the ip address change of the VM Guest, I rebuilt the image):

From the VM Host:

C:\Users\James>**ping 172.18.46.115**

Pinging 172.18.46.115 with 32 bytes of data:
Reply from 172.18.46.115: bytes=32 time<1ms TTL=64
Reply from 172.18.46.115: bytes=32 time<1ms TTL=64
Reply from 172.18.46.115: bytes=32 time<1ms TTL=64
Reply from 172.18.46.115: bytes=32 time<1ms TTL=64

Ping statistics for 172.18.46.115:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\James>**tracert 172.18.46.115**

Tracing route to Pi.mshome.net [172.18.46.115]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Pi.mshome.net [172.18.46.115]

Trace complete.

From the VM Guest:

Pi:~/Desktop$ **ping 10.0.0.138**
PING 10.0.0.138 (10.0.0.138) 56(84) bytes of data.
64 bytes from 10.0.0.138: icmp_seq=1 ttl=63 time=0.775 ms
64 bytes from 10.0.0.138: icmp_seq=2 ttl=63 time=0.520 ms
64 bytes from 10.0.0.138: icmp_seq=3 ttl=63 time=0.607 ms
64 bytes from 10.0.0.138: icmp_seq=4 ttl=63 time=1.15 ms
64 bytes from 10.0.0.138: icmp_seq=5 ttl=63 time=0.615 ms
64 bytes from 10.0.0.138: icmp_seq=6 ttl=63 time=5.95 ms
64 bytes from 10.0.0.138: icmp_seq=7 ttl=63 time=0.570 ms
64 bytes from 10.0.0.138: icmp_seq=8 ttl=63 time=0.594 ms
64 bytes from 10.0.0.138: icmp_seq=9 ttl=63 time=0.567 ms
64 bytes from 10.0.0.138: icmp_seq=10 ttl=63 time=1.09 ms
^C
--- 10.0.0.138 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 167ms
rtt min/avg/max/mdev = 0.520/1.243/5.952/1.583 ms

i:~/Desktop$ **traceroute 10.0.0.138**
traceroute to 10.0.0.138 (10.0.0.138), 64 hops max
  1   172.18.46.113  3.265ms  0.602ms  0.504ms 
  2   10.0.0.138  0.874ms  0.379ms  0.862ms

Pi:~/Desktop$ **ping 8.8.8.8**
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=41.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=19.10 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=22.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=39.7 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=39.9 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=36.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=24.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=22.4 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=27.3 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=34.9 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=19.2 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=27.6 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=28.5 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=28.2 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=31.6 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=53 time=33.1 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=53 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=53 time=24.0 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=53 time=35.7 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=53 time=23.5 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=53 time=34.2 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=53 time=27.1 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=53 time=38.7 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=53 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=53 time=27.1 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=53 time=44.8 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=53 time=19.9 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=53 time=29.3 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=53 time=30.0 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=53 time=41.5 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=53 time=22.8 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=53 time=39.8 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=53 time=19.3 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=53 time=54.1 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=53 time=24.2 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=53 time=31.5 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=53 time=23.7 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=53 time=26.10 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=53 time=34.4 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=53 time=23.7 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=53 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=53 time=25.8 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=53 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=53 time=22.5 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=53 time=34.3 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=53 time=24.0 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=53 time=61.7 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=53 time=52.3 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=53 time=29.7 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=53 time=20.9 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=53 time=19.8 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=53 time=28.9 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=53 time=24.0 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=53 time=25.1 ms
^C
--- 8.8.8.8 ping statistics ---
55 packets transmitted, 55 received, 0% packet loss, time 111ms
rtt min/avg/max/mdev = 19.208/29.511/61.664/9.326 ms

If you don't mind helping out still, what should I do next?

20

OK
Quick summery of what those tests prove.

  1. your VMhost has connectivity to the VMguest. Originally you said that the pihole console was not reachable from the VMhost. It should be now.

  2. your VMguest has access to the internet, 8.8.8.8 is google DNS.

Not sure how that access is happening, there are a number of ways that can be configured to work, so can we make another test please (to make sure the VMguest has direct access, not NAT'ed to the VMhost address.)

From another system on your local network, attempt to ping the ip address of your VMguest.
172.18.46.115 if I read the above correctly.

If that works, whatever windows has set up is fine and we can start to investigate name serving.

If it does not work, then we have to add a route to your network to assist your network clients in finding your VMguest, since the name server service depends on the IP layer to function.
Essentially we (may, depending on what windows VM has actually configured) have to add a static route to your router to direct IP traffic to your VMhost, as the first step in reaching your VMguest.

I'd wait for the outcome of that test, but I'm aware of the time lapse between us, so if your VMguest is reachable, investigate the nslookup command. It's the same command for both Linux and Windows, but differs in detail IIRC nslookup /? will explain the windows variant, and man nslookup will explain the Linux version. /? option is less than helpful, full syntax is here:

Both provide an interactive interface where you can enter names and receive name server responses. By default I guess the target name server on your network will be your router.

Once you have tried a few names ("google.com" etc) and received usable responses, issue the "server 172.18.46.115" directive at the nslookup prompt. That will target your pihole server for name lookups. If your config on the pihole is usable, that will also resolve names.

Harry

21

Thanks Harry

I've attempted to ping 172.18.46.115 from two separate devices on the network and both have 100% packet loss.

How do I set a static route on the router?

22

Do not know your router type. If you know it, and can tell me, I will try and get a copy of the manual so I can advise more effectively. There is nothing like a standard interface.

Essentially you are looking for something like "static route", "network route setup".. etc.
Keyword to look for is probably nexthop, which is what you are trying to tell the router.

Essentially "to get to this address, send stuff here"

Example page from one of my devices.

Screenshot%20from%202020-01-02%2019-22-51|690x374

Harry

23

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.