pfSense Software Firewall Rules Guide - zenarmor.com (2024)

pfSense® Software is an open-source, user-friendly, and simple-to-assemble firewall and routing platform based on the FreeBSD operating system. It is becoming more used, particularly among home networks and small companies. Because it is safe, dependable, user-friendly, and administered using a web user interface, and because it is one of the top open-source firewalls.

In this guide, we will briefly explore the fundamentals of packet filtering setup for the pfSense Software firewall and demonstrate how to create packet filtering firewall rules by explaining the following topics:

• What are the Fundamentals of the pfSense Firewall Rule?
  • What is State table size?
• How do pfSense Firewall Rules Work?
  • What are Interface Groups?
  • What is Rule Processing Order?
  • What are the Automatically Added Firewall Rules?
• What are Configuration Options for Firewall Rule on pfSense?
  • What are Advanced Options on Firewall Rule?
• What are Floating Rules?
  • What are Precautions/Caveats for Floating Rules?
  • What are the Possible Applications of Floating Rules?
  • What is Processing Order for Floating Rules?
  • What is Match Action in Floating Rules?
• What are the Best Practices for pfSense Firewall Rules?

What are the Fundamentals of the pfSense Firewall Rule?​

This section focuses on fundamental firewall ideas and sets the groundwork for knowing how to implement firewall rules using the pfSense® software. Rule and ruleset are two words that appear often in this chapter:

• Rule: Individual item on the Firewall > Rules screen on pfSense software web UI. A rule tells the firewall how to match or process network traffic.

• Ruleset: Refers to a collection of regulations as a whole. Either the whole collection of firewall rules or a set of rules in a particular context, such as the rules on an interface tab. The full ruleset for a firewall is the total of all user-configured and automatically inserted rules.

The rulesets on the Interface tabs are considered on a first-match basis. This implies that when reading the ruleset for an interface from top to bottom, the firewall will use the first rule that matches. Once the evaluation reaches this match, the firewall performs the action provided by this rule. Always keep this in mind while developing new regulations, particularly those that limit traffic. The most liberal rules should be placed at the bottom of the list, allowing constraints and exceptions to be placed above them.

What is State table size?​

The status database of the firewall is limited in size to avoid memory fatigue. Each state consumes around 1 KB of Memory. The default state table size in pfSense is determined using about 10% of the firewall's available RAM. For a firewall with 1 GB of Memory, the state table may contain around 100,000 entries by default.

Typically, each user connection consists of two states: one formed when the connection enters the firewall and another when it exits the firewall. Hence, with a state database size of 1,000,000, the firewall can support about 500,000 active user sessions transiting the firewall prior to dropping new connections. This limit may be extended as necessary, so long as it does not exceed the firewall's RAM capacity.

You may increase the state table size by following the next steps::

1. Navigate to System > Advanced > Firewall & NAT on pfSense UI.

2. Enter the desired number for Firewall Maximum States, or leave the box blank for the default calculated value.

3. Click Save.

Figure 1. Setting Firewall Maximum State Size on pfSense

The firewall keeps track of the use history of the state table. To see the historical state table chart, you may follow the steps below::

1. Go to Status > Monitoring on pfSense UI.

2. Click the Settings button with a wrench icon to expand graph options.

3. Set Category for the Left Axis to System

4. Set the Graph for the Left Axis to States

5. Click Update Graph button to refresh the graphs.

Figure 2. Viewing historical state table on pfSense

How do pfSense Firewall Rules Work?​

With the pfSense® software, rules on interface tabs are applied interface-by-interface, always in the incoming direction. This indicates that the LAN interface rules are used to filter traffic launched by hosts connected to the LAN. The Internet-originating traffic is filtered using the WAN interface rules. Since all rules in the pfSense software are stateful by default, when traffic meets an allow rule, a state table entry is produced. This state table entry immediately permits all reply traffic.

Floating rules (Floating Rules) are the exception to this rule, since they may operate on any interface utilizing the inbound, outbound, or both directions. Outbound rules are never necessary since each interface's incoming direction is always filtered. In some situations, such as a firewall with several internal interfaces, their availability might drastically decrease the number of needed firewall rules. Apply Internet traffic egress rules as outward floating rules on the WAN interface to avoid duplicating them on each internal interface. Using incoming and outbound filtering makes a setup more complicated and prone to user mistakes, but it may be useful for some applications.

What are Interface Groups?​

Interface groups are a way to apply rules to several interfaces simultaneously. This simplifies rule settings if identical rules are needed on several interfaces. Like interface rules, interface group rules are only handled in the incoming direction. The OpenVPN, L2TP, and PPPoE VPN tabs are unique Interface groups that are produced automatically behind the scenes.

A group may be used for a collection of interfaces, such as all LAN or DMZ interfaces, or for a collection of VLANs.

What is Rule Processing Order?​

There are three primary types of interface rules on the pfSense software firewall:

• Standard interface rules

• Floating rules, and

• Interface Group rules (including VPN tab rules).

The processing order of pfSense interface firewall rules is crucial and works as follows:

1. Floating Rules

2. Interface Group Rules

3. Interface Rules

