Asymmetric routing means that the request packets are sent to one gateway, but the response packets are received from another gateway, that is, the returning packets are taking a different path. Normally this wouldn’t be problematic as the end devices don’t really care about which gateway they receive the packets from. However, asymmetric routes become a problem when NAT is used or having a firewall in between the network. When a firewall receives a response packet that it’s unaware of the original flow, it may consider the response packet invalid and drops it.

Scenario

Let’s put it into perspective. What would happen when PC1 try to ping PC2?

asymmetric_routing.jpg

Cause

As you can see from the diagram, PC1 will send ICMP echo request packets to its gateway Firewall 1. Firewall 1, having both VLAN2 and VLAN3 IP configured, will inter-vlan routing the packets directly to PC2; PC2 received the request packets, will send out ICMP echo reply packets to its gateway Firewall 2. Firewall 2, having never heard of the ICMP echo request, would consider the reply packets invalid and drop it. On PC1’s terminal window, you will probably see “Request timed out” because it never received the response packets.

Now that we understand the cause, how should we resolve it? Perhaps you may find this topology ridiculous, but I’ve actually seen it in real world. And it might be difficult to wrap you mind around the problem not having the diagram drawn out. But now that we have, it might become obvious to how to resolve this asymmetric routing issue. The following are a few measures that I have on top of my mind:

Solution

  • Remove VLAN3’s IP 10.3.3.254 from Firewall 1, so that traffic from VLAN2 won’t be directly inter-vlan routed to VLAN3. Then configure a static route telling the firewall 1 to route 10.3.3.0/24 via gateway 10.2.2.253: ip route 10.3.3.0 255.255.255.0 10.2.2.253. But then you would also have to remove VLAN2 on firewall 2.

    If there are end devices also using Firewall 1’s VLAN 3 10.3.3.254 as gateway, then this solution wouldn’t be feasible.

  • It might be possible to enable asymmetric routing on some firewall so that the firewall won’t drop the packets. But doing so introduce security risks as well as unexpected NAT behaviour.

  • Add an unused VLAN with a new subnet between firewall 1 and firewall 2. For example, you may use VLAN101 with subnet 192.168.101.252/30 on the network. Then configure interface vlan 101 on firewall 1 with the IP 192.168.101.254; Also, on Firewall 2 with the IP 192.168.101.253. Then configure a new static route on both Firewall. For example:

      Firewall 1: ip route 10.3.3.0 255.255.255.0 192.168.101.253
  Firewall 2: ip route 10.2.2.0 255.255.255.0 192.168.101.254

    I think this is the best way to address this situation because there are minimal side effects as it doesn’t affect any hosts inside the network.

  • Deploy policy-based routing. As policy based routes precede routes from normal routing table, you can tell Firewall 1 to force source address 10.2.2.0/24 destination address 10.3.3.0/24 to route to firewall 2 gateway 10.2.2.253, so that the packets will go through firewall 2 first.

    Sometimes there are topologies that don’t even use 2 VLAN or subnets. Just 1 subnet with hosts pointing to 2 different gateways. Then option 4 would remain feasible. But you would have to policy-route every individual hosts that use Firewall 2 as gateway on Firewall 1; And on firewall 2 policy-route hosts that use Firewall 1 as gateway 1.

If the reason behind having two gateways on the same network in the first place is for high availability. Then I’d suggest using FHRP such as VRRP, HSRP, or GLBP. That way you can have a few gateways serving a single virtual IP while reducing the complexity of the network and adding resilience.