This section will determine which pfSense deployment scenarios is most applicable by analysing our network diagram.

In this section, we will make use of our network diagram to understand how and where pfSense will fit into our environment. As an example, we will use a relatively typical small Office/Home Office setup. We begin by looking at our network diagram:

In this small office scenario, the firewall that we have diagrammed clearly meets the definition of a perimeter firewall, which is the most common of pfSense deployments.

A perimeter firewall becomes the gatekeeper of all traffic flowing between interfaces. We will define firewall rules based on how we want that traffic to flow. A few common rules that most networks enforce are:

• Allow all from LAN to WAN: The LAN should have outbound access to the WAN so its users can access the internet.
• Allow some from LAN to WAN: The practice known as egress filtering involves limiting the types of traffic allowed to leave a network to ensure unauthorized or malicious traffic never leaves it.
• Block all from WAN to LAN: Do not allow external users to get into our own private network.
• Allow HTTP from LAN to DMZ: Allow our internal users to access our company's web server.
• Allow HTTP from WAN to DMZ: Allow external users to access our company's web server.
• Block all from DMZ to LAN: Our DMZ is insecure since we are allowing external users to come and access the web server. We want to protect ourselves by blocking any traffic that attempts to access our LAN from the DMZ.

pfSense also employs many advanced firewall features to accommodate the needs of more complex networks. pfSense is capable of the following:

• Supporting dozens of interfaces.
• Handling multiple internet connections, in case the primary internet connection fails (multi-WAN).
• Failover protection, in case the primary firewall dies (CARP).
• Load balancing, to optimize network traffic by balancing demanding loads.

pfSense is highly flexible and can also be configured as any of the following devices. It's important to note that these roles are simply services that we will use within our perimeter firewall deployment, but larger environments may want to build these roles as separate machines to improve performance:

• Router: This is the second most common deployment of pfSense. A router determines a packet's destination and then sends it on its way, without applying any firewall rules. A router is not necessarily deployed at the perimeter of a network.
• VPN appliance: A VPN server provides encrypted remote network connections. pfSense supports all the major virtual private networking protocols, such as IPsec, OpenVPN, and L2TP.
• DHCP appliance: A DHCP server assigns IP addresses to clients that request them.
• DNS appliance: A DNS server associates names with IP addresses. It's much easier to remember google.com than its IP address.
• VoIP appliance: Voice over IP (VoIP) is digital telephony, possible with pfSense.
• Sniffer appliance: Sniffers analyse packets for patterns. This is often to detect and prevent traffic that attempts to exploit known vulnerabilities. pfSense utilizes the most widely deployed sniffer package in existence, Snort.
• Wireless Access Point: pfSense can be deployed strictly as a wireless access point, through it rarely is.
• Switch: It is possible to disable all filtering in pfSense and use it as a switch. That makes for one expensive switch (by way of comparison, a simple 5-port GBEthernet switch can be obtained for less than $20 USD), but it is an option.     

pfSense can be configured with many more devices—pfSense being deployed as a special purpose appliance is only limited by the number of packages supported by the platform.