Wireguard VPN¶
The company's VPN at
wg.448.global. The way employees and admins reach internal-only services. Effectively the front door to the internal network.
| Field | Value |
|---|---|
| Public URL | https://wg.448.global (likely admin/portal UI; the VPN itself is UDP) |
| Audience | engineers, admins, possibly all staff |
| Criticality | critical — without it, internal services are unreachable |
| Maturity | [INFO NEEDED] |
| Owner | [INFO NEEDED] |
| Last reviewed | 2026-05-05 |
1. At a glance¶
Wireguard is the company VPN. When employees connect, their laptop joins the internal network and can reach services that aren't exposed to the public internet (Vault, Portainer, internal dashboards). Without it, those services are unreachable. Anyone with a valid Wireguard config has direct network access — losing one is roughly equivalent to losing a key to the office.
2. Business purpose¶
- Secure remote access to internal services.
- Network-layer barrier against public exploitation of internal-only apps.
- Choke-point for revoking access when someone leaves.
3. Audience¶
Engineers and admins. [CONFIRM] whether all staff have access or only IT/engineering.
4. Hosting & cloud infrastructure¶
- Server: O1 ORA448Global VPS
- Management UI: WG-Easy at
wg.448.global/admin/config - Reverse proxy (UI): Caddy on the same O1
Infrastructure map¶
| Item | Value | Notes |
|---|---|---|
| Portal URL | wg.448.global | WG-Easy admin UI |
| Public IP (VPN endpoint) | O1's public IP | [INFO NEEDED] exact IP |
| VPN port (UDP) | 51820 | |
| Allowed IPs (peer routing) | 0.0.0.0/0, ::/0 — full-tunnel |
every byte of peer traffic transits O1; see KI-009 |
| DNS pushed to peers | 1.1.1.1 (IPv4), 2606:4700:4700::1111 (IPv6) |
Cloudflare |
| Portal HTTPS port | 443 | |
| Wireguard product | WG-Easy | |
| Active peers | 4 | not actively used today |
| Strategic direction | put TnE Connect APEX apps behind WG while APEX security hardening is in flight; roll out WG clients to all Eidos staff (per RM-042) | |
| VPN subnet | [INFO NEEDED] |
|
| Open decision | whether to keep portal at wg.448.global or migrate to wg.projecteidos.com / wg.eidos-global.com before the staff-wide client rollout — re-issuing configs later is costly |
Credentials in Vault¶
| Secret type | Vault path / link | Last rotated |
|---|---|---|
| Portal admin login | [INFO NEEDED] |
|
| Server private key | [INFO NEEDED] |
losing this requires rotating all peer configs |
| Per-user peer configs | [INFO NEEDED] |
should be issued and tracked individually |
| Pre-shared keys (if enforced) | [INFO NEEDED] |
5. Technology behind it¶
- Type: off-the-shelf
- Protocol: WireGuard (kernel module / userspace
wireguard-go) - Likely management layer: WG-Easy / Firezone / similar
[CONFIRM]
6. Data it handles¶
- Network traffic (encrypted in flight; the VPN endpoint sees client→target metadata)
- Peer configurations (private keys for each user — these are secrets)
7. External dependencies¶
- Public DNS pointing to the VPN endpoint.
- Anything internal users need to reach — the entire blast radius of "VPN is up" depends on these.
8. Authentication & access¶
- End-user "login": possessing a valid peer config (private key) is auth.
- Portal login:
[INFO NEEDED]— should be Authentik SSO + MFA. - MFA on the VPN itself?
[INFO NEEDED]— WireGuard alone is config-based; MFA requires an overlay (Firezone, NetBird, etc.). - Revocation procedure when someone leaves:
[INFO NEEDED]
9. Maturity assessment¶
| Dimension | Status | Evidence |
|---|---|---|
| Backups | [INFO NEEDED] |
server keys + peer config DB |
| Monitoring | [INFO NEEDED] |
active-peer count, throughput |
| Alerting | [INFO NEEDED] |
endpoint unreachable |
| Redundancy | [INFO NEEDED] |
typically single endpoint |
| Patching cadence | [INFO NEEDED] |
|
| Peer audit | [INFO NEEDED] |
how often is the peer list reviewed? |
10. Known risks & vulnerabilities¶
- Full-tunnel via O1 Free VPS — see KI-009. VPN traffic competes with Vault/Authentik on the same host.
- Co-existence with Tailscale on a personal account — see KI-010. The two VPN systems serve overlapping purposes; clarify role-split.
- Putting customer-facing TnE Connect URLs behind WG would change the audience model — only peer-config holders can reach the app. Plan customer-onboarding flow before flipping the switch.
- Peer registry not source-controlled (KI-015) — WG-Easy stores peers in its own DB on O1; no off-host backup.
[INFO NEEDED]Stale peer configs — peers from ex-employees / old laptops still authorized.[CONFIRM]Server private key not backed up — a fresh key requires regenerating every peer config.[CONFIRM]Single point of failure for internal access — if the VPN is down and Tailscale is on a personal account also unreachable, no admin can fix things internally.
11. Impact if it goes down¶
- Admins lose access to internal-only systems (Vault, Portainer, Beszel, etc.).
- Emergency operations on the rest of the estate become much harder.
- Worth pre-defining a break-glass path: e.g. an admin who can SSH to the VPN host directly via console / cloud-provider browser console.
12. Owner & on-call¶
[INFO NEEDED]
13. References & links¶
- Portal: https://wg.448.global
- Domain: see domains.md