Fix Velop mesh flooding Pi-hole with PTR requests

[chrislph]

Info

Linksys Velop is a mesh wifi system made up of nodes that work together to provide network coverage, parental controls and so on. It has various modes of operation, but a common one for home users is where it is added to an existing network and picks up its networking from an existing router via DHCP.

One of its functions is to find and identify devices on the network so they can be presented in the Velop app. Each node makes tens to hundreds of PTR requests every minute to the network's DNS server. Normally this traffic would not be visible because it would be handled by the router's DNS server.

Pi-hole can be configured in different ways but one common approach is to ammend the router's DHCP to stop using the router for DNS and switch to using Pi-hole for DNS. Another common approach is to disable the router's DHCP entirely and enable Pi-hole's DHCP to replace it. This way Pi-hole always presents itself as the DNS server.

Either way, with Pi-hole as the DNS server, Pi-hole users will now see all the Velop PTR traffic. These swamp the Query Log and graphs and make them difficult to use for other devices on the network.

Fix

One way to deal with this would be to make the Velop nodes revert to using the original router for DNS. However, on checking, it may be the case that the network settings cannot be edited and are fixed as DHCP.

If Pi-hole is the DHCP server there is a way to make it tell just the Velop nodes to use the original router for DNS, while everything else continues to use Pi-hole as normal. This was mentioned by @yubiuser and there is an external template for it by another user.

I've tested this with a friend who has these Velop mesh nodes and it has fixed the problem. They are no longer sending PTR requests to Pi-hole. They continue to find and show devices on the network, and features like parental control continue to work. All other devices continue to use Pi-hole as normal.

Steps

Identify nodes

Use Pi-hole's Dashboard graph to identify how many nodes are flooding it with PTR queries. Find these nodes in Tools > Network and make a note of their MAC addresses. You will probably find that the Velop parent node is not sending PTR requests, it is just the child nodes.

So if you have, eg, 4 Velop nodes, 1 is set as parent and the other 3 are child nodes, you would only need to configure those 3 nodes in the next section. This is my friend's graph and you can see the 3 child nodes dominating the graph.

Create bypass config

Log into the Pi-hole terminal and edit a new dnsmasq config file:

sudo nano /etc/dnsmasq.d/90-bypass.conf

Paste in the text

# Send Velop DNS to router rather than Pi-hole
# The config below is for 3 Velop nodes
# Copy and paste the Velop node sections to add more
#   or delete unwanted sections for fewer

# Define router (replace xxx's with IP address of original router)
dhcp-option=tag:router,6,xxx.xxx.xxx.xxx

# Velop node 1 (replace XX's with node's MAC address
dhcp-host=XX:XX:XX:XX:XX:XX,set:router

# Velop node 2 (replace XX's with node's MAC address
dhcp-host=XX:XX:XX:XX:XX:XX,set:router

# Velop node 3 (replace XX's with node's MAC address
dhcp-host=XX:XX:XX:XX:XX:XX,set:router

Edit the text and replace the xxx's with the original router's IP address. Replace the XX's with the MAC addresses of the Velop nodes that are sending PTR requests, identified in the previous step. If you have more than 3 nodes doing this, copy and paste the Velop sections to add more. If you have fewer then delete the unwanted sections. Each section should have a valid MAC address.

Save the file and quit nano.

Activate new config

Reboot the Pi-hole. This is a simple way to make sure the changes have definitely taken and are working across reboots.

Finally, reboot all the Velop nodes. This forces them to reconfigure the mesh. When they come back up and do a DHCP request, the Pi-hole will answer and give them the address of the original router for DNS. Everything else on the network, including devices attached to the nodes, will continue to use Pi-hole for DNS.

Check results

Observe the graph and Query Log and you will see the nodes are no longer flooding them with queries, as these are now going to the router's DNS to deal with. You can see that at the end of the above graph. Here's an image of it hours later looking much better. Once the busy part of the graph has scrolled off the left side the graph scale will adjust back to normal.

Any other Velop functions used prior to the change, such as Parental Control, will continue to work after the change.

Revert if ever needed

