Wireguard parser bug

I set up wireguard server on my home router. My home provider assigns dynamic IP addresses and allocates domain name for the ip-address in a format: 1234567890.cl.a-n-t.ru. I am using this domain name in the configuration of wireguard clients as an end point name of the server. It looks like wireguard parser of the config on openwrt could not process this name in a proper way and connection can't be established.
Here are some logs:

Sun Mar 12 23:11:39 2023 daemon.notice netifd: vpn (10420): Try again: `1234567890.cl.a-n-t.ru:51820'. Trying again in 12.84 seconds...
Sun Mar 12 23:11:57 2023 daemon.notice netifd: vpn (10420): Try again: `1234567890.cl.a-n-t.ru:51820'
Sun Mar 12 23:11:57 2023 daemon.notice netifd: vpn (10420): Configuration parsing error
Sun Mar 12 23:12:02 2023 daemon.notice netifd: Interface 'vpn' is now down
Sun Mar 12 23:12:02 2023 daemon.notice netifd: Interface 'vpn' is setting up now
Sun Mar 12 23:12:07 2023 daemon.notice netifd: vpn (11204): Try again: `1234567890.cl.a-n-t.ru:51820'. Trying again in 1.00 seconds...
Sun Mar 12 23:12:13 2023 daemon.notice netifd: vpn (11204): Try again: `1234567890.cl.a-n-t.ru:51820'. Trying again in 1.20 seconds...
Sun Mar 12 23:12:19 2023 daemon.notice netifd: vpn (11204): Try again: `1234567890.cl.a-n-t.ru:51820'. Trying again in 1.44 seconds...
root@OpenWrt:~# pgrep -f -a wg; wg show; wg showconf vpn
11216 wg-crypt-vpn
11225 /usr/bin/wg setconf vpn /tmp/wireguard/vpn
interface: vpn
[Interface]

root@OpenWrt:~# cat /tmp/wireguard/vpn
[Interface]
PrivateKey=xxxxxxxxx
[Peer]
PublicKey=xxxxxx
AllowedIPs=192.168.0.0/20
Endpoint=1234567890.cl.a-n-t.ru:51820
PersistentKeepalive=25

When I replace domain name with IP address, the connection establishes successfully. I am using OpenWrt 22.03.3 on both end points. It is interesting that the same config with the domain name works perfectly on andriod device. However it doesn't work in Wireguard Pro on Windows 10! If I replace domain name with Ip adress in Windows config, connection establishes as well.

Any ideas what to do?

Are you able to look up the domain name using nslookup in the terminal or the web interface? Because the wg tool apparently fails to do that.

Good point. Here is ping from the web interface:
ping_web
Here is CLI output:
ping_cli

Try creating a CNAME and see if it helps.
Go to any free DDNS provider and create a sub-domain there, then create a new CNAME record in this domain pointing to your current name. It should be something like
myhost.ddnsdomain.tld CNAME 2000XXXXXX.cl.a-n-t.ru.
Then use this new name in your configuration. Make the name ('myhost') as simple as possible, e.g. use just letters.

Yes, this was my first idea. I don't really like it, because my provider changes my IP less than once every 30 days. In such case free DDNS providers send email to manually confirm the record. If it is not confirmed, it will be deleted. Most probably, I will make a CNAME record in the end.

Here is an interesting capture. Looks like nslookup error relates to AAAA record, which I don't need at all:

22:44:32.635218 IP 100.69.39.46.37769 > 8.8.8.8.53: 60714+ A? 200*******.cl.a-n-t.ru. (40)
22:44:32.635250 IP 100.69.39.46.37769 > 8.8.8.8.53: 60714+ A? 200*******.cl.a-n-t.ru. (40)
22:44:32.635439 IP 100.69.39.46.37769 > 8.8.8.8.53: 61227+ AAAA? 200*******.cl.a-n-t.ru. (40)
22:44:32.635447 IP 100.69.39.46.37769 > 8.8.8.8.53: 61227+ AAAA? 200*******.cl.a-n-t.ru. (40)
22:44:32.671451 IP 8.8.8.8.53 > 100.69.39.46.37769: 60714 1/0/0 A 217.117.252.153 (56)
22:44:32.691450 IP 8.8.8.8.53 > 100.69.39.46.37769: 61227 ServFail 0/0/0 (40)
22:44:32.691545 IP 100.69.39.46.37769 > 8.8.8.8.53: 61227+ AAAA? 200*******.cl.a-n-t.ru. (40)
22:44:32.691553 IP 100.69.39.46.37769 > 8.8.8.8.53: 61227+ AAAA? 200*******.cl.a-n-t.ru. (40)
22:44:32.746331 IP 8.8.8.8.53 > 100.69.39.46.37769: 61227 ServFail 0/0/0 (40)

Some providers will consider your subdomain alive as soon as they keep receiving queries for it, so there is no need to update the record(s).
AAAA errors are normal.
Feel free to PM me your full domain if you want to run a quick test, I have a subdomain ready for the exercises )

Strange thing. When I do ping explicity with Ipv4, there are replies:

root@OpenWrt:~# ping  200*******.cl.a-n-t.ru
ping: bad address '200*******.cl.a-n-t.ru'
root@OpenWrt:~# ping -4 200*******.cl.a-n-t.ru
PING 200*******.cl.a-n-t.ru (217.117.252.153): 56 data bytes
64 bytes from 217.117.252.153: seq=0 ttl=59 time=5.215 ms
64 bytes from 217.117.252.153: seq=1 ttl=59 time=5.063 ms

So, is my problem related to DNS resolver or wireguard parser?

If you think the issue is related to the AAAA failure, you can try setting "Filter IPv6 AAAA records" in DNS server - Advanced settings.

Andrew, thank you so much!
I am using dnsmasq, which doesn't have filter of AAAA records. I followed this workaroung: https://community.ui.com/questions/dnsmasq-remove-IPv6-DNS-AAAA-results-for-a-domain/4cf3ff95-9ae8-4d23-a066-f8dbf356e601
I added in /etc/config/dhcp:

config domain
        option name '200*******.cl.a-n-t.ru'
        option ip '::'

Now ping works and wireguard establishes connection!

root@OpenWrt:~# ping 200*******.cl.a-n-t.ru
PING 200*******.cl.a-n-t.ru (217.117.252.153): 56 data bytes
64 bytes from 217.117.252.153: seq=0 ttl=59 time=3.063 ms
64 bytes from 217.117.252.153: seq=1 ttl=59 time=2.991 ms
root@OpenWrt:~# wg show
interface: VPN2
  public key: (hidden)
  private key: (hidden)
  listening port: 55562

peer: (hidden)
  preshared key: (hidden)
  endpoint: 217.117.252.153:51820
  allowed ips: 192.168.1.16/32
  latest handshake: 2 minutes, 31 seconds ago
  transfer: 972 B received, 1.32 KiB sent
  persistent keepalive: every 25 seconds

It does. At least I have it in DHCP and DNS - Advanced Settings.
The same in the shell: uci set dhcp.{instance}.filter_aaaa='1'

Which Openwrt version are you using?
I don't have such:

root@OpenWrt:~# uci get dhcp.lan.filter_aaaa
uci: Entry not found
root@OpenWrt:~# uci get dhcp.@dnsmasq[0].filter_aaaa
uci: Entry not found

Ah, OK, I'm running a Snapshot on the device that I used to check.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.