[OPNsense Series Part 4] WireGuard VPN and a Safer Remote Admin Flow

Once the Proxmox + OPNsense layout is stable, the next requirement becomes obvious: administrators need a trustworthy way in. WireGuard is the light tunnel between the admin laptop and OPNsense, but the tunnel alone is never enough. You have to decide who may use it, which subnet it lands on, what stays public, where the management UIs live, and how to recover when a config goes sideways.

This post focuses on designing and validating the remote-admin flow rather than chasing every UI checkbox. Before you tighten anything, confirm you have at least one out-of-band path (IPMI/iKVM on a separate network, serial console, or Proxmox local account) so a broken VPN doesn’t strand you.

What this post covers

1. Why WireGuard is a good fit and why it should terminate on OPNsense
2. How to carve out an admin-only subnet and IP plan
3. How to visualize the remote-access flow and place each management UI
4. A WireGuard-on-OPNsense configuration + verification checklist
5. Common mistakes and recovery precautions

Concepts highlighted in this post

1. Admin subnet: a private range dedicated to management traffic, separate from service workloads.
2. WireGuard peer group: a set of peers bound to one interface where keys and AllowedIPs are managed as a unit.
3. Management UI isolation: keeping Proxmox, OPNsense, backup dashboards, and IPMI endpoints behind the VPN or a dedicated VLAN.

-### Glossary quick hits

• AllowedIPs: the unordered list of CIDR ranges WireGuard associates with a peer. On the server, decrypted packets are only accepted if their source IP matches this list. On the client, only destinations inside the list are routed through the tunnel.
• Split tunneling: limiting the client’s AllowedIPs so only specific ranges go through the VPN—for example, 10.10.30.0/27—while the rest of the internet flow keeps using the local gateway.
• Out-of-band path: any console or network path that stays reachable when the VPN dies (physical console, IPMI/iKVM, a dedicated management VLAN, etc.).

Reading card

• Time: ~18 minutes
• Prereqs: OPNsense interface setup, DHCP/NAT basics, WireGuard key exchange
• Outcome: you can justify which IP ranges are reserved for admins, what to keep public, and how to verify the tunnel.

Why run WireGuard directly on OPNsense

WireGuard needs only a single UDP port, has clean mobile + desktop client coverage, and keeps configuration readable. When OPNsense itself hosts the interface, you gain three practical benefits:

1. The VPN termination point and the firewall live on the same box, so admin traffic is governed immediately.
2. Internal hosts such as Proxmox, NAS, and PBS can keep using OPNsense DHCP/DNS, while remote admins receive the same DNS through each WireGuard peer’s DNS field.
3. During incidents you can inspect the interface, disable it temporarily, or rotate keys without leaving the firewall console.

Running WireGuard inside OPNsense instead of a sidecar VM ensures that “VPN → firewall” is the one canonical path for administrator packets.

Plan the admin subnet first

Without a dedicated admin range, VPN users eventually rummage through the same network as public services. Even on a tiny homelab, split “service” and “admin” ranges so policies stay crisp.

• 10.10.20.0/24: reverse proxies, app servers, databases.
• 10.10.30.0/27: management surfaces like Proxmox, PBS, switch management IPs, iLO/IPMI.
• 10.10.50.0/28: WireGuard client pool for laptops, tablets, and jump boxes.

Why these ranges?

Subnet	Why it fits	Usable addresses
10.10.20.0/24	Leaves room for growing service workloads	254
10.10.30.0/27	Covers Proxmox, PBS, switches, IPMI with slack	30
10.10.50.0/28	Enough for several admins + temporary devices	14 (13 after reserving server IP)

Scale the mask up (/26, /25…) if you have more gear, or pick another RFC1918 block if these collide with your LAN. The priority is keeping service and management ranges distinct and named.

Range sizing quick guide

Homelab size	Expected peers	Suggested WG subnet
Solo admin / 1-2 devices	2-4	/29 (8 addresses)
Small team	5-8	/28 (16 addresses)
Growing team / lab + auditors	9-16	/27 (32 addresses)
>16 peers or multiple sites	16+	/26 or dedicated /24

