384.13 VPN activating on IP by itself

[rn170uk]

Hi All,

I'm using 384.13 on an RT-AC68U. One of my fixed IPs which is not in the OpenVPN client settings is routing through VPN automatically - but not all the time. If I enabled/disable, then all is good for a couple of days, then Ntflx/AmPrm both tell me I'm using a VPN and I have to repeat the process.

Any ideas of options except rebooting every couple of days? If I added it to the VPN list with "WAN" as the setting, this still happens.

Thanks in advance

 

[Martineau]

I'm using 384.13 on an RT-AC68U. One of my fixed IPs which is not in the OpenVPN client settings is routing through VPN automatically - but not all the time. If I enabled/disable, then all is good for a couple of days, then Ntflx/AmPrm both tell me I'm using a VPN and I have to repeat the process.

Any ideas of options except rebooting every couple of days? If I added it to the VPN list with "WAN" as the setting, this still happens.

When the issue occurs, you should manually dump the VPN Clients' RPDB rules and their associated routing tables to look for anomalies:

ip rule

for ID in 254 111 112 113 114 115;do echo "Table "$ID;ip route show table $ID | grep -E "default|^128|^0";done

Alternatively you could use cron to schedule a debugging script e.g. ChkVPNConfig.sh

 

[rn170uk]

Thanks. Here is the result:

ASUSWRT-Merlin RT-AC68U 384.13-0 Wed Jul 31 17:27:27 UTC 2019
admin@RT-AC68U-8028:/tmp/home/root# ip rule
0:      from all lookup local
10101:  from 192.168.1.2 lookup ovpnc1
10102:  from 192.168.1.12 lookup ovpnc1
10103:  from 192.168.1.193 to aa.bbb.cc.ddd lookup ovpnc1
10104:  from 192.168.1.10 lookup ovpnc1
10105:  from 192.168.1.182 lookup ovpnc1
10106:  from 192.168.1.50 lookup ovpnc1
10301:  from 192.168.1.183 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default
admin@RT-AC68U-8028:/tmp/home/root#


for ID in 254 111 112 113 114 115;do echo "Table "$ID;ip route show table $ID | grep -E "default|^128|^0";done

Table 254
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.zzz dev ppp0
Table 111
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 112
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 113
Table 114
Table 115


(checkVPNConfig.sh): 19402 **Warning WAN IP address 172.xx.yy.zzz is Private - is Asus router behind an ISP modem?

(checkVPNConfig.sh): 19402 ***ERROR*** Selective Routing NOT enabled! - table 'main' is FORCE routing ALL traffic via VPN Client 1

(checkVPNConfig.sh): 19402 VPN Client 1 route Table: 111 (VPN KILL switch Protection ENABLED)

172.xx.yy.0/23 dev tun11  proto kernel  scope link  src 172.xx.yy.zzz
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11

(checkVPNConfig.sh): 19402 **Warning '0.0.0.0/1 via 172.xx.yy.1 dev tun11 ' found in VPN Client 1

(checkVPNConfig.sh): 19402 ***ERROR*** RPDB rules will be misdirected for VPN Client 2 via tun11

(checkVPNConfig.sh): 19402 ***ERROR*** '0.0.0.0/1 via 172.xx.yy.1 dev tun11 ' will misdirect VPN Client 2 via wrong VPN Client

(checkVPNConfig.sh): 19402 **Warning for multiple ACTIVE concurrent VPN Clients
UNIQUE ports are advised - Port 443:UDP is configured for use by several VPN Clients

 

[Martineau]

Thanks. Here is the result:

ASUSWRT-Merlin RT-AC68U 384.13-0 Wed Jul 31 17:27:27 UTC 2019
admin@RT-AC68U-8028:/tmp/home/root# ip rule
0:      from all lookup local
10101:  from 192.168.1.2 lookup ovpnc1
10102:  from 192.168.1.12 lookup ovpnc1
10103:  from 192.168.1.193 to aa.bbb.cc.ddd lookup ovpnc1
10104:  from 192.168.1.10 lookup ovpnc1
10105:  from 192.168.1.182 lookup ovpnc1
10106:  from 192.168.1.50 lookup ovpnc1
10301:  from 192.168.1.183 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default
admin@RT-AC68U-8028:/tmp/home/root#


