Building A High-Availability pfSense Firewall Pair

A single firewall can be reliable for years, yet it remains a single point of failure. A failed power supply, storage device, software upgrade, or careless interface change can disconnect an office from cloud services, voice platforms, remote staff, and the internet. A high-availability pfSense deployment reduces that exposure by keeping a second firewall ready to take over.

The usual design uses two pfSense appliances with shared virtual IP addresses. Common Address Redundancy Protocol, or CARP, presents those addresses to the local network, while pfsync replicates active connection states between the nodes. Configuration synchronisation then keeps rules, NAT, DHCP, VPN, and other settings aligned.

This arrangement suits an Australian branch office, workshop, school, or home lab with a business-grade NBN service and a 4G or 5G backup connection. It is valuable in Sydney and Melbourne offices where a short outage can interrupt SaaS work just as severely as a hardware fault, and in regional areas where replacement equipment may take several days to arrive.

Define The Failure You Need To Survive

Start by writing down what the pair must protect. A firewall cluster can handle a node failure, planned maintenance, and some interface faults, but it cannot automatically solve an NBN provider outage, a failed upstream modem, or a power cut affecting both appliances.

For a small site, the practical target is often continued LAN access, internet connectivity, site-to-site VPNs, and remote-access VPN availability when either firewall is offline. If the business depends on hosted accounting, Microsoft 365, VoIP, or Australian cloud regions, document acceptable downtime and which services need a live session to survive a failover.

Keep the design within pfSense’s supported architecture. Use matching hardware, the same pfSense release, equivalent interface names, and compatible packages. Mixing a 2.5 GbE appliance with a slower second unit can work, but it complicates troubleshooting and may create an unexpected bottleneck during a failure.

Choose Hardware And Network Interfaces

Each firewall needs a dedicated synchronisation path, normally a direct Ethernet connection or a small isolated switch segment. A second private link is useful for configuration synchronisation and state replication, while the production interfaces carry WAN, LAN, and optional DMZ traffic. Avoid sharing synchronisation traffic with a busy user VLAN.

Hardware vendors and appliance models vary widely in Australia. Imported mini-PCs may be inexpensive, but warranty handling, replacement time, power adapters, and Intel NIC compatibility matter more than a low purchase price. Karl’s hardware vendor guide is a useful reference when comparing appliance sources and network components.

Use a UPS for both firewalls, the NBN termination device, network switch, and wireless controller. In places affected by summer storms, bushfires, or unstable local power, a UPS and a tested shutdown policy may protect availability better than buying a faster CPU.

Prepare Addressing And Shared Services

Give each firewall a unique management address on every relevant subnet, then reserve a separate CARP virtual IP for the address used by clients. For example, the nodes might use 192.168.10.2 and 192.168.10.3, with 192.168.10.1 as the shared LAN address. The same principle applies to WAN, DMZ, and VPN-facing networks where CARP is appropriate.

CARP advertisements require correctly configured multicast or protocol traffic between the nodes. Firewalls, managed switches, and upstream equipment must permit the required traffic, and both machines need matching interface assignments. Confirm that switch port security, spanning-tree settings, and VLAN tagging do not interfere with the heartbeat.

Decide which device supplies DHCP and DNS services. pfSense can provide both, but a failover arrangement needs deliberate settings so clients do not receive conflicting leases or resolver addresses. Use the shared LAN address for clients, and make sure DNS Resolver, NTP, certificates, and gateway monitoring behave consistently after a role change.

Build The First Node Carefully

Install the same pfSense version on both appliances, but configure the primary node first. Set hostnames, interfaces, VLANs, gateways, DNS behaviour, firewall aliases, NAT rules, VPNs, and monitoring before enabling synchronisation. Export a configuration backup and record the physical port mapping.

Create the synchronisation account with a strong, unique password, then configure XMLRPC synchronisation from the primary to the secondary over the private link. Select only the settings that should replicate. Certificates, DHCP leases, package data, and interface assignments deserve special attention because an indiscriminate sync can overwrite a necessary node-specific value.

Treat the firewall configuration like infrastructure code. Keep encrypted backups outside the appliance and record changes in a repository or ticket system. Teams already using automated testing for PHP can borrow the same discipline from continuous integration practices: make small changes, review them, and retain a known-good version.

Enable CARP And State Synchronisation

After the primary configuration is stable, add the virtual IPs and configure CARP priorities. The intended primary should have the higher effective priority, while the secondary remains ready to become master. Set a clear pfsync interface and confirm that state traffic is not filtered or routed through an unsuitable path.

Test with ordinary traffic before scheduling an outage. Start a download, establish an SSH session, place a test VPN connection, and observe whether the sessions survive when the active node is stopped. Some protocols will reconnect regardless, while long-lived TCP sessions may expose a missed state or asymmetric routing problem.

Check gateway groups and monitoring targets as well. A firewall can remain powered on while its WAN path is unusable, so gateway health checks should be meaningful rather than aimed only at the provider’s immediate next hop. For NBN services, document how the modem or NBN connection device behaves during a firewall failover.

Plan Operations And Security

HA does not remove the need for patching. Upgrade one node at a time, verify that the surviving node is carrying traffic, and confirm that synchronisation is healthy before touching the other. Read the release notes for pfSense, installed packages, OpenVPN or IPsec changes, and any CARP-related behaviour.

Restrict management access to trusted administration networks and use multi-factor authentication where available. Log administrator activity, configuration changes, VPN events, and failover transitions to a central system. Australian organisations handling personal information should align firewall operations with the Privacy Act and the Australian Privacy Principles, particularly around access control, retention, and incident response.

The Essential Eight is not a complete firewall design, but its emphasis on patching, privileged access, backups, and logging provides a sensible operational baseline. Keep an offline or separately hosted configuration backup, because a synchronised mistake can otherwise reach both appliances.

Test Failover As A Routine Task

A cluster is only high availability if staff know how it behaves. Schedule a quarterly test that records the active node, CARP status, pfsync health, VPN reachability, DNS resolution, DHCP leasing, outbound internet access, and monitoring alerts. Test both planned failover and abrupt power loss.

The physical environment deserves testing too. Clean dust from vents, inspect UPS batteries, and confirm that cables are labelled and firmly seated. Small maintenance tasks can prevent strange faults; even basic device-care guidance, such as how to clean iPhone speakers safely, reinforces the broader principle of using gentle, documented maintenance rather than improvised tools.

Record the time required to restore service and the steps needed to return control to the preferred node. If failback is automatic, ensure it does not cause repeated role changes. If it is manual, document who authorises it and how the team verifies that synchronisation is complete.

Practical Recommendations For Deployment

A dependable pfSense pair benefits from simple standards that are easy to audit and repeat:

• Use identical or closely matched appliances with supported network adapters.
• Connect both firewalls, the network core, and the NBN termination equipment to a UPS.
• Reserve dedicated interfaces or VLANs for pfsync and configuration synchronisation.
• Give every node a unique management address and use CARP addresses for clients.
• Keep pfSense versions, packages, interface names, and time settings aligned.
• Store encrypted configuration backups away from both firewalls.
• Schedule failover drills and record the observed recovery time.

A well-built cluster should make maintenance uneventful rather than mysterious. Start with a small lab test, introduce the design during a controlled maintenance window, and keep the old firewall configuration available until traffic, VPNs, monitoring, and failback have all been verified. Then make the test schedule part of normal infrastructure operations.