Before deploymentSecurity

VPN Readiness

18 items ·12 critical ·4 warn ·2 info

A VPN is a controlled extension of the trusted network, and on OPNsense that means treating it as part of the rule set, not a magic back door. This checklist covers the IPsec and WireGuard paths: ciphers, identifiers, key handling, routing, firewall rules, and the operational habit of testing the tunnel from each peer type before declaring it ready.

When to use

Use this checklist before any IPsec or WireGuard VPN goes live, when proposals are being upgraded (e.g. moving from AES-CBC to AES-GCM, or from IKEv1 to IKEv2), and when a new peer is added. Re-run it after any OPNsense upgrade, because plugin versions change the available cipher suites.

How to use

Walk the list while reviewing the relevant VPN section (IPsec tunnel settings or WireGuard local/peer) and the firewall rules for the VPN interface. Mark each item, capture the negotiated cipher suite as proof, and file the change with the operator’s change system.

Critical12 items

A documented inventory of remote endpoints (sites, mobile users, partners) exists; each has a defined cipher suite.
IPsec: IKEv2 is the default; legacy IKEv1 is disabled unless required by a known peer.
```
VPN > IPsec > Tunnel Settings.
```
IPsec: Phase 1 uses AES-256-GCM or ChaCha20-Poly1305 with a modern DH group (14, 15, 16, or 20).
IPsec: Phase 2 matches Phase 1 cipher; PFS group is set (not "none") and lifetime is bounded.
IPsec: Local and remote identifiers are explicit (FQDN, user-FQDN, or IP), not the default "any".
WireGuard: listen port, private key, and public key are generated and stored in a secret manager.
```
VPN > WireGuard > Local; confirm key is not stored only in the running config.
```
WireGuard: peer AllowedIPs cover both the tunnel address and the routed subnets for site-to-site peers.
VPN protected subnets do not overlap the LAN or each other; routing is documented.
```
Firewall > Aliases; confirm the VPN tunnel subnets are present.
```
Firewall > Rules > IPsec (or WireGuard group) has rules that permit only the documented traffic between documented networks.
Pre-shared keys (IPsec) are strong, rotated, and not stored only in the running configuration.
MFA is enforced for human remote users (WireGuard + OPNsense captive portal, IPsec + per-user cert / token).
A pre-deploy VPN test from each peer type has been executed end to end and recorded.

Warning4 items

Certificates (where used) are issued from an internal CA, have a defined expiry, and renewals are tracked.
DNS for VPN clients is configured: internal DNS for site-to-site, internal DNS or split-DNS for remote users.
MTU for the VPN tunnel is tuned (typically 1400 for IPsec, 1420 for WireGuard) to avoid fragmentation.
An outbound NAT rule prevents traffic from leaking over the WAN when split-tunnelling (where required).

Info2 items

Dead-peer detection is enabled with sensible timeouts; idle peers are dropped after the documented interval.
The VPN log destination (strongSwan / WireGuard) is captured and shipped to remote syslog.