Keep this in mind while designing rules since this is the actual order of the rules in the ruleset. If an interface group has a rule to restrict traffic, for instance, that rule cannot be overridden by an interface tab rule since the traffic has already been acted upon by the group rule, which was matched first in the ruleset.

Nevertheless, since the rules are executed until a match is discovered, if a packet is not matched by the group rules, it may still be matched by an interface rule.

This is also essential when it comes to OpenVPN interface assignments. If a "permit all" rule exists on the OpenVPN tab, it is compared against the group rules. This indicates that the interface tab's rules will not apply. This may be problematic if OpenVPN rules need reply-to to verify that certain traffic leaves through the VPN.

What are the Automatically Added Firewall Rules?​

pfSense software applies internal firewall rules automatically for a number of reasons. This section discusses the purpose of automatically introduced rules.

You may view the automatically added firewall rules on the WAN interface by navigating to the Firewall > Rules > WAN.

Figure 3. Automatically added firewall rules on WAN interface

You may view the automatically added firewall rules on LAN interface by navigating to the Firewall > Rules > LAN.

Figure 4. Automatically added firewall rules on LAN interface

What is Anti-lockout Rule?​

By default, pfSense implements an anti-lockout rule to avoid locking out an administrator from the web interface. This is customizable with the Anti-lockout option on the System > Advanced > Admin Access page. This rule automatically enables traffic from any source inside the network to any firewall management protocol listening on the LAN IP address. The anti-lockout rule includes the following ports:

• TCP port 443 for the WebGUI

• TCP port 80 for the GUI redirect

• TCP port 22 if SSH is enabled.

• The configured port is the one permitted by the anti-lockout rule if the WebGUI port has been modified.

The anti-lockout rule can be seen in Figure 2. Automatically added firewall rules on LAN interface.

It is recommended practice to deactivate this rule and set up the LAN rules such that only an alias of trusted hosts may access the firewall's administrative interfaces. The best strategy is to restrict access from the LAN to a separate administrative management network.

How to Define Firewall Rule for Limiting LAN access to Firewall?​

You may establish firewall rules to limit access to your pfSense firewall by following the next steps:

1. Defining Aliases

2. Allow Accessing DNS from LAN

3. Allow Administrative Access

4. Block Firewall Access

5. Disabling Anti-lockout rule

1. Defining Aliases​

You may define an alias for both SSH and HTTPS ports that are utilized for administration by following the steps given below:

1. Navigate to Firewall > Aliases > Ports on pfSense UI.

2. Click +Add button to add an alias.

   

   Figure 5. Ports Aliases on pfSense

3. Type a Name, such as AdministrativePorts.

4. Type a Description, such as Ports used for FW Management.

5. Type 443 and HTTPS in the Port and Description fields respectively.

   See Also

   Replacing your BT Broadband Modem with pfSenseHow to turn old PC to a router with pfSense | Eccentrix

6. Click +Add Port button to add new Port Alias.

7. You may type 80 and HTTP in the Port and Description fields respectively.

8. Click +Add Port button to add new Port Alias.

9. Type 22 and SSH in the Port and Description fields respectively.

10. Click Save button to save settings.

    

    Figure 6. Adding Administrative Ports Aliases on pfSense

11. Click Apply Changes for activating the changes.

    

    Figure 7. Applying Changes for Ports Aliases on pfSense

12. Click IP tab.

13. Click +Add button to add IP aliases for administrators.

14. Type a Name, such as AdminPC.

15. Type a Description, such as Host used for Remote FW Management.

16. Type an IP address, such as 10.1.1.11 and a Description, such as Remote Admin IP. You may enter any number of hosts desired. Hosts must be identified using either their IP address or their fully qualified domain name (FQDN). Periodically, FQDN hostnames are re-resolved and updated. If a DNS query returns several IP addresses, all are utilized. You may also use an IP range such as 192.168.1.1-192.168.1.10 or a tiny subnet such as 192.168.1.16/28 to obtain a list of individual IP addresses.

    

    Figure 8. Adding Administrative IP Aliases on pfSense

17. Click Save to save the settings.

    

    Figure 9. Applying Changes for IP Aliases on pfSense

18. Click Apply Changes for activating the changes.

2. Allow Accessing DNS from LAN​

You may allow DNS queries to the LAN IP address, which is needed if the DNS Resolver or DNS Forwarder is enabled by following the next steps:

Figure 10. Adding Firewall Rule to allow DNS

1. Navigate to the Firewall > Rules > LAN.

2. Click the Add button with the UP arrow icon for defining a rule to allow the internal DNS server(s)

3. Select Pass for the allowed rule.

4. Select the Interface as LAN.

5.Select TCP/UDP for the Protocol.

6. Select the source as LAN net. This captures all traffic on the LAN interface bound for the specified destination.

7. Select the destination as LAN address.

8. Select DNS predefined port alias for the Destination Port Range.

9. Check Log packets that are handled by this rule option to enable logging.

   

   Figure 11. Setting Extra Options for Firewall Rule to allow DNS

10. Set Allow DNS for Description.

11. Click Save.

12. Click Apply Changes to activate the rule.

3. Allow Administrative Access​

You may allow administrative access from specific admin IPs/networks by following the steps given below:

1. Navigate to the Firewall > Rules > LAN.

