Introduction

If you've spent any time in homelab forums, you've seen the advice: stop trusting your ISP's all-in-one modem-router and put something real in front of your network. Two names come up constantly — pfSense and OPNsense. We've already covered OPNsense on this site. This time it's pfSense's turn, and the two are different enough in install flow and ecosystem that it's worth its own walkthrough rather than a footnote.

pfSense is one of the oldest and most widely deployed open-source firewall platforms out there, and a huge number of the people running it aren't doing so on dedicated appliance hardware — they're running it as a VM on a Proxmox box that's already doing other work. That's a completely reasonable setup, and it's what this guide walks through: building a proper pfSense CE virtual machine on Proxmox VE, installing it, and getting it routing real traffic without breaking your existing network in the process.

A word of caution before you start: this is one of those projects where a wrong turn can knock every device on your LAN offline, including the one you're using to read this. Keep a wired path to your Proxmox host's management interface that doesn't depend on the pfSense VM working, at least until you've confirmed everything's stable.

What You Will Learn

  • What pfSense actually is and why people run it as a VM instead of on dedicated hardware
  • How to lay out WAN and LAN bridges in Proxmox before you touch the installer
  • How to build a pfSense VM with the right CPU, disk, and network settings
  • Step-by-step installation, including the one thing that changed in pfSense CE 2.8 that trips up a lot of Proxmox users
  • How to run the initial setup wizard and get a LAN client online through the VM
  • Common errors, how to recover console access if you lock yourself out, and a few settings worth changing before you walk away

What Is This Feature?

pfSense is a free, open-source firewall and router operating system built on FreeBSD, maintained by Netgate. On real hardware it replaces your router outright — it terminates your WAN connection, does NAT, runs the firewall rules, hands out DHCP leases, and optionally handles VPNs, traffic shaping, and intrusion detection through add-on packages.

There are two editions. pfSense CE (Community Edition) is the free, open-source version this guide covers. pfSense Plus is Netgate's commercial variant with a few extra features aimed at their own hardware appliances and larger deployments. For a homelab or small office, CE covers pretty much everything you'd want.

Running it as a VM means Proxmox's virtual network bridges stand in for physical network ports. One bridge carries your WAN (internet) connection into the VM, another carries your internal LAN traffic out to your switch and the rest of your devices. The VM sits in the middle and does the routing and filtering that a physical box would otherwise do.

Why Would You Use It?

Most ISP-supplied routers are locked down: no real firewall logging, no VLANs, no way to segment an IoT device from the server holding your backups. pfSense gives you actual control — proper firewall rules, VLAN support, site-to-site and remote-access VPN, and a package system if you want to add IDS/IPS with Suricata later.

Running it virtualized instead of on a dedicated box means you're not buying a second piece of hardware just to route packets. If your Proxmox server already has spare CPU cycles and a couple of free NIC ports (or VLAN-capable switch ports), you can turn it into your router with zero additional hardware cost. The tradeoff is that your network now depends on that one server being up — if the Proxmox host reboots for updates, your internet goes down with it. Plenty of homelab users accept that tradeoff happily; it's worth knowing about before you commit.

Prerequisites

Before you start, make sure you have:

  • A Proxmox VE host, ideally 9.x, with at least two physical NICs — or one NIC plus VLAN-capable switch ports if you're trunking WAN and LAN over a single cable
  • The pfSense CE ISO downloaded from pfsense.org (this guide uses the 2.8.0 release, AMD64/amd64 image)
  • At least 1 GB of RAM and 8 GB of disk space free for the VM — 2 GB RAM and 20 GB disk is a more comfortable real-world minimum if you plan to add packages later
  • A second, isolated Proxmox bridge for LAN traffic — do not put your firewall's LAN side on the same bridge as your Proxmox management interface
  • Physical or console access to Proxmox in case something goes wrong with networking mid-setup

If you only have one physical NIC on the Proxmox host, you can still do this using VLANs on a managed switch, but that's a more advanced setup and outside the scope of this guide.

Step-by-Step Tutorial

1. Upload the ISO

In the Proxmox web UI, select your storage (usually local) in the left sidebar, open ISO Images, and click Upload. Point it at the pfSense CE ISO you downloaded. On a decent connection this takes a minute or two — the file is a little over 700 MB.

2. Set up your bridges

Go to your node, then System > Network. You need at least two bridges:

  • vmbr0 — your existing bridge, tied to the physical NIC that has your internet connection. This becomes pfSense's WAN.
  • vmbr1 — a new bridge, either tied to a second physical NIC or left with no physical port attached at all if you're just testing. This becomes pfSense's LAN.

Click Create > Linux Bridge, leave the bridge ports field pointing at your second NIC (or blank for an internal-only test bridge), and apply the configuration. Don't assign an IP address to vmbr1 on the Proxmox host itself — pfSense will own that address once it's up.

