Configuring pfSense Firewall rules is a very easy process. Easy in this case also goes with very detailed and granular. Which shows the nature and the flexibility of the pfSense Firewall. Undeniably one of the most popular firewall of choice among several communities and used for different applications including homelab environments. In fact, this article follows a series dedicated on how to run pfSense in a VMware homelab.
pfSense provides both commercial and open-source based setups effectively running a similar code, if not the same onto a virtual appliance. Resources wise is not very intensive and can comfortably run in a low spec Virtual Machine. Perfect for matching a VMware homelab environment encompassing VLANs to separate system, data and VM network traffic types. This is what the rest of the article covers showing some examples on how to define and create the pfSense Firewall rules to accommodate different traffic types and more importantly the traffic routing between several VLANs.
First part of the article covers a general overview on how to create and manage these rules in the pfSense Firewall. The second part shows some “working” examples. Rules are pretty basic, although more complicated ones can be created for more sophisticated scenarios. Which will be covered in dedicated articles.
Overview of the pfSense Firewall
From the Web GUI and then browsing the Firewall section it already shows the active interfaces. These are in fact any combination of physical network cards and VLANs associated to any of these network cards. pfSense Firewall rules can be created individually for each one of these interfaces and are executed as part of different chains. So if the network packets are traversing a specific network interface (physical and VLAN) the rules will be created in the same interface. The sample below shows a couple of physical (WAN and LAN, these are the virtual machine vNics!) and VLANs created in pfSense and sharing the LAN interface card as the physical medium. As per previous articles this setup supports separate VLANs for VMware vMotion and Provisioning traffic, VM Production network, VM LAB for testing and separate from Production, VM Nested to run additional Hypervisors like Nutanix AHV and Microsoft Hyper-V hosted in VMware environment and VSAN covering a separate VSAN LAB for learning and additional testing.
Floating Rules are a special type of firewall rules and typically perform additional actions not available with “simple” rules directly on the other interfaces or group tabs. Floating rules can run on multiple interfaces for inbound, outbound, or both directions. In general, most firewall configurations prefer simple rules over the “floating” ones. One more thing to take into consideration is the order how the firewall rules are processed. Floating rules are processed first and take precedence over the simple ones on the interfaces. Also all the rules will process from the top down and the first one matching the criteria then executes.
Moving to the pertinent tabs or interface names, it is possible to manage the existing chains. Interestingly, the pfSense Firewall also shows statistics on the inbound and outbound traffic. More advanced dashboard are also available in Status > Traffic Graph.
At the bottom of each chain for each interface, the buttons to create, delete and save the new rules. In addtion, a handy separator which allows to visually separate the rules in the chain and even add a specific accent color. For each change to the rules is necessary to save and apply for the pfSense Firewall to reload the active configuration. All in all, the process usually takes between 2 and 3 seconds!
At this point when adding a network rule the following details need to be set:
- Action
Pass, Block and Reject, depending on the desired effect.
- Disabled
Enables or disables the rule in the chain without deleting the rule itself. Useful for testing network communication
- Interface
Specifies the network interface the network packets will use
- Address Family
Specifies the Internet Protocol, typically IPv4. Includes IPv4 and IPv6 as well for IPv6 applications already.
- Protocol
Selects the Network Protocol like TCP, UDP, ICMP and many more
- Source
Identifies the packets origin. Highly flexible shows options for specific Hosts, Addresses, Network to include or exclude with the invert match option.
- Destination
Identifies the packets destination. Highly flexible shows options for specific Hosts, Addresses, Network to include or exclude with the invert match option.
Each one of these rule settings can be changed at any time.
A good start when creating pfSense Firewall rules is to make sure at least to grant access from specific locations or IP addresses to the Firewall itself. Depending if SSL encryption is enabled the standard port 80 and 443 should be open to allow connectivity to the Web GUI. In addition, allowing the ICMP protocol it provides a quick test with PING to test connectivity to the pfSense virtual router. The ICMP protocol can be customised even further based on the allowed response types.
Inter-VLAN routing
Another important and interesting feature is to provide inter-VLAN routing from the pfSense Firewall. Just using the built-in buttons to add new rules it is possible to decide which network packets are allowed to traverse which VLAN network. In this case for example, the PING will work for all Hosts in the Prod, LAB, Nested and VSAN networks. In addition also the ability to PING the vMotion and Provisioning gateway IP addresses. Very useful for troubleshooting connectivity on specific VMware Network Stacks and using custom routing tables. The “vmkping” command with the “S” and “I” options covers exactly this.
RDP, HTTPS, SSH and SMB access to specific Servers
Another section or divider in the pfSense Firewall rules can be created for example to provide access to dedicated services running on specific Hosts in the network. A few but typical examples include Remote Desktop Access (RDP), HTTP over SSL (HTTPS), Secure Shell (SSH) and Samba (SMB) from/to specific servers. In particular RDP for Windows based and SSH for Unix/Linux are a convenient way to remotely administer the Servers. Each one of these rules can be edited and disabled when required. Default chain policy is to drop packets if none of the rules matches the criteria.
Sample Network Ports for Veeam components
For specific applications of course it is possible to create ad-hoc pfSense Firewall rules. In this case for a Veeam protecting both the Virtual and Physical infrastructure, and depending where different components are located, the screenshot below shows a sample of the default network ports used by Veeam Backup Proxies. A full list of Veeam required network ports is available here.
Network configuration for FreeNAS
Another sample for network ports that require pfSense Firewall rules for popular applications include FreeNAS. In this case communication is allowed only to ports 80 and 443 from hosts in a different VLAN. This allows management over the Web interface only. Of course the FreeNAS Web interfaces can be accessed only with the correct credentials.
PfSense Firewall rules for NetApp ONTAP and VSC
For those who run NetApp ONTAP simulators and Virtual Storage Console (VSC) it is a good idea to configure the pfSense Firewall to allow access not just to the HTTP and HTTPS to access the Web Management interfaces but also to the specific network ports to ensure the communication between the ONTAP storage arrays, the NetApp VSC and the VMware VCSA should sit on separate VLANs and networks. These network ports are essential for many activities including data transport, storage array registration, configuration and management.
Nutanix and Hyper-V nested in VMware?
An additional use case is for homelab environments hosting nested Hypervisors. This includes for example the ability to run a Nutanix AHV cluster nested into a VMware environment. This allows to maximize the investment on a fantastic hardware setup based on Intel NUCs. Plenty of articles from the Community offer more and more ideas on how and what to run in a homelab.
Microsoft Active Directory behind a pfSense Firewall
An finally as a bonus use case the ability to restrict communication to a Microsoft Active Directory sitting on a separate VLAN and only to the required network ports. The sample below provides an idea of the required network ports that should be configured on the pfSense Firewall to allow authentication and authorization for all Active Directory Domain Services operations. Ranging from joining new Computers to the domain to a lot more sophisticated operations like replication to a secondary Domain Controller. In this example, the Microsoft Active Directory server sits on a VLAN separated from the Production environment.
Additional control with scheduling features
Once all the required rules have been created and tested, the pfSense offers even more functionalities. In fact it allows to enable or enforce the firewall rules at specific time. This creates the opportunity to let the firewall behave differently based on the time of the day, week and month. Something like different rules between Peak and Off-Peak.
pfSense Firewall additional features
On top of the extensive network rules, the pfSense Firewall offers additional features like creating Aliases, Natting, Traffic Shaping and Virtual IPs. Each one these includes nice options that further extend the capabilities of this virtual router. Aliases are great for “replacing” friendly names with IP Addresses or Hostnames and can be used to create rules in the firewall too. Traffic Shaping is usually working with floating rules and also allows to have standalone configurations. Natting and Virtual IPs work great and allow for endless scenarios especially when working together with other routers or other layer 3 devices. Really a lot to cover in dedicated articles.
Add Comment