2. Click the Add button with the UP arrow icon for defining a rule to allow the internal DNS server(s)

3. Select Pass for the allowed rule.

4. Select the Interface as LAN.

5. Select TCP for the Protocol.

6. Select the source as Single host/alias and AdminPC.

7. Select the destination as LAN address.

8. Select other for From field and then select AdministrativePorts predefined port alias for Custom filed of the Destination Port Range.

   

   Figure 12. Adding Firewall Rule to allow Admin Access

9. Check Log packets that are handled by this rule option to enable logging.

   

   Figure 13. Setting Extra Options for Firewall Rule to allow Administrative Access

10. Set Allow Administrative Access for Description.

11. Click Save.

12. Click Apply Changes to activate the rule.

4. Block Firewall Access​

You may block unprivileged firewall access from LAN by following the steps given below:

1. Navigate to the Firewall > Rules > LAN.

2. Click the Add button with the DOWN arrow icon for defining a rule to allow the internal DNS server(s)

3. Select Block for the allowed rule.

4. Select the Interface as LAN.

5. Select Any for the Protocol.

6. Select the source as LAN net.

7. Select the destination as LAN address.

   

   Figure 14. Adding Firewall Rule to block Firewall Access

8. Check Log packets that are handled by this rule option to enable logging.

   

   Figure 15. Setting Extra Options for Firewall Rule to block Firewall Access

9. Set Block Firewall Access for Description.

10. Click Save.

11. Click Apply Changes to activate the rule.

12. Drag and drop the newly defined Block Firewall Access rule under the Allow DNS rule. Your firewall rules should be ordered as given below.

    

    Figure 16. Reordering Firewall Rules

13. Click Save.

14. Click Apply Changes to activate the settings.

5. Disabling Anti-lockout rule​

After configuring the firewall rules, you may deactivate the webGUI anti-lockout rule by following the steps given below:

1. Go to System > Advanced > Admin Access or click the Settings button next to the anti-lockout rule on Firewall > Rules > LAN page.

2. Check on Disable webConfigurator anti-lockout rule option on webConfigurator pane. Unchecking this option allows access to the webConfigurator on the LAN interface independent of the user-defined firewall rule configuration. Check this box to deactivate this automatically inserted rule so that access to the webConfigurator is governed by the user-defined firewall rules. This configuration is also reset via the "Set interface(s) IP address" option in the console menu.

   

   Figure 17. Disabling webConfigurator anti-lockout rule

3. Click Save at the end of the page.

What are Anti-spoofing Rules?​

The antispoof functionality of pf is used by pfSense to prevent faked communications. This offers the RFC 3704-defined Unicast Reverse Path Forwarding (uRPF) functionality. Each packet is compared to the firewall's routing database, and if a connection attempt originates from an IP address on an interface where the firewall knows the target network does not exist, the packet is discarded. A WAN-bound packet originating from an internal network, for instance, gets discarded. Anything launched on the internal network with an external source IP address is dropped.

What is Block Private Networks Rule?​

The RFC 1918 subnets are automatically blocked when the Block private networks option is enabled on the WAN interface. Enable this option unless private IP space is in use on the WAN. Only traffic originating on the WAN side is affected. Local clients are still able to access hosts on private networks from behind the firewall. This option is accessible for all interface types but is often reserved for WAN interfaces. A similar rule may be manually made to block private networks on interfaces by defining an alias containing the RFC 1918 subnets and putting a firewall rule at the top of the interface rules to prohibit traffic with a source that matches the alias.

What is Prevent Bogon Networks Rule?​

Bogon networks are ones that should never be seen on the Internet, including IP address space that is reserved or unassigned. The existence of traffic from these networks suggests either faked traffic or the hijacking of an idle subnet for malevolent purposes. Bogon lists are meant to filter invalid Internet traffic (e.g., on WANs) entering the firewall when the source cannot be otherwise screened or verified, such as in the case of public services. If an interface's rules only permit particular remote sources, bogon blocking provides no value. pfSense software supports two dynamically updated bogon lists, one for IPv4 bogon networks and another for IPv6 bogon networks.

The pfSense firewall retrieves an updated list of bogons from Netgate servers at the beginning of each month. Before completing the update, the script runs at 3:00 a.m. local time and sleeps for a random period of time up to 12 hours. A monthly update is sufficient since new IP address assignments are deleted from the bogons list months before they are assigned. You may change the Update Frequency for Bogon Networks under System > Advanced on the Firewall & NAT page to refresh the list more regularly.

Figure 18. Changing Update Frequency for Bogon Networks

What is IPsec Rule?​

When a site-to-site IPsec connection is activated, the firewall automatically inserts rules that allow the tunnel to connect and flow traffic.

Because of the nature of policy routing, any traffic matching a rule specifying a gateway will be sent directly to the Internet, without IPsec processing. Rules are automatically introduced to negate policy routing for traffic headed for distant VPN subnets, however, they may not always achieve the desired result. To deactivate the automated negation rules, add a firewall rule at the top of the rules on the internal interface to let traffic to the VPN without a specified gateway.

What are Configuration Options for Firewall Rule on pfSense?​

