ANSWERED SOLVED - 10.4.0.1 DNS issue with WireGuard / OPNsense / NL servers

[TheHellSite 3]

Hi,
 

I am using AirVPN directly on an OPNsense firewall as a WireGuard gateway.

My setup is roughly as follows:

• OPNsense establishes the AirVPN WireGuard tunnel.

• The WireGuard endpoint is configured using: nl.vpn.airdns.org (213.152.161.137:1637)

• Selected VLANs / networks / hosts are policy-routed through the AirVPN gateway using OPNsense firewall rules.

• Other networks continue to use the normal WAN gateway.

• The client used for the tests below is an Arch Linux container.

• Client IP: 192.168.25.204

• Default gateway and DNS server of that client: 192.168.25.1
   

 

DNS setup

The VPN clients do not use the AirVPN DNS server directly as their configured DNS server. Instead, they use the OPNsense firewall as both their default gateway and DNS server.

On OPNsense I have a DNAT / port-forward rule which redirects DNS traffic from these VPN clients to the AirVPN DNS server. Depending on the configuration I am testing, the DNAT target is either 10.4.0.1 or 10.128.0.1.

The normal DNS flow is:

VPN client
192.168.25.204
    |
    | DNS query
    v
OPNsense
192.168.25.1
    |
    | DNAT
    v
AirVPN DNS
10.4.0.1 or 10.128.0.1
    |
    v
AirVPN WireGuard gateway

I originally used 10.4.0.1 as the AirVPN DNS server because it is documented as an AirVPN DNS resolver. Today I noticed that DNS queries are no longer answered when 10.4.0.1 is used as the DNAT target while the WireGuard tunnel is connected to nl.vpn.airdns.org.

The OPNsense firewall still passes the traffic correctly and the affected clients are otherwise routed through the AirVPN gateway normally. 10.128.0.1 works perfectly as both the DNAT target and AirVPN DNS server with the same nl.vpn.airdns.org setup. Also, when I switch the WireGuard endpoint to de.vpn.airdns.org and use 10.4.0.1 as the DNAT target, DNS works correctly again.

So the behaviour is currently:

WireGuard endpoint = nl.vpn.airdns.org (213.152.161.137:1637)
DNS DNAT target = 10.4.0.1
-> DNS queries time out

WireGuard endpoint = nl.vpn.airdns.org (213.152.161.137:1637)
DNS DNAT target = 10.128.0.1
-> DNS works perfectly

WireGuard endpoint = de.vpn.airdns.org
DNS DNAT target = 10.4.0.1
-> DNS works correctly

 

Additional tests

From the Arch Linux client, the route towards 10.4.0.1 is:

# ip route get 10.4.0.1
10.4.0.1 via 192.168.25.1 dev eth0 src 192.168.25.204 uid 0
    cache

When the DNS DNAT target is set to 10.4.0.1, a direct UDP query fails:

# dig @10.4.0.1 cloudflare.com

;; communications error to 10.4.0.1#53: timed out
;; communications error to 10.4.0.1#53: timed out
;; communications error to 10.4.0.1#53: timed out

; <<>> DiG 9.20.29 <<>> @10.4.0.1 cloudflare.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached

TCP fails as well:

# dig +tcp @10.4.0.1 cloudflare.com

;; Connection to 10.4.0.1#53(10.4.0.1) for cloudflare.com failed: timed out.
;; no servers could be reached

For comparison, when I change the OPNsense DNAT target to 10.128.0.1, DNS resolution works immediately.

I also tested:

# dig @10.4.0.1 cloudflare.com

while the DNAT target was 10.128.0.1, and received a successful response.
However, because the OPNsense DNAT rule redirects DNS traffic from these clients, I realize that this test may actually have been redirected to 10.128.0.1. Therefore I do not consider this proof that 10.4.0.1 itself was reachable in that test.
 

Questions

1. Is 10.4.0.1 still supposed to be reachable and usable as a DNS resolver from current AirVPN WireGuard connections?

2. Or is 10.128.0.1 now the recommended DNS server for WireGuard connections?

3. Is there currently any known issue with 10.4.0.1 when connected through Dutch servers / nl.vpn.airdns.org?

4. Since the exact same OPNsense DNAT setup works perfectly when using 10.128.0.1 as the target, I assume that the DNAT mechanism itself is working correctly. Is there any known reason why 10.4.0.1 specifically would behave differently as the DNAT target?

5. Is there any recommended OPNsense / pfSense configuration for forcing selected VPN clients to use AirVPN DNS while avoiding DNS leaks?

If useful, I can also provide:

• OPNsense WireGuard configuration

• firewall / policy-routing rules

• NAT / port-forward rules

• packet captures from the AirVPN interface

• wg show output

Thanks!

[Staff 10653]

Hello!

For AirVPN WireGuard connections, the IPv4 gateway and DNS server address is 10.128.0.1. WireGuard uses a single IPv4 subnet, and this address remains the same regardless of which AirVPN server you connect to.

Please keep 10.128.0.1 as your DNS DNAT target. 10.4.0.1 is an OpenVPN DNS address, and its availability through some WireGuard connections should not be relied upon. Your observation that it works through a German endpoint does not change the address to use with WireGuard. The reported difference alone does not establish a DNS outage on Dutch servers.

You are also right about the documentation: our Specs page describes 10.4.0.1 as reachable from any virtual subnet without explicitly restricting that statement to OpenVPN. That wording is misleading for WireGuard users, and we apologize for the confusion. We will assess the situation and either clarify the Specs page or make 10.4.0.1 consistently reachable for DNS queries through WireGuard on all servers (not recommended anyway, see below).

In any case, we recommend using the VPN gateway address as the DNS server address, as AirVPN supports this configuration, with both OpenVPN and WireGuard. We recommend using 10.128.0.1 for WireGuard DNS and ensuring that DNS traffic can only leave through the VPN tunnel. Route-injection attacks on hostile networks can otherwise divert DNS queries outside the tunnel, exposing the requested domain names and potentially enabling forged DNS replies. This class of attack can also affect WireGuard deployments, depending on the operating system’s routing and firewall configuration.

For your OPNsense setup, redirect the selected clients’ DNS traffic, both UDP and TCP port 53, to 10.128.0.1, ensuring that the redirected traffic is routed through the WireGuard tunnel. Firewall rules should prevent those clients from falling back to WAN when the VPN is unavailable. Port 53 redirection alone does not control applications using DNS over HTTPS or DNS over TLS.

Your interpretation of the successful dig @10.4.0.1 test with DNAT targeting 10.128.0.1 is correct: it does not demonstrate that 10.4.0.1 itself answered.

Kind regards
 

[TheHellSite 3]

Hi,
 

wow, thank you very much for the incredibly fast and detailed response! CASE CLOSED.
 

That clears things up completely. I will use 10.128.0.1 as the DNS server and DNAT target for my WireGuard setup from now on.

Also, thank you for acknowledging that the current Specs page is somewhat misleading regarding 10.4.0.1 and WireGuard. Looking forward to the updated documentation.

I also appreciate the additional explanation regarding DNS leak prevention and making sure DNS traffic cannot fall back to WAN. My OPNsense rules are already designed around that principle.

Overall very happy with the support and I'll happily renew for another three years when the Cyber Deal becomes available again. 🙂

Cheers!