RT-AX86U + OpenVPN + AdGuard Home = No Internet on Android

[ChitlinNoodleSoup]

Good evening, all. This site always comes up when Googling questions about my routers so I figured I'd sign up and ask a question I have not been able to find an answer for. My current setup is an RT-AX86U router running OpenVPN server. I also have AdGuard Home installed on a Windows PC. I have the IP of the PC running AdGuard entered as DNS server 1 under DHCP server settings in the router. DNS Server 2 is left blank. Advertise router's IP... is set to no. With this configuration, AdGuard works perfectly. Every device on the LAN queries AdGuard for DNS.

My OpenVPN clients are a Windows PC at work and my Android phone. From Work, I can connect to VPN and my DNS queries show up in AdGuard. Ads are blocked as expected. If I connect from my Android phone I can access everything on the LAN but I have no internet. What's strange is that DNS queries from my phone show up in AdGuard's query log as "processed" but I get an error in Chrome that DNS was not resolved. If I change the DNS server address in the router back to my router's IP, I have internet and LAN access but, obviously DNS queries are routed via WAN and not to AdGuard. This leads me to believe there's something in AdGuard that I'm overlooking.

Does anyone have any suggestions?

 

[eibgrad]

If you had indicated that ALL your OpenVPN clients failed to resolve DNS from AdGuard, it would have been my guess that PC's firewall or the AdGuard service itself was denying access to any clients other than those on the local private network (e.g., 192.168.1.0/24). That's NOT uncommon. But presumably both OpenVPN clients share the same tunnel IP network (e.g., 10.8.0.0/24), so if it works for one, I can't see how it doesn't work for the other. There has to be some other difference that's NOT obvious at the moment, but I don't know what that would be.

