How to Configure VPN on pfSense

pfSense is a free firewall and routing platform that people install on a small PC or a dedicated appliance to run a home or small-office network. Because it sits between your devices and the internet, it can also be the place where a VPN lives: instead of installing an app on every phone, TV and laptop, the firewall opens one encrypted tunnel and sends chosen traffic through it. That is the idea behind running a VPN on pfSense.

This guide is about building the VPN client side of that setup, the part that connects out to a VPN service. It explains what to collect before you start, how interfaces, outbound NAT, gateways and rules fit together, how to send only some devices through the tunnel, how to handle DNS, and how to test the result. It does not hand you a copy-paste configuration, because menu names change between versions and your VPN service decides which connection method you can use. If you have not decided between a firewall and apps yet, read VPN router vs VPN app first.

What running a VPN on pfSense really means

A pfSense box can take two very different VPN roles, and mixing them up causes most beginner confusion.

• Server role. You host the VPN on your own firewall so that you can reach your home network from outside. Your phone dials in to pfSense.
• Client role. Your pfSense dials out to a VPN service. Devices behind it can then use that tunnel for their internet traffic.

This article is about the client role. In this role, pfSense creates a virtual network interface for the tunnel, and a gateway that represents the far end of it. Your normal internet connection (the WAN) keeps working next to it. Each firewall rule on the LAN decides which gateway a device's traffic uses: the default WAN gateway, or the VPN gateway.

That last point is the whole design. pfSense does not "turn the VPN on" for the network in one switch. You decide, rule by rule, who goes through the tunnel. This gives you precise control that a phone app never offers, and it is also the reason a first-time setup takes an afternoon.

What to prepare before you open the web interface

Spend ten minutes gathering things; it prevents half-configured states that are hard to debug.

1. Hardware that can cope. Encryption uses CPU. A small box with a modern processor that supports hardware AES will usually be comfortable on a home line; very old or low-power hardware may become the bottleneck. Check your CPU load while a speed test runs.
2. Current software. Update pfSense to a stable release before you begin. Guides written for old versions often show menus that have moved.
3. Connection details from your VPN service. You need to know which methods your service allows on a router. For an XPASS pass, the My Pass page lists the supported connection methods and setup instructions, so read that rather than guessing. If a method needs a certificate, a key or a configuration file, download it and keep it somewhere safe.
4. A clear picture of your LAN. Note your LAN subnet, which devices use static addresses and what range DHCP hands out. Home networks normally use private ranges defined in RFC 1918, such as 192.168.x.x. If the VPN service's network happens to use the same range as your LAN, routing breaks in confusing ways, so check for an overlap now.
5. A way back. Write down your current firewall settings or take a configuration backup (Diagnostics, then Backup and Restore, in most versions). If something locks you out, you can restore.
6. A maintenance window. Do the work when nobody is in a video call. Adding an interface and rules can drop connections briefly.

If you want one consistent tunnel for every device in the house, a firewall is a good home for it. If you only need protection on a couple of laptops and phones, apps are simpler; the help guide for setting up a VPN on a router covers the lighter route.

The five building blocks, in order

Whatever method your service uses, the pfSense configuration follows the same order. Learn the order and the menus become easy to find.

1. Import the credentials

Under the certificate manager you add the certificate authority and client certificate if your method uses them. For a key-based method, you paste the keys into the tunnel's settings. Use the exact values from your provider and avoid editing them. A single wrong character in a key is a classic cause of "tunnel never comes up".

2. Create the tunnel

Under the VPN menu you add a client entry with the server address, port, credentials and encryption settings from your provider. Two practical notes:

• Give the entry a descriptive name, such as "VPN-out". You will be choosing among interfaces and gateways later, and vague names cause mistakes.
• Do not tick options that pull routes automatically unless you want the whole firewall to route through the tunnel. For selective routing, you want the tunnel to come up without taking over the default route.

If you are unsure which family of tunnel to use, WireGuard vs OpenVPN explains the trade-offs in plain language. Keep the settings your provider recommends unless support tells you otherwise.

