Homelab Build — Part 14 — Remote Access: Adding a VPN via pfSense (WireGuard & OpenVPN)

Why Remote Access Must Terminate at the Firewall

In Part 12 of our Homelab Build series, we documented the full topology of our lab, spanning pfSense routing, Windows Server 2025 domain controllers, enterprise certificate authorities, and monitoring agents. Up to this point, however, managing this infrastructure has required sitting physically in front of a member workstation on the internal LAN or connecting to local Wi-Fi.

The temptation for many engineers when they first need remote management is to create simple port-forwarding NAT rules on their router: mapping public port 8006 to Proxmox VE, port 3389 to a jump box, or port 22 to an administrative Linux VM. In modern infrastructure operations, this is unacceptable. Automated internet scanners like Shodan and Censys index newly opened management ports within minutes. Exposing web GUIs or remote desktop protocols to the public internet invites constant brute-force credential stuffing, unpatched zero-day exploits, and denial-of-service attempts.

Think of remote access into your homelab like visiting a high-security research facility. Port-forwarding is the equivalent of cutting private exterior doorways directly into the server room, the records vault, and the executive office, leaving each locked with a standard domestic key. If an intruder picks or kicks in any one door, they are instantly inside your most sensitive workspace. Terminating a VPN at pfSense is building a single, reinforced security gatehouse at the outer fence. Visitors must present unforgeable cryptographic credentials at the gatehouse before they are granted access, and even then, internal security checkpoints determine exactly which corridors they are permitted to walk.

By terminating your remote access tunnels directly on pfSense, you ensure that unauthenticated internet packets are dropped silently at the firewall boundary without ever reaching internal hypervisors or domain controllers.

WireGuard vs OpenVPN: A Practical Comparison

When implementing remote access on pfSense, engineers frequently debate whether to choose WireGuard or OpenVPN. Rather than treating them as mutually exclusive competitors, enterprise homelabs benefit from deploying both in a tiered hybrid architecture:

WireGuard is our primary daily driver. Its lean cryptographic handshake connects within milliseconds, handles roaming seamlessly when your phone shifts from 5G to public Wi-Fi, and does not drain mobile battery because it transmits zero packets when idle. Furthermore, WireGuard is completely silent: if an unauthorized IP sends UDP packets to your WireGuard port, pfSense returns zero response, making the port appear completely closed to port scanners.

OpenVPN serves as our indispensable fallback. Because WireGuard operates strictly over UDP, restrictive network environments—such as hotel Wi-Fi, conference halls, corporate guest networks, and international airports—frequently block all non-standard outbound UDP traffic. OpenVPN can be configured to listen on TCP port 443, effectively disguising VPN traffic as standard HTTPS web browsing and punching through the most aggressive egress firewalls.

Subnet Design and Split-Tunnel Routing

In Part 3 of our series, we established an organized IP addressing scheme across dedicated VLANs. To integrate remote access cleanly, we allocate two dedicated, non-overlapping /24 subnets for our VPN clients:

For administrative remote access, we implement split-tunneling rather than full-tunneling. In a full-tunnel setup (AllowedIPs = 0.0.0.0/0), all client traffic—including 4K video streaming, app updates, and personal browsing—is forced across the VPN, consuming your homelab’s residential uplink bandwidth.

In a split-tunnel configuration, only traffic destined for our internal enterprise aggregate (10.10.0.0/16) is routed across the encrypted tunnel. Everything else exits directly through the client’s local physical gateway. This delivers maximum browsing performance on the client device while preserving homelab internet bandwidth.

Step-by-Step: Configuring WireGuard on pfSense

WireGuard is available as an officially supported package on pfSense Community Edition (CE) and pfSense Plus. Follow these steps to configure the server tunnel:

1. Install the WireGuard Package.
Navigate to System > Package Manager > Available Packages. Search for WireGuard, click Install, and confirm. Once installed, a new menu item appears at VPN > WireGuard.

2. Enable the WireGuard Subsystem.
Navigate to VPN > WireGuard > Settings. Check the box to Enable WireGuard and click Save.

3. Create the Server Tunnel.
Go to VPN > WireGuard > Tunnels and click Add Tunnel:

Click Save Tunnel, then copy the generated Public Key to a secure notepad—you will need this public key when configuring client devices.

4. Add a Client Peer.
Switch to the Peers tab and click Add Peer:

Client Configuration and DNS Routing

On your client device (Windows, macOS, Linux, iOS, or Android), install the official WireGuard client application. Generate a keypair, provide the public key to pfSense as shown above, and build the following client configuration file:

