The Router Trinity

There are technically two separate companies housed in the suite, with separate subnets set up for themselves, but they wanted to be able to exchange data at some point in the past.  The link between the two networks is accomplished by no less than three consumer-grade "cable/dsl routers."

Let's start with a picture so you have something to boggle at:

Internally, each company runs on a /24 randomly placed in the 10.0.0.0/8 private IP space, so each company's addresses aren't routable on the public Internet.  (Also, it's a gross abuse of a class A private network range.)  The two companies also have separate networking hardware, so company A's internal traffic doesn't consume company B's bandwidth.

The problem comes when someone in company A needs access to a system in company B.  R1 (visible on network A at 10.1.1.1) is a consumer-grade device, only capable of handling one subnet on its LAN ports, and one uplink.  Thus, traffic destined for network B gets matched by a static route and redirected to R2 to act as gateway.

Now R2 can receive the packets, but we've spent its only LAN subnet allocation on company A's subnet space... but unlike R1, R2's unoccupied uplink can be connected to company B.  There's only one problem with a direct link at this point: these are consumer-grade devices.  To protect the Internet at large, they recognize private IP ranges, and don't allow them to be assigned to the uplink.

To change the network again, the same trick is used: R2 passes traffic over an address that isn't on network B to another such bogus address on R3's uplink.  Again, R2 gets a static route, this time to direct 10.250.1.0/24 via gateway at 3.4.5.1.  By the time it gets down to R3, it has the correct address for the LAN-side network (which is company B), which R3 mysteriously accepts.

I would think that a device that prevented itself from getting a private IP on its uplink would also refuse to route private traffic that came in over an uplink, but this is apparently not the case.  My best guess is that this isn't firewalled, in case the routers are doing VPN termination on behalf of the private network—once decrypted, the VPN source will be a private IP whose route maps back to the uplink.  Or, R3 just knows to expect that because it has a static route set up for traffic returning to network A.  It's hard to say, because R3 died today, so I couldn't get in and look at it.

There's another set of static routes in all this, to bring traffic back from company B to company A.  Presumably, company B's default gateway recognizes the subnet for network A and forwards (exactly as R1 did) to R3, which has a route set to forward to R2, which probably has another static route to forward to R1.  R1 may even have a static route to send network A's traffic into the switch, again on a LAN port.  I don't think any of the routers' bridge tables are big enough to really handle connecting a whole network to it, even if it's only visible on one port.

Now you might be wondering about the bogus public IPs linking R2 and R3.  What happens if anyone in the company tries to access those addresses?  That traffic goes to either R1 or Gateway B, which don't have any routes for them, so they forward to the public Internet and traffic goes to its intended destination.  R2 and R3 don't handle any traffic destined for the outside world, so their addresses also don't clash with anything they're forwarding.


One triple-NIC Linux machine (one port for each subnet's switch, and one uplink for network A) could do the job with fewer hardware units and one less cable, but they couldn't be had for under $200 when company A was being launched.  It hadn't accumulated any spare hardware yet.