3. Assign the interface

After the tunnel starts, it exists but the firewall has not yet given it a name in the interface list. Under Interfaces, then Assignments, add the new tunnel as an interface, enable it and give it a clear description. Leave the IP configuration at "None" unless your provider explicitly gives you a tunnel address. This step is what makes the tunnel usable in rules and NAT.

4. Check the gateway

Under System, then Routing, a gateway for the new interface should appear. Make sure it is marked online and that its monitor address is something reachable through the tunnel. If the monitor address is unreachable, pfSense will mark the gateway as down even though traffic flows, and your rules will refuse to use it. Do not set this gateway as the default gateway unless you want every device, including the firewall's own updates, to use it.

5. Add outbound NAT

Your LAN uses private addresses that the VPN network cannot route back to. So traffic leaving through the tunnel must be translated to the tunnel's address. Switch outbound NAT to hybrid mode (or manual, if you prefer to write every rule), and add a rule that translates your LAN subnet when it leaves via the new interface. Without this rule, the tunnel shows as connected but devices get no internet. This is the single most common mistake in the whole project.

Sending only the devices you choose

Now you decide who uses the tunnel. The tool for this is policy-based routing: a firewall rule on the LAN interface that, in its advanced options, names the VPN gateway.

A tidy way to build it:

1. Give the chosen devices static leases. In the DHCP server settings, reserve an address for each device you want in the tunnel, for example a media box, a work laptop and a tablet.
2. Create an alias. Under Firewall, then Aliases, make a host alias containing those addresses, named something like "VPN_CLIENTS".
3. Add the LAN rule. Create a pass rule with the source set to that alias. In the advanced section, set the gateway to the VPN gateway.
4. Mind the rule order. Rules are evaluated top to bottom. Put local-network exceptions above the VPN rule so printers, file shares and the router's own web page are still reachable without going through the tunnel. A short pass rule for the LAN subnet as destination, placed first, does this.
5. Leave everything else alone. Devices outside the alias match the normal "allow LAN to any" rule and use the WAN.

This approach is the firewall's equivalent of split tunneling, but done by device instead of by app. It is a good fit when a family wants the living-room TV behind the VPN while the home-office machine stays on the plain connection.

Goal	How to do it on pfSense
Whole house through the VPN	One LAN rule for the entire subnet with the VPN gateway set
Only chosen devices	Alias of static addresses, rule with the VPN gateway
Only one VLAN or Wi-Fi network	Rule on that VLAN interface with the VPN gateway
Chosen destinations only	Alias of destination addresses, rule with the VPN gateway
Nothing, but keep the tunnel ready	Leave the interface up and add no rules

A separate VLAN or guest Wi-Fi for "VPN devices" is often the neatest design, because one rule covers anything that joins that network and you do not need to track addresses.

DNS: the part people forget

If devices send DNS questions to your ISP while their traffic goes through the tunnel, the websites they look up are exposed outside the tunnel. This is the idea behind a DNS leak, and firewalls can leak just as easily as laptops.

Practical choices:

• Use the DNS servers your provider gives you for the VPN-routed devices, and make the rule for DNS traffic use the same VPN gateway. If the DNS resolver on pfSense forwards queries, set its outgoing interface to the tunnel for those clients, or hand out the provider's DNS addresses by DHCP only to the VPN group.
• Block stray DNS. Add a rule that blocks outbound port 53 (and 853 for encrypted DNS) from VPN clients to anywhere except the chosen resolver, so devices cannot fall back to their own settings.
• Watch for devices with built-in DNS. Some TVs and browsers use their own encrypted DNS and ignore what DHCP tells them. Test each device, not just the firewall.

After the setup, use a leak test from a VPN client device. If the resolver shown belongs to your home ISP, your DNS rule needs work.

Building a kill switch with firewall rules

When a phone VPN drops, the app can block traffic. On pfSense you build the same protection yourself. The mechanism is the gateway-down behaviour of the policy rule.

