I have two different networks (separate LANs), each with their own ISP gateway, that I want to cross (users from one LAN to reach the other LAN). The ISP gateways are stupid branded home gateways without any fancy functionalities (e.g. static routing).

Basically the current topology is:

LAN1 -> ISP_G1 -> WAN
LAN2 -> ISP_G2 -> WAN

I want to be able to cross the LANs but keeping the WAN traffic to each one of them. My idea is to use a Linux machine as a router/dhcp server, in order to keep WAN connectivity to each LAN, but also be able to e.g. ping from one LAN to another.

The topology that I am trying this is:

WAN -> ISP_G1 -> LAN1/Switch1 -> Linux/Router <- LAN2/Switch2 <- ISP_G2 <- WAN

The Linux/Router machine has two Ethernet interfaces, each connected to the different LANs, and also serves as the DHCP server giving two different subnets to the clients from each LAN.

The addressing is the following:

Linux/Router machine:

ISP gateways:

DHCP in the ISP gateways is turned off, instead the Linux machine is the DHCP server giving IPs to clients according to the different subnets e.g. and Also it tells to the clients that their gateway is not the ISP gateways but the Linux machine itself, e.g. for LAN1 and for LAN2.

My problem is that only one LAN can have access to both subnets and their WAN, and this depends on which WAN gateway is configured on the Linux machine.

For example: If the Linux machine is configured with ISP_G2 as its gateway, LAN1 can access LAN2 but cannot access the WAN, and vice versa.

I am trying to designate a different gateway based on route tables on the Linux machine e.g.:

ip route add default via dev eth0 table subnet1
ip rule add from table subnet1

But then while LAN1 can access the WAN through the ISP_G1, it can no longer access LAN2.

What I need is a way to change the LAN1 gateway to ISP_G1, ONLY for traffic that is meant for the WAN, and keep the Linux machine as the LAN1 gateway for all LAN related traffic.

Any pointer is greatly appreciated

  • "it tells to the clients that their gateway is not the ISP gateways..." Why? The clients should still be told that the ISP gateways are their default gateways (as I understand your topology), but in addition you'll want to push a static route to each LAN giving the linux router as the specific gateway for the other subnet. Traffic destined for the outside world shouldn't need to be relayed through the inter-lan router. – user4556274 Aug 12 '16 at 15:05
  • But I cannot set a static route on the ISP gateways. For example if the LAN1 gateway is ISP_G1, then I cannot cross to LAN2. As such if a client on LAN1 pings LAN2, ISP_G1 will not know what to do with the packet. Adding a static route manually for each client is not a viable option. People should just connect and be ready to go via DHCP. Thanks. – Xavi Aug 12 '16 at 15:12
  • DHCP option 121 is the option for pushing static routes from your DHCP server to each client. You don't need to configure them manually on each client. – user4556274 Aug 12 '16 at 15:15
  • Thanks for the pointer, DHCP classless static routing did indeed the trick. Although I found out that not all DHCP clients support that extension by default, hopefully this will not be a major problem. – Xavi Aug 13 '16 at 1:50

I think source routes should make it possible, but you'd need to create all routes explicitly for both networks, that is, both the default route and a route for the other network. Something like this:

ip route add default via dev eth0 table subnet1
ip route add dev eth1 table subnet1
ip rule add from table subnet1

Same for the other block, and a default route for the central box itself.

The other option would be to tell DHCP to give the clients both a default route, and a static route to the other network block. Thus, they would talk to their own internet gateway without going through the central box, and only go through the center to get to the opposite side.

There are mentions of option classless-static-routes in the context of dhclient, but the ISC DHCP server doesn't seem to support that directly.

Instead the option may need to be inserted manually. There are some examples for this here, but the explanation on the format is slightly brief. RFC 3442 describes the format under "Classless Route Option Format".

  • "but you'd need to create all routes explicitly for both networks" That's not the only drawback to routing based on source IP. If you do that then regardless of which interface a particular host wants to use it'll still go out the interface you specify. Where I work the ssh/management interface is segmented from the production interface. So if there's a website you manage you would have to choose between being able to ssh and being able to view the website. Without PBR, you'd have to go to a completely different machine just to get to a different port number. – Bratchley Aug 12 '16 at 19:10
  • As user4556274 also mentioned, DHCP option 121 seems to do the trick. At some point I might try source routing rules, if I discover issues with DHCP clients. – Xavi Aug 13 '16 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.