Although this recipe demonstrated how to configure a basic static route, we glossed over a rather important detail involving asymmetric traffic. Suppose there is a node on the LAN network with an IP address of 192.168.1.3.

Assume this node wants to establish a session with a node on the DMZ network with an IP address of 192.168.2.3. So far, so good: the LAN default gateway is 192.168.1.1, and pfSense uses our newly created static route to send the packet to the gateway at 192.168.1.2, ensuring that the packet reaches its destination on the 192.168.2.0/24 network. An entry is added to the state table.

The return traffic is a different story. Return traffic will ultimately pass through the DMZ's gateway at 192.168.1.2, and from there to 192.168.1.3, which will be recognized as a LAN net address. Thus, while the original packet was inter-network traffic (LAN to DMZ), the return traffic is seen as intra-network traffic by pfSense (LAN to LAN). The return traffic is thus never filtered by pfSense, since pfSense only filters traffic between networks. As far as pfSense is concerned, the packet never received a response; the connection was never completed, the entry is dropped from the state table, and the connection between 192.168.1.3 and 192.168.2.3 is dropped.

There are two ways to deal with this scenario. One is to ensure that traffic that enters and leaves through the same interface is not checked by pfSense. In our case, all traffic between the two nodes enters and leaves via the LAN interface, so it would work. We can do this by following these steps:

1. Navigate to System | Advanced.
2. Click on the Firewall & NAT tab.
3. Check the Static route filtering checkbox.
4. Click on the Save button.

Another possibility is to create firewall rules to cover both the sending of packets to the DMZ node and the return traffic. We won't discuss this solution in detail, but any attempt to solve the problem in this way would include the following elements:

1. A LAN network rule to cover traffic from the LAN to the DMZ, specifying as the destination the DMZ gateway (192.168.1.2).
2. A floating rule to cover return traffic, specifying as the source the DMZ gateway.
3. Both rules should use the Sloppy option for State type, which will cause pfSense to perform a less strict state match on return traffic.

At a minimum, you should consider using the Static route filtering option in situations such as this. While adding static routes is often unavoidable, hopefully this digression illustrates why we try to avoid static routes when possible.