Routing conflicts with Asuswrt-Merlin and Entware-ng's openconnect

[ResumeNothing]

I had originally posted this on the VPN forum, thinking this was a VPN issue. Additional details are on that thread:

https://www.snbforums.com/threads/openconnect-client-on-asus-rt-ac68p-router-not-working.40633/

I've been trying to get OpenConnect running from the command line on an ASUS RT-AC68P router that I've flashed with Asuswrt-Merlin. Everything seems to work, except that my IP is still the one provided by my ISP, and I believe I've narrowed it down to a routing issue where Asuswrt-Merlin immediately overwrites the routes that OpenConnect tries to add.

Before running OpenConnect, my routes look like this:

Destination Gateway Genmask Flags Metric Ref Use Iface
xx.xx.xxx.x * 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
xx.xx.xxx.0 * 255.255.248.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default xx.xx.xxx.x.res 0.0.0.0 UG 0 0 0 eth0

Afterward, they look like this:

Destination Gateway Genmask Flags Metric Ref Use Iface
yy.yy.yyy.yyy xx.xx.xxx.x 255.255.255.255 UGH 0 0 0 eth0
xx.xx.xxx.x * 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
xx.xx.xxx.0 * 255.255.248.0 U 0 0 0 eth0
zz.zz.0.0 * 255.255.0.0 U 0 0 0 tun0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default xx.xx.xxx.x 0.0.0.0 UG 0 0 0 eth0

xx.xx.xxx.x is the ISP provided IP, yy.yy.yyy.yyy is the IP I should have from VPN, and zz.zz.0.0 looks like it was derived from the X-CSTP-Address, which is the same IP mentioned in this line of the OpenConnect output:

Connected as zz.zz.zzz.zzz, using SSL + lzs

What makes me think this is a routing issue is that I can't get rid of the "default xx.xx.xxx.x" route. This command seems to work for about a second:

route del -net default gw xx.xx.xxx.x dev eth0

Sometimes if I run "route -n" fast enough, I can see that it's gone, but then next time I run it, it's back again. At the same time, I can see the following in the system log in the router interface:

Aug 13 19:00:28 WAN_Connection: ISP's DHCP did not function properly.
Aug 13 19:00:28 stop_nat_rules: apply the redirect_rules!
Aug 13 19:00:32 WAN_Connection: WAN was restored.
Aug 13 19:00:32 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!

My thought was is that there might be some sort of setting that would prevent the rules from coming back in and restoring the routes. I tried moving the file mentioned in the logs somewhere else, but that didn't seem to help.

It also seems like I might be able to prevent the rules from running if I can get routes set up fast enough that the WAN connection doesn't think there's a problem with the ISP's DHCP. Unfortunately, I don't have a very good grasp on what rules I need to make this work, and they seem to get over written before I can run them or not run at all because some other rule is already there.

Does anyone know of a setting in in the Asuswrt-Merlin interface I could change that would prevent it from overwriting the routes, or have an idea of what routes I can set that might prevent the rules from running?

Thanks!

 

[ResumeNothing]

Just to follow up on this, I was able to get this to work via the following:

1. Make a writeable copy of /etc/resolv.conf
2. Run OpenConnect (may need to use an altered vpnc-script that forces route to be used instead of ip route)
3. Run the following commands:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
route add -net 0.0.0.0 netmask 0.0.0.0 gw z.z.z.z dev tun0

Where z.z.z.z is the internal VPN IP address. At some point I'll probably work out how to use JFFS so OpenConnect can start on boot, but for now I'm leaving it running in the background in a tmux session so it doesn't stop when the ssh session ends.