for ID in 254 111 112 113 114 115;do echo "Table "$ID;ip route show table $ID | grep -E "default|^128|^0";done

Table 254
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.zzz dev ppp0
Table 111
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 112
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 113
Table 114
Table 115


(checkVPNConfig.sh): 19402 **Warning WAN IP address 172.xx.yy.zzz is Private - is Asus router behind an ISP modem?

(checkVPNConfig.sh): 19402 ***ERROR*** Selective Routing NOT enabled! - table 'main' is FORCE routing ALL traffic via VPN Client 1

(checkVPNConfig.sh): 19402 VPN Client 1 route Table: 111 (VPN KILL switch Protection ENABLED)

172.xx.yy.0/23 dev tun11  proto kernel  scope link  src 172.xx.yy.zzz
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11

(checkVPNConfig.sh): 19402 **Warning '0.0.0.0/1 via 172.xx.yy.1 dev tun11 ' found in VPN Client 1

(checkVPNConfig.sh): 19402 ***ERROR*** RPDB rules will be misdirected for VPN Client 2 via tun11

(checkVPNConfig.sh): 19402 ***ERROR*** '0.0.0.0/1 via 172.xx.yy.1 dev tun11 ' will misdirect VPN Client 2 via wrong VPN Client

(checkVPNConfig.sh): 19402 **Warning for multiple ACTIVE concurrent VPN Clients
UNIQUE ports are advised - Port 443:UDP is configured for use by several VPN Clients

The RPDB rules show that your intention is to have the following five devices routed via VPN Client 1

10101:  from 192.168.1.2 lookup ovpnc1
10102:  from 192.168.1.12 lookup ovpnc1
10104:  from 192.168.1.10 lookup ovpnc1
10105:  from 192.168.1.182 lookup ovpnc1
10106:  from 192.168.1.50 lookup ovpnc1

and a single device routed via VPN Client 2

10301:  from 192.168.1.183 lookup ovpnc2

whilst all references to a single destination IP aa.bbb.cc.ddd only from device 192.168.1.193 should also be routed via VPN Client 1.

10103:  from 192.168.1.193 to  lookup ovpnc1

Unfortunately, the actual Selective Routing tables show that your desired Selective Routing rules are incorrect

Table 254
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.zzz dev ppp0
Table 111
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 112
0.0.0.0/1 via 172.xx.yy.1 dev tun11
128.0.0.0/1 via 172.xx.yy.1 dev tun11
default via 172.xx.yy.1 dev tun11
Table 113
Table 114
Table 115

and my crude ChkVPNConfig.sh script has attempted to explain in simple layman's terms why the actual routing tables are causing the weird symptom you have described.

i.e.

1. VPN Client 2 is incorrectly routing traffic via physical interface tun11 (which is actually VPN Client 1) rather than interface tun12
2. ALL (non-VPN) WAN traffic is also forced via physical interface tun11 (which is actually VPN Client 1) rather than interface ppp0.​

I suggest you stop both VPN Clients, and focus on correcting the forced routing of ALL WAN traffic via VPN Client 1

Ensure the reworded GUI 'Force Internet traffic through tunnel=' (was previously 'Redirect Internet traffic=') is explicitly set to 'Policy Rules(strict)' for both VPN Clients, then start VPN Client 1 only.

The WAN routing table (254) should now look like

Table 254
default via 172.xx.yy.zzz dev ppp0

with the two clever OpenVPN override rules '0.0.0.0/1' and '128.0.0.0/1' being absent.
If the two OpenVPN rules are still present, then a dirty hack would be to manually delete them

ip route delete 0.0.0.0/1

ip route delete 128.0.0.0/1

to allow non-VPN Client 1 traffic to correctly use the WAN.

Also, to correct the VPN Client 2 issue, check if your VPN ISP allows multiple VPN connections from the same device, or if an alternative destination Port is available.