How I used Proxmox and pfSense to finally stop worrying about my internet going down during server maintenance.

It’s a familiar feeling for any home lab enthusiast. You’re in the middle of a big software update on your main server, or maybe you’re just rebooting it after a quick tweak. Suddenly, the Wi-Fi cuts out. Your partner calls from the other room, “Is the internet down again?” Your smart home devices go dark. It’s a reminder that your entire digital life runs through that one machine. I was tired of this being my reality, which is why I embarked on a project to build a truly redundant router setup.

My goal was simple: I wanted to be able to take one of my servers completely offline for maintenance, or even have it fail unexpectedly, without bringing my entire home network to a screeching halt. A brief interruption of a few seconds is fine, but I wanted the network to heal itself automatically for anything longer.

If you’re running a virtualized router on Proxmox, pfSense, or a similar platform, you have a powerful but fragile single point of failure. This is the story of how I fixed that.

Why Even Bother with a Redundant Router Setup?

Let’s be honest, for most homes, a single router from your ISP is good enough. But if you’re like me and you use your home lab for critical services—or you just have a low tolerance for downtime from your own tinkering—then creating a failover system is a fantastic project.

The main benefits for me were:

• Zero-Downtime Maintenance: I can now perform Proxmox host updates, reboot servers, and even test new hardware on my primary machine without anyone in the house noticing the internet is gone.
• Real-World Skills: Setting this up teaches you a ton about networking, virtualization, and high availability concepts that are used in enterprise environments.
• Peace of Mind: It’s just nice knowing that if one server has a hardware issue, the backup is ready to take over instantly.

The core of my project involved adding a second Proxmox server to my lab. With two hosts ready, I could finally tackle the single point of failure that was my lone virtualized pfSense router.

The Big Challenge: One Public IP, Two Routers

You can’t just plug two routers into your cable modem and call it a day. Your Internet Service Provider (ISP) typically only gives you a single public IP address. So, how do you make two routers share it?

The solution lies in a concept called a “Virtual IP” (VIP). Instead of assigning your public IP directly to one router, you assign it to a virtual address that can float between your two router instances. One router acts as the “MASTER” and actively handles all traffic. The second router is the “BACKUP,” constantly monitoring the master. If the backup stops receiving a heartbeat signal from the master, it immediately takes control of the virtual IP and becomes the new master. This failover is the magic that makes a redundant router setup possible.

Understanding CARP: The Heart of pfSense High Availability

This automatic failover process is managed by a protocol. In the world of pfSense and OPNsense, this protocol is called CARP, or the Common Address Redundancy Protocol. It’s a free, open-source alternative to similar proprietary protocols used in expensive enterprise gear.

Here’s a simple breakdown of how it works:

1. Shared Virtual IP: Both of your pfSense VMs are configured with the same virtual IP address on their WAN and LAN interfaces.
2. Master and Backup Roles: One firewall is given a primary status (MASTER) by setting its “advertising skew” value to a low number, like 0. The backup is given a higher number, like 100. The lower number wins.
3. Heartbeats: The MASTER firewall constantly sends out CARP “advertisements” or heartbeats to the network, essentially shouting, “I’m here, and I’m in charge!”
4. Failover: The BACKUP firewall listens for these heartbeats. If it doesn’t hear them for a short period (usually about a second), it assumes the MASTER is down. It then takes over the Virtual IP and becomes the new MASTER.

This process is incredibly fast and is the standard way to achieve high availability. For a deep dive into the technical specifics, the official Netgate documentation for pfSense High Availability is an excellent resource.

My Proxmox & pfSense Redundant Router Setup: An Overview

I won’t provide a line-by-line tutorial here, but I will walk you through the key steps I took to get my system running.

First, I configured two identical pfSense virtual machines, one on each of my Proxmox hosts. The crucial part of the Proxmox setup was networking. I created a Linux Bridge on each host that was tagged with a specific VLAN (e.g., VLAN 99). I then physically connected a port from each Proxmox host assigned to this VLAN to a small, unmanaged switch along with the port from my cable modem. This created an isolated “WAN zone” where both routers could see the internet connection.

Inside pfSense, the configuration looked like this:

• Sync Settings: First, I set up High Avail. Sync (System > High Avail. Sync) on the primary node. This is amazing because it automatically copies all of your firewall rules, DHCP settings, and more to the backup router. You only have to manage one firewall!
• Create Virtual IPs: Next, under Firewall > Virtual IPs, I created CARP VIPs for both my WAN and LAN interfaces. This is where I assigned the “Advertising Skew” to define the MASTER (skew 0) and BACKUP (skew 100) roles.
• Update Outbound NAT: A critical step is to change your Outbound NAT rules (Firewall > NAT > Outbound) to use the WAN’s CARP Virtual IP as the translation address. If you don’t, your traffic will leave with the wrong source IP after a failover.
• DHCP & DNS: Finally, I made sure my LAN’s DHCP server was configured to give out the LAN’s CARP Virtual IP as the gateway and DNS server, not the individual IP of the primary router.

After a bit of testing and tweaking, it worked perfectly. I could unplug my primary server, and within about 2-3 seconds, my network traffic would seamlessly failover to the backup. It felt like magic. If you’re an OPNsense user, the process is very similar, as it also uses CARP. You can find more info in the OPNsense CARP configuration guide.

Was It Worth It?

Absolutely. For a home lab enthusiast, this project hits the sweet spot of being incredibly useful, a fantastic learning experience, and genuinely cool. It requires a second server, which is a consideration, but if you already have the hardware, the reward is a rock-solid network that you can rely on, even when you’re breaking things. The days of shouting “Sorry, the internet will be back in a minute!” are finally over.