Many settings are available when defining firewall rules in the pfSense® software GUI under Firewall > Rules to govern how traffic is matched and regulated. Each of the firewall rule options is detailed in this section:

• Action: This option defines whether the rule will allow, block, or reject traffic.

  • Pass: A packet matching this rule will be permitted to traverse the firewall. If state tracking is enabled for the rule, an entry is produced in the state table that permits associated return traffic to pass through.
  • Block: A packet that matches this rule is rejected. A rule configured to block will drop traffic invisibly. A blocked client will not get a response and will thus wait until the connection timeouts. This is the default action of the deny rule in pfSense.
  • Reject: A packet that matches this rule will be deleted, and for supported protocols, a message will be sent back to the sender indicating that the connection has been denied. Rejected TCP communication is responded to with a TCP RST (reset), whereas rejected UDP traffic is responded to with an ICMP unreachable message. While reject is a viable option for any firewall rule, IP protocols other than TCP and UDP cannot be refused; other IP protocols will be dropped quietly since there is no standard for rejecting other protocols.

  What is the Difference Between pfSense Block and Reject?

  While there is no major advantage to block over reject, the recommended practice for WAN rules is to use block. There is a considerable advantage in avoiding actively passing information to possible attackers, and it is also a poor practice to automatically react to an unnecessary external request.

  The best practice for rules on internal interfaces is to use reject in the majority of cases. When a host attempts to access a resource that is not authorized by the firewall, the application attempting to access the resource may become unresponsive until the connection runs out or the client software quits attempting to access the service. With reject, the connection is instantly denied, preventing client hangs. This is often little more than a nuisance, but it is nevertheless advisable to use reject to prevent any application issues caused by data being dropped quietly inside a network.

• Disabled: Check this box to deactivate a rule without removing it from the rule list. It will still remain on the screen for firewall rules, but the rule will be grayed out to signify its disabled condition.

• Interface: The Interface drop-down menu provides the receiving interface for the traffic that will be governed by this rule. Note that traffic is only filtered on the interface where it originated by interface and group tab rules. The LAN ruleset filters traffic originating from the LAN and headed for the Internet or any other interface of pfSense firewall.

• Address Family: Indicates whether the rule applies to IPv4, IPv6, or both IPv4 and IPv6 traffic. The rules will only match and take action on packets that match the specified protocol. Aliases that include both sorts of IP addresses may be used, and the rule will match only addresses from the appropriate protocol.

• Protocol: The protocol matched by this rule. These settings are mostly self-explanatory. TCP/UDP is compatible with both TCP and UDP communication. Specifying ICMP will provide a drop-down menu for selecting the ICMP type. There are also many additional common protocols accessible.

  

  Figure 19. Firewall Rule Protocol Options on pfSense

  tip

  This option defaults to TCP when a new rule is created since TCP is a popular default and displays the required information for that protocol. To make the rule applicable to any protocol, enter any in this area. Inadvertently implementing a TCP rule that prevents non-TCP traffic such as ping, DNS, etc. from passing is one of the most frequent errors made while adding new rules.

• ICMP Subtypes: This drop-down includes all potential ICMP types to match when ICMP is chosen as the protocol. The recommended approach for passing ICMP is to just pass the needed kinds when possible. Sending just a form of Echo Request that allows an ICMP ping to pass is the most typical use case.

  

  Figure 20. Firewall Rule ICMP Subtypes Options on pfSense

• Source: This column defines the IP address, subnet, or alias of the source IP packets that will match this rule. The drop-down menu for source has the following predefined options:

  • Any: Matches any address.
  • Single host or Alias: Matches a single IP address or hostname alias. When enabled, an alias may be entered in the Source Address box.
  • Network: Matches a range of IP addresses using both an IP address and a subnet mask.
  • PPPoE Clients: If the PPPoE server is enabled, this macro will match traffic from the client IP range for the PPPoE server.
  • L2TP Clients: If the L2TP server is enabled, this macro will match traffic from the client IP range for the L2TP server.
  • Interface Net: This list contains an item for each interface on the firewall. These macros precisely describe the subnet for that interface, including any IP alias VIP subnets that vary from the interface's declared subnet.
  • Interface Address: This list contains an item for each interface on the firewall. The IP address defined on the interface is specified by these macros.

  

  Figure 21. Firewall Rule Source Options on pfSense

  To specify the source port for rules matching TCP and/or UDP, click the Display Advanced button. The source port is concealed behind the Display Advanced button because TCP and UDP connections are derived from a random port in the ephemeral port range and the source port must generally be set to any (between 1024 through 65535, the exact range used vary depending on the OS and OS version that is initiating the connection). The source port and destination port are virtually never identical, and should never be set as so unless it is known that the program in use employs this uncommon behavior. Moreover, it is permissible to describe a source port as a range between 1024 and 65535.

  

  Figure 22. Firewall Rule Source Port Range Options on pfSense

  By selecting Invert Match option, the rule will be triggered for all traffic except for the specified source value.

  tip

  Using Invert Match on <interface> Net macros such as LAN net might result in unintended rule behavior if the interface additionally employs Virtual IP addresses. This is a result of matching traffic against the interface network OR the VIPs. With a Subnet of 192.168.1.0/24, a VIP of 10.0.0.1/32, and a rule with a negated interface macro such as pass on $LAN from any to ! $LAN_net, for instance, traffic headed for 192.168.1.100 will pass since the destination IP address does not match the VIP.

