RT-AC87U - 380.59 - OpenVPN Policy rules do not get applied

[alcomatt]

My policy rules have been working fine through last few upgrades, however with the recent release they stopped working altogether. Although they seem to be applied according to logs, the actual rule table for ovpnc1-5 does not get populated with them.

Here is the vpn client config file used:

client
dev tun
remote blah.blah.com 993
proto tcp-client
remote-cert-tls server
auth-user-pass
tls-client
pull
persist-key
resolv-retry infinite
reneg-sec 0
verb 3
script-security 2 system
auth-nocache
route-delay 2
redirect-gateway def1

<ca>
omitted certs for obvious reasons
</ca>

And the screenshot from router configuration screen:

The policy rules are defined as follows:

0.0.0.0 195.245.213.0/24 VPN
0.0.0.0 217.149.240.0/20 VPN
0.0.0.0 44.229.145.0/26 VPN

The client connects fine and the tunnel comes up:

May 16 13:00:52 openvpn[5496]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
May 16 13:00:52 openvpn[5496]: /usr/sbin/ip link set dev tun11 up mtu 1500
May 16 13:00:53 openvpn[5496]: /usr/sbin/ip addr add dev tun11 10.100.201.64/22 broadcast 10.100.203.255
May 16 13:00:55 openvpn-routing: Configuring policy rules for client 1
May 16 13:00:55 openvpn-routing: Creating VPN routing table
May 16 13:00:55 openvpn-routing: Adding route for 0.0.0.0 to 195.245.213.0/24 through VPN client 1
May 16 13:00:55 openvpn-routing: Adding route for 0.0.0.0 to 217.149.240.0/20 through VPN client 1
May 16 13:00:55 openvpn-routing: Adding route for 0.0.0.0 to 44.229.145.0/26 through VPN client 1
May 16 13:00:55 openvpn-routing: Completed routing policy configuration for client 1
May 16 13:00:55 openvpn[5496]: Initialization Sequence Completed

On the surface it appears ok and I can see the rules

/tmp/home/root# ip rule
0:      from all lookup local
1101:   from all to 195.245.213.0/24 lookup ovpnc1
1102:   from all to 217.149.240.0/20 lookup ovpnc1
1103:   from all to 44.229.145.0/26 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

However the ovpnc1 table is missing the required entries:

/tmp/home/root# ip route show table ovpnc1
10.9.8.1 dev tun15  proto kernel  scope link  src 10.9.8.2
92.232.38.1 dev eth0  proto kernel  scope link
169.254.39.0/24 dev br0  proto kernel  scope link  src 169.254.39.21
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
92.232.38.0/23 dev eth0  proto kernel  scope link  src 92.232.38.41
10.100.200.0/22 dev tun11  proto kernel  scope link  src 10.100.201.64
127.0.0.0/8 dev lo  scope link

Traceroute goes over WAN:

/tmp/home/root# traceroute 195.245.213.1
traceroute to 195.245.213.1 (195.245.213.1), 30 hops max, 38 byte packets
1  10.165.52.1 (10.165.52.1)  6.621 ms  7.533 ms  10.065 ms
2  croy-core-2a-xe-815-0.network.virginmedia.net (81.96.228.141)  9.844 ms  6.046 ms  7.573 ms

After adding the routing entries manually:

/tmp/home/root# ip route add 195.245.213.0/24 dev tun11 table ovpnc1
/tmp/home/root# ip route add 217.149.240.0/20 dev tun11 table ovpnc1
/tmp/home/root# ip route add 44.229.145.0/26 dev tun11 table ovpnc1

The ovpnc1 table gets populated properly now:

/tmp/home/root# ip route show table ovpnc1
10.9.8.1 dev tun15  proto kernel  scope link  src 10.9.8.2
92.232.38.1 dev eth0  proto kernel  scope link
44.229.145.0/26 dev tun11  scope link
169.254.39.0/24 dev br0  proto kernel  scope link  src 169.254.39.21
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
195.245.213.0/24 dev tun11  scope link
92.232.38.0/23 dev eth0  proto kernel  scope link  src 92.232.38.41
10.100.200.0/22 dev tun11  proto kernel  scope link  src 10.100.201.64
217.149.240.0/20 dev tun11  scope link
127.0.0.0/8 dev lo  scope link

And the traceroute goes via the VPN link now

traceroute 195.245.213.1
traceroute to 195.245.213.1 (195.245.213.1), 30 hops max, 38 byte packets
1  10.100.201.254 (10.100.201.254)  41.935 ms  41.907 ms  41.669 ms
2  ip-185.212-91-26-0.dynamic.chello.pl (212.91.26.185)  42.238 ms  41.307 ms  45.511 ms

Is this a bug or have I messed something up in the configuration?

 

[RMerlin]

Try changing route-delay to 5, see if it helps.

 

[alcomatt]

Thanks Merlin.

I've managed to get it going eventually by adding

nobind
route metric 1

to the extra options.

 

[RMerlin]

Thanks Merlin.

I've managed to get it going eventually by adding

nobind
route metric 1

to the extra options.

That's odd. I'll have to see if I can reproduce it in any way, tho the only real test server I can connect to is the free VPNBook account I'm using for tests.

 

[alcomatt]

I've got a feeling that it was the vpn provider who started meddling on their side. Either way thanks for the help and for the brilliant firmware!