Changed hardware now wireguard interface does not work when phone is on 5G

I upgraded my router/firewall and migrated settings to the new one. I cannot figure out why the wireguard interface (copy/pasted from old unit) only accepts connections when the phone connecting to it is on a WiFi network (tested on several remote networks). The phones simply cannot connect it is on my cellular 5G or LTE (tested with 2 different phones). When I try (wireguard for iOS), I see this error on the phones:

DNS resolution failure
One of more endpoint domains could not be resolved.

The timing of this breakage is too coincidental to when I switched OpenWRT routers. I do not believe anything on the phones is to blame. Any thoughts?

/etc/config/network
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd1d:692b:58dc::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'
	option ipv6 '0'

config bridge-vlan
	option device 'br-lan'
	option vlan '3'
	list ports 'eth0:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '4'
	list ports 'eth0:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '5'
	list ports 'eth0:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'eth0:t'

config device
  option type 'bridge'
  option name 'lxcbr0'
  option ipv6 '0'
  option bridge_empty '1'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

config interface 'guest'
	option device 'br-lan.3'
	option proto 'static'
	option ipaddr '10.9.7.1'
	option netmask '255.255.255.0'

config interface 'homeoffice'
	option device 'br-lan.4'
	option proto 'static'
	option ipaddr '10.9.6.1'
	option netmask '255.255.255.0'
	list dns '1.1.1.1'
	list dns '1.0.0.1'

config interface 'iot'
	option device 'br-lan.5'
	option proto 'static'
	option ipaddr '10.9.5.1'
	option netmask '255.255.255.0'

config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr '10.9.8.1'
	option netmask '255.255.255.0'

config interface 'lxc'
	option device 'lxcbr0'
	option proto 'static'
	option ipaddr '10.0.4.1'
	option netmask '255.255.255.0'

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '44500'
	list addresses '10.200.200.200/24'
	option private_key 'xxx'
	option delegate '0'

config wireguard_wg0
	option description 'phone1'
	list allowed_ips '10.200.200.201/32'
	option route_allowed_ips '1'
	option public_key 'xxx'
	option preshared_key 'xxx'

config wireguard_wg0
	option description 'phone2'
	list allowed_ips '10.200.200.202/32'
	option route_allowed_ips '1'
	option public_key 'xxx'
	option preshared_key 'xxx'

config wireguard_wg0
	option description 'laptop'
	list allowed_ips '10.200.200.203/32'
	option route_allowed_ips '1'
	option public_key 'xxx'
	option preshared_key 'xxx'

config wireguard_wg0
	option description 'ipad'
	list allowed_ips '10.200.200.204/32'
	option route_allowed_ips '1'
	option public_key 'xxx'
	option preshared_key 'xxx'

I can post my entire /etc/config/firewall but for now I just posted the parts that apply to wg0:

config zone
  option name 'wg0'
  option input 'REJECT'
  option output 'ACCEPT'
  option forward 'REJECT'
  list network 'wg0'

config rule 'wg'
  option name 'allow-wireguard'
  option proto 'udp'
  option target 'ACCEPT'
  option src 'wan'
  option dest_port '44500'
  option family 'ipv4'

config forwarding
  option src 'wg0'
  option dest 'iot'

config forwarding
  option src 'wg0'
  option dest 'wan'

config rule
  option src 'wg0'
  option target 'ACCEPT'
  option name 'wg dhcp and dns'
  list proto 'tcp'
  list proto 'udp'
  option dest_port '53 67 68'

config rule
  option src 'wg0'
  option dest 'iot'
  option dest_port '80 554 9000'
  option target 'ACCEPT'
  option name 'wg camera access'

config rule
  list proto 'udp'
  option src 'wg0'
  option dest 'lxc'
  option dest_port '53'
  option target 'ACCEPT'
  option name 'pi-hole-dns guest to wg'

That's the cause of your problem. Or, rather, a symptom of the cause.

What DNS servers do the phones try to use when on mobile data? Are those DNS servers reachable when on mobile data, before enabling the VPN? Does the endpoint FQDN in the WireGuard client tunnel configuration exist on those same DNS servers?

I should know this but I don't... where can I find the DNS server the phone is using (latest iOS)?

