OpenVPN problems

[Woody1]

I'm running v380.63_2 on a AC-68U. I am using a wired connection. I have several .opvn configurations connecting to different OpenVPN servers in different locations. All of the VPN servers are provided by the same provider and the settings are similar for all of them.

Every time I connect to one of the servers, I get a connection which lasts for about 9 minutes, then it appears that the routing rules get changed and the routing from my PC through the VPN gets dropped. The VPN status still shows "connected", but I am no longer routed through the VPN.

This is what I see in the system log when the routing changes:

Nov 26 15:10:16 rc_service: udhcpc 2398:notify_rc start_firewall
Nov 26 15:10:16 dhcp client: bound 108.249.221.39 via 108.249.220.1 during 600 seconds.
Nov 26 15:10:17 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!

The other problem I get is that the connection speeds are terrible. Running OpenVPN through the router gives an upload speed of about 1.7 Mbs. Using an OpenVPN client on my PC provides a speed of about 19 Mbs up.

Is this type of speed the best to be expected using this router? If not, does anybody have any suggestions for how to fix the routing or the speed problems?

 

[Woody1]

Update: I had Adaptive QOS turned on. When I turned off all QOS functions, the VPN routing stopped dropping and the throughput speed improved quite a lot. So, it appears that QOS is not compatible with the built-in VPN client. Is there any way to configure QOS to work well with OpenVPN?

 

[Zirescu]

I would check your configs as it would appear that there is likely a ping-restart 600 value in there. I haven't seen any issues with the 87U and QOS, though the QOS settings sometimes need a reboot of the router. If you can use 128 encryption connection this should improve the speeds some as well. If you're using something higher you'll see slow down. There's limited cpu/ram on the routers so will always perform less than a computer.

 

[Woody1]

Ok, looking at the .ovpn file, there's no parameter for ping-restart or anything similar. Also, I tested with both encrypted and unencrypted connections and both had the same problems. Clearly, QOS is what's causing the problem. When I switched from Adaptive QOS to Traditional QOS, the problem with routing resets appears to stop, but the upload speed is still terrible.

I found this thread from over a year ago discussing a similar problem: http://www.snbforums.com/threads/slow-openvpn-on-ac87r.24490/
According to this thread and some other discussions I've read, QOS applies the upload limit to the VPN download limit. That's consistent with the speeds I'm seeing with QOS turned on.

Looks like this is a bug that's been around a long time. I'm surprised more people haven't run into it. I would like to find a solution, but I think that it's something that needs to be fixed in the firmware.

 

[Zirescu]

Are you using the Automatic Bandwidth setting or Manual? I'm using Automatic and I max out my upload bandwidth.
I wonder if your ISP is causing you to drop your WAN IP address too frequently. The dhcp-client message you have there looks like it's the WAN side and the 600 seconds isn't likely a coincidence.

 

[Woody1]

I tried it using Adaptive QOS with Automatic Bandwidth and that does work at full speed. So it appears that the bug only affects the manual bandwidth setting.

The problem is that the routing problem still happens when I turn on QOS. After about 9 minutes, the regular nat rules get applied and the routing through the VPN fails. My WAN IP hasn't changed in months, so I don't think that's the problem. This routing change doesn't seem to happen with QOS turned off. Very confusing. My network connection is U-Verse/ADSL. My connection type is "Automatic IP", so I guess that the router checks for WAN DHCP periodically. I'm not sure why QOS would have any effect on the routing, and I don't see an obvious way to fix this so that the VPN will work with QOS turned on.

 

[Zirescu]

Which client instance are you running on? Do you have more than one instance running at a time?

 

[Martineau]

The problem is that the routing problem still happens when I turn on QOS. After about 9 minutes, the regular nat rules get applied and the routing through the VPN fails. My WAN IP hasn't changed in months, so I don't think that's the problem. . I'm not sure why QOS would have any effect on the routing, and I don't see an obvious way to fix this so that the VPN will work with QOS turned on.

Are you using a custom VPN fwmark script to implement the routing, or are you using the RPDB Policy rules in the GUI?

I suspect each time you tinker with the QOS manual options, the iptables get flushed, and until you restart the VPN Client, routing will fail.

 

[Woody1]

Are you using a custom VPN fwmark script to implement the routing, or are you using the RPDB Policy rules in the GUI?

I suspect each time you tinker with the QOS manual options, the iptables get flushed, and until you restart the VPN Client, routing will fail.