3. Create the VM

Click Create VM in the top right. Work through the wizard with these settings:

  • General: Name it something like pfsense, pick a VM ID
  • OS: Use the CD/DVD ISO image option and select the pfSense ISO you uploaded. Guest OS type: Linux works fine here since there's no dedicated FreeBSD entry in older Proxmox versions — it only affects a couple of default UI hints, not functionality
  • System: Machine type q35, BIOS SeaBIOS (simpler and well-tested for this combination), leave Qemu Agent unchecked — pfSense doesn't ship it by default
  • Disks: 20 GB is a comfortable size, bus type VirtIO SCSI single
  • CPU: 2 cores, type host for the best performance
  • Memory: 2048 MB, and turn off the ballooning device — a firewall VM should have its RAM allocation fixed, not shrinking under host memory pressure
  • Network: attach the first NIC to vmbr0 with model VirtIO (paravirtualized). After the VM is created, add a second network device from Hardware > Add > Network Device attached to vmbr1, same VirtIO model

Older guides for pfSense on Proxmox recommend using an Intel E1000 NIC for the install and swapping to VirtIO afterward. That advice dates back to when FreeBSD's vtnet driver was flaky. pfSense CE 2.8 runs on a current FreeBSD 14 base with a much more mature VirtIO network driver, so going straight to VirtIO on both interfaces works fine in practice.

4. Boot the installer

Start the VM and open its console. You'll land on the pfSense boot menu — let it time out or press Enter. Accept the copyright notice, then choose Install.

Here's the part that catches people off guard: starting with pfSense CE 2.8.0, the installer fetches the base system over the network instead of copying it entirely from the ISO. That means your WAN-side NIC (the one on vmbr0) needs working internet access during installation, not just after. If vmbr0 isn't actually uplinked yet, the installer will sit there failing to reach Netgate's servers. Get your WAN bridge connected to a real upstream connection before you boot the ISO.

Pick ZFS as the partition layout when asked — it's the default for a reason, since it gives you boot environments you can roll back to if a future update goes badly. Choose your target disk, confirm, and let the install run. It typically takes three to five minutes on a VM disk.

When it finishes, choose to reboot. Before the VM restarts, go to Hardware in the Proxmox UI and either remove the ISO from the CD/DVD drive or change the boot order so the VM doesn't boot back into the installer.

5. Assign interfaces

On first boot you'll hit a console prompt asking "Should VLANs be set up now?" — answer n unless you already know you need VLAN tagging inside the VM itself. Next it asks you to assign WAN and LAN interfaces. You'll see device names like vtnet0 and vtnet1 — these correspond to the two network devices in the order you added them in Proxmox. Assign the first as WAN and the second as LAN, confirm, and let it apply.

pfSense will bring up LAN with the default address 192.168.1.1/24 and a DHCP server already running on it.

6. Connect and run the setup wizard

Plug a laptop into a switch port on the same physical NIC or VLAN as vmbr1, or spin up a throwaway VM attached to vmbr1 for testing. It should pick up a DHCP lease in the 192.168.1.x range. Open a browser to https://192.168.1.1, click through the self-signed certificate warning, and log in with the default credentials — username admin, password pfsense.

The setup wizard launches automatically. It'll walk you through hostname and domain, DNS servers, time zone, your WAN connection type (DHCP is the common case for a home internet connection), and finally forces you to set a real admin password. Don't skip that last part — leaving the default password on an internet-facing firewall is exactly the kind of mistake that ends up on a "how I got hacked" forum post.

Commands Explained

Most of pfSense's day-to-day configuration happens through the web GUI rather than a shell, but a few console and shell commands are worth knowing, especially for recovery:

Command / Menu OptionWhat it does
Console option 1 (Assign Interfaces)Re-maps which network device is WAN vs. LAN — useful if you added a NIC in the wrong order
Console option 2 (Set interface IP address)Manually resets an interface's IP from the console if you've locked yourself out of the GUI
Console option 4 (Reset to factory defaults)Wipes configuration back to a clean install without reinstalling the OS
pfSsh.php playback enableallowallwanRun from console option 8 (shell) — temporarily adds an allow-all rule on WAN, handy for pulling files or debugging when you're locked out from outside
ifconfigFreeBSD's equivalent of ip addr — lists interfaces and their assigned addresses, useful for confirming vtnet0/vtnet1 got the IPs you expect
pfctl -srPrints the currently active firewall ruleset as the packet filter actually sees it, which is the fastest way to confirm a rule you added is really in effect

Common Errors

Installer hangs at "Fetching distribution" — this is almost always the online-install issue from step 4. Your WAN NIC has no internet path yet. Check that vmbr0 is actually bridged to a NIC with a working upstream connection.