Log into the Pi-hole terminal and delete the config file

sudo rm /etc/dnsmasq.d/90-bypass.conf

Reboot the Pi-hole and once it's back up reboot the Velop nodes. They will revert to using Pi-hole for DNS.

[loopback]

Thanks
I have a Velop router with one node.
I had to use pi-hole for dhcp because my router would not work for client settings.
The one node did PTR constantly.
Pi-hole dns was not happy till I restarted the Velop mesh.
I hate the Velop but have too much invested to switch right now.
Thanks again for you help.

[chrislph]

Did this work for you?

[loopback]

Worked great.
I just want to add that my Velop node was moved near a computer with no wired or wifi connection and I use the nodes port for access.
That also works great. Moving the node does not seem to effect my wifi coverage. Win win.

[misha_thal]

Seems to be working so far! Thank you so much!

[marpstar]

This worked great for me, too. I'm new to pi-hole and Velop routers. I didn't even know I was looking for this, stumbled across it while looking for another Velop-related issue. I did have to reboot the router via the Linksys app to get things to take effect, but it's working wonderfully now. Thank you!

[Bucking_Horn]

Thank you for that detailed procedure.

Alllow me to note that I consider this not as a fix, but as a workaround, in a somewhat double sense of the word: It works around the immediate issue by working around Pi-hole, i.e. by-passing it.

It's a viable means to address the issue, so it's well worth applying.
But you should note that the Velops' DNS traffic won't be filtered by Pi-hole anymore.

Maybe you've checked out other options already, but if you'd be willing to continue to investigate a solution wihout by-passing Pi-hole:
Since there seems to be no way to control the behaviour on the Velop devices themselves, did you check for other options within Pi-hole that may potentially impact their behaviour?

If Pi-hole is allowing those PTRs, did yo try to adjust the TTL in order to afect the frequency of requests?
If Pi-hole is blocking them, did you try to switch from NULL-blocking to another blocking mode to see if this has an effect?

[chrislph]

@Bucking_Horn

I consider this not as a fix, but as a workaround

Indeed, I don't think it's possible to prevent the Velops from sending these requests, it appears to be part of how the mesh functions to detect clients across the area of coverage. Between them they send 100+ requests every 30 seconds, wiping everything off the Query Log.

@Bucking_Horn

It's a viable means to address the issue, so it's well worth applying.
But you should note that the Velops' DNS traffic won't be filtered by Pi-hole anymore.

That would include firmware update checks and possibly any analytics reporting, although in testing with my friend we reviewed the long-term data logs and couldn't find either. Some functionality is managed via their smartphone apps or web apps, so they may use client devices for those things and those would be covered by Pi-hole.

@Bucking_Horn

If Pi-hole is allowing those PTRs, did yo try to adjust the TTL in order to afect the frequency of requests?

No I wasn't aware that was possible, but it could explain the traffic volume. What is the default TTL for Pi-hole PTR responses? Is this updated using a dnsmasq config file? The PTR requests were not blocked.

Since these are now going to the original router's DNS, and the Velops continue to function for client discovery and client features, it's not clear to me if these PTR requests are being answered by the original router, since the Velops and clients can access both subnets.

ONT --> 'wan' Original router 192.168.0/24 'lan' --> 'wan' Velop parent node 192.168.1/24 'lan' --> Clients and Velop child nodes

This is in normal mode; they also support bridge mode sitting on the original subnet, at the expense of client functions such as parental control.

Additional observations – the Velops can replace an existing router and take over PPPoE directly. In that case there would be no original router's DNS to use in the process I posted. For people in that situation I was wondering whether the same workaround could be used but simply pointing the Velops to a dummy address.

This would mean they try and fail to send their PTR requests there, and have no external DNS of their own, but at least Pi-hole is kept clear of the noise. Then again they may become very unhappy. In that case perhaps an old router can be repurposed as a second LAN DNS server, just to act as a sink for the Velops.

If someone has Velops taking over PPPoE and wants to try this it would be interesting to know how they behave. [ Edit – post by @zetafish saying that blocking PTRs made his Velops "behave badly" ]

