Static Routes

Static routes are used when hosts or networks are reachable through a router other than the default gateway. pfSense knows about the networks directly attached to it, and reaches all other networks as directed by its routing table. In networks where an internal router connects additional internal subnets, a static route must be defined for that network to be reachable. The routers through which these other networks are reached must first be added as gateways. See Gateways for information on adding gateways.

Static routes are found under System > Routing on the Routes tab.

Managing Static Routes

To add a route:

  • Navigate to System > Routing on the Routes tab
  • Click fa-plus Add to create a new static route
  • Fill in the configuration as follows:
    Destination Network:
     Specifies the network and subnet mask that is reachable using this route.
    Gateway:Defines the router through which this network is reached.
    Disabled:Check if the static route should not be used, only defined.
    Description:Some text to describe the route, its purpose, etc.
  • Click Save
  • Click Apply Changes

To manage existing routes:

  • Navigate to System > Routing on the Routes tab
  • Click fa-pencil next to an entry to edit an existing route
  • Click fa-trash next to an entry to delete a route
  • Click fa-ban to disable an active route
  • Click fa-check-square-o to enable a disabled route
  • Click Apply Changes

Example Static Route

Figure Static Routes illustrates a scenario where a static route is required.

../_images/diagrams-static-route-example.png

Static Routes

Because the 192.168.2.0/24 network in Figure Static Routes is not on an interface directly connected to pfSense, a static route is needed so the firewall knows how to reach that network. Figure Static Route Configuration shows the appropriate static route for the above diagram. As mentioned earlier, before a static route may be added a gateway must first be defined.

../_images/routing-edit-static-route-example.png

Static Route Configuration

Firewall rule adjustments may also be required. If custom LAN rules are used, they must allow traffic to pass from a source of the networks reachable via static routes on LAN.

Bypass Firewall Rules for Traffic on Same Interface

In many situations when using static routes, traffic ends up routing asymmetrically. This means the traffic will follow a different path in one direction than the traffic flowing in the opposite direction. Take Figure Asymmetric Routing for example.

../_images/diagrams-asymetric-routing.png

Asymmetric Routing

Traffic from PC1 to PC2 will go through pfSense since it is the default gateway for PC1, but traffic in the opposite direction will go directly from the router to PC1. Since pfSense is a stateful firewall, it must see traffic for the entire connection to be able to filter traffic properly. With asymmetric routing such as this example, any stateful firewall will drop legitimate traffic because it cannot properly keep state without seeing traffic in both directions. This generally only affects TCP, since other protocols do not have a formal connection handshake the firewall can recognize for use in state tracking.

In asymmetric routing scenarios, there is an option that may be used to prevent legitimate traffic from being dropped. The option adds firewall rules which allow all traffic between networks defined in static routes using a more permissive set of rule options and state handling. To activate this option:

  • Click System > Advanced
  • Click the Firewall/NAT tab
  • Check Bypass firewall rules for traffic on the same interface
  • Click Save

Alternatively, firewall rules may be added manually to allow similar traffic. Two rules are needed, one on the interface tab where the traffic enters (e.g. LAN) and another on the Floating tab:

  • Navigate to Firewall > Rules
  • Click the tab for the interface where the traffic will enter (e.g. LAN)
  • Click fa-level-up Add to add a new rule to the top of the list
  • Use the following settings:
    Protocol:TCP
    Source:The local systems utilizing the static route (e.g. LAN Net)
    Destination:The network on the other end of the route
    TCP Flags:Check Any flags (Under Advanced Features)
    State Type:Sloppy State (Under Advanced Features)
  • Click Save
  • Click the Floating tab
  • Click fa-level-up Add to add a new rule to the top of the list
  • Use the following settings:
    Interface:The interface where the traffic originated (e.g. LAN)
    Direction:Out
    Protocol:TCP
    Source:The local systems utilizing the static route (e.g. LAN Net)
    Destination:The network on the other end of the route
    TCP Flags:Check Any flags (Under Advanced Features)
    State Type:Sloppy State (Under Advanced Features)
  • Click Save

If additional traffic from other sources or destinations is shown as blocked in the firewall logs with TCP flags such as “TCP:SA” or “TCP:PA”, the rules may be adjusted or copied to match that traffic as well.

Note

If filtering of traffic between statically routed subnets is required, it must be done on the router and not the firewall since the firewall is not in a position on the network where it can effectively control that traffic.

ICMP Redirects

When a device sends a packet to its default gateway, and the gateway knows the sender can reach the destination network via a more direct route, it will send an ICMP redirect message in response and forward the packet as configured. The ICMP redirect causes a route for that destination to be temporarily added to the routing table of the sending device, and the device will subsequently use that more direct route to reach that destination.

This will only work if the client OS is configured to permit ICMP redirects, which is typically the case by default.

ICMP redirects are common when static routes are present which point to a router on the same interface as client PCs and other network devices. The asymmetric routing diagram from the previous section is an example of this.

ICMP redirects have a mostly undeserved bad reputation from some in the security community because they allow modification of a client routing table. However they are not the risk that some imply, as to be accepted, the ICMP redirect message must include the first 8 bytes of data from the original datagram. A host in a position to see that data and hence be able to successfully forge illicit ICMP redirects is in a position to accomplish the same end result in multiple other ways.