DNS Fails when VPN is active

Technical Support for Routers VPN, DNS, Leaks
1

Hello everyone. I'm running into a problem with my GL-AXT1800 running 4.7. I have it set up as a VPN client device connecting into an OpenVPN server in the cloud. When the VPN is disabled, I can resolve DNS with no issues. As soon as I enable OpenVPN client, DNS resolution fails on every device connected to the router. OpenVPN connects just fine and seems not to be the issue.

PS C:\Users\TheBRidg> nslookup` [`reddit.com`](http://reddit.com/)
Server: UnKnown`
Address:` [`192.168.8.1`](http://192.168.8.1/)
DNS request timed out.`
timeout was 2 seconds.`

Oddly, DNS works when I SSH directly into the router:

root@GL-AXT1800:/tmp# nslookup` [`reddit.com`](http://reddit.com/)

Server:` [`127.0.0.1`](http://127.0.0.1/)

Address:` [`127.0.0.1:53`](http://127.0.0.1:53/)

Non-authoritative answer:`

Name:` [`reddit.com`](http://reddit.com/)

Address:` [`151.101.129.140`](http://151.101.129.140/)

The VPN is working and routing correctly. I can ping 8.8.8.8 with the VPN enabled and can see that it's traversing my OpenVPN server and out into the Internet.

PS C:\Users\TheBRidg> ping` [`8.8.8.8`](http://8.8.8.8/)

Pinging` [`8.8.8.8`](http://8.8.8.8/) `with 32 bytes of data:`

Reply from 8.8.8.8: bytes=32 time=57ms TTL=54`

PS C:\Users\TheBRidg> tracert` [`8.8.8.8`](http://8.8.8.8/)

Tracing route to` [`8.8.8.8`](http://8.8.8.8/) `over a maximum of 30 hops`

1 <1 ms <1 ms <1 ms console.gl-inet.com [192.168.8.1]`

2 55 ms 53 ms 53 ms` [`192.168.254.1`](http://192.168.254.1/) `<-- OpenVPN Server`

I ran nmap from behind my router. When the VPN is off, 53 gets through. When it's on, 53 is blocked.

I have changed every combination of:

  • DNS Rebinding Attack Protection
  • Override DNS Settings of All Clients
  • Allow Custom DNS to Override VPN DNS

I have also changed every combination of:

  • Block Non-VPN Traffic
  • Allow Access WAN
  • Services from GL.iNet Use VPN

I have tried all combinations of DNS Server Setting Modes and can confirm that it's showing 8.8.8.8 and 8.8.9.9 as my primary DNS servers.

None of it seems to be working.

Near as I can tell, every time I turn on the VPN a new firewall rule appears redirecting port 53 to localhost 1653. A version of DNSMasq starts up running on 1653 on the router. I have enabled logging in /etc/dnsmasq.vpn and can see that it's receiving requests.

I feel like there's something going on when DNS gets redirected from 53 to 1653 and whatever version of DNSMasq is running there is broken. I'm smart enough to get this far (I think) but not smart enough to figure out why DNSMasq isn't working.

This is driving me absolutely bonkers!

1 Like
3

Sorry I didn't reproduce the issue with axt1800 firmware 4.7. I checked this info for your reference. The DNS connection is complete and the process is still alive.

root@GL-AX1800:~# cat /proc/net/nf_conntrack|grep dport=53
ipv4     2 udp      17 59 src=10.8.0.2 dst=209.244.0.3 sport=58659 dport=53 packets=1 bytes=59 src=209.244.0.3 dst=10.8.0.2 sport=53 dport=58659 packets=1 bytes=59 mark=0 zone=0 use=2
ipv4     2 udp      17 59 src=10.8.0.2 dst=209.244.0.3 sport=33507 dport=53 packets=1 bytes=59 src=209.244.0.3 dst=10.8.0.2 sport=53 dport=33507 packets=1 bytes=59 mark=0 zone=0 use=2
ipv4     2 udp      17 59 src=10.8.0.2 dst=64.6.64.6 sport=33507 dport=53 packets=1 bytes=59 src=64.6.64.6 dst=10.8.0.2 sport=53 dport=33507 packets=1 bytes=59 mark=0 zone=0 use=2
ipv4     2 udp      17 59 src=192.168.8.152 dst=192.168.8.1 sport=43705 dport=53 packets=2 bytes=118 src=192.168.8.1 dst=192.168.8.152 sport=1653 dport=43705 packets=2 bytes=118 mark=0 zone=0 use=2
root@GL-AX1800:~# 
root@GL-AX1800:~# 
root@GL-AX1800:~# ps w |grep dnsm
 8964 root      1316 S    grep dnsm
30289 dnsmasq   4708 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
30295 root      4704 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
30449 root      4596 S    /usr/sbin/dnsmasq -C /etc/dnsmasq.conf.vpn -x /var/run/dnsmasq/dnsmasq.vpn.pid --server=209.244.0.3 --ser
30450 root      4592 S    /usr/sbin/dnsmasq -C /etc/dnsmasq.conf.vpn -x /var/run/dnsmasq/dnsmasq.vpn.pid --server=209.244.0.3 --ser
root@GL-AX1800:~#

Can you capture DNS traffic to debug:

opkg update
opkg install tcpdump
tcpdump -i ovpnclient -s0 -n port 53
4

Here you go. This was a few seconds of TCPdumping:

root@GL-AXT1800:~# tcpdump -i ovpnclient -s0 -n port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnclient, link-type RAW (Raw IP), capture size 262144 bytes
17:45:23.634379 IP 192.168.254.3.48678 > 8.8.4.4.53: 52140+ A? wss-primary.slack.com. (39)
17:45:23.634525 IP 192.168.254.3.48678 > 8.8.8.8.53: 52140+ A? wss-primary.slack.com. (39)
17:45:23.762992 IP 192.168.254.3.58975 > 8.8.4.4.53: 57136+ A? edge.microsoft.com. (36)
17:45:23.763135 IP 192.168.254.3.58975 > 8.8.8.8.53: 57136+ A? edge.microsoft.com. (36)
17:45:24.158168 IP 192.168.254.3.35490 > 8.8.4.4.53: Flags [S], seq 1496110758, win 29200, options [mss 1460,sackOK,TS val 33252488 ecr 0,nop,wscale 6], length 0
17:45:24.158315 IP 192.168.254.3.35492 > 8.8.4.4.53: Flags [S], seq 3311612873, win 29200, options [mss 1460,sackOK,TS val 33252488 ecr 0,nop,wscale 6], length 0
17:45:24.241868 IP 192.168.254.3.33408 > 8.8.4.4.53: 32870+ A? functional.events.data.microsoft.com. (54)
17:45:24.242014 IP 192.168.254.3.33408 > 8.8.8.8.53: 32870+ A? functional.events.data.microsoft.com. (54)
17:45:25.418155 IP 192.168.254.3.35470 > 8.8.4.4.53: Flags [S], seq 3488699113, win 29200, options [mss 1460,sackOK,TS val 33252614 ecr 0,nop,wscale 6], length 0
17:45:25.418276 IP 192.168.254.3.35472 > 8.8.4.4.53: Flags [S], seq 2085948347, win 29200, options [mss 1460,sackOK,TS val 33252614 ecr 0,nop,wscale 6], length 0
17:45:25.454468 IP 192.168.254.3.34103 > 8.8.4.4.53: 13169+ A? outlook.office.com. (36)
17:45:25.454612 IP 192.168.254.3.34103 > 8.8.8.8.53: 13169+ A? outlook.office.com. (36)
17:45:25.858183 IP 192.168.254.3.35474 > 8.8.4.4.53: Flags [S], seq 1289138008, win 29200, options [mss 1460,sackOK,TS val 33252658 ecr 0,nop,wscale 6], length 0
17:45:25.858328 IP 192.168.254.3.35476 > 8.8.4.4.53: Flags [S], seq 1012052569, win 29200, options [mss 1460,sackOK,TS val 33252658 ecr 0,nop,wscale 6], length 0
17:45:25.979609 IP 192.168.254.3.35494 > 8.8.4.4.53: Flags [S], seq 3299464331, win 29200, options [mss 1460,sackOK,TS val 33252670 ecr 0,nop,wscale 6], length 0
17:45:25.980598 IP 192.168.254.3.35496 > 8.8.4.4.53: Flags [S], seq 1930807377, win 29200, options [mss 1460,sackOK,TS val 33252670 ecr 0,nop,wscale 6], length 0
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel
root@GL-AXT1800:~#
5

Please make sure there's not any network range conflict. I'll PM you to get a syslog to check.

6

I feel like a fool. I finally figured it out and it wasn't a problem with my GL-Inet.

I thought I should post a solution in case somebody else runs across this issue in the future.

UFW on my openvpn server was blocking all traffic forwarded from tun0 to eth0 except ICMP. This made me think that everything was working.

To complicate things, when you resolve a DNS address from the GL-Inet itself over SSH or LuCI, it is bypassing the VPN and going straight out the WAN port. This resulted in the confusing behavior I discovered.

The fix was to run the following command on my OpenVPN server:

sudo ufw route allow in on tun0 out on eth0

This only works if you also have IP forwarding enabled in syscontrol.

Thanks to the GL Inet Staff who were trying to help me out.

2 Likes