In pfSense, rules on interface tabs are applied on a per-interface basis, always in the inbound direction on that interface. This means traffic initiated from the LAN is filtered using the LAN interface rules. Traffic initiated from the Internet is filtered with the WAN interface rules. Because all rules in pfSense are stateful by default, a state table entry is created when traffic matches an allow rule. All reply traffic is automatically permitted by this state table entry.
The exception to this is Floating rules (Floating Rules), which can act on any interface using the inbound, outbound, or both directions. Outbound rules are never required, because filtering is applied on the inbound direction of every interface. In some limited circumstances, such as a firewall with numerous internal interfaces, having them available can significantly reduce the number of required firewall rules. In such a case, apply egress rules for Internet traffic as outbound rules on the WAN to avoid having to duplicate them for every internal interface. The use of inbound and outbound filtering makes a configuration more complex and more prone to user error, but it can be desirable in specific applications.
Interface groups, discussed in Interface Groups, are a method to place rules on multiple interfaces at the same time. This can simplify some rule configurations if similar rules are required on many interfaces in the same way. Interface group rules, like interface rules, are processed in the inbound direction only. The VPN tabs for OpenVPN, L2TP, and the PPPoE server are all special Interface groups that are automatically created behind the scenes.
For example, a group may be used for a collection of interfaces including all LAN or DMZ type interfaces, or for a group of VLANs.
Interface groups are not effective with Multi-WAN because group rules
cannot properly handle
reply-to. Due to that deficiency, traffic matching
a group rule on a WAN that does not have the default gateway will go back out
the WAN with the default gateway, and not through the interface which it
Rule Processing Order¶
So far we have talked about how the rules are processed on an interface tab, but there are three main classes of rules: Regular interface rules, Floating rules, and Interface Group rules (including VPN tab rules). The order of processing of these types is significant, and it works like so:
Interface Group Rules
The rules are ordered in that way in the actual ruleset, keep that in mind when crafting rules. For example, if an interface group contains a rule to block traffic, that rule cannot be overridden with an interface tab rule because the traffic has already been acted upon by the group rule, which was matched first in the ruleset.
The rules are processed until a match is found, however, so if a packet is not matched in the group rules, it can still be matched by an interface rule.
Another significant place this comes into play is with assigned OpenVPN
interfaces. If an “allow all” rule is in place on the OpenVPN tab, it is matched
with the group rules. This means the rules on the interface tab will not apply.
This can be a problem if OpenVPN rules need to have
reply-to in order to
ensure certain traffic exits back via the VPN.
See Ordering of NAT and Firewall Processing for a more detailed analysis of rule processing and flow through the firewall, including how NAT rules come into play.
Automatically Added Firewall Rules¶
pfSense automatically adds internal firewall rules for a variety of reasons. This section describes automatically added rules and their purpose.
To prevent locking an administrator out of the web interface, pfSense enables an anti-lockout rule by default. This is configurable on the System > Advanced page under Anti-lockout. This automatically added rule allows traffic from any source inside the network containing the rule, to any firewall administration protocol listening on the LAN IP address. For example, it grants access to TCP port 443 for the WebGUI, TCP port 80 for the GUI redirect, and TCP port 22 if SSH is enabled. If the WebGUI port has been changed, the configured port is the one allowed by the anti-lockout rule.
In security-conscious environments, the best practice is to disable this rule and configure the LAN rules so only an alias of trusted hosts can access the administrative interfaces of the firewall. A better practice yet is to not allow access from the LAN but only from an isolated administrative management network.
Restricting access to the administrative interface from LAN¶
First, to configure the firewall rules as desired to restrict access to the required management interface(s). In this typical use case example, both SSH and HTTPS are used for management, so create a ManagementPorts alias containing these ports (Figure Alias for Management Ports).
Then create an alias for hosts and/or networks that will have access to the management interfaces (Figure Alias For Management Hosts).
The resulting aliases are shown in Figure Alias List.
Then the LAN firewall rules must be configured to allow access by the previously defined hosts, and deny access to all else. There are numerous ways to accomplish this, depending on specifics of the environment and how egress filtering is handled. Figure Example Restricted Management LAN Rules show two examples. The first allows DNS queries to the LAN IP address, which is needed if the DNS Resolver or DNS Forwarder are enabled, and also allows LAN hosts to ping the LAN IP address. It then rejects all other traffic. The second example allows access from the management hosts to the management ports, then rejects all other traffic to the management ports. Choose the methodology that works best for the network environment in question. Remember that the source port is not the same as the destination port.
Once the firewall rules are configured, disable the webGUI anti-lockout rule on the System > Advanced page (Figure Anti-Lockout Rule Disabled). Check the box and click Save.
If the management interface can no longer be accessed after disabling the anti-lockout rule, the firewall rules were not configured appropriately. Re-enable the anti-lockout rule by using the Set Interface(s) IP address option at the console menu, then choose to reset the LAN IP address. Set it to its current IP address, and the rule will automatically be re-enabled.
pfSense uses the antispoof feature in
pf to block spoofed traffic. This
provides Unicast Reverse Path Forwarding (uRPF) functionality as defined in RFC
3704. The firewall checks each packet against its routing table, and if a
connection attempt comes from a source IP address on an interface where the
firewall knows that network does not reside, it is dropped. For example, a
packet coming in WAN with a source IP address of an internal network is dropped.
Anything initiated on the internal network with a source IP address that does
not reside on the internal network is dropped.
Block Private Networks¶
The Block private networks option on the WAN interface automatically puts in a block rule for RFC 1918 subnets. Unless private IP space is in use on the WAN, enable this option. This only applies to traffic initiated on the WAN side. Local clients may still reach hosts on private networks from the inside of the firewall. This option is available for any interface, but is generally only used on WAN type interfaces. A similar rule can be created manually to block private networks on interfaces by creating an alias containing the RFC 1918 subnets and adding a firewall rule to the top of the interface rules to block traffic with a source matching that alias. (See Private IP Addresses for more information about private IP addresses.)
Block Bogon Networks¶
Bogon networks are those which should never be seen on the Internet, including
reserved and unassigned IP address space. The presence of traffic from these
networks might indicate either spoofed traffic or an unused subnet that has been
hijacked for malicious use. pfSense provides two bogons lists that are updated
as needed, one for IPv4 bogon networks and one for IPv6 bogon networks. If
Block bogon networks is enabled, the firewall will fetch an updated bogons
list on the first day of each month from
files.pfsense.org. The script runs
at 3:00 a.m. local time, and sleeps a random amount of time up to 12 hours
before performing the update. This list does not change very frequently, and new
IP address assignments are removed from the bogons list months before they are
actually used, so a monthly update is adequate. If the list must be updated more
frequently, change the Update Frequency for bogons under System >
Advanced on the Firewall & NAT tab.
The bogons list for IPv6 is quite large, and may not load if there is not enough memory in the system, or if the maximum number of table entries is not large enough to contain it. See Firewall Maximum Table Entries for information on changing that value.
Make sure the firewall can resolve DNS host names, otherwise the update will
fail. To ensure the firewall resolve DNS, browse to Diagnostics > DNS
Lookup, and try to resolve
files.pfsense.org. If that works, then go to
Diagnostics > Test Port and try to connect to
files.pfsense.org on port
80 as demonstrated in Figure
Forcing a bogons update¶
With the relatively infrequent changes to the bogons list, and advance notice of new public IP assignments, a monthly bogons update is adequate. However there may be scenarios where a manual bogon update can help, such as if the bogon updates have been failing because of an incorrect DNS configuration. Execute an update via the firewall web interface at Diagnostics > Tables, by selecting bogons or bogonsv6 then click Update.
When a site to site IPsec connection is enabled, rules are automatically added allowing the remote tunnel endpoint IP address access to UDP ports 500 and 4500, and the ESP protocol on the WAN IP address used for the connection. When IPsec for mobile clients is enabled the same traffic is allowed, but from a source of any, rather than a specific source address.
Because of the way policy routing works, any traffic that matches a rule specifying a gateway will be forced out to the Internet and will bypass IPsec processing. Rules are added automatically to negate policy routing for traffic destined to remote VPN subnets, but they do not always have the intended effect. To disable the automatic negation rules, see Disable Negate rules and add a firewall rule at the top of the rules on the internal interface to pass traffic to the VPN without a gateway set.
Automatically added IPsec rules are discussed in further depth in IPsec.