Add 1 extra address for the WireGuard server interface itself, and reserve spares for temporary devices.

Checklist while carving the ranges

1. Reserve the VPN block so no DHCP scope grabs it later.
2. Tag every management surface (Proxmox UI, PBS, NAS, switches, IPMI) and pin each to the admin subnet via static mapping or reservation.
3. Create DNS names like mgmt-proxmox.lan so clients rely on stable records rather than raw IPs.

Remote-access flow and UI placement

Visualizing the path makes policy reviews easier.

Guiding principles:

1. Public-facing ports exist only on the service subnet where the reverse proxy lives.
2. Management UIs only exist on the admin subnet and are reachable exclusively from WireGuard peers.
3. The WAN side exposes a single UDP port (51820 by default); no management port touches the internet directly.
4. Use different AllowedIPs per peer: most peers only see 10.10.30.0/27, while a limited few can also reach 10.10.20.0/24 for troubleshooting.

Peer permission matrix

Peer	AllowedIPs example	What they can touch
Lead admin	10.10.50.2/32,10.10.30.0/27,10.10.20.0/24	Management + service ranges
Backup operator	10.10.50.3/32,10.10.30.5/32	PBS only
External auditor	10.10.50.4/32,10.10.30.0/27	Admin subnet only

The narrower the AllowedIPs, the smaller the blast radius if that key leaks.

AllowedIPs only governs routing. Pair it with app-level controls (e.g., Proxmox RBAC, PBS read-only roles) and additional firewall rules if you want strict per-peer authorization.

Also add explicit firewall rules on both sides of the WireGuard interface: allow “WireGuard → admin subnet” and confirm the stateful rules (or explicit entries) let “admin subnet → WireGuard” replies through. Without both, ping, SSH, and HTTPS feel flaky.

AllowedIPs trap: client AllowedIPs controls routing. If you forget to add 10.10.30.0/27, your laptop will exit the tunnel and talk to Proxmox over the open internet. Conversely, adding 0.0.0.0/0 tunnels all traffic—including corporate VPNs—and may violate policy.

How does a packet really move?

Keep this flow in mind when you verify routes or check wg show.

WireGuard-on-OPNsense configuration checklist

Focus on outcomes rather than every click.

1. Plugin
   • Install os-wireguard. Success = VPN > WireGuard menu appears.
   • If not, use System > Firmware > Plugins and reboot.
2. Local instance
   • Generate interface keys, pin the listen port to 51820.
   • Assign Tunnel Address = 10.10.50.1/28. Success = wg show lists interface: wg0.
3. Peers
   • Generate keys per admin, add them as peers.
   • Use AllowedIPs = 10.10.50.x/32,10.10.30.0/27 style entries.
   • For clients managed via wg-quick configs, include DNS = 10.10.30.1 (if you want to override the resolver), MTU = 1420 as a starting point, and PersistentKeepalive = 25 to keep NAT sessions alive. Adjust MTU by testing ping -M do -s 1400 10.10.30.1 and lowering if you see fragmentation errors.
   • Success = wg show lists the peer and, when active, latest handshake shows a recent timestamp.
4. Firewall rules
   • WAN rule: allow UDP 51820 (log it for audits).
   • Assign the WireGuard interface and permit only the admin subnet on that tab; add matching egress if you disable states.
5. Routing & DNS
   • Confirm the admin subnet does not overlap with existing routes (System > Routes > Status). Add static routes if the subnet lives on another interface.
   • Publish mgmt-* hostnames in internal DNS so WireGuard clients resolve them via the pushed DNS.
6. Logging
   • Watch VPN > WireGuard > Log for join/leave events.
   • Optionally forward to syslog/NetFlow for central auditing.
7. Key rotation
   • Rotate keys during maintenance windows: generate new peer keys, update clients, then rotate the interface key last. Confirm wg show reflects the new public keys and retire old configs immediately.

Sample peer configuration (wg-quick)

[Interface]
PrivateKey = <client-private-key>
Address = 10.10.50.2/28
DNS = 10.10.30.1
MTU = 1420

[Peer]
PublicKey = <opnsense-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.30.0/27,10.10.20.0/24
PersistentKeepalive = 25

