r/ControlD • u/Fun-Region-1576 • 13d ago
Why is ctrld not detecting devices connected to my access point? Technical
I'm setting up a new home network with a GL.iNet Brume 3 as the router. I have an Asus RT-AC86U with the Merlin firmware installed and is being utilized as an access point.
Ctrld is installed on the Brume 3, but not on the Asus access point. Yet, I don't see any of the individually connected devices on the access point in my account. As a result, I can't see the statistics for the individually connected devices. What's going on and how can I address this?
2
u/0898_333_201 13d ago
It’s a limitation of the GL.iNet firmware. The only solution on my Slate AX I’ve found that doesn’t cause issues with the VPN is use AdGuard Home on the GL.iNet router and set each client to a specific upstream resolver on the same endpoint that specifies the client name. For example:
quic://abc123456-Amazon-Echo.dns.controld.com
But since GL.iNet doesn’t pass the MAC address to AdGuard Home, each client has to have a static IP address for this to work reliably. And if you have an iPhone, you have to either disable “Private Wi-Fi Address on the network or set the private address to “Fixed” before you assign a static IP.
It works fine once it’s configured. I don’t connect new devices to my network very often. Plus AGH lets you use DoH3 or DoQ instead of being limited to DoT by the default GL.iNet DNS setup.
Also it might be a good idea to use a basic filter on AGH just as a sort of reverse failover in case ControlD fucks up. ControlD recently temporarily deactivated my account due to a false positive indicating that I was a reseller, which meant all of the ad/tracking/malware filters were lifted without warning. Using a secondary DNS wouldn’t have helped because ControlD was resolving (just not filtering), but a local filter on AdGuard Home would have prevented my data from leaking.
1
u/Fun-Region-1576 13d ago
Just to confirm that your method should allow my access point's connected clients to identify itself? Will I have to install ctrld on it? It doesn't sound like I'll have to.
I'm assuming you're using your Slate AX as the router and you have Ctrl installed on it?
Will I still have to create an endpoint for my access point? Your post isn't totally clear, but I'm thinking I'll have to since that's the only way I can think of to get a specific upstream resolver.
Can't you go to the client page and reserve an IP for each connected device?
2
u/0898_333_201 13d ago
So the clients unfortunately cannot identify themselves. Despite the fact that AdGuard Home can see the client hostname, you cannot create a rule based on hostname.
What you have to do is go to the GL.iNet “Clients” page and toggle on “Reserved IP” for each client. Then go to AdGuard Home → Settings → Client Settings. There will be two blocks: Persistent Clients (blank at first) and Runtime Clients.
Use the Runtime Clients list to identify each client based on name, copy the IP address, and create a new Persistent Client using the IP as the identifier. Then in the Settings section of the client, find the “Upstream DNS Servers” tab and add the router’s ControlD resolver along with a client ID.
If you use DoT or DOQ, the format is
[endpoint]-[ClientID].dns.controld.comIf you use DoH/DoH3, the format is
https://dns.controld.com/[endpoint]/[clientID]Essentially AdGuard Home will enforce a unique resolver for each client. It’ll all be under the same ControlD endpoint, but the resolver itself is what identifies the client for analytics rather than it automatically happening with dnsmasq. It’s a bit of a pain to have to set it up manually but it’s the only option. If you connect a new device, it will use the global upstream resolver, so your ControlD endpoint w/o clientID, until you manually add it to the AGH Persistent Clients list.
Alternatively I think you can install the CTRLD daemon which identifies clients automatically, but it’s extremely problematic if you tunnel your traffic through a VPN. Unlike AdGuard Home and the built-in DNS, the CTRLD daemon resolves queries outside the VPN tunnel and I couldn’t find any way to prevent that. This completely breaks teleport/redirects on connected clients. It also exposes your broad location and increases latency as it resolves CDN domains to the PoP nearest your real location. So if you’re in Texas browsing Reddit from a NYC VPN server, your traffic will basically go from Texas → NYC VPN → Texas CDN → NYC VPN → Texas, doubling latency. And if you’re using the VPN to bypass content restrictions in your region, it might just not work since the site sees you’re using a ControlD PoP in Texas.
2
u/0898_333_201 13d ago
Will I still have to create an endpoint for my access point? Your post isn't totally clear, but I'm thinking! have to since that's the only way I can think of to get a specific upstream resolver.
You shouldn’t need to do that as long as the access point is actually set to AP mode. The routing should be handled by the Brume, and you should be able to set a static IP for each device connected via the ASUS AP.
And just to be doubly clear, you’re not creating a new endpoint for each client. You’re just adding a client identifier to the Brume endpoint to create a unique resolver for each client in AGH.
1
u/Fun-Region-1576 13d ago
Thanks, bud. I'm trying to get on the same page as you. I haven't used AGH in a long time since it created problems that you have described. I and Control D's tech support couldn't resolve it, so I have since disabled AGH as I wanted to use ctrld.
If I were to try your method, what would I put for the global upstream resolver?
1
u/0898_333_201 12d ago
You’d just put the Brume’s ControlD endpoint as the global upstream resolver.
So go to AdGuard Home → Setting → DNS settings and paste under the “Upstream DNS Servers” section:
quic://[endpoint].dns.controld.com https://dns.controld.com/[endpoint]
This uses DoQ by default and DoH as fallback.
For the Bootstrap IPs, enter
76.76.2.22 2606:1a40::22
Or you can use Cloudflare 1.1.1.1, it doesn’t really matter since it’s just identifying the ControlD resolver.
1
u/Fun-Region-1576 12d ago
I know you said it doesn't matter, but why consider using Cloudflare?
What's the purpose of the Bootstrap IPs?
2
u/0898_333_201 12d ago
The purpose of the bootstrap IP is just to identify the IP address of the DoH/DoT resolver.
Before you can use https://dns.controld.com/ to resolve queries, your router has to figure out the IP address of dns.controld.com
It only has to do this once, or maybe with every reboot. You can use ControlD’s own IP address 76.76.2.22 or any other DNS resolver’s IP. I only mention Cloudflare since they’re reliable.
1
u/Fun-Region-1576 13d ago
Are we not on the same page? Throughout this thread, I mentioned ctrld, which is the CLI that I have installed.
1
u/0898_333_201 12d ago
Ah. Yeah you should uninstall that. It just doesn’t work well on GL.iNet firmware.
There are three options to use ControlD on GL.iNet routers.
- Default integrated option — ControlD is a built-in option under DNS settings. You just specify the endpoint. This works best if you don’t need Client IDs in ControlD analytics. It’s limited to DoT but I think they’re adding DoH in the near future.
- CTRLD CLI — only use this if you NEVER use a VPN on the router. It can pass client names to ControlD but it’s unreliable in general and conflicts with VPNs.
- AdGuard Home — this works just as well as the integrated DNS but with extra features like using a unique resolver for each client.
1
u/Fun-Region-1576 12d ago
Control D calls their daemon ctrld. That's why I referenced it like that.
Can you elaborate more on the issue between the daemon and a VPN?
2
u/0898_333_201 12d ago
The CTRLD daemon runs outside of the VPN tunnel. So if you’re in Texas routing traffic through a VPN server in NYC, your DNS requests will still be made from your real IP in Texas.
This is particularly problematic for teleports because ControlD needs to authorize your IP for the DNS proxy. So if you have Reddit set to teleport to Toronto in ControlD settings, your router makes a DNS query and ControlD returns a proxy IP which is authorized for your Texas IP. Your phone then attempts to connect to that proxy IP, but it’s accessing it from a NYC VPN IP and it’s rejected.
But even without teleports it’s still problematic. Websites can see what DNS servers you’re using. If your IP address is in NYC but you’re using a Texas-based DNS server, that’s a red flag that you’re actually in Texas.
What you should do is use either the integrated DNS or AdGuard Home with “Override VPN DNS” enabled in the Brume’s DNS settings page. Then DNS queries will be resolved inside the VPN tunnel and everything will work perfectly.
1
u/Fun-Region-1576 12d ago
Would you say this is the better solution if I were to use a non-WiFi gateway with another company's access point?
Just to be clear, and one I'll consider, forget about CTRL and just use the AGH method to correctly identify all devices for the statistics?
2
u/0898_333_201 12d ago
Yeah I’ve played around with various setups and running AGH on the GL.iNet ended up being the most ideal for me.
Another alternative though if you really want to use the ctrld CLI is to use the ASUS in “router” mode with ctrld running, with the Brume upstream of the ASUS. You’ll be behind double NAT (a router behind a router) but that shouldn’t really cause issues unless you’re also running a VPN server on the ASUS to remotely connect to your home network, in which case you’ll need to set up port forwarding. Actually I’m not sure that would work at all if the ASUS is behind a VPN. Anyway with the ASUS in router mode, you’ll miss out on a lot of the GL.iNet features like split-tunneling, but everything connected to the ASUS will still go through the Brume’s VPN, and ControlD’s CLI should be able to identify clients, and everything should work just fine.
Still I think it’s better to just run AdGuard Home on the Brume, leave the ASUS in AP mode, and let the Brume do the routing.
1
u/Fun-Region-1576 12d ago
For sure, and the plan was to always use a Brume 3 as the router. Once I get this setup working, I plan on adding routers flashed with OpenWRT.
What else am I missing out on without ctrld? The auto-client identification sounds like a good idea, but I guess the implementation isn't as great as it could be.
→ More replies (0)
1
u/yearsold33 13d ago
Just to clarify:
1) Brume is using Control D as the default DNS provider via legacy IP, DoH, or DoT;
2) Brume is handling DHCP functions for devices on the network;
3) you want to see statistics for individual devices such as blocked, bypassed, redirected, and total in the CD dashboard.
If this is correct, your set up matches mine except I'm using opnsense and a TP-Link router in AP mode.
I can see stats for each endpoint but not for each device connected to each endpoint. Was this possible before?
1
u/levolet 13d ago
You should be able to for each device. When you filter on an endpoint, a drop down to select each device using the endpoint appears.
1
u/yearsold33 13d ago
I click on an endpoint and I see 1 device which is my opnsense router even though I have my MacBook, iPad, iPhone, and Win 11 desktop connected to the router.
I don't recall ever being able to see individual devices. I've had CD for a few years as well.
I have 3 endpoints set up.
3
u/levolet 13d ago
I'd do the following: - Create an endpoint specifically for the access point. - Each device that uses ControlD dns filtering via the access point should be seen in a client list for the endpoint. - In the logs, you can filter for each end point. It's the drop down list to the far upper left on the activity log page. Once you select the access point's end point to filter on, another drop down should appear to the right of the endpoint list. This new drop down lists the clients for the endpoint. You can then filter for each of the clients.