I should note that as I test, I removed the FQDN from Endpoint = my.freedns.name.com:44500 and replaced it with my external numerical IP Endpoint = a.b.c.d:44500 ... the phone appeared to connect, but I did not see it on the router/firewall by running wg from the shell.

You know what? I have no idea. It might be somewhere blindingly obvious, but I can't find it on my iPhone either.

However, the app Network Analyzer [sic] by Techet (developer) does show the IPv4 and IPv6 (if configured) resolvers.

When you swapped out the hardware, did your external IP address change? Are you on a dynamic IP? If so, then what's the TTL of your DDNS record? You might find that once the TTL expires everything "magically" starts working.

Yes, the IP address did change. I made sure to update the record. If I use a tool like ‘dig my.ddns.com’ the correct external IP comes up.

The fact that it does not connect when I use the pure numeric IP is a red flag to me. I do not get an error message on the phone. It behaves as though it’s connected. But like I said above, there is no evidence on the OW device that a client has connected.

Does wg indicate a handshake at all?

Check if you have the same IP on the wan interface as the one in the icanhazip.com
There is a chance they moved you to CGNAT with the new router.

The ip pulled back from that website matches what my.ddns.com resolves to… so odd

Is it the same with the one that gets returned with this?
. /lib/functions/network.sh; network_get_ipaddr IP_WAN wan; echo $IP_WAN

Yes, that output matches https://whatismyipaddress.com which also matches what my.ddns.com resolves to... it seems like the problem is on the iOS devices but they works fine hours before I swapped the router/firewall so I feel like it has to be something on there rather than the phones.

Confirm that the client can reach the server:

tcpdump -evni any udp port 44500
1 Like

I think you need to specify a DNS server in the wg config for your iOS client.
That is specific for Apple

Under [Interface]
Add
DNS = 9.9.9.9

@egc - I have one in there. Still no luck. Only connects if the phone is on WiFi; cannot connect over cellular.

[Interface]
Address = 10.200.200.201/32
PrivateKey = xxx
DNS = 1.1.1.1

[Peer]
PublicKey = xxx
PresharedKey = xxx
Endpoint = my.ddns.com:44500
AllowedIPs = 0.0.0.0/0

@vgaetera - I can run tcpdump but when I look at the output of wg on the router/firewall, I see that the latest handshake: is a long time ago. I get nothing from:

# tcpdump -i wg0

@vgaetera - I see you edited your post.

If I am on cellular and I try to connect, I get that DNS error on the phone and nothing in

tcpdump -evni any udp port 44500

If I change the Endpoint = on the phone's profile hardcoding the IPv4 address, I get the same (nothing in tcpdump).

If I connect to WiFi and then connect with either profile tcpdump goes nuts outputting tons of lines and wg shows a current handshake.

Restart the client device and try using a different DNS on the client.
Temporarily replace the domain name with the current IP to test the VPN config.
Keep monitoring tcpdump to identify incoming upstream connections.

OK so I rebooted the phone. I found isc dig in the app store. When I disconnect from wifi and use cellular, and run my.ddns.com in that app, I do not get an answer section at all. If I use another website like google.com I do get an answer section.

I think this is pointing at my cellular provider's DNS or the DDNS provider....

1 Like

Try doing a dig of your DDNS hostname... from a computer inside your LAN... pointing dig at your cellular provider's DNS.

Depending on the TTL of the DDNS record, different resolvers may take some time to update their own caches. You might find that one resolver gives you the right answer where another one does not.

Alternately, something entirely different might be going on.

OK! The issue is with the free subdomain I have been using on freedns.afraid.org ... I registered for a new one and that is working as expected. Note that I also use this subdomain to access friend's/family's systems remotely and they too are not working.

Summary - wild goose chase due to breakage occurring at the same time I changed my hardware out. As usual thank you all for the engagement. This is a fantastic community. Love you guys :love_you_gesture:

3 Likes

A while back I finally bit the bullet and started paying afraid.org for DDNS. It's a decent service, and isn't riddled with spam and advertising, so I figured it was worth some of my cash.

I really like the ability to update DDNS with a simple curl call to a unique URL. It's clever.

2 Likes