Routing between 7 (seven!) subnets, 2 of them have dynamically assigned IPs

Question

I am using RaspberryPi (Raspbian OS) in an extremely complex routing scheme, which I could manage until number of subnets was five :)

Currently, I have the following interfaces, as shown by ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.1.251  netmask 255.255.255.0  broadcast 192.168.1.255
eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.44.1  netmask 255.255.255.0  broadcast 192.168.44.255
    ether b8:27:eb:b9:ca:47  txqueuelen 1000  (Ethernet)
eth0:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.45.1  netmask 255.255.255.0  broadcast 192.168.45.255
    ether b8:27:eb:b9:ca:47  txqueuelen 1000  (Ethernet)
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.35.0.74  netmask 255.255.255.255  destination 10.35.0.73
tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.35.0.18  netmask 255.255.255.255  destination 10.35.0.17
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.42.1  netmask 255.255.255.0  broadcast 192.168.42.255
wlan1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    inet 192.168.46.1  netmask 255.255.255.0  broadcast 192.168.46.255

eth0 provides internet access to the outside world (fixed IP)

tun0 and tun1 are the VPN interfaces to different VPN servers, they get dynamically assigned IPs from their respective server (this seems to be the core problem)

wlan0 and wlan1 are wifi networks (functioning as access points!) that should route all of their traffic through tun0 and tun1, respectively

eth0:1 and eth0:2 are the interfaces that share the hardware with eth0 (only one Ethernet port on RaspberryPi) and should provide the same functionality as wlan0 and wlan1, but to a wired clients.

DHCP server is run on RaspberryPi to assure that wlan0 and wlan1 give out adresses in their respective classes to their wireless clients. No DHCP is provided on the shared wire, of course -- I configure each client device to route their traffic either through 192.168.44.1 or 192.168.45.1, depending to which VPN (or no VPN) I want them to be connected to.

If it is not crystally clear, here are all the networks I have to deal with:

eth0, 192.168.1.1/24 (upstream internet)

eth0:1, 192.168.44.1/24 (downstream wired clients going through tun0)

eth0:2, 192.168.45.1/24 (downstream wired clients going through tun1)

tun0, 10.35.0.74/32 (first upstream VPN)

tun1, 10.35.0.18/32 (second upstream VPN)

wlan0, 192.168.42.1/24 (downstream wireless clients going through tun0)

wlan0, 192.168.46.1/24 (downstream wireless clients going through tun1)

Note, that this is current configuration with bold IPs provided by the VPN servers.

The problem is denoted in bold - the IPs, provided by the VPN server change dynamically after every reconnection (even if they don't, they could). For me, it is pretty easy to figure out even such multi-way routing if all adresses are fixed. With one VPN, one wireless, and eth0:1 is also easy, as the VPN server pushes the default route when connecting and the rest is easy. In any case I know to set up a NAT for one wifi being routed to one VPN

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

as shown here:

https://pimylifeup.com/raspberry-pi-vpn-access-point/

However, to have two VPN connections I have to prevent the server from messing with my routing, of course I can do that with:

pull-filter ignore redirect-gateway

in VPN client configuration files.

After I do this, I am lost. Traffic is obviously not routed to tun0 or tun1. The difference between the VPN server and me is that server can push the exact route as it knows the exact ip of the VPN interface (server determines it), and I don't know!

I tried to set up routing using the iptables, based purely on network device names, but I have been unsuccessful so far. Can anyone suggest the correct route (sic) I can take to set up this routing?

Answer 1

The difference between the VPN server and me is that server can push the exact route as it knows the exact ip of the VPN interface (server determines it), and I don't know!

You don't need to. The 'tun' interfaces created by your VPN client are "layer 3" interfaces and don't use the route gateway address for anything at all – you would get the same result by simply routing traffic through the whole device. For example:

ip route add <dstA>/24 dev tun0
ip route add <dstB>/24 dev tun1

Or if you want it to be based on client IP address:

ip route add 0.0.0.0/0 dev tun0 table 10
ip rule add pref 100 from 192.168.44.0/24 lookup 10

(On layer-2 interfaces such as Ethernet, Wi-Fi, or 'tap', the same interface connects you to multiple local devices based on what MAC address you send the packets to. The 'gateway' or 'via' address that you specify in routes is used for one thing only: it gets resolved to a MAC address.

Layer-3 interfaces such as 'tun' or 'ppp', however, do not have MAC addressing at all – they have only two ends and there's no distinction between "on-link" and "distant" hosts. So there's no need for the route to have a gateway, because no matter what you send, the packets always reach the same destination, in this case the VPN server.)

Finally, if you did need to know the default gateway address, you can have the VPN client tell you – e.g. OpenVPN supports --up scripts which receive all information regarding network configuration.

eth0:1 and eth0:2 are the interfaces that share the hardware with eth0

They are lies that ifconfig is telling you for historical reasons. These "alias" interfaces haven't actually existed on Linux for a long time; nowadays the OS manages them as a single eth0 interface which simply has multiple addresses assigned to it.

On another note, for the same reason as in the previous section, there's no real difference between your clients using eth0:1 and eth0:2 as their gateway – both of their IP addresses resolve to the exact same MAC address. The packets can only be distinguished by the clients' own source IP address.