When we have local networks that are reachable through a router other than pfSense's default gateway, we need to configure a static route. A simple example of this situation is a router that is connected to the LAN network. The following diagram illustrates this scenario:

In this scenario, the LAN interface has a static IP address of 192.168.1.1. The DMZ router is connected to the LAN switch and DMZ's WAN interface has an IP address of 192.168.1.2. DMZ is not directly connected to pfSense, and the DMZ network is not reachable through pfSense's default gateway. Therefore, it is necessary to define a static route.

Setting up a static route for the 192.168.2.0 network involves first adding 192.168.1.2 as a new gateway, and then adding a new static route which has 192.168.1.2 as its gateway:

1. To begin, first navigate to System | Routing.
2. On the Gateway tab, click on the Add button. On the gateway configuration page, select the correct interface in the Interface drop-down box. This should match the interface on which the gateway resides (in our example, it would be LAN).
3. Type a name in the Name edit box.

4. In the Gateway edit box, enter the gateway IP address (again, in our example, it would be 192.168.1.2).
5. Leave the Default Gateway checkbox unchecked.
6. You may want to enter an IP for monitoring the gateway in the Monitor IP edit box; this way, the gateway can be marked as down if it does not respond to pings from this address.
7. You can enter a brief description in the Description field; then click on Save.
8. And on the main Routing page, click on the Apply Changes button.
9. Next, click on the Static Routes tab and click on the Add button to add a new static route.
10. In the Destination network edit box, enter the network that will be reached by this static route (in this example, it would be 192.168.2.0). Don't forget to select the appropriate CIDR in the adjacent drop-down box (in this example, it would be 24).
11. In the Gateway drop-down box, select the gateway you created in the first step.
12. You can enter a description in the Description field, and then click on the Save button.

pfSense now knows a route to the DMZ router, but there is still a problem with our configuration. To illustrate this problem, imagine there is a node attached to the LAN switch. Assume that this node has an IP address of 192.168.1.3. This node wants to establish a session with a node on the DMZ router (assume the destination node has an IP address of 192.168.2.3).

The LAN node's default gateway is 192.168.1.1 (the LAN interface IP), so it sends packets destined for the DMZ node to pfSense, which in turn uses the static route to send the packets to the DMZ network via the 192.168.1.2 gateway. pfSense also adds a state table entry for this connection. The DMZ node receives the packets from the LAN node, and sends a reply, which is sent out through the DMZ router's gateway (192.168.1.2). Since the destination is on the LAN network, the return traffic is never filtered by pfSense, as pfSense only filters traffic between networks, not intra-network traffic. Since as far as pfSense is concerned, the connection was never completed, the entry gets dropped from the state table, and the connection between the LAN node and the DMZ node is dropped. 

Another scenario in which you may have a problem is with ICMP redirects, which are sent by a gateway when the gateway knows a more direct route to the destination host. If the sending node allows ICMP redirects, their routing table will temporarily add the new route. For example, NODE 1 tries to establish a session with NODE 2. This request goes through its default gateway (192.168.1.1) and reaches the pfSense box. pfSense, realizing there is a more direct route to NODE 2 via 192.168.1.2, sends an ICMP redirect back to NODE 1, informing it of the more direct route, but sends the initial TCP SYN packet to NODE 2 via the static route, and creates a state table entry for the connection. However, all subsequent communication between NODE 1 and NODE 2 takes place through 192.168.1.2, and pfSense does not see this traffic, since it is intra-network traffic. The state table entry created for the connection expires and is deleted. If the ICMP redirect-learned route of NODE 1 expires before the session ends, NODE 1 will send the next packet destined for NODE 2 to pfSense. Since it is not a packet establishing a new connection, pfSense will reject it, and the connection between NODE 1 and NODE 2 will be dropped.

There are two possible ways of dealing with these types of scenarios. The first is to navigate to System | Advanced, click on the Firewall & NAT tab, and under Firewall Advanced, check the Static route filtering checkbox. If this option is enabled, and one or more static routes have been defined, then traffic that enters and leaves through the same interface will not be checked by pfSense. This applies to our example, since traffic between NODE 1 and NODE 2 enters and leaves through the LAN interface.

Enabling this option will get the job done, but it will apply to all cases where traffic enters and leaves through the same interface, not just this one. Ideally, we want a rule that only applies to interfaces that have static routes to them. So, the second option is to create two rules: a rule on the interface through which the static route passes, and a floating rule to cover the return traffic.

To create the first rule, navigate to Firewall | Rules and click on the tab of whichever interface through which the static route passes (in the case of the example, LAN). Make sure the Action drop-down box is set to Pass and the Protocol drop-down box is set to TCP. Source should be set to match the setting in the Interface drop-down box (LAN net), since states only become an issue when the packets are sent and received through this interface. For Destination, choose Single host or alias in the drop-down box and in the adjacent edit box, specify the IP address of the static route's gateway (in this case, 192.168.1.2). Scroll down to the Extra Options section and click on the Show Advanced button.

In the Advanced section, set the TCP Flags option to Any Flags (the rule will match regardless of what TCP flags are set or not set). In the State type drop-down box, select Sloppy (this performs a less strict state match on return traffic). When you have finished making changes, click on the Save button. This rule should be placed at the top of the firewall rules table for this interface to ensure it gets applied.

Next, you have to make a floating rule for the return traffic. Click on the Floating tab and click on the Add button. Make sure the Action column is set to Pass and in the Interface listbox, make sure the same interface selected in the first rule is selected (in our case, LAN). The direction set in the Direction drop-down box should be set to out, and Protocol should be set to TCP. Reversing source and destination from the previous rule, we set Source to 192.168.1.2 and Destination to LAN net. Again, scroll down to Extra Options, click on the Show Advanced button, scroll down, set TCP Flags to Any Flags, and set State type to Sloppy. When you have finished click on Save, and on the main floating rules page, click on the Apply Changes button. You now have rules covering traffic in both directions.

There is another potential issue with this setup that we haven't addressed yet. Once we set up the static route and add appropriate rules to take into account the asymmetrical nature of traffic between LAN and DMZ, nodes on the two networks should be able to connect to each other. But if a node on DMZ tries to access the internet, it will likely fail; because the default allow LAN (or an alias with specifically defined networks) to any rule only works for traffic whose source is the LAN net. While this result may be consistent with your intended policy (you may want to keep nodes on DMZ from accessing the internet), if you want to allow this network to access the Internet, you will have to alter the Source setting on the default allow LAN (or alias) to any rule to allow traffic with a source of any.