I am asking if anyone has configured multiple ddns names in an endpoint (client) configuraiton with GL being the client device. I am only using wireguard as a client on my wireguard - server is hosted on a separate server. This is personal use, not commercial, so “hacks” to get this to work may be ok.
I have seen instances where some DNS providers block access to some DDNS names (likely valid except instead of blocking host.domain.com they just block the entire domain.com. The domain.com is shared amongst 100,000+ users wtih various host.domain.com entries. Since the domain.com I was using was blocked, wireguard clients using that DNS provider were resolving my host.domain.com as 0.0.0.0 preventing connections.
I am hoping to be able to use multiple ddns providers to decrease the risk of dropped connections. If the first Peer endpoint entry cannot connect, automatically try another (new Peer section?) with the same configuration and just a different endpoint defined?
Also, alternatively, separate wireguard client configs would work, too, if I can get a failed connection to try the second client config automatically if a connection cannot be established.
I am running 4.7 code on the client devices currently, and am not in a hurry to get to 4.8 if this can work in 4.7.
I'm not sure if it is configurable but I think it should be possible.
It is just domain translation, so... aslong a domain can translated to an A record to your wgserver a different peer or client with this domain as endpoint should be possible, since that A record becomes just the ip endpoint after resolve.
I think most of it needs to be done on the domain side
What probably is not possible is the same peer with the same keys both on different domains, it will see it as a dupe connection I think and fail, you need to turn the other off.
What I am seeking though is multiple domains that resolve to the same public ip. That part is easy. The harder part is getting the client-side to try the second domain if the first is not responding correctly. VPN policy in 4.8 code might address this, and I might be able to push that down to 4.7 by adding vpn policy routing. Since I am not sure on that piece, I am hesitant to just start throwing packages on the device haphazardly.
And to be honest, having a totally second wireguard server instance for this is fine, too. That would be easy enough on the server side. But I still need to client to see server a is not connecting so I will try server b now.
Hmm you may be able to do this with mwan3 but I don't think it is compatible with gl software since they already have their own version, but it is not made for vpn.
also there might be complications to the policy routing since mwan3 also routes.
It is possible to create multiple client interfaces with the same private and public keys and also same virtual ip, only the peers need different keys in order for the wg client interfaces to be online (that is atleast what I think, it does work on vanilla OpenWrt but I expect it should work also on the gl software)
Then let mwan3 change the route based on mwan3 decisions.
I really don’t think the keys would be an issue either way as only 1 tunnel should be active at a time. This is the first time this has happened to me since I set up my ddns name, and it appears to be only one DNS provider that I have seen that is blocklisting the domain name itself. I may be chasing a ghost here. For my RV it isn’t a problem to lose the VPN really, but for my daughter it was a bigger deal. Streaming quit working when the wireguard tunnel went down, which might as well be the world burning to her lol.
I believe the crux of the issue lies in why some DNS providers hijack or return incorrect DNS resolution results.
Switching to encrypted DNS or a trusted DNS provider might be a simpler and more convenient solution. DNS - GL.iNet Router Docs 4
@will.qiu I cannot control what the providers do, I just have to find a way to work around it. What is your proposal here? That I send the dns provider a strongly worded email so they quit blocking the domain? Encryption doesn’t help with this, it is already a DoH provider. If you query any host on ignorelist.com using the ControlD service with ad blocking enabled you will get back a 0.0.0.0 response. Do the same query on Quad9, it will likely work fine. The issue is that ControlD blocked the entire group (over 100,000 accounts on FreeDNS use that domain for ddns) instead of just blocking the offending subdomain.ignorelist.com members. I happened to be using ControlD on the devices that got blocked, so the wireguard connection would not work as the clients tried to connect to 0.0.0.0.
What is the solution that I can do to avoid this? Quit using filtered DNS? Yes, I can and did quit using ControlD to resolve DNS on those clients - but what happens if the provider I switched to does the same thing? The reason I was using that provider was to block malware and ads. For now I have given up on blocking ads and am using just the malware list.
I am not willing to set up another pihole for my daughter. I do have one in my RV, though. But unless I have full control over DNS routing, such that I can point mysub.ignorelist.com to a different provider that will never filter ignorelist.com, I am always at someone else’s mercy.
None of this is the fault of GL or the equipment, it is mostly overzealous blocking at ControlD. But the process to flag a domain for review is only available to paying customers. I will be darned if I am going to pay them a fee to complain they are doing something dumb.
tl/dr - I don’t see how anything you posted will help @will.qiu
I am going to go another route. I will use dns forwarding to send myhost.ignorelist.com to a non-filtering dns server for resolution and all others to go to the filtered doh provider. Just need to get to remote sites for testing. I can leave my wireguard alone this way and should be easier.
On the flint2, it is easy enough to add to the forwarding list in the LuCi gui. However, the X3000 doesn’t appear to show forwarder configuration in LuCi on 4.7.4. So I will have to do some playing with that to make sure I get the uci commands proper. Any help on this @will.qiu ?
It’s quite unlikely that a core internet service like DNS would suffer widespread resolution errors for a single domain name.
That’s why we previously suggested switching to a more reliable DNS provider.
However, if the issue involves a DNS provider that includes filtering functionality and an incorrect filter list, your concern makes sense.
Yes, using DNS forwarding would be a simpler and more useful solution.
We’ve checked — the X3000 (v4.7.4) firmware still supports DNS forwarding:
Also, your command looks correct, though there’s a small typo — the ’ after 8.8.8.8 should be '.
The order doesn’t matter.
Alternatively, based on your initial idea, you can modify /lib/netifd/proto/wgclient.sh for 4.7.x version to check the DDNS list before enabling the interface and automatically replace the endpoint with the correct address.
No offense @will.qiu but you are missing something. They offer a service to filter malware and adservers out via DNS (like pihole can). They marked the ddns domain I was using as an adserver, thus none of their clients could resolve any hosts on *.ignorelist.com. It was not an outage and not due to their lack of reliability. They made a bad decision that affected me. I am just trying to prevent that exact thing from happening again.
Onward - I have no idea how I overlooked that as it is the same in other routers. All I can say is I must have been staring at it too long lol. I set that and it appropriately routed the request. Without the forward, it resolves the host as 0.0.0.0. Once I enter the forward in there it resolves to the proper ip.
tl/dr - I think this will solve my problem. I simply forwarded the request for myhost.ignorelist.com to 8.8.8.8 for resolution.
Turns out there are a few ways to do this. Those mentioned above, but also dnscrypt-proxy2 has a directive forwarding_rules that can be used in the dnscrypt-proxy.toml config where you can route DNS requests directly within dnscrypt-proxy2. I have tested this on a flint3, flint2, slate ax, and beryl ax so far and all work properly so far.