No internet on any LAN client after setup — double check NAT outbound rules under Firewall > NAT > Outbound. pfSense defaults to automatic outbound NAT, which usually just works, but if someone switched it to manual mode at some point and the rule for your WAN subnet is missing, LAN clients will get local IPs fine but never reach the internet.

GUI unreachable after a reboot, no error, just times out — check the VM console first. If pfSense boots fine and shows LAN with an IP, the problem is almost always on the Proxmox side: the client machine is on the wrong bridge, or a VLAN tag mismatch between the client's switch port and vmbr1.

Intermittent connection drops or corrupted downloads through the firewall — this is the same hardware checksum-offload issue that shows up with OPNsense on VirtIO NICs. The vtnet driver's checksum offloading occasionally disagrees with Proxmox's virtual NIC implementation, and some packets get silently corrupted. Go to System > Advanced > Networking and check the boxes to disable hardware checksum offloading, then reboot the VM.

Troubleshooting

If you genuinely can't reach the GUI and don't know why, start at the Proxmox console for the VM rather than guessing from the network side — it's a serial-free path into the box that doesn't depend on any of the networking you're trying to debug.

From there, console option 1 tells you immediately whether WAN and LAN are wired to the interfaces you think they are. It's an easy thing to get backwards if you added the two NIC devices in Proxmox in a different order than you assigned them during install.

If interfaces look right but you still can't connect, drop into the shell (option 8) and run ifconfig. Confirm vtnet1 (or whichever device is LAN) actually shows the 192.168.1.1 address. If it doesn't, something went wrong during interface assignment and it's faster to just redo option 1 than to chase it further.

Locked out of the GUI because of a firewall rule you added yourself? That's what pfSsh.php playback enableallowallwan is for — it's a sanctioned, documented pfSense recovery command, not a hack. Run it, fix your rule through the GUI, and remember to remove the allow-all rule afterward since it defeats the purpose of having a firewall.

And if none of that works, console option 4 resets to factory defaults. You'll redo the setup wizard, but you won't have to reinstall the OS from ISO.

Best Practices

Take a Proxmox snapshot of the pfSense VM before any package install or major rule change. Firewall changes are exactly the kind of thing that look fine until you're locked out, and a snapshot turns a bad afternoon into a thirty-second rollback.

Keep LAN traffic off your Proxmox management bridge. If vmbr1 shares a physical NIC with anything else sensitive, use a VLAN-aware bridge and tag it rather than mixing untagged traffic across trust boundaries.

Set the VM to auto-start with the host, and give it startup priority ahead of anything that depends on network access — there's no point booting a NAS VM before the firewall that routes its traffic is even up.

Back up your configuration regularly under Diagnostics > Backup & Restore. It's a single XML file, and having a recent copy means a hardware failure costs you a VM rebuild, not a from-scratch reconfiguration of every firewall rule and VPN tunnel you've set up.

Honestly, if you're only running pfSense to get basic NAT and a handful of firewall rules, don't feel obligated to install every optional package that shows up in the package manager. Each one is more surface area to keep patched. Add Suricata or pfBlockerNG only if you actually plan to tune and monitor them.

Frequently Asked Questions

Is pfSense CE really free?

Yes, fully. It's open source under Apache 2.0 licensing for the core system. Netgate makes money from support contracts, hardware appliances, and the Plus edition, not from CE licensing.

Should I use pfSense or OPNsense?

Both do the job well and share a common ancestor. pfSense has a larger user base and more third-party guides; OPNsense ships a more modern UI and slightly faster release cadence for security patches. If you've read our OPNsense guide and already have opinions, trust them — this isn't a case where one is objectively better.

Do I need real hardware, or is a VM good enough?

For a home network, a VM is genuinely fine. The performance hit versus bare metal is small unless you're pushing multi-gigabit WAN speeds with heavy IDS inspection turned on.

Can I passthrough a physical NIC instead of using a bridge?

Yes, and some people prefer it for WAN specifically, since it removes Proxmox's virtual switch from the path entirely. It requires IOMMU passthrough setup, which is a separate topic from this guide.

What happens to my network if the Proxmox host reboots?

Everything routed through the pfSense VM goes down until the host and VM come back up. If that's unacceptable for your household, this setup isn't the right fit — a dedicated appliance would serve you better.

Conclusion

A pfSense VM on Proxmox gives you a real, configurable firewall without buying separate hardware for it — the tradeoff is that your router now shares a fate with your hypervisor. For most homelabs that's a fair trade. The install itself is short once you know about the online-install networking requirement in 2.8, and the console menu gives you enough of a safety net that a bad rule or a wrong interface assignment isn't the end of the world. Take the snapshot before you start tweaking rules, and you'll be fine.