VPN authentication and authorisation — who is on the other end, and what they can do · OPNsense

Encryption protects the bytes on the wire. It does not, by itself, tell either endpoint who is on the other end. A VPN that encrypts traffic to an unknown peer is a VPN that may be talking to the right party, to an attacker who captured the configuration, or to nothing useful at all. Authentication answers the question who. Authorisation answers the question what they are allowed to do. Both are required; neither alone is enough.

This lesson covers how VPNs authenticate the peer (pre-shared keys, certificates, public keys), how the authenticated identity maps to firewall rules and routing decisions, and the production failure modes of misaligned authentication and authorisation.

Authentication: who is the peer?

VPN authentication establishes that the peer is who it claims to be. Three mechanisms dominate:

Pre-shared keys (PSK). Both endpoints are configured with the same secret string. During the handshake, each side proves knowledge of the secret without sending it across the network. The mechanism is simple and requires no PKI.

PSK has two production problems. First, the secret is shared: every endpoint that needs to authenticate must hold a copy, and the more copies exist, the more places the secret can leak. Second, PSK does not identify an endpoint by name — it only proves the peer knows the string. A leaked PSK lets an attacker impersonate any endpoint.

For small deployments with one or two peers, PSK is acceptable. For larger deployments, or for any deployment where the operator wants to know which peer is which (for logging, for per-peer rules, for incident response), PSK is the wrong tool.

Certificates (X.509). Each endpoint holds a private key and a certificate signed by a certificate authority (CA) that both sides trust. During the handshake, the peer proves possession of the private key corresponding to the certificate. The certificate carries a name (the Subject or a Subject Alternative Name) that uniquely identifies the endpoint.

Certificates scale: every endpoint has its own key pair, the CA signs each certificate, the operator can revoke individual certificates without rotating every secret. The cost is the PKI: a CA, a way to issue certificates, a way to revoke them, and a way to distribute the CA chain to every endpoint.

Public keys (WireGuard). WireGuard uses a model closer to SSH than to IPsec: each peer has a key pair (a Curve25519 key), the public key is shared out-of-band, and the private key never leaves the endpoint. There is no CA in the WireGuard model — the operator distributes public keys directly to the peers that need them.

The WireGuard model scales differently: every peer has exactly one identity (its public key), the firewall holds a table mapping public keys to allowed IPs, and adding a new peer means adding a new entry to the table. There is no PKI to manage, no certificates to revoke, no CA chain to distribute.

Mechanism	Identity model	Scaling	Revocation	Operator effort
PSK	Anonymous (knows the string)	Poor at scale	Rotate the key everywhere	Low
Certificate	Named (Subject / SAN)	Excellent	Revoke the certificate	High (PKI)
WireGuard public key	Named (the key itself)	Excellent	Delete the peer entry	Low

Authorisation: what is the peer allowed to do?

Authentication establishes identity. Authorisation decides what the identity can do. In a VPN, authorisation is typically expressed in three places:

Phase 2 / tunnel selectors (IPsec). The IPsec tunnel configuration specifies the local and remote networks (or addresses) that the tunnel carries. A tunnel between 10.0.0.0/24 and 10.1.0.0/24 authorises traffic between those subnets; it does not authorise traffic between 10.0.0.0/24 and 10.2.0.0/24.

Allowed IPs (WireGuard). Each WireGuard peer has an AllowedIPs list. The firewall only accepts packets from the peer whose source IP is in the list, and only routes packets to the peer whose destination is in the list. A peer with AllowedIPs = 10.0.0.0/24 is authorised for that subnet; it cannot send traffic from 10.1.0.0/24 and have it accepted.

Firewall rules. Above the VPN layer, the firewall rules decide what traffic is permitted between the VPN subnet and the rest of the network. A WireGuard peer that authenticates successfully and is allowed to use 10.0.0.0/24 still cannot reach the Internet unless a firewall rule permits it.

The three layers compose. Authentication establishes the peer. The tunnel / AllowedIPs authorisation decides which subnets the peer can claim. The firewall rules decide what the peer can actually reach.

Why the firewall cannot rely on the inner header alone

A VPN carries inner packets whose source IP is the peer’s inside address. The firewall sees the inner packet after decapsulation, with a source IP that the peer could plausibly spoof if the VPN did not validate it.

This is the reason WireGuard’s AllowedIPs is enforced at the tunnel level: the firewall drops any inner packet whose source is not in the peer’s AllowedIPs list. The inner source IP is not trusted on its own — it is trusted only because the tunnel layer validated it against the peer’s authorisation.

The discipline: never assume the inner source IP is authentic without tunnel-level validation. The firewall rule that allows traffic from 10.0.0.0/24 works because WireGuard has already verified the packet came from a peer authorised for that subnet. Without that verification, a malicious peer could send traffic with an arbitrary inner source IP and the firewall would let it through.