• Destination: This column defines the IP address, subnet, or alias of the destination that will match this rule. Refer to the Source option's explanation under Source for further information. Just one extra macro exists:

  • This firewall (self): Matches each and every IP address on each and every firewall interface.

  

  Figure 23. Firewall Rule Destination Options on pfSense

  The target port, port range, or alias is supplied here for TCP and/or UDP rules. In contrast to source, specifying a destination port is often essential, since it is more secure than using any port and is often known in advance depending on the protocol. Choose (other) to manually input a port value or to use a port alias. The drop-down lists provide a variety of popular port values.

  tip

  Enter the lower port value in the From section and the higher port value in the To section to define a continuous range of ports.

• Log: This checkbox controls whether packets matching this rule are reported in the firewall log.

• Description: Add a reference description here. This is optional and has no effect on the rule's functioning. The ideal procedure is to provide wording outlining the rule's intent. The maximum character length is 52.

  

  Figure 24. Firewall Rule Extra Options on pfSense

What are Advanced Options on Firewall Rule?​

This part of the pfSense firewall rule contains options that are less likely to be used or have functionality that is unclear to novice users. Click the Display Advanced button in the Extra Options pane of a firewall rule to see all advanced settings. If an option in this portion of the page has been selected, it will be shown the next time the rule is loaded.

• Source OS: One of the most distinctive characteristics of pf and, by extension, pfSense software is the ability to filter connections based on the originating operating system. pf provides passive operating system fingerprinting ("p0f") for TCP rules, which enables rules to match depending on the operating system that initiated the TCP connection. Comparing the features of the TCP SYN packet that establishes TCP connections with a fingerprints file, the p0f feature of pf detects the operating system in use. Especially with open-source operating systems such as BSDs and Linux, it is feasible to modify the fingerprint of an operating system to make it resemble that of another OS. This is not simple, but it is doable if a network has technically competent people with administrator or root-level access to systems.

• Diffserv Code Point: Differentiated Services Code Point is a means for apps to express how they would want their traffic to be handled by routers as it is forwarded along its path. Most often, this is used for service quality or traffic-shaping reasons. The long term is sometimes simplified to Diffserv Code Point or DSCP, and is also referred to as the TOS field.

  The program or device that generates the packets, such as Asterisk through its tos_sip and tos_audio configuration settings, will set the DSCP field in the packets. It is then the responsibility of the firewall and other intermediate routers to match and queue or otherwise process the packets.

  To match these parameters in the firewall, choose the Diffserv Code Point item that corresponds to the value set by the originating device from the drop-down menu. There are a variety of possibilities, each with a distinct significance based on the kind of traffic.

  DSCP has the disadvantage of assuming that routers support or act on the field, which may or may not be the case. Various routers may interpret identical DSCP values in unanticipated or incompatible ways. Worst still, some routers would completely remove the DSCP information from packets before forwarding them. However, because of the way pf matches traffic, the DSCP value must be provided on the first packet of a connection that creates a state, since packets are not individually examined after a state is generated.

• IP Options: This checkbox allows packets with specified IP parameters to pass. By default, pf filters all packets that include IP parameters, among other reasons, to prevent OS fingerprinting. Tick this box to allow IGMP and other multicast IP options communication.

• Disable Reply-To: By default, the firewall adds the reply-to keyword to rules on WAN-type interfaces to guarantee that traffic entering a WAN exits through the same WAN. Under some circ*mstances, such as when some traffic is routed through a separate firewall/router on the WAN interface, this behavior is unacceptable. In some instances, choose this option to deactivate reply-to just for the traffic that matches this rule, rather than globally.

• Tag and Tagged: The Tag and Tagged fields are helpful in conjunction with floating rules, allowing the firewall to tag a packet with a certain string when it enters an interface and then performs a different action on a matched packet using a floating rule on its way out.

• Maximum state entries this rule can create: This option restricts the overall maximum number of connections permitted by this rule. If further connections fit this rule after its connection limit has been reached, this rule will not be evaluated. If a later rule matches, the action of that rule is applied to the traffic; otherwise, the default refuses rule is executed. After the number of connections allowed by this rule falls below this limit, traffic may once again conform to this rule.

• Maximum number of unique source hosts: This parameter determines the maximum number of simultaneous source IP addresses allowed for this rule. Each source IP address is permitted an infinite number of connections, but the overall number of source IP addresses is capped at this figure.

• Maximum number of established connections per host: Use this parameter to deny access based on connections per host. This value may restrict a rule to a certain number of connections per source host (e.g. 10) as opposed to a total number of connections. This setting determines the maximum number of completely established (finished handshake) connections per host that fit the rule. This option is only compatible with TCP connections.

• Maximum state entries per host: This option operates similarly to the previously defined count, however, it just checks for state entries and not if a successful connection was achieved.

