In computing, a firewall can mean one of two things: it can refer to a network appliance that has as one of its functions the ability to filter incoming and outgoing traffic (hardware) or a service running on a computer that has the ability to filter traffic (software). In this chapter, we will be using the latter sense of the term. We will be focused primarily on the ability to use pfSense as a means of filtering traffic on your network, which is likely to be one of pfSense's primary functions, regardless of the deployment scenario.

In this chapter, we will cover firewall rules and rule methodology. We will also cover several services that are part of pfSense's core firewall functionality, such as NAT and scheduling. In fact, we will cover everything except traffic shaping, which will be covered in the next chapter. The topics covered in this chapter are:

An example network

It often helps to use concrete examples to help illustrate concepts, so once again we will imagine a hypothetical network in order to understand how we would go about configuring firewall rules for a specific environment. Imagine a network with four subnets: SALES, MARKETING, DEVELOPERS, and a DMZ, and with the following requirements:

All subnets should be allowed to access the Internet, subject to the restrictions outlined as follows:

• SALES should not be able to talk to MARKETING and DEVELOPERS; MARKETING should not be able to talk to SALES and DEVELOPERS; DEVELOPERS should not be able to talk to SALES and MARKETING.
• SALES, MARKETING, and DEVELOPERS should be able to talk to the DMZ, but the DMZ should not be able to talk to any local subnets (other than DMZ).
• SALES and MARKETING share a printer that is on the MARKETING subnet, so SALES should have access to that printer, but not any other nodes on MARKETING.
• The company is cracking down on non company related Internet use that consumes excessive bandwidth, so YouTube should be blocked on all subnets.
• Developers waste too much time on Slashdot, so https://slashdot.org/ should be blocked on the DEVELOPERS subnet, although access should be allowed during lunch hour (Noon-1 PM).
• The company wants to set up an FTP server for customers, which is to be placed in the DMZ subnet. For the FTP server to be accessible via the Internet, access to port 21 must be allowed and traffic to port 21 must be forwarded to the FTP server.
• The company also wants to incorporate some redundancy into the firewall configuration, so there should be two redundant firewalls, with one set up as the master firewall. The second firewall will only be used if and when the master firewall fails.

As you might imagine, these requirements will figure prominently in what firewall/NAT rules we will implement. We can tentatively diagram our network in the following way:

An example corporate network, with separate networks for different departments, and some shared resources.

pfSense's firewall capabilities are more than enough to meet the requirements of our network. We will revisit this scenario in subsequent sections.