Monthly Archives

September 2020

Gl inet OpenVPN client routing all traffic, ignoring pushed routes

If you’re using the rather excellent Gl inet series of routers as VPN end points, then you may find they have a “feature” which causes all traffic to tunnel through the OpenVPN, even if you push smaller subnet routes.

[email protected]:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
 1  10.254.254.17 (10.254.254.17)  78.267 ms  76.049 ms  77.880 ms
 2  10.34.56.1 (10.34.56.1)  82.636 ms  84.339 ms  80.361 ms
 3  *  *  * (81.82.83.84)  82.747 ms  122.769 ms  93.138 ms
 4  *  *  *
 5  *  *  *
 6  tcma-ic-3-0.network.myisp.net (62.63.64.65)  128.810 ms  157.364 ms  141.007 ms
 7  162.158.32.254 (162.158.32.254)  78.899 ms  144.601 ms  83.033 ms
 8  one.one.one.one (1.1.1.1)  80.166 ms  79.087 ms  76.484 ms

There is a script which runs on these devices which forces all internet traffic to route down the OpenVPN tunnel, no matter what settings you seem to apply either on the client web page, or on the server side of things. This seems to be evidenced by looking at the routing table, which seems to generate two default routes, with the ethernet route being a higher (and therefore deprioritised) metric.

[email protected]:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               128.0.0.0       U     0      0        0 tun0
default         10.10.99.1      0.0.0.0         UG    10     0        0 eth0
10.10.19.0      *               255.255.255.0   U     0      0        0 br-lan
10.10.99.0      *               255.255.255.0   U     10     0        0 eth0
10.10.222.0    10.254.254.17   255.255.255.0   UG    0      0        0 tun0
10.254.254.17   *               255.255.255.255 UH    0      0        0 tun0
18.203.182.0    *               255.255.255.0   U     0      0        0 eth0
86.11.242.12    10.10.99.1      255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       *               128.0.0.0       U     0      0        0 tun0

After *much* searching around, I eventually got directed to this post on the Gl-inet forums https://forum.gl-inet.com/t/openvpn-configuration-to-avoid-the-default-redirection-all-through-the-vpn/6519/5 which details the cause of this.

You have to edit two files – /etc/init.d/startvpn

Just add a # to the line lan2wan_forwarding disable which is in ovpn_firewall_start() section

The next file to edit is /etc/vpn.user

Just add # marks on every line between (and including) if and fi on the section # Load default rules

Finally, reboot or restart your OpenVPN service for the new rules to take place. After a reset, you can see that the routing is as it should be

[email protected]:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.10.99.1      0.0.0.0         UG    10     0        0 eth0
10.10.19.0      *               255.255.255.0   U     0      0        0 br-lan
10.10.99.0      *               255.255.255.0   U     10     0        0 eth0
10.10.222.0    10.254.254.17   255.255.255.0   UG    0      0        0 tun0
10.254.254.17   *               255.255.255.255 UH    0      0        0 tun0
86.11.242.12    10.10.99.1      255.255.255.255 UGH   0      0        0 eth0

And a ping

[email protected]:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
 1  10.254.254.17 (10.254.254.17)  0.733 ms  0.591 ms  0.426 ms
 2  *  *  *
 3  *  *  *
 4  31.32.33.31 (31.32.33.31)  9.383 ms  8.870 ms  31.55.185.180 (31.55.185.180)  8.968 ms
 5  core2-hu0-8-0-5.colindale.theotherisp.net (191.99.127.154)  9.055 ms  core1-hu0-6-0-6.colindale.theotherisp.net (211.121.192.0)  8.594 ms  core2-hu0-12-0-1.colindale.theotherisp.net (191.99.127.118)  8.984 ms
 6  core2-hu0-7-0-0.colindale.theotherisp.net (191.72.16.128)  8.900 ms  peer7-et-7-0-1.telehouse.theotherisp.net (101.159.252.92)  15.313 ms  peer7-et-3-1-4.telehouse.theotherisp.net (109.159.252.168)  9.227 ms
 7  *  109.159.253.95 (109.159.253.95)  10.421 ms  14.362 ms
 8  one.one.one.one (1.1.1.1)  9.379 ms  9.363 ms  9.062 ms

Note, I install nano on my devices but obviously you can use VIM or any other preferred text editor.
I also noted during my research that others using OpenWRT suggested similar behaviour, but the fix may or may not be related to the above.

Also note that changing this may cause an unexpected security issue as traffic will now go locally other than the routed subnets.

Finally, be VERY confident that this will fix your issue if your device is remote deployed. Perhaps make sure you still have remote access to the device if the VPN breaks, or be prepared to travel to the device if it breaks. With the low cost of Gl-inet devices, its worth having a spare on hand to test against before deploying to live.

CreateSRSMedia.ps1 – invalid version

I’ve been messing around trying to get my HP Slice built with the latest Teams Room System (SRS client) which is billed as an “easy way” to create the requisite recovery/build media for an SRSv2 Environment.

However, it is EXTREMELY picky around the Windows version you build with. This was with the 1909 build from Microsoft, but because there was a patch, the version was different.

Your Windows installation media is version 10.0.18362.592. Your SRSv2 kit requires version 10.0.18362.418.

However, if you’re just doing some testing, you can force overriding the check from within the script relatively quickly.

!! THIS IS NOT RECOMMENDED FOR PRODUCTION SYSTEMS !!

Open the Powershell script in your favourite editor and find the line

if ($img.Version -ne $KitOsRequired)

and change -ne (not equals) to

if ($img.Version -eq $KitOsRequired)

Which will cause it to fail in the positive and allow you to continue setup.