• Maximum new connections / per second: This type of rate limitation ensures that a high TCP connection rate does not overwhelm a server or the firewall's state table. Limits may be imposed on incoming connections to a mail server, therefore decreasing the strain of spambots overloading the system. It may also be used on outbound traffic rules to prevent any one machine from overloading the firewall's state table or making an excessive number of quick connections, both of which are typical actions of viruses. The rule may be specified with a connection count and the number of seconds for the time period. Any IP address that exceeds the set number of connections during the specified time period will be banned for one hour by the firewall. This is handled behind the scenes by the virusprot table, whose usual function is virus protection. This option is only compatible with TCP connections.

• State timeout in seconds: This field is used to establish a state timeout for traffic matching these criteria, overriding the default state timeout. After a connection has been dormant for this period of time, the connection will be closed. The default state timeout relies on the optimization technique used by the firewall. T

  tip

  This option restricts traffic exclusively in the incoming direction, therefore it is not very helpful by itself. The default state timeout will still apply to outbound traffic for a matched connection. To utilize this option correctly, a corresponding floating rule with a comparable state timeout setting must exist in the outgoing route followed by the traffic.

  

  Figure 25. Firewall Rule Advanced Options on pfSense-1

• TCP Flags: By default, new TCP pass rules examine just the TCP SYN flag, out of a potential set of SYN and ACK. To accommodate for more complicated cases, such as working around asymmetric routing or other non-traditional traffic flow combinations, utilize this collection of options to modify how the firewall rule matches flags. The first row specifies which flags must be set in order to comply with the regulation. The second row specifies the list of packet flags that will be examined for a match. The meanings of the most frequent flags are as follows:

  • SYN: Coordinate sequence numbers. Shows a newly attempted connection.
  • ACK: Signifies data ACKnowledgment. These are responses that inform the sender that data was received successfully.
  • FIN: Signifies that there are no more data from the sender and closes the connection.
  • RST: Connection reset. This flag is set in response to a request to establish a connection on a port that does not have an active listening daemon. Moreover, firewall software may be configured to reject unwanted connections.
  • PSH: Specifies that data, including the data in this packet, should be pushed or flushed by delivering the data to the application.
  • URG: Specifies that the urgent field is important and that this packet should be sent before non-urgent data.
  • Any Flags: You may Check Any Flags to permit TCP with any flags set.

• State Type: There are three alternatives for tracking states that may be set per rule:

  • Keep: When selected, the firewall will construct and keep an entry for authorized traffic in its state table. This is the default and best option in the majority of cases.
  • Sloppy State: Sloppy is a less stringent method of maintaining state that is designed for asymmetric routing circ*mstances. When the firewall can view just fifty percent of a connection's traffic, the normal state-keeping checks fail and traffic is prohibited. During a sloppy state check, mechanisms in pf that prevent certain types of attacks will not activate.
  • Synproxy: This option instructs pf to act as a proxy for inbound TCP connections. TCP connections are initiated through a three-way handshake. The first packet of a TCP connection is an SYN from the source, which is followed by an SYN-ACK from the destination and an ACK from the source to complete the handshake. This is normally handled by the host behind the firewall, but synproxy state has the firewall perform this handshake instead. This helps prevent SYN floods, a sort of denial of service attack. This is normally used solely for WAN interface rules.Nowadays, this form of attack is best addressed at the level of the target operating system, since all current operating systems have the capability to do so on their own. Since the firewall cannot determine which TCP extensions the back-end host supports, it advertises no supported TCP extensions while in synproxy mode. This implies that connections made using synproxy state will not utilize window scaling, SACK, or timestamps, resulting in a performance decrease in the vast majority of circ*mstances.This option is helpful for opening TCP ports to sites that do not handle network abuse adequately and when speed is not a priority.
  • None: This option will not save the rule's status. This is only required in a handful of extremely specialized advanced circ*mstances.

  tip

  Setting None here just impacts traffic in the incoming direction, therefore it is not really beneficial as a state is still produced in an outgoing way. It must be matched with a floating rule with the same option set in the outbound direction.

• No XML-RPC Sync: This option stops this rule from syncing through XMLRPC with other High Availability cluster members. High Availability addresses this issue.

• VLAN Priority (Match and Set): 802.1p, sometimes referred to as IEEE P802.1p or Priority Code Point, is a method for matching and tagging packets with a particular quality of service priority. 802.1p works at layer 2 with VLANs, unlike DSCP. Yet, similar to DSCP, the upstream router must also support 802.1p for it to be effective. This section has two choices. The first will match an 802.1p field in order for the firewall to take action. Once a packet travels through this firewall, the second will insert an 802.1p tag. Some ISPs may need the setting of an 802.1p tag in specific regions, such as France, in order to handle voice/video/data on segregated VLANs with the necessary priority to assure quality. There are eight priority levels for 802.1p, and each has a two-letter GUI code. In descending order of importance, they are:

  • BK: Background
  • BE: Best Effort
  • EE: Exceptional Effort
  • CA: Critical Applications
  • VI: Video
  • VO: Voice
  • IC: Internetwork Control
  • NC: Network Control

• Schedule: This option configures a schedule that specifies the days and hours the rule will be active. If you choose "none," the rule will always be enabled.

• Gateway: This option configures a Gateway or Gateway Group to be utilized by the matched traffic.

• In/Out Pipe (Limiters): These options offer Limiters to impose a bandwidth restriction to the traffic entering (In) and leaving (Out) this interface.