# Administrative Laptop - WireGuard Split-Tunnel Client Configuration
[Interface]
# Client private key generated on this device
PrivateKey = aAAA...YOUR_CLIENT_PRIVATE_KEY...AAAA=

# Client static IP on the homelab WireGuard subnet
Address = 10.10.50.2/24

# Active Directory DNS server from Part 5 (DC01)
DNS = 10.10.10.10

[Peer]
# Server public key copied from pfSense tun_wg0
PublicKey = sSSS...PFSENSE_SERVER_PUBLIC_KEY...SSSS=

# External public endpoint: Dynamic DNS FQDN and pfSense listen port
Endpoint = vpn.yourdomain.com:51820

# Split-tunnel routing: route only internal homelab subnets across the VPN
AllowedIPs = 10.10.0.0/16

# Keepalive interval to maintain stateful NAT translation across mobile carriers
PersistentKeepalive = 25

Notice two critical configuration choices in this client profile:

First, AllowedIPs = 10.10.0.0/16 directs your operating system’s routing table to send only packets destined for our homelab through the WireGuard virtual adapter. All other destinations route normally out your local network connection.

Second, DNS = 10.10.10.10 points client name resolution directly to our Active Directory Domain Controller deployed in Part 4 and Part 5. This allows you to open your browser and access internal hosts like https://pve01.lab.karanth.ovh:8006 or connect via RDP to dc01.lab.karanth.ovh without needing to memorize raw IP addresses.

Configuring OpenVPN as an SSL/TLS Fallback

To guarantee connectivity when connecting from corporate networks or public hotspots that block outbound UDP traffic, we configure OpenVPN using pfSense’s built-in wizard:

1. Launch the OpenVPN Remote Access Wizard.
Navigate to VPN > OpenVPN > Wizards. Select Local User Access for user authentication and click Next.

2. Select the Certificate Authority.
Select the internal Certificate Authority established in Part 7 (or create a dedicated pfSense OpenVPN CA). Generate a new server certificate named OpenVPN_Server_Cert with standard RSA 2048-bit or ECDSA P-256 keys.

3. Configure Server Parameters.
Set the operational parameters as follows:

4. Install the Client Export Package.
Navigate to System > Package Manager > Available Packages and install openvpn-client-export. Once installed, navigate to VPN > OpenVPN > Client Export. This tool automatically bundles the CA root certificate, user certificate, private key, and connection directives into a single ready-to-import .ovpn configuration file for Windows, macOS, or mobile OpenVPN Connect apps.

Dynamic DNS and Inbound Firewall Rules

Most residential internet service providers assign dynamic public IPv4 addresses that change periodically. To ensure your VPN clients can always locate your firewall, configure Dynamic DNS (DDNS) directly within pfSense:

Navigate to Services > Dynamic DNS > Dynamic DNS Clients and click Add. Select your DNS provider (such as Cloudflare, DuckDNS, or Namecheap), enter your API token, and set your desired hostname (e.g., vpn.yourdomain.com). pfSense monitors its WAN interface and updates your public DNS record automatically whenever your ISP leases a new address.

Next, create the WAN firewall rules to permit inbound VPN handshakes:

Navigate to Firewall > Rules > WAN and create the following two rules:

Firewall Rules for Administrative Access

By default, traffic emerging from an authenticated WireGuard or OpenVPN tunnel is evaluated on the Firewall > Rules > WireGuard and OpenVPN tabs. If no rules exist, pfSense blocks all traffic.

Rather than creating a lazy “Allow All to Any” rule, implement a least-privilege administrative ruleset that enforces proper zone isolation:

Troubleshooting VPN Connections

When a remote access tunnel fails to pass traffic, diagnose the breakdown systematically using the pfSense diagnostic console:

# Check active WireGuard interfaces, public keys, and latest handshakes
wg show

# Inspect listening sockets on pfSense to verify WireGuard and OpenVPN are running
sockstat -4 -l | grep -E '51820|1194'

# Monitor the WAN interface (vtnet0) in real time for incoming WireGuard handshake packets
tcpdump -ni vtnet0 -s 0 'udp port 51820'

Final Thoughts

Building an enterprise homelab is an exercise in realism. In production corporate environments, infrastructure engineers rarely sit in the same room as the physical servers they manage; day-to-day operations take place over secure, encrypted tunnels from corporate laptops and remote jump hosts.

By terminating remote access cleanly at your pfSense virtual router, pairing high-speed WireGuard tunnels with OpenVPN SSL fallback, and enforcing strict zone-based firewall rules, you give your homelab production-grade accessibility without sacrificing perimeter security.