Skip to content

VPN — WireGuard

Remote access is a WireGuard hub with 12 peers. It currently runs on CR-LEVEL-04, which is being re-roled to the retail-ISP bdr-2 — so the VPN must migrate off it first.

As-built (on CR-LEVEL-04)

  • Hub interface wg000, listen udp/18472, hub address 10.249.1.1/27, 12 peers on 10.249.1.2–.13. The pool 10.249.1.0/27 is redistributed into OSPF.
  • All peers share client-endpoint=wgvpn.pubinvest.co.uk, is-responder=yes, and each peer's allowed-address is its own /32.

Peers are split by the DNS handed to them (not by firewall policy):

Group DNS Peers
Network-access internal 10.1.84.34 lewis .2, sina .3, chris .4, james .5, lewis-2 .12, sean .13
WAN-only public 8.8.8.8 sina-parents-1/2/3 .6/.7/.11, jamie .8, sadaf .9, caldytablet .10

The split is not enforced today

The forward chain has no default-drop, so any WG peer can reach all of 10.0.0.0/8 by adding a client-side route. Worse, the management address-list contains 10.249.1.0/26, so every VPN client (families included) can manage routers. This is a security gap the target design closes.

Compromised keys

The interface private key and all 12 peer private keys were printed to discovery/raw/CR-LEVEL-04/ (gitignored) during discovery — treat them as compromised. Rotate the server key and reissue all 12 client configs once, as part of the migration. No keys are reproduced in this portal.

Also: gre-bolton → 178.17.243.197 is a dormant legacy tunnel (confirm and delete), and there is a stale udp/18475 input rule to remove.

Target design

  • One instance, running on the OPNsense pair (CARP HA), bound to the CARP VIP, preserving the existing tunnel IPs.
  • Per-peer firewall keyed on the tunnel /32 — WireGuard cryptographically source-pins the /32, so a rule matched on it is as strong as the tunnel itself.
  • A vpn-full-access address-list becomes the policy: promoting or demoting a peer is a one-line edit, no client reconfiguration.
  • Rules: isolate intra-VPN; full-access peers reach a scoped internal chain (not blanket 10/8); everyone else is dropped from 10.0.0.0/8 + 172.16.0.0/12; WAN-only peers get internet only.
  • Remove 10.249.1.0/26 from the management list fleet-wide.

A two-instance variant gives stronger isolation but requires reissuing configs; the single-instance per-peer-firewall approach is preferred.