OpenVPN broken on Opal 4.8.3 Beta

Router VPN, DNS, Leaks
1

I’ve noticed in 4.8.3 beta on Opal that OpenVPN routing isn’t working.

Before the Beta Upgrade:

^C# marmite# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=283.980 ms
64 bytes from 8.8.8.8: seq=1 ttl=116 time=280.733 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max = 280.733/282.356/283.980 ms

marmite# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.200 0.0.0.0 UG 0 0 0 eth0.2
10.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ovpnclient
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

marmite# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 10.16.0.1 (10.16.0.1) 275.413 ms 277.399 ms 278.903 ms
2 172.17.0.1 (172.17.0.1) 275.670 ms 276.892 ms 277.316 ms
3^C

After the beta upgrade, traffic is bypassing openvpn, and going straight out via the default gateway (ie the mangle iptable rule is being ignored):

marmite# ping -c3 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: seq=0 ttl=118 time=4.908 ms
64 bytes from 8.8.8.8: seq=1 ttl=118 time=4.823 ms
64 bytes from 8.8.8.8: seq=2 ttl=118 time=4.353 ms

--- 8.8.8.8 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 4.353/4.694/4.908 ms

On the stable v4.3.25 firmware, GL.iNet's ROUTE_POLICY iptables rules and secondary routing tables are working flawlessly. The router's firewall is successfully intercepting your LAN traffic, stamping it with the correct OpenVPN mark, and seamlessly steering it into the VPN tunnel behind the scenes.

On the v4.8.3 beta, that entire background tagging system isn’t working.

It looks like the firmware assumes that Wireguard is being used for OpenVPN.

The most glaring issue I saw is that TUNNEL10_ROUTE_POLICY (the WireGuard mangle chain) was completely filled with packet counters, while TUNNEL100_ROUTE_POLICY (OpenVPN) was sitting at absolute zero.

Anyone else seen this?

2

Hi,

We checked locally and it seems that OpenVPN on Opal v4.8.3 beta6 is working properly.

image
image1789×913 66.1 KB

Could you please further clarify your set up and provide a screenshot of Admin Panel → VPN → VPN Dashboard?

4

A bit offtopic but not to create a new thread: is AmneziaWG support coming to Opal? I’ve tried latest 4.8.3 beta released on 10th of June but it doesn’t seem to work yet.

5

The Opal is currently planned to receive AmneziaWG support, but it is unlikely to be included in v4.8.3. It is more likely to be introduced in v4.8.4.

6

stable 4.8.3 out now :slight_smile:

https://fw.gl-inet.com/firmware/sft1200/release4/sft1200-4.8.3_release4-1006-0609-1780999327.tar

8

I just tried GA 4.8.3 version, resetting to factory defaults

Same problem:

Marmite# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.200 0.0.0.0 UG 0 0 0 eth0.2
10.15.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ovpnclient1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.2
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

Marmite# ip r get 8.8.8.8
8.8.8.8 via 192.168.0.200 dev eth0.2 src 192.168.0.250 uid 0
cache

Marmite# traceroute -i ovpnclient1 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 10.15.0.1 (10.15.0.1) 434.908 ms 312.205 ms 312.049 ms
2 172.17.0.1 (172.17.0.1) 311.433 ms 312.597 ms 311.884 ms
3 no-rdns-yet.veloxserv.net (195.191.219.65) 312.045 ms 313.006 ms 310.634 ms
4 100.69.165.28 (100.69.165.28) 311.933 ms 313.364 ms 312.945 ms
5^C

Marmite# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 192.168.0.200 (192.168.0.200) 1.182 ms 1.009 ms 0.984 ms
2 10.0.0.1 (10.0.0.1) 2.047 ms 1.958 ms 1.915 ms
3 gateway.qld.originbroadband.com.au (116.255.16.1) 6.898 ms 4.753 ms^C
Marmite#

Traffic can be forced with traceroute to ignore routing and go through OpenVPN, but the rule based routing looks broken. (I’ve got the default - kill switch on, and global proxy on - as default)

10

ok, it’s only internal traffic that’s bypassing the VPN.

What’s the official way to get all traffic through the VPN?

15

Hi,

In firmware v4.8.3, Global Mode routes traffic from all connected client devices through OpenVPN, but traffic generated by the router itself is handled separately.
The commands you ran over SSH test traffic originating from Opal itself, not traffic forwarded from the connected devices.

As a result, ip route get and a normal traceroute run directly on Opal may still select the WAN interface eth0.2.

Currently, the official firmware does not provide a supported to route all traffic, including traffic generated by the router itself, through the VPN.

Thank you for your understanding and support.