• By default, pfSense can skip a rule whose gateway is down and then let traffic fall through to the next rule, which is the WAN. That silently moves your devices outside the tunnel.
• Enable the system option that keeps policy-routed traffic from leaving through the WAN when its gateway is unavailable, or add an explicit block rule after the VPN rule that catches the VPN group.
• Test it. Disable the tunnel on purpose and check that the VPN group has no internet at all. Then re-enable it. A kill switch you have never tested is a hope, not a protection. The background is in what a VPN kill switch is.

For devices that must stay online even when the tunnel fails (a smart doorbell, say), keep them out of the VPN alias entirely.

MTU, speed and other tuning

Tunnels add a few bytes of header to every packet, so full-size packets may no longer fit. When the maximum transmission unit is wrong, you get strange symptoms: small pages load, large ones stall, uploads freeze. Path MTU Discovery is meant to handle this, but filtered ICMP can break it.

Steps to try, one at a time:

1. Lower the tunnel's MTU by about 40 to 80 bytes from the interface default, or enable MSS clamping on the VPN interface.
2. Re-test a large download, not only a web page.
3. Change only one setting between tests so you know what helped.

If throughput is low, remember that encryption is CPU work and that a single tunnel is often limited by one processor core. Compare speed tests with the tunnel off and on, and see why internet speed changes with a VPN before you blame the firewall.

Testing the finished setup

Run the same checklist every time you change something.

1. Gateway status shows online for the VPN gateway.
2. From a VPN-group device, a public IP check shows the VPN's address, not your home connection's.
3. From a normal device, it still shows your home address.
4. DNS test shows the intended resolver.
5. Kill-switch test: disable the tunnel, confirm the VPN group loses internet, re-enable it.
6. Local access test: printers and file shares still work from VPN-group devices.
7. Reboot test: restart pfSense and confirm the tunnel comes back by itself.

Write the results down. When something breaks months later, a list of what normal looked like saves hours.

Common mistakes and troubleshooting

Symptom	Likely cause	What to check
Tunnel connected, no internet for clients	Missing outbound NAT	NAT rule for the LAN subnet on the VPN interface
Gateway shows offline though tunnel is up	Monitor address unreachable	Change or disable the monitor IP
Everything including the firewall uses the VPN	Default gateway changed	Set the WAN as the default again
Large pages stall	MTU or MSS too high	Lower MTU, enable MSS clamping
Works until reboot	Interface not assigned or tunnel not set to start	Interface assignment and service status
Slow speeds	CPU limit or distant location	CPU load during test, try another location
Local printer unreachable	Rule order	Move the LAN-destination pass rule above the VPN rule
Streaming or banking app complains	Service dislikes VPN connections	Move that device out of the alias

Never expose the firewall's administration page to the internet while you experiment, and keep the router's login protected with a strong password and two-factor authentication where available. A VPN protects traffic in transit; it does not fix a weakly protected firewall.

If a particular website refuses to work through the tunnel, that is the website's decision, not a fault in pfSense. The help article on websites not working with a VPN explains what you can try, such as moving that device out of the VPN group.

When pfSense is the wrong tool

A firewall build is not for everyone. If you travel, a router at home does nothing for your phone at an airport. If nobody in the house is comfortable with firewall rules, a misconfiguration can leave devices unprotected without anyone noticing. If your hardware is weak, the VPN may turn a fast connection into a slow one. In those cases, use the apps on the devices that matter, and keep the firewall for what it does best.

With XPASS, you can use the free VPNclient app on iPhone, Android, Windows and macOS with the login details on your My Pass page, and check the supported connection methods there before you decide whether a router build suits your pass. The download page lists the official apps.

Summary

Running a VPN on pfSense means creating a client tunnel, assigning it as an interface, checking its gateway, adding outbound NAT and then deciding with firewall rules which devices use it. Handle DNS deliberately, build and test a kill switch, tune MTU when large pages stall, and test from both a VPN device and a normal one. Keep your VPN service's connection method in mind, because that decides what you can configure at all.

If you would rather start with a simple pass and the app route, the pricing page shows the options at your own pace.