There's a feature request for the ability to ignore domains in the Query Log. It's very popular but it's clear from the dev posts that it's not straightforward. I'm just wondering if the approach I detailed in a reply there might be one way to achieve it? Or does Pi-hole 6 have this ability?

If this was available it would allow the Velops to continue to be filtered by Pi-hole without taking over the Query Log and making it unusable for normal ad-blocking diagnostics, but I appreciate the comments in that thread re the difficulties.

[Bucking_Horn]

@chrislph

What is the default TTL for Pi-hole PTR responses? Is this updated using a dnsmasq config file?

Since Pi-hole FTL v5.10.1, Web v5.7 and Core v5.5 released Sep 2021, the default TTL for DNS records directly served by Pi-hole is 0 seconds for allowed and 2 seconds for blocked DNS requests:
(Note: TTL for records procured via Conditional Forwarding would be controlled by the target machine.)

@DL6ER

Handle TTL for blocked queries separately
You can now set your own local-ttl value if you want to.
Note that this changes the default TTL for local hostnames from two seconds to “do not cache” (dnsmasq’s default). If you want to avoid this, create a file like /etc/dnsmasq.d/99-local-ttl.conf and add a line like local-ttl=60 for one minute TTL on local hostnames.

Assuming the Velops would honor that TTL for their PTR requests, that would at least allow you to control the frequency of those requests.

I also vaguely recall a report from a user who were able to tackle this by switching DHCP duty from their Velop to Pi-hole. But that's probably not applicable to your setup with Velops operating behind a router.

[chrislph]

@Bucking_Horn

Assuming the Velops would honor that TTL for their PTR requests, that would at least allow you to control the frequency of those requests.

Thanks for that, I'm curious to see how the Velops behave using this approach but they're currently working at my friend's place so we'll have to wait for an excuse. If anyone else with Velops sees this and can test, please do and report findings.

@Bucking_Horn

I also vaguely recall a report from a user who were able to tackle this by switching DHCP duty from their Velop to Pi-hole. But that's probably not applicable to your setup with Velops operating behind a router.

We are using Pi-hole's DHCP. All the clients are using Pi-hole's DHCP, including the Velop child nodes (the ones doing the PTRs). The Velop parent node (the one that routes upstream) has a static IP as the gateway on that subnet.

[misha_thal]

My router's DNS is not to good, so I used Quad9. Seems to work - but will that be a problem down the road?

[chrislph]

It's not clear why Velop child nodes create these requests. All the queries I've seen are for private addresses such as 90.1.168.192.in-addr.arpa and the DNS server replies with hostnames such as deskjet123c.lan.

When the DNS server is changed from the Pi-hole to the router, the router is now answering those queries instead. But in the tests I've done, since the router DNS isn't being used by anything, it doesn't know the hostnames and replies with NXDOMAIN. Despite this, the Velops seem to continue to function just fine.

If instead you send those queries externally to Quad9, Quad9 will similarly have no such records and will reply with NXDOMAIN.

I think as far as the Velops are concerned the result is the same – they get the same empty response whether its from the router or an external public DNS.

From a privacy point of view though it's not ideal. Private IP info is leaving your network to become external traffic, and it's arriving at Quad9 who could theoretically log the info, build a profile of your network addresses and so on. I imagine Google DNS would be doing something like that. I'd trust Quad9 much more than Google.

It may be possible to use a non-existent IP on the LAN for the DNS. This would still keep the queries away from Pi-hole but would also mean the Velops are sending hundreds of queries each which are all delaying for several seconds and timing out, instead of receiving an instant NXDOMAIN. I don't know how they might handle that or if that would cause any problems. If you're able to test this it would be interesting to find out. Do they keep working? Are hostnames still visible in the app for parental control and so on?

When you say your router's DNS is not too good, for the purposes of this workaround it simply needs to be available and to respond. If you are able to use it, that will keep the Velop's PTR queries on the local network and away from external services with their own privacy policies.

[misha_thal]

Thanks for the reply. I have setup a DNS Server on my Synology NAS - that seems to work just fine.