Slow "remote" connections to clients within LAN

Expected Behaviour:

Not slow

Actual Behaviour:

I have Pi-hole running successfully for a few weeks - running as both DNS and DHCP server on my Network with Orbi as my router and wifi. Pi-hole is connected to LAN via eth(0) on the same switch as the router. The issue I have is that internal remote connections are really slow (15-30 seconds to initiate). I use a variety of clients for it - VNC, Google Desktop, Jump Desktop (VNC), and native Apple sharing. Anything using VNC (port 5900) or Google Remote (port 443) has slowed considerably since installing. It's both in initiating and establishing the connection, as well as using once established. I have a lot of headless clients (Mac Mini's, crypto miners, etc) so use remote frequently. It was almost instantaneous prior to installing Pi-hole. Otherwise, network is fast, connection times and latency is great on websites.

Debug Token:

https://tricorder.pi-hole.net/kj8f4o3kb1

Your debug log is normal. I would be surprised if the presence of Pi-hole on the device interferes with these services on ports not used by Pi-hole. I run VNC on one of my Pi's with no problems.

When you initiate any of these remote connections, are you doing it by IP address or by domain name?

That is a good question - I just let the remote clients manage it - it appears both Jump and Google Remote Desktop use domain name. Native VNC is rocket fast with no latency, which I believe also uses domain name. Prior to putting Pi-hole in all of the clients were essentially instantaneous.

One thing I notice is many of my clients on the network have two ipv6 addresses. One 2601:643:xxxx (same prefix as router and primary Pi-hole ipv6) and the other fe80::5724:xxxx (assume that's internally generated?). No idea if that's part of the problem, or even a problem. Not an ipv6 expert to put it mildly.

Thanks - I appreciate the help!

As a troubleshooting step, disable IPv6 on your network and the clients experiencing the problem.

Will do - on both the router and Pi-hole? Thanks

That actually seems to have helped - interesting. I wonder if the way I have it set up on the router is creating some conflict given I have the two addresses schemes for ipv6.. As a related follow-up question, how should I have the router (Orbi) setup wrt ipv6? The options for ipv6 assignment on the LAN for the Orbi are:

  • Use DHCP Server

  • Auto Config (default)

  • use this interface id xxxx:xxxx:xxxx:xxxxx (optional selection)

DHCP is disabled on the router and enabled on the Pi-hole. Ipv6 is also enabled on the Pi-hole. The Orbi is still in router mode (not AP) - just deselected "Use Router as DHCP"

I am beginning to wonder if, although I have "Use as DHCP Server" disabled on the Orbi that it only applies to ipv4, and it's still generating them for devices, hence getting the two ipv6 addresses on some clients.
At the top of the ipv6 config page there is a "Internet Connection Type" selection which is currently set to "auto detect". the other selections are auto config, fixed, pass through, DCHP, and PPOE. My assumption was that's how it gets it's WAN ipv6 from the Modem (Comcast), whereas the selections at the top of this note are for the LAN.

Thanks

Strictly speaking, DHCP is indeed an IPv4 only protocol. The proper name for its IPv6 counterpart would be DHCPv6.
It may well be that your router would still offer your ISP's DNS servers for IPv6, be that via DHCPv6 or router advertisements (RAs), alongside Pi-hole offering its own addresses.
Clients may then choose any of those DNS servers.

As your original issue is about slow connections to local clients, it could be that clients initiating the connection preferring IPv6 over IPv4 try to explicitly determine a prospective connection target hostname's IPv6 address via your router's IPv6 or your ISP's DNS servers - to no avail, as a public DNS server wouldn't know any local hostnames and your router doesn't know them any more. Connection initiation may then continue with probing other IPv6 DNS servers before eventually falling back to IPv4.

However, I have no explanation why a connection would stay slow once it has been established in this scenario.

If you cannot configure the way your router offers IPv6 DNS servers, keeping IPv6 switched off would be your only option to prevent Pi-hole being by-passed.

If you want to address just the slow connections, trying to configure your client software to prefer or use IPv4 exclusively may solve that specific issue.

Thanks again for the help. I think I now have my head abound ipv6. I don't think I have a DNS issue with ipv6 as have run a bunch of leak tests on various devices (not explicitly pointed to Pi-hole) and doesn't appear I am leaking to Comcast which is good. The "prefer ipv4" really helped on one of my clients, as did a few reboots on some of the Windows machines. Much appreciated!

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