Different static routes for green/blue network

We need to define different static routes for green and blue network in order to reach the same target network (over different VPN tunnels). A simple static route doesn’t solve this, because it tries to route all traffic through one single gateway. More details:

GREEN network: 192.168.16.0/24, IPFire’s green IP is 192.168.16.254
BLUE network: 192.168.17/24, IPFires’ blue IP is 192.168.17.254

In the green network, there is a gateway (IP: 192.168.16.240) which routes to the network 192.168.0.0/24 connected via VPN tunnel “A”.

In the blue network, there is another gateway (IP: 192.168.17.240) which routes to the same target network as above, but uses a different VPN tunnel “B”.

The IPs of IPFire (192.168.16.254 and 192.168.17.254) act as default gateways for all other devices in the green/blue network.

The goal is:

Traffic from all devices on GREEN with target 192.168.0.0/24 should be routed over 192.168.16.240.
Traffic from all devices on BLUE with target 192.168.0.0/24 should be routed over 192.168.17.240.

How can I realize this in general?

Hi @baruch234.

Pufff, this is very complicated for me. Maybe, somebody can help better than me.

On the other hand, maybe this can help you (thank searching by Google):

Debian / Ubuntu Linux static routing for two interfaces:

Here is an updated config file named /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.9.38.76
        netmask 255.255.255.240
        network 10.9.38.64
        broadcast 10.9.38.79
	### static routing for eth0 that connects to the VLAN ###
        post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.9.38.65
        pre-down route del -net 10.0.0.0 netmask 255.0.0.0 gw 10.9.38.65

auto eth1
iface eth1 inet static
        address 204.186.149.140
        netmask 255.255.255.240
        network 204.186.149.128
        broadcast 204.186.149.143
        ## default gateway for eth1 and the server ##
        gateway 204.186.149.129
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 10.0.80.11 10.0.80.12
        dns-search nixcraft.in

You have to adapt it to your needs. I don´t now this can work in IPFire.

I just hope it helps you :+1:.

Regards.

:thinking: I think maybe you can try

On hosts in GREEN network,
add static route to 192.168.0.0/24 subnet via 192.168.16.240
and
On hosts in BLUE network,
add static route to 192.168.0.0/24 subnet via 192.168.17.240

for example
ip route add 192.168.0.0/24 via 192.168.16.240 dev eth0

Let us know what the effect is.

Thanks a lot for your hints/references. I tried the following with IPFire:

ip route add 192.168.0.0/24 dev green0 via 192.168.16.240

… this is accepted, but after entering

ip route add 192.168.0.0/24 dev blue0 via 192.168.17.240

I received

RTNETLINK answers: File exists

so, this way, it is not possible to define two different static routes bound to different adapters. Meanwhile, I found a solution which does not 100% meet my needs, but is working:

[1] set one static route via GUI
192.168.0.0/24 via 192.168.16.240 dev green0 proto static

[2] set apropriate firewall rules to allow

  • outgoing traffic from GREEN to 192.168.0.0/24
  • outgoing traffic from BLUE source-natted over GREEN to 192.168.0.0/24

This allows all devices on GREEN & BLUE network to connect to 192.168.0.0/24. But devices on both source networks will always use (share the bandwidth of) the same VPN tunnel.

For the single device that needs high bandwidth - explicit: should use both VPN tunnels simultaneously - I set static routes on the device itself, which has different network adapters in both networks GREEN & BLUE.

:thinking: Below I show how I understand my hint

Hi @tphz,
thanks for your reply. I understand. This way every device that is connected to both networks (GREEN & BLUE) is able to use both gateways simultaneously. The problem is, that this solution is not very flexible. We have devices, that:

  • connect only to one of both networks or to both networks
  • have single/multiple NICs in the network
  • are very simple and don’t allow static routes to be applied (e.g. power supply components)

So my initial idea was to apply the additional route only to IPFire as it acts as the central gatway. This would have offered the freedom not to reconfigure every device on the two networks individually.

We have one single device that absolutely needs (and is able) to use both gateways simultaneously/load balanced. For this device I realized just the porposal you made. This works fine.

As a conclusion, it seems to be impossible to set something like a conditional route to IPFire…