Avoid Asymmetric Routing in Load Balancing (pfSense example)


My previous blogs Use pfSense to Load Balance Web Servers (1) and Use pfSense to Load Balance Web Servers (2) introduced the deployment of pfSense as load balancer to distribute web traffic to backend server nodes (i.e. Clst1-S1 and Clst2-S2; Clst2-S1 and Clst2-S2). pfSense hosts Server Cluster 1’s virtual IP and Server Cluster 2’s virtual IP

In the previous lab, when we accessed from internal Mgmt PC (, the traffic was successfully load balanced to either Clst1-S1 ( or Clst1-S2(

Failed Scenario

However, I received a question that when access from Mgmt2 (diagram below) which is in the same subnet as the backend nodes, Mgmt2 cannot reach the web service.

Mgmt IP: (successfully accessed
Mgmt2 IP: (failed to access
Cluster 1 VIP:
Cluster 1 Node 1 IP:
Cluster 1 Node 2 IP:

I replicated the failed scenario and observe the following:pfSense_mgmt2_failed.png

Asymmetric Routing

What is the difference between access the web service from Mgmt and Mgmt2?

Mgmt PC is external to the web service subnet. When the user requests to access, the traffic reaches pfSense load balancer, and then forwarded to either Clst1-S1( or Clst1-S2( Let’s assume Clst1-S1 responses to the request this time. Since Mgmt PC is in a different subnet (, the return traffic reaches its default gateway on pfSense ( first, and then routed to Mgmt PC.

However, Mgmt2 PC is internal to the web service subnet. When the user requests to access, the traffic reaches pfSense load balancer, and then forwarded to Clst1-S1 ( Since Mgmt2 PC is in the same subnet as the web servers (, the return traffic goest to Mgmt2 PC directly via SW1, without transiting through the default gateway on the load balancer.

Asymmetric routing occurs. Although some devices have tolerance on asymmetric routing,  these days, we still try to avoid whenever we can. For example, F5 load balancer allows asymmetric routing but it will limit the features. Asymmetric routing also adds network complexity and security concerns.

SNAT as Solution

If the business requirement says the user must have access to the web service from the same subnet, then SNAT can be a solution to avoid the asymmetric routing problem.

pfSenseLB translates the source IP of the traffic initiated from Mgmt2 from to In this case, when Clst1-S1 receives the traffic from Mgmt2, it will response to, which forces the return traffic through pfSenseLB. pfSenseLB then translates back to and sends to Mgmt2.


The following screenshot demonstrates SNAT configuration details on pfSense.

After the SNAT, we can successfully access from Mgmt2 now.

NAT hit can be checked using shell command ‘pfctl -vvs nat’.


Be careful of asymmetric routing in load balancing design. For example, one-arm and multi-path (nPath) design may involve asymmetric routing. The selection of design models depends on business requirements. SNAT is a potential solution to asymmetric routing problem.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s