2

I have a couple router/firewall boxes (pfSense, TMG 2010, ISA 2006) on my network that are stateful. Right now they all have an interface on the same subnet as most end user devices and servers. I will be making some changes and putting some servers on their own subnets behind these firewalls so I'm wondering if I should set up one dedicated subnet for the routers to route packets to each other through. There are no routing protocols, only static routes.

I'm trying to avoid asynchronous routing which can be a problem for stateful firewalls since traffic flows in a different path into and out of the network. If traffic flows back through a different path and the firewall in that path does not have a record in the state table then the traffic could get blocked.

My basic question is this: is this an ideal way to approach this problem? Why or why not? I have not been able to find much in terms of best practices but this approach would leave only one router on each subnet so I would avoid the current situation of different machines having different default gateways.

Current

Router 1              Router 2              Router 3
192.168.1.1/24 ------ 192.168.1.2/24 ------ 192.168.1.3/24 ------ All other devices
       |                     |                      |
       V                     V                      V
10.10.10.1/24         10.20.20.1/24         10.30.30.1/24

Proposed

Router 1              Router 2              Router 3
192.168.1.1/24                                              ------ All other devices
10.200.200.1/24 ----- 10.200.200.2/24 ----- 10.200.200.3/24 ------ Routers/Firewalls only
       |                     |                      |
       V                     V                      V
10.10.10.1/24         10.20.20.1/24         10.30.30.1/24
Oliver
  • 33
  • 6

2 Answers2

1

Following on from my comment, something like this

      +----------+    +----------+   +----------+
      | Router 1 |    | Router 2 |   | Router 3 |
      +-------+--+    +----+-----+   +--+-------+
              |            |            |
              |            |            |10.200.200.0/24
              |            |            |
           +--v------------v------------v-+
           |           Router A           +-------------+
           +-+---------+---------------+--+             |
             |         |               |                |
             |         |               |                |
             |         |               |                |
+------------v-+ +-----v-------+ +-----v-------+ +------v------+
|192.168.1.0/24| |10.10.10.0/24| |10.20.20.0/24| |10.30.30.0/24|
+--------------+ +-------------+ +-------------+ +-------------+

Router 1 = 10.200.200.1

Router 2 = 10.200.200.2

Router 3 = 10.200.200.3

Router A = 10.200.200.254

This way, each of the networks at the bottom only has 1 router, and therefore 1 default route. The edge routers only need 1 internal route to access the internal subnets.

The internal router does become more complex because it needs to be aware of the multiple upstream routers, and keep track of connections to avoid the async routing. The benefits are worth it I believe: All the complexity is contained to that router, with the rest kept simple. And you can have full control over the multiple connections on that host. For example, you can NAT traffic from all 3 connections to the same internal server, but the server doesn't need to know any of that, the internal server will track each connection and route the traffic appropriately to avoid async.

This is very similar to the setup at my work, except we only have 2 upstream connections. Router A is a pair of Linux boxes running in H/A. Tracking of the connections is done using Policy Based Routing. The best guide I've found for PBR is: http://www.cyber.com.au/~twb/doc/dual-uplink.txt

fukawi2
  • 5,494
0

I would say you're introducing an extra level (literally) of complexity.

I'm assuming your async routing issues come from the situation eg 192.168.1.55 sends a packet to 10.20.20.55 but doesn't have a route for it via 192.168.1.2 so sends it via it's default at 192.168.1.1 where it gets redirected to 192.168.1.2. The reply packet then goes directly from 192.168.1.2 to the original source, so 192.168.1.1 only see's the client to server packets, not the server to client packets.

In my environments, I avoid the firewall issue with async routing by adding a rule to allow bounce routing (anything in and out the same interface == same layer 2 == allow). You're not introducing any security issues since the src and dst of a packet are on the same layer 2 and can talk directly to each other anyway, you're just "encouraging" performance issues by routing sub-optimally.

fukawi2
  • 5,494