• Ackqueue/Queue: These parameters specify the ALTQ traffic shaper queues that are applied to incoming and outgoing traffic on this interface.

Figure 26. Firewall Rule Advanced Options on pfSense-2

What are Floating Rules?​

Floating Rules are a unique sort of advanced rule that may execute complex operations that are not feasible with rules on the interface or group tabs. Many interfaces may be affected by floating rules in the incoming, outbound, or both directions. The usage of incoming and outbound filtering makes rule creation more complicated and prone to user mistakes, although it is useful in some situations.

The majority of firewall setups will never have floating rules, or they will only be available through the traffic shaper.

Figure 27. Floating Firewall Rules on pfsense

What are Precautions/Caveats for Floating Rules?​

Floating rules can be much more effective than other rules, but they are also more complicated, and it is simpler to make a mistake that might result in unforeseen effects in passing or obstructing traffic.

Floating rules in the inbound direction that are applied to numerous WANs will not have reply-to added as with individual interface rules; hence, the same issue arises as with interface groups: The traffic will always depart the WAN through the default gateway, and will never return correctly.

Considering the relative unfamiliarity of many users with Floating rules, they may not consider searching there for firewall rules. As a result, they might be somewhat more challenging for the administration, since they may not be the most apparent location to search for regulations.

Consider the source and destination of packets carefully based on their inbound and outbound path. For instance, outbound rules on a WAN would have a local firewall source (after NAT) and a distant destination.

What are the Possible Applications of Floating Rules?​

The most typical use of Floating rules is for shaping ALTQ traffic. Only floating tab rules may match and queue traffic without explicitly forwarding the traffic.

Moreover, floating rules may be used to govern traffic exiting the firewall itself. Floating rules may prohibit the firewall from gaining access to certain IP addresses, ports, etc.

Additional popular applications include ensuring that no traffic may enter a secure network from other channels, regardless of the regulations that govern other interfaces. By restricting access to a secure network from all places other than those authorized, the risk of subsequently permitting traffic to enter through an unexpected channel is reduced. Similarly, they may be used to prevent VPN traffic from leaking by preventing traffic meant for private networks from leaving a WAN interface.

For asymmetric routing, they can successfully implement state timeouts, tag/match operations, "no state" rules, and "sloppy state" rules.

What is Processing Order for Floating Rules?​

In the inbound direction, floating rules function similarly to interface or group rules, with the exception that they are handled before those rules. On the other way, though, things get rather more complicated.

As firewall rules are evaluated after NAT rules, rules in the outbound direction on a WAN cannot ever match a local/private IP address source if outbound NAT is enabled for that interface. By the time the packet reaches the rule, its source IP address is the WAN interface IP address. In the majority of instances, this issue may be circumvented by utilizing the match options to tag a packet on the LAN on its way in and then matching that tag on its way out of the firewall.

Floating rules are executed prior to interface group rules and interface rules, therefore this must also be considered.

What is Match Action in Floating Rules?​

Matching is exclusive to floating rules. A rule with the match action will neither pass nor block a packet, but will match it in order to send traffic to queues or limiters for traffic shaping. Match rules are ineffective when Quick is enabled.

• Quick: Determines whether rule processing stops after a rule is matched. The Quick behavior is automatically applied to all interface tab rules, but it is optional for floating rules. Without the Fast option selected, the rule will only apply if no other rules match the traffic. It changes the "first match wins" behavior to "last match wins". With this method, it is possible to create a default action that will only take effect if no other rules match, analogous to the default block rules on WANs. In the majority of circ*mstances, it is advisable to check Quick. There are few circ*mstances in which leaving Quick unchecked is required, although they are uncommon. Without Quick selection, the only rules they would have for the majority of circ*mstances are match rules and traffic shaper rules.

• Interface: The Interface option for floating rules is distinct from that for regular interface rules: It is a multiple-select box, allowing for the selection of one, many, or all potential interfaces. Ctrl-click interfaces to pick them individually, or use alternative click/drag or shift-click combinations.

• Direction: Unlike interface rules, floating rules are not restricted to the incoming direction. Moreover, they may act in the outward direction by picking out or in both directions by selecting any. The direction in is also accessible. The out direction is important for filtering traffic from the firewall itself, matching other unwanted traffic attempting to depart an interface, and completely defining "sloppy state" rules, "no state" rules, and alternative state timeouts.

• Marking and Matching: Utilizing the Tag and Tagged fields, an interface tab rule may label a connection, which can subsequently be matched in the outbound direction by a floating rule. This is a handy method for acting on WAN outbound traffic from a certain internal host that could not be matched otherwise owing to NAT concealing the source. Similarly, it may be used to shape outgoing WAN traffic from traffic that was specially labeled on its route inside the firewall.

Use, for instance, a brief text in the Tag field of a LAN rule to identify a packet originating from 10.3.0.56. Next, on a quick, outward, floating rule on the WAN, use Tagged with the same string to act on the traffic matching the LAN rule.

What are the Best Practices for pfSense Firewall Rules?​

This section discusses basic setup best practices for firewall rules on pfSense Software. You may apply the following best practices when you configure pfSense firewall rules:

