I’ve followed this guide and successfully set up a tunnel between my Mac and my Fly org’s network.
I can verify it works, since the following shows me the apps within my org:
dig +short txt @fdaa:x:xxxx::3 _apps.internal
However, when I don’t specify the DNS server explicitly, I do not get a list of my apps (instead, I get a NXDOMAIN answer):
dig +short txt _apps.internal
This seems to indicate that my Mac isn’t actually using the Fly DNS server set up by Wireguard.
I did some additional investigation, and can verify that the DNS is getting set up by Wireguard, because I can see it under System Settings → Wi-Fi → Details… → DNS. The DNS server is indeed there.
Does anyone have any idea how I can get MacOS to use the configured DNS server? One thing I found was Kurt’s answer here, about restarting my terminal before DNS will work. This unfortunately did not work for me.
Hey! Can you try running dig without +short to see what DNS server dig uses. I had a similar issue when I had both the 6PN wireguard and tailscale active, and my system was prioritizing tailscale’s DNS.
That is… really interesting. You mentioned 6pn wireguard not playing well with Tailscale, but I’m not using Tailscale on my current computer. Wondering if it could it be a VPN app I’ve previously installed, even if it’s not running…
I started having issues on MacOS with WireGuard today, yesterday fly deploy was working fine. Today fly doctor tells me:
Pinging WireGuard gateway (give us a sec)... FAILED
(Error: ping gateway: no response from gateway received)
We can't establish connectivity with WireGuard for your personal organization.
WireGuard runs on 51820/udp, which your local network may block.
If this is the first time you've ever used 'flyctl' on this machine, you
can try running 'flyctl doctor' again.
If this was working before, you can ask 'flyctl' to create a new peer for
you by running 'flyctl wireguard reset'.
If your network might be blocking UDP, you can run 'flyctl wireguard websockets enable',
followed by 'flyctl agent restart', and we'll run WireGuard over HTTPS.
None of the commands in the error message help my case.
@josepablov , I believe the issue you’re experiencing is different from the one I have. In my case, my system is simply not picking up on my DNS configuration, so this is an issue with my machine. In your case, you’re experiencing an issue with the Fly builder.
I was playing with this yesterday and checking the generated resolv.conf file in different scenarios. If tailscale and wireguard are both active, then the resolver was trailscale. If I quit tailscale (via the app), then it would use wireguard. And if I quit both it was my local 192.168.1.1.
Do you see more than just wireguard and the other usual/local resolvers when you run scutil --dns?
Overall though, this seems to be a common issue on MacOS unfortunately. I noticed that tailscale stays active in System settings > Network > VPN, even though I turn it off from the app, so that’s another place to check.
So I actually don’t use Tailscale on this current machine, but I was asking in case I could apply the same method to get it working on my computer.
When I run scutil --dns, I only see the usual resolvers. I could paste the output here if that’s helpful, but I think it’s entirely standard (192.168.1.1 as #1, then local, then 5 arpa resolvers; and for scoped queries, it’s just 192.168.1.1).
For context, I’m also starting up my wireguard connection with sudo wg-quick up <config>, where config is the file that fly wireguard create created. I’m not running any VPNs actively, I don’t have Private Relay on; idk what else could be interfering with my DNS.
And Wireguard is clearly adding the Fly DNS here (under wifi settings):
Sorry I can’t help further with this, I’m stuck! Hopefully someone has gone through this and can help.
The weird thing is, and maybe it’s because I’m using the wireguard app and not the cli, the wireguard DNS server never shows up in my Wi Fi DNS settings, even when it’s working (i.e. when I don’t need to include the @IP in the dig command).
Omg, the Wireguard GUI works but not wg-quick. I noticed that the Wireguard GUI actually installs a VPN profile when adding the tunnel, whereas wg-quick doesn’t, so I guess that MacOS will prioritize DNS settings when they are specified in a VPN profile, but not via whatever wg-quick does.
I hate to rely on a GUI that is distributed via the mac app store, but this solves my problem. Thanks a ton Andie!
That’s so awful. Well glad I’m on this end of the “works for me” this time! Thanks again for the help.
For posterity / if this helps anyone, this is the output of scutil --dns now that the Wireguard GUI has successfully updated my DNS config via VPN profile:
DNS configuration
resolver #1
nameserver[0] : fdaa:x:xxxx::3
if_index : 30 (utun8)
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 102800
resolver #2
nameserver[0] : 192.168.1.1
if_index : 15 (en0)
flags : Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
order : 200000
<resolver #3 through resolver #8>
...
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 192.168.1.1
if_index : 15 (en0)
flags : Scoped, Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
nameserver[0] : fdaa:x:xxxx::3
if_index : 30 (utun8)
flags : Scoped, Request AAAA records
reach : 0x00000002 (Reachable)