Five-minute verification checklist

1. Interface check: wg show should reveal interface: wg0 with listening port: 51820.
2. Client bring-up: wg-quick up homelab (or the mobile app). Confirm both the client tunnel IP (10.10.50.x/28) and server tunnel IP (10.10.50.1) respond to pings.
3. Ping ladder: ping 10.10.50.1 (WireGuard), ping 10.10.30.1 (LAN gateway), ping 10.10.30.5 (Proxmox).
4. DNS test: nslookup mgmt-proxmox.lan 10.10.50.1 should return the admin IP.
5. Failure triage: compare OPNsense logs and client logs (journalctl -u wg-quick@homelab) to distinguish key mismatch vs. firewall block.

Backup and key-management guardrails

• Inventory keys outside of the OPNsense backup so you can verify which peers should exist after a restore.
• Encrypt backups that contain WireGuard private keys or export sanitized configs with keys removed.
• Staged restores: after restoring OPNsense, compare wg show public keys with your inventory before allowing clients to reconnect.
• Revocation plan: document how to remove a compromised peer (delete from OPNsense, regenerate peer key, confirm firewall logs).

Decide what stays public and what hides behind VPN

WireGuard does not mean every service must vanish, but it lets you be intentional.

• Keep public: HTTPS reverse proxy (443), HTTP-01 validation (80), tightly scoped APIs. Layer in GeoIP or rate limiting anyway.
• Force behind VPN: Proxmox UI, OPNsense UI, backup servers, monitoring, internal Git, automation control planes, IPMI/iLO.
• Conditional: SSH. If you must expose it, restrict to one jump VM; everything else stays reachable over the tunnel.

SSH caution: Even a hardened jump VM is a tempting target. Use key-based auth, rate limiting, and treat the jump host as disposable.

Common mistakes and recovery tips

1. AllowedIPs = 0.0.0.0/0 by accident
   • Symptom: corporate networks suddenly lose internet whenever the VPN is up.
   • Cause: client-side AllowedIPs hijacks all routes (server-side alone rarely hurts).
   • Fix: scope AllowedIPs to 10.10.50.x/32,10.10.30.0/27 and keep split tunneling.
2. Reusing the admin subnet as a generic DHCP pool
   • Symptom: random devices get admin-range IPs or collide with WireGuard static IPs.
   • Fix: keep DHCP scopes in the service subnet, limit the admin subnet to static mappings/VLANs, and prevent DNS name overlap.
3. OPNsense UI still listening on WAN
   • Symptom: you can reach the UI from LTE.
   • Fix: System > Administration > Listen Interfaces → select only LAN, WireGuard, or localhost, then retest from outside.
4. Restoring backups without reconciling keys
   • Symptom: every peer fails after a config restore or old keys linger.
   • Fix: compare wg show public keys against your inventory, rotate keys after a restore, and only re-enable the interface once peers are confirmed.
5. No out-of-band console
   • Symptom: misconfiguring WireGuard bricks remote access entirely.
   • Fix: keep Proxmox console, IPMI, or iKVM reachable and document the credentials.
6. WireGuard is the only management door
   • Symptom: a broken tunnel blocks every UI, including Proxmox snapshots.
   • Fix: maintain at least one alternate management path (local account, physical switch path, or secondary VPN) to break the dependency loop, and keep IPMI networks isolated from the admin subnet.

Logging reality: WireGuard logs are intentionally sparse (handshakes, errors). For traffic-level auditing, enable logging on the OPNsense firewall rules or export NetFlow/IPFIX from the LAN interface instead.

Wrap-up

WireGuard on OPNsense is more than a “VPN plugin.” By carving an admin subnet, placing sensitive UIs there, and keeping the public footprint tiny, your homelab or small office stack becomes much easier to defend. Remember the anchors:

1. Design the admin subnet, DNS, and routing before onboarding users.
2. Terminate WireGuard on OPNsense so every admin packet hits the firewall ruleset.
3. Prepare recovery paths—console, snapshots, key rotation—and review AllowedIPs and UI exposure regularly.

Next time we will connect this design to deployment workflows: OPNsense backups, GitOps, and automated validation.