Issue routing on a gateway server via an openvpn connection.

I have a machine with a WiFi connection and an ethernet connection. The ethernet connection is connected via a hub to several other devices. The WiFi connection is not secure, and I want to use openvpn to tunnel to a remote secure network. This was working earlier this year, but a number of things have changed and it no longer works. The openvpn tunnel starts up successfully, ip forwarding is in effect, and there is traffic between the various networks, however, none of the devices connected to the ethernet hub can reach the internet thru the tunnel, but they can reach the internet via the WiFi connection.

Test 1 with openvpn tunnel. I can access the internet from the gateway server (traceroute to google.com). I can not access the internet from any system on the Net1 network.


ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: Net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 24:4b:fe:6e:eb:bb brd ff:ff:ff:ff:ff:ff
altname eno2
altname enp3s0
inet 10.168.1.8/21 brd 10.168.7.255 scope global Net1
valid_lft forever preferred_lft forever
3: WNet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 40:ec:99:ef:a9:de brd ff:ff:ff:ff:ff:ff
altname wlo1
altname wlp0s20f3
inet 172.20.2.149/20 brd 172.20.15.255 scope global WNet1
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.2.5/24 brd 10.8.2.255 scope global tun0
valid_lft forever preferred_lft forever

ip route:

0.0.0.0/1 via 10.8.2.1 dev tun0
default via 10.8.2.1 dev tun0
10.8.2.0/24 dev tun0 proto kernel scope link src 10.8.2.5
10.168.0.0/21 dev Net1 proto kernel scope link src 10.168.1.8
128.0.0.0/1 via 10.8.2.1 dev tun0
172.20.0.0/20 dev WNet1 proto kernel scope link src 172.20.2.149
207.244.78.68 via 172.20.0.1 dev WNet1

traceroute google.com on local machine:

traceroute to google.com (172.217.0.46), 30 hops max, 60 byte packets
1 10.8.2.1 (10.8.2.1) 14.834 ms 14.863 ms 14.864 ms
2 v121.ce04.wdc-02.us.leaseweb.net (207.244.125.61) 14.862 ms v121.ce03.wdc-02.us.leaseweb.net (207.244.125.60) 16.411 ms 16.437 ms
3 edm-011.yelaiyehao.com (173.208.126.12) 16.437 ms 16.437 ms 16.436 ms
4 te-0-5-0-4.bb03.ams-01.leaseweb.net (31.31.38.236) 16.435 ms po-102.bb01.wdc-10.leaseweb.net (31.31.38.248) 16.433 ms 16.431 ms
5 72.14.218.226 (72.14.218.226) 19.351 ms 19.349 ms xe-2-2-1.bb04.ams-01.leaseweb.net (31.31.34.1) 19.287 ms
6 72.14.218.226 (72.14.218.226) 19.335 ms 18.013 ms 18.011 ms
7 <snip>

traceroute on machine (10.168.2.1) on Net1 (hangs at first hop which is the gateway server above):
traceroute to google.com (172.217.0.46), 30 hops max, 60 byte packets
1 10.168.1.8 (10.168.1.8) * * *
2 * * * *
3 <snip>

Test 2 same as above except the default route has been change to 172.20.0.1. I can access the internet from the gateway server (traceroute to google.com), and from any system on the Net1 network.


ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: Net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 24:4b:fe:6e:eb:bb brd ff:ff:ff:ff:ff:ff
altname eno2
altname enp3s0
inet 10.168.1.8/21 brd 10.168.7.255 scope global Net1
valid_lft forever preferred_lft forever
3: WNet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 40:ec:99:ef:a9:de brd ff:ff:ff:ff:ff:ff
altname wlo1
altname wlp0s20f3
inet 172.20.2.149/20 brd 172.20.15.255 scope global WNet1
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.5/24 brd 10.8.0.255 scope global tun0
valid_lft forever preferred_lft forever

ip route:

default via 172.20.0.1 dev WNet1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.5
10.168.0.0/21 dev Net1 proto kernel scope link src 10.168.1.8
172.20.0.0/20 dev WNet1 proto kernel scope link src 172.20.2.149
207.244.78.68 via 172.20.0.1 dev WNet1

traceroute google.com on local machine:

traceroute to google.com (172.217.0.46), 30 hops max, 60 byte packets
1 944cad61.cst.lightpath.net (148.76.173.97) 2.730 ms 3.493 ms 3.488 ms
2 944d5ed6.cst.lightpath.net (148.77.94.214) 4.086 ms 4.081 ms 4.075 ms
3 10.138.64.111 (10.138.64.111) 5.316 ms 5.312 ms 5.308 ms
4 10.249.88.83 (10.249.88.83) 5.303 ms 5.299 ms 5.414 ms
5 64.15.3.144 (64.15.3.144) 8.112 ms 8.108 ms 8.105 ms
6 64.15.1.88 (64.15.1.88) 6.350 ms 64.15.3.182 (64.15.3.182) 5.140 ms 64.15.0.218 (64.15.0.218) 5.279 ms
7 <snip>

traceroute on system (10.168.2.1) on Net1 (same as above except for hop 1):

traceroute to google.com (172.217.0.46), 30 hops max, 60 byte packets
1 10.168.1.8 (10.168.1.8) * * *
2 944cad61.cst.lightpath.net (148.76.173.97) 2.730 ms 3.493 ms 3.488 ms
3 944d5ed6.cst.lightpath.net (148.77.94.214) 4.086 ms 4.081 ms 4.075 ms
4 10.138.64.111 (10.138.64.111) 5.316 ms 5.312 ms 5.308 ms
5 10.249.88.83 (10.249.88.83) 5.303 ms 5.299 ms 5.414 ms
6 64.15.3.144 (64.15.3.144) 8.112 ms 8.108 ms 8.105 ms
7 64.15.1.88 (64.15.1.88) 6.350 ms 64.15.3.182 (64.15.3.182) 5.140 ms 64.15.0.218 (64.15.0.218) 5.279 ms
8 <snip>

Misc


net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.WNet1.forwarding = 1
net.ipv4.conf.Net1.forwarding = 1

Question:


Why did Test 1 fail?
Test 2 demonstrates that ip forwarding is enabled.
Test 2 demonstrates that the default route on the remote machine is correct.
The local traceroute demonstrates that the remote tunnel has internet access.

What I notice is that all address used are (large) private address ranges and what I think is going wrong is that a packet with a private range address is forwarded through the VPN tunnel but either the VPN provider drops the packet (because it is an unknown private range address source address) or the packet is forwarded to the destination but that will drop it because the of the private range address

If this is indeed the case, you will need is masquerading.

Thanks. I was too focused on the routing. firewalld, which was doing the masquerading, had not been started.