Mapping identity to rules

A practical deployment has many peers — site offices, remote users, partner networks. Each peer has different authorisation. The mapping the operator builds is the VPN policy:

Peer	Identity	Allowed subnets	Firewall rules
Site A	Cert subject `CN=site-a` or WireGuard pubkey `Abc…`	`10.1.0.0/24`	Site A → internal services; no Internet
Site B	Cert subject `CN=site-b` or WireGuard pubkey `Def…`	`10.2.0.0/24`	Site B → internal services + Internet
Remote admin	WireGuard pubkey `Ghi…`	`10.99.0.5/32` (a single host)	Admin → management subnet only

The identity (certificate name, public key) maps to the AllowedIPs (which subnets the peer can claim) which maps to the firewall rules (what the peer can reach). The three are consistent: a peer that authenticates as site-a and is allowed 10.1.0.0/24 has rules permitting Site A traffic, and no rules for other subnets.

Read-only / Safewg show— The WireGuard interface summary. Each peer is identified by its public key. The 'allowed ips' column is the authorisation: peer A is allowed only the host 10.0.0.50 (a remote admin); peer B is allowed the subnet 10.0.1.0/24 (a site office). The firewall can now apply per-peer rules: traffic from peer A is subject to admin rules; traffic from peer B is subject to site-office rules. The keys are the identity — the operator logs which key connected, when, and how much it transferred.

$ wg show wg0

interface: wg0
public key: serverpubkeygoeshere0123456789abc=
private key: (hidden)
listening port: 51820

peer: clientpubkeyA==
endpoint: 203.0.113.50:51234
allowed ips: 10.0.0.50/32
latest handshake: 12 seconds ago
transfer: 1.24 MiB received, 348.2 KiB sent

peer: clientpubkeyB==
endpoint: 198.51.100.75:51820
allowed ips: 10.0.1.0/24
latest handshake: 1 minute, 23 seconds ago
transfer: 245.8 MiB received, 78.4 MiB sent

Illustrative output

Failure modes

Five failure modes appear repeatedly:

PSK leak. The pre-shared key is committed to a Git repository, pasted into a chat, or shared with a contractor who should not have it. Every endpoint that knew the PSK now needs a new key. Mitigation: use certificates or per-peer public keys, rotate PSKs aggressively, never store PSKs in version control.
Certificate expiry not monitored. A certificate expires; the tunnel stops negotiating; the operator finds out when users report the outage. Mitigation: monitor certificate expiry with the same alerting used for TLS certificates.
Wrong AllowedIPs. A WireGuard peer’s AllowedIPs is set to 0.0.0.0/0 (the default that means “all traffic”) when the operator intended a specific subnet. The peer now claims every source IP, and the firewall routes all VPN traffic through that peer. The fix is to set AllowedIPs to the peer’s actual subnet.
Authorisation broader than authentication. A peer authenticates with one identity but is allowed subnets that belong to a different peer. The misconfiguration is silent — the tunnel works, the traffic flows, and the wrong peer is using the wrong authorisation. The fix is per-peer AllowedIPs and per-peer firewall rules.
Firewall rules not aligned with the VPN subnet. The VPN subnet is 10.99.0.0/24 but the firewall rules reference 10.99.0.0/16. Traffic from the VPN is dropped because the source does not match. The fix is to use the actual VPN subnet in the rules.

Default AllowedIPs of 0.0.0.0/0 is a routing footgun

WireGuard’s default AllowedIPs for a new peer is 0.0.0.0/0 — meaning the peer is allowed to claim any source IP. This is the correct setting for a full-tunnel remote-access VPN (where the peer should send all its traffic through the firewall), but it is the wrong setting for almost every other case.

The trap: the operator adds a new peer, leaves AllowedIPs at the default, and the peer is now authorised for every subnet. The operator then adds firewall rules for the specific subnet the peer should reach, but the AllowedIPs footgun means the peer could (with manual configuration) claim any source.

The discipline: set AllowedIPs deliberately for every peer. For site-to-site, use the peer’s subnet. For remote access, use 0.0.0.0/0 only when full-tunnel is intended.

Summary

Authentication establishes who the peer is. Authorisation decides what the peer can do.
PSK is simple but anonymous and does not scale. Certificates and per-peer public keys carry identity and scale.
The firewall rule that permits VPN traffic is layered on top of tunnel-level authorisation (Phase 2 selectors, AllowedIPs). The tunnel layer must validate the inner source IP before the firewall rule trusts it.
Per-peer identity is what enables per-peer rules, per-peer logs, and per-peer revocation.
The five recurring failure modes — PSK leak, certificate expiry, wrong AllowedIPs, authorisation mismatch, rule subnet mismatch — all surface as silent configuration errors that produce broken tunnels or leaked authorisation.