1. Keep it concise: The shorter a ruleset, the more manageable it is. Long rulesets are difficult to work with, increase the likelihood of human mistakes, tend to become too permissive, and are much more challenging to audit. Use aliases to reduce the length of the ruleset.

2. Implement Default Deny: The default deny rule discreetly blocks any rules that do not match any user-defined rules or other automatically added rules. There are two fundamental access control theories in computer security:

   • default allow
   • default deny

   The ideal method for firewall rules is to deny by default. Firewall administrators should design rules to allow just the bare minimum necessary traffic for a network's requirements, and let the rest traffic drop using the default deny rule (implicit deny) integrated into the pfSense® software. Using this process results in a minimum amount of deny rules in a ruleset. They still have a role for certain applications, but their usage will be limited in the majority of contexts by implementing a deny-by-default method.

   pfSense software uses default deny on the WAN and default allow on the LAN in a setup with two LAN and WAN interfaces. Everything incoming from the Internet is forbidden, but everything outbound from the LAN to the Internet is allowed. This technique is used by all consumer-grade routers, all related open-source projects, and the majority of comparable commercial products. It's what the majority of users anticipate out of the box, thus it's the default setup. Nevertheless, although this is a simple method, it is not suggested for long-term use.

   Users of the pfSense software often ask, "What harmful things should I block?" Yet, this is the incorrect question when it comes to the default allow method. Marcus Ranum included default permission in his article "Six Dumbest Concepts in Computer Security," which is required reading for every security practitioner. Avoid keeping the default allow all rule on the LAN and putting block rules for "bad stuff" above the permit rule.

3. Audit Firewall Rules: Periodically reviewing the firewall rules and NAT settings manually to verify they continue to meet the minimal needs of the current network environment is the recommended practice. The suggested frequency of such evaluations varies depending on the context. On networks with few changes, a limited number of firewall administrators, and effective change control methods, quarterly or semi-annual updates are often sufficient. For rapidly changing environments or those with inadequate change control and several users with firewall access, the configuration should be reviewed at least weekly.

4. Document the Configuration: It might be difficult to recollect what is configured where and why for all networks. The recommended practice is to describe the purpose of firewall and NAT rules using the Description field. Create and maintain a more extensive configuration document covering the whole pfSense software setup for bigger or more complicated installations. This assists future firewall configuration reviews in determining which rules are essential and why they exist. This applies to any other configuration element. It is also essential to maintain this paper currently. Review this document in conjunction with periodic configuration reviews to verify that it reflects the current setup. Ensure that this page is updated if there are configuration changes.

5. Implement Logging Methods: pfSense software does not record any forwarded traffic and logs all lost traffic by default. This is the default behavior of almost every commercial and open-source firewall. That is the most practical option, since tracking all passed communication is seldom desired owing to the created load and volume of logs. From a security standpoint, this practice is quite backward. Traffic that is blocked cannot disrupt a network, therefore its log value is limited, but information on traffic that is let through might be crucial if a system is infiltrated. After removing any unnecessary block noise as indicated in the preceding section, the remaining data is useful for trend analysis. Whenever an abnormally high or low log volume is seen, it is likely necessary to explore the nature of the recorded traffic. Open source host-based intrusion detection system (IDS) OSSEC may collect firewall logs through syslog and generate alerts depending on anomalous log volume.

6. Regular Backup: pfSense software contains numerous firewall rules that correspond to your customized network settings. Periodically saving a copy of the Pfsense configuration in a secure location is crucial. These backups can be lifesavers in the event of a software failure.

7. Eliminating Log Noise: The pfSense software reports packets that are denied by the default deny rule. This implies that every Internet traffic that is banned is recorded. Sometimes there will not be much noise in the logs, but in many situations, there will always be something spamming the logs continually.

   In networks employing huge broadcast domains, a technique widely used by cable ISPs, these are typically NetBIOS broadcasts from clueless users who connect Windows workstations straight to their broadband connections. These computers will continuously transmit, among other things, broadcast requests for network surfing. ISP routing protocol packets or router redundancy protocols such as VRRP or HSRP may also be observed. In co-location settings, such as data centers, there may be a mix of all of these elements.

   Since there is little benefit in knowing that the firewall stopped 14 million NetBIOS broadcasts in the last day, and because noise might be obscuring vital logs, it is advisable to implement a block rule for repetitive noise traffic on the WAN interface. By implementing a block rule without logging on the WAN interface, this traffic will continue to be denied, but the logs will no longer be bloated.

   The rule shown in Figure Firewall Rule to Disable Logging Broadcasts is configured on a test system where the "WAN" is located behind an edge firewall on an internal LAN. We implemented this rule to block, but not log, any packets destined for the subnet's broadcast address in order to eliminate log noise and allow us to focus on the relevant data.

   

   Figure 28. Firewall Rules to Restrict Logging Broadcasts on pfsense

   Best practice is to add equivalent rules that fit the particulars of any detected log noise in an environment. Review the firewall logs under Status > System Logs, Firewall tab, to determine the kind of traffic the firewall is blocking and the frequency with which it arrives. If a certain kind of traffic is continuously being recorded more than five times per minute and it is neither malicious nor significant, apply a block rule to decrease log noise.