This is why it can be helpful to NAT the traffic from the tunnel as it's dropped on the private network (br0), so ALL of it appears to be originating from the router's LAN interface (e.g., 192.168.1.1). You avoid various anomalies this way. OTOH, you can no longer distinguish one OpenVPN client from another for logging purposes in the AdGuard service. And it requires the ability to add the NAT rule (I assume you're running OEM firmware, NOT Merlin).

 

[ChitlinNoodleSoup]

If you had indicated that ALL your OpenVPN clients failed to resolve DNS from AdGuard, it would have been my guess that PC's firewall or the AdGuard service itself was denying access to any clients other than those on the local private network (e.g., 192.168.1.0/24). That's NOT uncommon. But presumably both OpenVPN clients share the same tunnel IP network (e.g., 10.8.0.0/24), so if it works for one, I can't see how it doesn't work for the other. There has to be some other difference that's NOT obvious at the moment, but I don't know what that would be.

This is why it can be helpful to NAT the traffic from the tunnel as it's dropped on the private network (br0), so ALL of it appears to be originating from the router's LAN interface (e.g., 192.168.1.1). You avoid various anomalies this way. OTOH, you can no longer distinguish one OpenVPN client from another for logging purposes in the AdGuard service. And it requires the ability to add the NAT rule (I assume you're running OEM firmware, NOT Merlin).

I'm running the latest Merlin firmware on this router. And, yes. both VPN clients are using the default 10.8.0.0 subnet.

 

[eibgrad]

As an experiment, using ssh, copy/paste the following command and see if it helps.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

This change will NOT survive a reboot w/o being added as a nat-start script, but for right now, we just want to see if the change makes any difference.

 

[ChitlinNoodleSoup]

As an experiment, using ssh, copy/paste the following command and see if it helps.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

This change will NOT survive a reboot w/o being added as a nat-start script, but for right now, we just want to see if the change makes any difference.

That does work but, as expected, queries show as originating from the router instead of the client.

 

[eibgrad]

That does work but, as expected, queries show as originating from the router instead of the client.

I'm a little surprised it did work. As I said, you don't normally find some OpenVPN clients working and others NOT to the same target device and service. But regardless, that strongly suggests it *is* a firewall issue on the PC hosting AdGuard, or else the AdGuard service itself (perhaps an option in its config file).

If you don't want to mask the actual OpenVPN client IP from the AdGuard service by using the NAT rule, then you'll have to investigate what's denying access to 10.8.0.0/24 on that PC and reconfigure it.

 

[ChitlinNoodleSoup]

I'm a little surprised it did work. As I said, you don't normally find some OpenVPN clients working and others NOT to the same target device and service. But regardless, that strongly suggests it *is* a firewall issue on the PC hosting AdGuard, or else the AdGuard service itself (perhaps an option in its config file).

If you don't want to mask the actual OpenVPN client IP from the AdGuard service by using the NAT rule, then you'll have to investigate what's denying access to 10.8.0.0/24 on that PC and reconfigure it.

I'm not too worried about seeing the actual client in AdGuard. Being able to use VPN and AdGuard together on my mobile device is more important. How would I go about adding that NAT rule permanently while I investigate the issue with the firewall / PC running AdGuard?

 

[eibgrad]

Make sure you have "Enable JFFS custom scripts and configs" under Administration > System set to Yes. Then ssh into the router and copy/paste the following.

#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/nat-start"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

Note, as a precaution, this will NOT overwrite any existing nat-start script.

Finally, reboot.

 

[ChitlinNoodleSoup]

Make sure you have "Enable JFFS custom scripts and configs" under Administration > System set to Yes. Then ssh into the router and copy/paste the following.

#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/nat-start"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

Note, as a precaution, this will NOT overwrite any existing nat-start script.

Finally, reboot.

This is great. Thanks for taking the time to help me with this. Hopefully, one day, I understand what all of that means.

I think I might have figured out what's causing the issue but now I just have to figure out what to do about it. I forgot that I keep my home PC connected to my work PC via OpenVPN. We lost internet at work this morning so that VPN connection broke. I picked up my phone (connected to home VPN) and realized that everything was working as expected. Remembering the command you had me enter last night, I rebooted my router to make sure that wasn't the reason everything was working. Even after a reboot, everything was working as expected. So I have some weird routing stuff going on having that VPN active. I might just move AdGuard to another PC if I can't figure out the routing issues.

 

[eibgrad]

Based on your last reply, here's what's probably happening.

Let's assume your local IP network is 192.168.1.0/24, and your primary router (the normal default gateway) is 192.168.1.1.

When the PC running AdGuard is connected to the OpenVPN server at work, it's probably configured to route *everything* except the local network (192.168.1.0/24) over the VPN, which would include any replies from remote access over your own OpenVPN server! That's why AdGuard reports "processing" (so the inbound request does reach the AdGuard server), but the replies do NOT return over the local network, to your normal default gateway (192.168.1.1), and finally to your own OpenVPN client.

What you need to do is create a static route on that PC that tells it to route 10.8.0.0/24 back to your normal default gateway (192.168.1.1).

route -p add 10.8.0.0/24 192.168.1.1

The -p option makes it persistent across a reboot.

Also, this is an elevated privilege operation, so it will require Administrative privileges w/ the command interpreter (cmd).

Also, make sure your own OpenVPN server and the one at work are NOT using the same 10.8.0.0/24 network for their respective tunnels (that's a common IP network to be used for OpenVPN server).

P.S. You could instead add that route via a custom directive in the OpenVPN client on that PC w/ the following command.

route 10.8.0.0 255.255.255.0 net_gateway

That would then manage the adding and removing of that same route as the OpenVPN client comes up and down. But this assume you're allowed to modified that OpenVPN client w/ the new directive.

 

[ChitlinNoodleSoup]

Based on your last reply, here's what's probably happening.

Let's assume your local IP network is 192.168.1.0/24, and your primary router (the normal default gateway) is 192.168.1.1.

When the PC running AdGuard is connected to the OpenVPN server at work, it's probably configured to route *everything* except the local network (192.168.1.0/24) over the VPN, which would include any replies from remote access over your own OpenVPN server! That's why AdGuard reports "processing" (so the inbound request does reach the AdGuard server), but the replies do NOT return over the local network, to your normal default gateway (192.168.1.1), and finally to your own OpenVPN client.

What you need to do is create a static route on that PC that tells it to route 10.8.0.0/24 back to your normal default gateway (192.168.1.1).

route -p add 10.8.0.0/24 192.168.1.1

The -p option makes it persistent across a reboot.

Also, this is an elevated privilege operation, so it will require Administrative privileges w/ the command interpreter (cmd).

Also, make sure your own OpenVPN server and the one at work are NOT using the same 10.8.0.0/24 network for their respective tunnels (that's a common IP network to be used for OpenVPN server).

P.S. You could instead add that route via a custom directive in the OpenVPN client on that PC w/ the following command.

route 10.8.0.0 255.255.255.0 net_gateway

That would then manage the adding and removing of that same route as the OpenVPN client comes up and down. But this assume you're allowed to modified that OpenVPN client w/ the new directive.

I actually have my PC at home set to use my router as the default gateway so only traffic intended for the LAN at work leaves my network. But I did overlook the fact that both VPN servers were using the same subnet. I've corrected that and it seems that all is well. I am able to use OpenVPN and AdGuard from all devices. Thanks again for your help!