We may have local networks that are reachable through a router other than pfSense's default gateway. In such cases, we need to configure a static route. To illustrate this, we will present a simple example of a router connected to the LAN network.

In this case, the LAN interface has an IP address of 192.168.1.1; this is a static IP address. We also have the DMZ router connected to the switch for the LAN network. DMZ's WAN-side interface has an IP address of 192.168.1.2 (assume this is also a static IP address). DMZ is not directly connected to pfSense, and the DMZ network is not reachable through pfSense's default gateway. In fact, the gateway will block the DMZ's packet, since as a WAN interface, it has been configured to block private networks. In order for routing to the DMZ network to work, we must define a static route.

To set up a static route, we must first add 192.168.1.2 as a gateway and then add a static route to that gateway. The process is relatively easy:

1. Navigate to System | Routing. The default tab should be the Gateway tab.
2. On the Gateway tab, click on Add.
3. On the gateway Edit page, select the correct interface using the Interface drop-down box, matching the interface on which the gateway resides (in our case, LAN).
4. Enter an IP for monitoring the gateway in the Monitor IP edit box, if desired. This will help pfSense mark the gateway as down, if it stops responding to pings from the IP address entered.
5. Enter a brief, nonparsed description in the Description field, if desired.
6. When done, click on the Save button and on the main Routing page, click on Apply Changes.
7. We now have our gateway, but we need to add a static route. To do so, click on the Static Routes tab and click on the Add button.
8. On the static routes Edit page, enter the network that will be reached, as well as the correct CIDR, in the Destination network edit box (in our case, it would be 192.168.2.0/24).
9. In the Gateway drop-down box, select the gateway you created in steps 1-6.
10. Again, you may enter a brief description in the Description field.
11. When done, click on the Save button.

pfSense now has a route to the DMZ router, which is good. However, there is a problem with this configuration. As an example, imagine that there is a node attached to the LAN switch and that this node has an IP address of 192.168.1.3. This node is trying to establish a session with a node on the DMZ router that has an IP address of 192.168.2.3.

The LAN node's default gateway should be the LAN interface IP, that is, 192.168.1.1. It therefore sends packets whose destination is 192.168.2.3 to pfSense, which in turn uses the static route we just created to send packets to the DMZ via the 192.168.1.2 gateway. When the DMZ node sends return traffic, however, it won't find 192.168.1.3 on the local network, and then will try the default gateway (192.168.1.2). The LAN switch, seeing that the target node is on the LAN, will forward the packets to 192.168.1.2 without the intervention of pfSense, as pfSense only filters traffic between networks directly connected to it. As far as pfSense is concerned, the connection was never completed. Thus, the entry gets dropped from the state table and the connection between the LAN node and the DMZ node gets dropped. This diagram illustrates the asymmetrical routing that takes place.

Yet another possibility is a situation you may have with ICMP redirects. This is a type of redirect that is sent by a gateway when it knows a more direct route to a destination. If the sending node allows such redirects, then their routing table will temporarily add the new route. Again, consider the example in which our LAN node at 192.168.1.3 tries to communicate with our DMZ node at 192.168.2.3. The request goes through the LAN's default gateway and reaches pfSense. Since pfSense realizes there is a more direct route to 192.168.2.3 via 192.168.1.2, it sends an ICMP redirect back to 192.168.1.3, informing it of this more direct route. At the same time, it sends the initial TCP SYN packet to 192.168.2.3 via the static route; pfSense also creates a state table for this entry. All subsequent communication between 192.168.1.3 and 192.168.2.3, however, will take place through the DMZ gateway (192.168.1.2). pfSense will not see this traffic, since as far as it is concerned, it is intra-network traffic. The state table entry created for this connection will eventually expire and be deleted. If the ICMP redirect-learned route between 192.168.1.3 and 192.168.2.3 expires as well, then 192.168.1.3 will send the next packet after its expiration to pfSense. Since this is not a packet establishing a new connection, pfSense will reject it. The connection between 192.168.1.3 and 192.168.2.3 will then be dropped.

There are two ways we can deal with these situations. One is to navigate to System | Advanced, click on the Firewall & NAT tab, scroll down to Firewall Advanced, and enable the Static route filtering option. If this option is enabled when one or more static routes have been defined, traffic that enters and leaves through the same interface will not be checked by pfSense. This would apply to traffic sent to 192.168.2.3 from 192.168.1.3, since it enters through the LAN interface (192.168.1.3) and exits via a static route that again sends it to the LAN interface (192.168.1.2).

Enabling this option will solve the immediate problem, but it will also apply to all cases in which traffic enters and leaves through the same interface, not just this instance. It would be better if we had a rule that only applied to interfaces that have static routes associated with them. We can get this done by creating two rules: a rule on the interface through which the static route passes, and a floating rule that will cover the return traffic. This can be done by following this procedure:

1. Navigate to Firewall | Rules and click on the tab of whichever interface the static route passes through (in our example, it would be LAN).
2. Click on one of the Add buttons at the bottom of the page to add a rule.
3. Make sure the Action drop-down box is set to Pass (the default) and the Protocol drop-down box is set to TCP (also the default).
4. The Source should be set to match the setting in the Interface drop-down box (in our example, it would be LAN net).
5. For Destination, choose Single host or alias in the drop-down box. In the adjacent edit box, enter the IP address of the static route's gateway (in our example, it would be 192.168.1.2).
6. Scroll down to the Extra Options section and click on the Show Advanced button.
7. In the Advanced section, set the TCP Flags option to Any Flags. This will cause the rule to match traffic on the interface regardless of what TCP flags are set or not set.
8. In the State type drop-down box, change the setting to Sloppy. This will cause pfSense to perform a less strict state match on return traffic.
9. When you are done making changes, click on the Save button. You should place this rule at the top of the firewall rules table for the interface to ensure that it always gets applied.
10. The next step is creating a floating rule for the return traffic. To do this, click on the Floating tab, and from that tab, click on the Add button.
11. Again, make sure the Action column is set to Pass, and that Protocol is set to TCP.
12. In the Interface listbox, the same interface selected in the first rule should be selected (in our example, LAN).
13. The direction set in the Direction drop-down should be set to out.
14. As with the first rule, scroll down to Extra Options and click on the Show Advanced button.
15. Set the TCP Flags option to Any Flags.

16. Set the State type to Sloppy.
17. When you are done, click on the Save button, then on the main Rules page, and finally on Apply Changes. You now have rules covering traffic in both directions.

One other potential issue that may arise is nodes on our DMZ network trying to connect to the internet. Our static routes and firewall rules have taken into account the asymmetric nature of sessions between the LAN and DMZ. Yet we didn't consider what happens if the DMZ tries to connect to the internet, and it will likely fail. This is because the default Allow LAN to any rule only matches traffic whose source is the LAN net. While this rule may be entirely consistent with your intended policy, you may, after all, want to keep nodes on the DMZ from accessing the internet. If you want to change this outcome, you will have to change the default allow rule. Specifically, you will have to alter the source setting from LAN net to any, so that LAN traffic can pass to the internet regardless of its source.