I'm using the Policy Rules as set in the GUI. I have the policy rules set up to route one or more LAN IPs via the VPN. The sequence is that I turn on QOS, then activate the VPN client. The VPN connects and routes successfully. Then, after about 9 minutes, the routing reverts back to my local routing. The VPN status shows that it's still connected, but nothing gets routed through the VPN.

If I turn off the QOS, the routing problem stops.

@Zirescu: I'm only using one client at time.

 

[Martineau]

I'm using the Policy Rules as set in the GUI. I have the policy rules set up to route one or more LAN IPs via the VPN. The sequence is that I turn on QOS, then activate the VPN client. The VPN connects and routes successfully. Then, after about 9 minutes, the routing reverts back to my local routing. The VPN status shows that it's still connected, but nothing gets routed through the VPN.

If I turn off the QOS, the routing problem stops.

@Zirescu: I'm only using one client at time.

You will need to check the contents of the RPDB tables

Issue the following commands (assumes VPN Client 1 is being used) when the VPN routing is working, and after when the routing is broken:

ip rule

ip route show table 111

 

[Woody1]

Ok, here's what I saw:

I used Client 4. It started and ran normally for about 9 minutes.

While Client 4 connected and properly routed:

admin@Asus-Merlin:/tmp/home/root# ip rule
0:      from all lookup local
10701:  from 192.168.123.54 lookup ovpnc4
32766:  from all lookup main
32767:  from all lookup default

admin@Asus-Merlin:/tmp/home/root# ip route show table 114
88.150.183.140 via 108.249.220.1 dev eth0
108.249.220.1 dev eth0  proto kernel  scope link
25.0.4.0/24 dev tun14  proto kernel  scope link  src 25.0.4.2
192.168.123.0/24 dev br0  proto kernel  scope link  src 192.168.123.254
108.249.220.0/22 dev eth0  proto kernel  scope link  src 108.249.221.39
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 25.0.4.1 dev tun14
128.0.0.0/1 via 25.0.4.1 dev tun14
default via 25.0.4.1 dev tun14

----------------------------------------------------------------------
Client 4 still connected, but routing has failed:

admin@Asus-Merlin:/tmp/home/root# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

admin@Asus-Merlin:/tmp/home/root# ip route show table 114
25.0.4.0/24 dev tun14  proto kernel  scope link  src 25.0.4.2
192.168.123.0/24 dev br0  proto kernel  scope link  src 192.168.123.254
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 25.0.4.1 dev tun14
128.0.0.0/1 via 25.0.4.1 dev tun14
default via 25.0.4.1 dev tun14

 

[Martineau]

While Client 4 connected and properly routed:

admin@Asus-Merlin:/tmp/home/root# ip rule
0:      from all lookup local
10701:  from 192.168.123.54 lookup ovpnc4

----------------------------------------------------------------------
Client 4 still connected, but routing has failed:

So routing rule (created by RMerlin script /usr/sbin/vpnrouting.sh)

10701:  from 192.168.123.54 lookup ovpnc4

has been flushed..so RMerlin's RPDB Selective routing is no more robust than the fwmark method!
So you will need to restart the VPN (which calls vpnrouting.sh) i.e. include in nat-start

service restart_vpnclient4

or if you would rather not interrupt the existing VPN Client connection then simply code

ip rule add from 192.168.123.54 table ovpnc4 prio 10701

 

[Woody1]

But it looks like the rules get flushed every 9 or 10 minutes. I would have to constantly restart the VPN. I think that will cause constant problems.
Why is it that the rules get flushed only when QOS is turned on?

 

[Martineau]

But it looks like the rules get flushed every 9 or 10 minutes. I would have to constantly restart the VPN. I think that will cause constant problems.
Why is it that the rules get flushed only when QOS is turned on?

Well it is the prerogative of the developers...ASUS don't have to explicitly inform @RMerlin / @john9527 etc. about changes they have done nor indeed why they choose to do things in the way they have!

RMerlin has stated many times that (Trad) QOS is flawed/broken on these routers yet some find it fits their needs perfectly, while for others - like yourself - it is a frustrating experience!

 

[Woody1]

Well it is the prerogative of the developers...ASUS don't have to explicitly inform @RMerlin / @john9527 etc. about changes they have done nor indeed why they choose to do things in the way they have!

RMerlin has stated many times that (Trad) QOS is flawed/broken on these routers yet some find it fits their needs perfectly, while for others - like yourself - it is a frustrating experience!

Thanks for your help and suggestions. If you think of any other possible fixes I can try, please let me know!