Now that we have covered some basic firewall principles, we can begin our firewall configuration. To create and/or edit firewall rules, log in to pfSense and navigate to Firewall | Rules. This should present you with a list of interfaces across the top of the page; you can see the ruleset for each interface by clicking on its name (initially, you will see the ruleset for the WAN interface). Typically, we will click on the interface for which we want to create/edit rules first, although you can create rules for any interface from any tab, since the Rule Edit page will provide an Interface option that allows you to choose the interface to which the rule applies. Click on the interface for which you want to add a rule and use one of the two Add buttons at the bottom of the page to create a rule. The Add button with the up arrow will place the newly created rule at the top of the table, while the Add button with the down arrow will place the newly created rule at the bottom of the table. Another helpful option is to use the Copy button, which can be seen on the right side of a table listing of a current rule. The Copy button (represented by an icon showing two sheets of paper) allows you to create a new rule based on an existing rule. When you press the Copy button, you will generate a new rule in which all the options are initially identical to the old rule.
Choosing any of the options outlined earlier will launch the Edit page for firewall rules. The first section of the page is Edit Firewall Rule, and the first option is the Action drop-down box, which allows you to select what happens to packets that meet the rule criteria. The options for the rule are as follows:
- Pass: Let the traffic pass
- Block: The packet is dropped silently
- Reject: The packet is returned to the sender with a TCP RST or ICMP port unreachable message (TCP RST is for TCP traffic, ICMP port unreachable is for UDP traffic)
There is a split of authority on whether the best practice is to block traffic or reject it. The advantage of Reject, of course, is that the sender knows right away that access to the resource is not allowed, whereas with block, the connection eventually times out:
Creating a rule in pfSense. The rule allows TCP traffic to pass from the DEVELOPERS network to a WAN address.
This Disabled checkbox, if checked, will result in the rule being disabled without removing it from the ruleset. The Interface drop-down box allows you to select the interface to which this rule applies (the interface from which packets must come in on for the rule to apply). The Address Family drop-down box lets you select which Internet protocol version to which the rule applies: the choices are IPv4, IPv6, or both (IPv4+IPv6). Finally, the Protocol drop-down box allows you to select which IP protocol the rule should match. You should try to avoid using the any option here, and only allow the protocol or protocols you need to allow.
The next section of the page is Source, which allows you to specify where the packets must originate if they are to match the rule. In the Source drop-down box, you can specify several options: any will result in any packet on the interface matching the rule; Single host or alias enables you to enter a single IP address or alias (we will cover how to create an alias later in the chapter). Network allows you to enter a subnet (if you select it, you must enter the network portion of the address and the CIDR). You can also select PPPoE clients (PPPoE stands for Point-to-Point over Ethernet) or L2TP clients (L2TP stands for Layer 2 Tunnelling Protocol). The remaining options allow you to select as the source either an entire interface you previously created (for example, LAN) or an address on that interface. The Invert match checkbox, if checked, will result in the rule being applied to the opposite of what is selected for the source. For example, if you select LAN net and check Invert match, the rule will apply to everything but the LAN net. Clicking on the Show advanced button will reveal the Source port range options. You can select ports from the drop-down boxes or type them directly into the edit boxes.
The Destination section allows you to select the destination the packets must match for the rule to apply. It mirrors the Source section, with the exception of the fact that the Destination port range field is always visible and showing/hiding this option is not possible. As with Source, you can invert the match.
The next section is called Extra Options. The Log checkbox, if checked, will log packets that are handled by the rule. Usually you won't want to turn on logging for rules, since that's a good way to use up all remaining disk space, but if you need to log packets for an individual rule, you can do it here. You can also enter a brief description for future reference. Clicking on the Advanced Options button will show the Advanced Options section of the page.
The Source OS drop-down box allows you to select the operating system from which the packets must come if the rule is to be applied. There are many options (including Any), although there does not seem to be options for newer versions of Windows (there are no options for Windows 7, 8 , or 10, although there are options for older versions as well as a generic Windows option). The Diffserv Code Point option allows you to apply the rule only to certain Diffserv Code Point values; different Diffserv values are used for traffic filtering or queue assignments. Traffic shaping must be enabled for this option to work.
By default, pfSense blocks packets with IP options set; checking the Allow IP options checkbox allows these packets to pass. The Disable reply-to checkbox is designed for setups in which a non-WAN interface is the gateway for part of our network. If this is the case, reply-to traffic for a packet will be routed through the defined gateway rather than through the interface on which the packet arrived. This can result in the gateway forwarding the packet to the firewall, and the firewall sending it back, resulting in an eventual timeout. In cases such as this, we should enable the Disable reply-to option.
The Tag edit box allows you to mark a packet matching the rule. You can then use the mark to match on NAT and/or filter rules. The next option, Tagged, allows you to match a packet if a mark was placed on it by another rule.
The following options may be of some help in mitigating a DoS attack. Max. states defines the maximum state entries the rule can create, while Max. src nodes defines the maximum number of unique source hosts. Max. connections defines the maximum number of established connections per host. It only works on TCP (you have to have a connection for this rule to apply, so obviously it would not work with a connectionless protocol such as UDP). Max. src. States sets the maximum state entries per host. Max. src. Conn. Rate sets the maximum new connections per host. Max. src. Conn. Rate and Max. src. Conn. Rates together control the number of connections allowed per host per second(s). The first edit box specifies the number of connections and the second edit box specifies the time interval. For example, setting Max. src. conn. Rate to 25 and Max.src. conn. Rates to 60 will allow 25 connections per host per minute (60 seconds). Finally, State timeout specifies the amount of time before a state entry will expire. Obviously, this can help prevent the state table from filling up, thus potentially thwarting DoS attacks, but if the timeout is set for too short a time, legitimate traffic could be dropped. Max src. Conn. Rate, Max.src. Conn. Rates, and State timeout only apply to TCP connections.
The next setting, TCP Flags, can be used to choose which TCP flags need to be set or cleared in order for the rule to match. Check the flag in the set row to require that the flag be set; check the flag in the out of row to require that it be cleared. Check the Any flags checkbox for the rule to match if any flag is set or cleared.
The No pfSync checkbox, if checked, will result in states created by the rule not being synced over pfSync if Common Address Redundancy Protocol (CARP) is being used. The State type drop-down box allows you to choose which type of state tracking mechanism to use. The Keep option is the default option, and it works with all protocols. Sloppy also works with all protocols. It invokes a less stringent form of state tracking. This can be useful if asymmetric routing is used (like the situation with multiple gateways described earlier). Synproxy will automatically proxy incoming TCP connections. This is useful, because if it is invoked, pfSense will not create a new state table entry for a new TCP connection until it receives a SYN ACK packet. This will help protect your network from spoofed SYN flood attacks. As you probably have guessed, it only works on TCP connections. Finally, None results in no state entries being created for this rule.
The No XMLRPC Sync checkbox, if checked, will prevent this rule from syncing to other CARP members. Note that this only works between two or more master CARP members; it does not prevent the master from overwriting the rule on a slave CARP member. The VLAN Prio option allows you to choose an 802.1p priority level that must be set for on a VLAN packet for the rule to match. These priority levels (which were discussed in Chapter 3, Working with VLANs) are represented in the drop-down box as acronyms. The following table describes each acronym:
|
Acronym |
Description |
|---|---|
|
BK |
Background |
|
BE |
Best Effort |
|
EE |
Excellent Effort |
|
CA |
Critical Applications |
|
VI |
Video with less than 100 ms latency |
|
VO |
Voice with less than 10 ms latency |
|
IC |
Internetwork Control |
|
NC |
Network Control |
The VLAN priority set drop-down box allows you to choose an 802.1p priority to apply to the packets that match this rule. The abbreviations in this drop-down box are identical to the ones in the VLAN Prio drop-down box.
The Schedule drop-down box allows you to apply the rule only during a predefined time range. You can't create the time range on this page; you need to do this from Firewall | Schedules. The process will be detailed later in this chapter. The none option leaves the rule enabled all the time.
The Gateway drop-down box allows you to select a gateway for traffic matching the rule. If default is selected, then the system routing table is used. Otherwise, the traffic goes out on the selected gateway. This is useful if you want to set up policy based routing.
The next option is In/Out pipe. This allows you to pipe traffic coming from a selected interface (the In interface), and send traffic leaving the interface to another interface (the Out interface). The Ackqueue/Queue option allows you to pipe traffic coming from a specific traffic shaping queue and send the ACK traffic to a specific ack queue.
When you are finished making changes, click on the Save button at the bottom of the page. This will return you to the main Rules page.
Floating firewall rules are rules that are different from other firewall rules in two significant ways:
- They can be applied in any direction
- They can be applied to more than one interface
The following screenshot shows how to configure a floating rule:
Configuring a floating rule. Floating rules have the Quick option, and more than one interface can be selected.
Floating rules can be created by clicking on the Floating tab on the Rules page and clicking on one of the Add buttons. The options are similar to those in the conventional rule Edit page, with the following exceptions:
- The Quick checkbox, if checked, will cause pfSense to apply the rule to packets matching the rule and pfSense will not attempt to filter the packets against any other rules
- In the Interface listbox, more than one interface may be selected
- In the Direction drop-down box, you can choose to apply the rule to traffic coming into the interface (in), traffic leaving the interface (out), or both (any)
Keep in mind that floating rules are parsed before other rules, so even if the Quick option isn't enabled, a misconfigured floating rule could easily defeat the purpose of rules on individual interfaces.
To demonstrate the rule creation process, we will create one of the rules needed for our example network. Each subnet requires a rule to allow access to the Internet, so we will create such a rule for the DEVELOPERS subnet. The process, which is relatively simple, is outlined as follows:
- We navigate to Firewall | Rules, and click on the DEVELOPERS tab. Then we can click on either Add button below the table to add a new rule.
- On the Edit page, many of the default values can be used; the default Action value of Pass is kept. For Interface, we select DEVELOPERS as the interface from which packets must come in on to match this rule. We can set the Address Family field to IPv4, IPv6, or IPv4+IPv6, depending on whether or not our network supports IPv4 addresses, IPv6 addresses, or both. We only need to allow TCP traffic, so we leave Protocol set to TCP.
- The packets must come from the DEVELOPERS subnet for the rule to apply, so we set Source to DEVELOPERS net. We don't need to set a port range for this rule, so we will not click on the Show Advanced button.
- For this rule to apply, the traffic must be destined for the Internet, so for Destination, we select WAN net. We leave Destination port range unchanged, since we don't need to set a port range.
- For Description, we type Allow DEVELOPERS to WAN rule for future reference. Then we click on the Save button. Once we are returned to the main Rules page, we need to click on the Apply Changes button to reload the firewall rules.
That's all there is to it – nodes on the DEVELOPERS subnet should now be able to access the Internet. Keep in mind we still need to create similar rules for the other subnets, and we can do that easily by just clicking on the Copy button in the right side of the table next to that rule. Once we do that, we change Interface to the new interface (for example, ENGINEERING), and we change Source to match what we set in Interface. We change Description accordingly (for example, Allow ENGINEERING to WAN rule) and click on Save. We have now made a duplicate rule for another subnet. Another option would be to set up a floating rule to allow Internet access to all subnets that require it.