Intro

This article will describe a scenario when traffic is not flowing in the direction the firewall expects based on it’s configured routing table. This is commonly known as asymmetric routing. First the scenario will be explained, then what the problem is and what happens and lastly there will be given an example on how this scenario can be solved using Policy Based Routing.

Scenario

The scenario/setup is as shown in the below schematic. We have a firewall with the public IP 198.51.100.10 assigned to it’s WAN Ethernet interface. Behind the firewall we have two additional interfaces, the DMZ and behind the DMZ there is a Webserver with a private IP. Behind the LAN interface there is a router that is configured with a public network, so the router in this scenario will NOT perform any address translations when clients need to connect to e.g. the Internet. Internet access for the clients behind the router will not go through the firewall but rather directly through the router who has its own interface/connection to the Internet.

The routing table in the firewall is configured like this:

• Route WAN all-nets GW=198.51.100.1
• Route WAN 198.51.100.0/24
• Route DMZ 172.16.1.0/24
• Route LAN 192.168.1.0/24
• Route LAN 203.0.113.0/24 GW=192.168.1.2

What is a bit unusual here is that the firewall routing table is configured with instructions that the public IP network 203.0.113.0/24 is located behind a router situated behind the LAN interface of the firewall and that is the reason for the unusual packet flow.

The problem

What the client want to do in this scenario is to connect to the Webserver by connecting to the public WAN IP of the firewall (198.51.100.10). The firewall performs address translations and translates the public IP 198.51.100.10 to the internal IP of the Webserver (172.16.1.10). The process works fine according to the Green arrows until the client source IP (203.0.113.10) arrives on the WAN interface. 

This is unexpected by the firewall as according to it’s routing table and this particular route will match:

• Route LAN 203.0.113.0/24 GW=192.168.1.2

This IP address should only arrive from the LAN interface, not the WAN. The firewall will in this case determine that this is a routing fault and drops the packet due to “Default_Access_Rule”. For more information about “Default_Access_Rule”, see the following KB article: https://kb.clavister.com/324735778/the-meaning-of-the-default-access-rule-log-entry

Using an Access Rule

The issue can in some cases be solved by creating an Accept ACCESS rule to allow the 203.0.113.0/24 network to be accepted on the WAN interface (basically overriding the Default_Access_Rule routing check for this network). But in this scenario it would unfortunately not be enough as shown in the below image.

The packet comes a little further in the process and reaches the Webserver. The Webserver replies back to the client (203.0.113.10) by replying to it’s default gateway (which is the firewall, blue arrow).

Now things go wrong again, the firewall performs a reverse route lookup to determine where to forward the response and according to it’s routing table, this route matches:

• Route LAN 203.0.113.0/24 GW=192.168.1.2

The packet is then forwarded to the router (red arrow) and the client who gets confused why it gets a packet from an IP it has not observed before (172.16.1.10), the client will drop the packet.

Using an Access rule would not be enough to solve this scenario, the Access rule can then be removed and we then look into another solution involving Policy Based Routing.

The solution

The solution to this problem will be to use Policy-Based Routing to create a override condition to allow the incoming packets from the client to be allowed to arrive on the WAN interface and making sure the reply packets returns the same way they came in.

Step-1: Create a new routing table with Ordering = Only. This is done under Network->Routing→Routing Tables→Add.

Step-2: Open the newly created routing table (lets call it MyTable) and add the following routes to it:

• Route WAN all-nets GW=198.51.100.1
• Route DMZ 172.16.1.0/24

This route in the <main> routing table should not be changed. It is basically an identical copies placed in the new routing table.

The route towards DMZ is needed for the firewall to be able to forward the request to the internal Webserver. Since ordering Only is set on the routing table it will cause the lookup to “stay” in this routing table (based on the PBR rule in this case), meaning the location of the Webserver must be included in the routing details.

Step-3: Create a new Policy-Based Routing rule. This is done under Network->Routing->Policy-Based Routing Rules. The rule should look as follows:

• Forward Routing Table = MyTable
• Return Routing Table = MyTable
• Source Interface = WAN
• Source Network = 203.0.113.0/24
• Destination Interface = Any (or Core)
• Destination Network = IP_WAN (198.51.100.10)
• Service=HTTPS

Step-4: All done, the configuration can now be deployed.

As shown in the picture below, the packet flow will now move according to the blue arrows. The PBR rule basically creates an override with the conditions lined out in the PBR rule parameters. If the conditions are fulfilled, the PBR rule will trigger, pick up the packet and place the packet(s) in the MyTable routing table.

When the Webserver replies, the only matching path (route) back to the client (203.0.113.10) will be by using the following route in MyTable:

• Route WAN all-nets GW=198.51.100.1

And the problem is then solved.

Related articles