Firewalling Fundamentals | pfSense Documentation (2024)

This section deals primarily with introductory firewall concepts and lays theground work for understanding how to configure firewall rules using pfSense®software.

Basic Terminology¶

Rule and ruleset are two terms used throughout this chapter:

Rule:: Refers to a single entry on the Firewall > Rules screen. A rule instructsthe firewall how to match or handle network traffic.
Ruleset:: Refers to a group of rules collectively. Either all firewall rules as awhole, or a set of rules in a specific context such as the rules on aninterface tab. The complete firewall ruleset is the sum of all user configuredand automatically added rules, which are covered further throughout thissection.

Rulesets on the Interface tabs are evaluated on a first match basis.This means that reading the ruleset for an interface from top to bottom, thefirst rule that matches will be the one used by the firewall. Evaluation stopsafter reaching this match and then the firewall takes the action specified bythat rule. Always keep this in mind when creating new rules, especially whencrafting rules to restrict traffic. The most permissive rules should be towardthe bottom of the list, so that restrictions or exceptions can be made abovethem.

Note

The Ethernet and Floating tabs are exceptions to this rule processinglogic. See Ethernet (Layer 2) Rules and Floating Rules for details.

Stateful Filtering¶

pfSense software is a stateful firewall, which means it remembers informationabout connections flowing through the firewall so that it can automaticallyallow reply traffic. This data is retained in the State Table. Theconnection information in the state table includes the source, destination,protocol, ports, and more: Enough to uniquely identify a specific connection.

Using this mechanism, traffic need only be permitted on the interface where itenters the firewall. When a connection matches a pass rule the firewallcreates an entry in the state table. Reply traffic to connections isautomatically allowed back through the firewall by matching it against the statetable rather than having to check it against rules in both directions. Thisincludes any related traffic using a different protocol, such as ICMP controlmessages that may be provided in response to a TCP, UDP, or other connection.

State Policy¶

The behavior of state matching can be fine-tuned by changing the State Policy toeither strictly bind states to interfaces and only match on those interfaces(“Interface Bound States”) or it can be more relaxed and ignore the interfacewhen matching packets to states (“Floating States”).

This behavior can be changed globally() and on a per-rule basis(Firewall Rule Configuration, Advanced Options, State Policy).

State table size¶

The firewall state table has a maximum size to prevent memory exhaustion. Eachstate takes approximately 1 KB of RAM. The default state table size in pfSenseis calculated by taking about 10% of the RAM available in the firewall bydefault. On a firewall with 1GB of RAM, the default state table size can holdapproximately 100,000 entries.

Block vs. Reject¶

There are two ways to disallow traffic using firewall rules on pfSense:Block and reject.

A rule set to block will silently drop traffic. A blocked client will notreceive any response and thus will wait until its connection attempt times out.This is the behavior of the default deny rule in pfSense software.

A rule set to reject will respond back to the client for denied TCP and UDPtraffic, letting the sender know that the connection was refused. Rejected TCPtraffic receives a TCP RST (reset) in response, and rejected UDP trafficreceives an ICMP unreachable message in response. Though reject is a validchoice for any firewall rule, IP protocols other than TCP and UDP are notcapable of being rejected; These rules will silently drop other IP protocolsbecause there is no standard for rejecting other protocols.

Deciding Between Block and Reject¶

There has been much debate amongst security professionals over the years as tothe value of block vs. reject. Some argue that using block makes more sense,claiming it “slows down” attackers scanning the Internet. When a rule is set toreject, a response is sent back immediately that the port is closed, while blocksilently drops the traffic, causing the attacker’s port scanner to wait for aresponse. That argument does not hold water because every good port scanner canscan hundreds or thousands of hosts simultaneously, and the scanner is notstalled waiting for a response from closed ports. There is a minimal differencein resource consumption and scanning speed, but so slight that it shouldn’t be aconsideration.

If the firewall blocks all traffic from the Internet, there is a notabledifference between block and reject: Nobody knows the firewall is online. Ifeven a single port is open, the value of that ability is minimal because theattacker can easily determine that the host is online and will also know whatports are open whether or not the blocked connections have been rejected by thefirewall. While there isn’t significant value in block over reject, the bestpractice is to use block on WAN rules. There is some value in not activelyhanding information to potential attackers, and it is also a bad practice toautomatically respond to an external request unnecessarily.

For rules on internal interfaces the best practice is to use reject in mostsituations. When a host tries to access a resource that is not permitted byfirewall rules, the application accessing it may hang until the connection timesout or the client program stops trying to access the service. With reject theconnection is immediately refused and the client avoids these hangs. This isusually nothing more than an annoyance, but it is still a good idea to usereject to avoid potential application problems induced by silently droppingtraffic inside a network.