Networking for the Cloud Engineer: Why pfSense Should Be in Your Toolbox

Over the festive holidays, I had the chance to work on a new project: configuring a pfSense router for my home network. Moving away from ISP-provided equipment has always been my preference, and I initially tried replacing my ISP router with a Juniper SRX300. Unfortunately, I encountered significant speed issues with my FTTP connection. After extensive troubleshooting, it became apparent that these issues were due to compatibility between Juniper's hardware and the technology used by Openreach.

A bit of research led me to pfSense as a viable alternative—a maintained, feature-rich software solution that is well-supported by the community. I decided to give it a go and purchased a generic four-port mini PC with 8 GB of RAM and an Intel N100 processor. Admittedly, this setup is overkill since it doesn't serve Wi-Fi, but I didn’t want my router to be a bottleneck in the network.

Setting Up pfSense

Installing the pfSense Community Edition was straightforward. For Openreach-based FTTP providers, minimal configuration is required. Simply input your ISP username and password, and pfSense supports all the necessary technologies commonly used by UK ISPs, such as PPPoE and DHCP (Sky). After a quick reboot, the connection was live, and I achieved full speed, unlike with the Juniper setup.

What I found particularly helpful was the wealth of guides and videos available online from others who have configured pfSense for various UK ISPs. This made it easy to find and apply the correct settings.

Configuring Subnets and Bridging Interfaces

In my setup, I needed just one subnet for all devices on the network. Unlike Juniper routers, pfSense doesn’t offer a simple way to do this out of the box. To achieve this, I had to bridge two interfaces together. Here’s how I configured it:

1. Create a Bridge Interface: Navigate to Interfaces > Assignments > Bridges. Add a new bridge interface and select the interfaces you want to include.
2. Configure DHCP for the Bridge: Go to Services > DHCP Server and select the newly created bridge interface. Enable DHCP and configure the address range.
3. Set Firewall Rules for the Bridge: Under Firewall > Rules, add rules for the bridge interface to allow traffic as needed.

While this required more manual configuration than some other routers, the flexibility and control offered by pfSense made it worthwhile.

Firewall and NAT Configuration

pfSense’s firewall is impressive. It comes with automatic NAT configuration enabled by default, which worked seamlessly with the WAN interface. However, I needed to create a firewall rule to allow outbound traffic. This was a simple task:

1. Go to Firewall > Rules > LAN.
2. Add a rule to allow all outbound traffic from the LAN network.
3. Save and apply the settings.

The process was intuitive and straightforward, and I appreciated how quickly I could get up and running.

Advanced Routing and VPN Configuration

For the main configuration, I didn’t need to adjust routes or static routes. However, I’ve been experimenting with policy-based routing for an OpenVPN connection. While the routing works, the VPN itself has been somewhat unstable, and traffic isn’t flowing as expected. I’m still tinkering with this setup and hope to resolve the issues soon.

Drawing Parallels with Azure and Enterprise Firewalls

Working with pfSense has provided a hands-on understanding of networking principles that directly relate to Azure and other enterprise-grade firewalls like Palo Alto, Fortinet, and Azure Firewall. Here are some key parallels:

1. Firewall Rules: Configuring rules in pfSense mirrors the process of managing Network Security Groups (NSGs) in Azure. The principles of allowing and denying specific traffic flows are foundational across both platforms. Similar to Azure Firewall, pfSense allows for granular rule definition, including source, destination, ports, and protocols.
2. Routing: The routing features in pfSense align closely with Azure Route Tables and UDRs (User-Defined Routes). The ability to define static routes and implement policy-based routing is a valuable skill transferable to cloud environments.
3. NAT Configuration: pfSense’s automatic NAT setup is similar to Azure’s default SNAT/DNAT configuration. Customizing these settings in pfSense can help understand how Azure handles inbound and outbound traffic for public-facing resources.
4. Diagnostics Tools: The diagnostic tools in pfSense, such as traceroute, packet capture, and ARP table monitoring, are akin to Azure’s Network Watcher capabilities. These tools are crucial for troubleshooting and optimizing both on-premises and cloud networks.
5. VPN Setup: Configuring OpenVPN in pfSense parallels setting up Azure VPN Gateway for site-to-site or point-to-site connections. Both require a deep understanding of certificates, routing, and security policies.

Diagnostic Tools: A Game-Changer

One of the standout features of pfSense is its comprehensive suite of diagnostic tools. From ping and traceroute to ARP tables and session monitoring, the depth of information available rivals that of many enterprise-grade firewalls. These tools have already proven invaluable in troubleshooting connectivity issues and optimizing network performance.

Final Thoughts

pfSense has been a fantastic addition to my home network. Its flexibility, robust feature set, and extensive community support make it an excellent choice for anyone looking to move away from ISP-provided routers. For cloud engineers like me, working with pfSense is a great way to deepen your understanding of networking fundamentals and apply those skills to cloud environments such as Azure.

In the future, I’m considering testing OPNSense, a fork of pfSense that some say offers a better experience. For now, though, I’m thoroughly enjoying the process of exploring what pfSense can do.

Whether you’re managing a home lab or architecting enterprise networks, pfSense is a tool worth having in your toolbox. If you’re already using pfSense or considering it, I’d love to hear your experiences and tips!