Skip to content

Network

How the boxes are wired together — VPN, internal subnets, who can reach whom.

Posture, 2026-05-05: two distinct VPN systems coexist: - WireGuard via WG-Easy on O1 (wg.448.global) — the advertised company VPN; lightly used (~4 peers), strategic plan is to put TnE Connect behind it for security. - Tailscale on Vishnu's personal account — the actually used admin path for E2 and O1. Personal account is a real risk (see KI-010).

The two OCI tenancies (EIDOSDev1 + ORA448Global) are not natively networked. Cross-tenancy access happens only via Tailscale today.

High-level topology

graph LR
    Internet((Public Internet)) -->|443/80| CaddyE1[Caddy on E1]
    Internet -->|443/80| CaddyO1[Caddy on O1]
    Internet -->|22 SSH| E1[E1 host SSH]:::ssh
    Admin[Engineer laptops] -->|Tailscale<br/>personal account| TS[E2 + O1]
    Admin -->|WireGuard via wg.448.global| WGS[O1 WireGuard server]
    WGS -->|full-tunnel 0.0.0.0/0| Internet2((Internet via O1))
    classDef ssh fill:#fee

Notes: - E1's SSH is still on the public internet — port 22 still listening. E2 and O1 have OCI ingress on 22 closed; SSH only via Tailscale. - WireGuard is full-tunnel — peers route all traffic through O1, including general internet browsing. - There is no inter-tenancy networking at the OCI VCN level.

WireGuard (wg.448.global)

Field Value
Server host O1 ORA448Global VPS
Public hostname wg.448.global
Public IP (UDP endpoint) [INFO NEEDED] (server's O1 public IP)
UDP port 51820
VPN subnet [INFO NEEDED]
Management product WG-Easy (admin.wg.448.global/admin/config)
Allowed IPs (split vs full tunnel) 0.0.0.0/0, ::/0 — full-tunnel: every byte of peer traffic routes through O1
DNS pushed to peers 1.1.1.1 (Cloudflare IPv4), 2606:4700:4700::1111 (IPv6)
Active peers 4
Peer issuance admin-gated; not a self-service flow
Vault entry for server private key [INFO NEEDED]
Peer audit cadence [INFO NEEDED] (none today, given peer count is small)

Strategic plan: put the TnE Connect APEX apps behind WireGuard while the APEX security hardening is in flight. WG becomes the security wrapper rather than a developer convenience.

See app doc: 20-wireguard.md.

Risks specific to the WG setup

  • Full-tunnel routes all peer traffic through O1, an Always-Free Ampere A1 with a single 6 GB shared instance. Bandwidth and CPU contention with the 13 other apps on O1.
  • Putting customer-facing TnE Connect URLs behind WG restricts them to anyone with a peer config — this changes the audience model. Document who gets configs and how it's revoked.
  • WG full-tunnel + Cloudflare DNS — every peer's DNS resolution goes via Cloudflare, not the corporate Authentik / domain authority chain.

Tailscale (admin overlay)

Field Value
Account Vishnu's personal Tailscale account
Members E2, O1
Missing E1 still uses public SSH
Cross-tenancy reachability only via Tailscale (no OCI VCN peering)

Why this matters: - A personal account holds the source-of-truth for inter-tenancy connectivity. If that account is locked, suspended, or the bill goes unpaid, ops loses its admin path simultaneously. - Tailscale's free tier has a 100-device cap and ACLs are tied to the account owner. Visibility for other admins (Bradley, Tracey) into the tailnet depends on Vishnu sharing. - Off-boarding risk: if Vishnu were to leave, every device's tailnet membership is affected. - E1 not yet on the tailnet means SSH is still publicly reachable on E1 — partly defeats the lock-down on the other two.

Migration target: a self-hosted option (Headscale) on a dedicated host, or a company-account Tailscale subscription. See KI-010.

Public exposure

Most app URLs are publicly reachable from the internet — by design today, with planned hardening:

Surface Public today? Plan
Customer-facing apps (Parallax, TnE Connect tenants, WordPress sites, CRMs) yes TnE Connect to move behind WireGuard while APEX hardening is underway
Admin UIs (vault., portainer., monitor., coder., n8n.) yes [CONFIRM] Phase-2: Wireguard or Authentik forward-auth in front
WordPress /wp-login.php yes hardening with WAF / fail2ban / 2FA plugin
GitLab /users/sign_in yes fine for SSH push but admin login should be Authentik-only
ADBs (E3, E4, E5, O2, O3) yes — Free tier only allows public endpoints see KI-011
SSH on E1 yes — port 22 open on internet move E1 onto Tailscale and close 22
SSH on E2, O1 no — OCI ingress closed on 22; only Tailscale

AI-powered attack-surface concern (per Vishnu): modern automated attackers continually scan and exploit public dashboards. Reducing the public surface (Wireguard / SSO-forward-auth) is on the Phase-2 list.

OCI IAM ↔ Authentik chain

Layer What it does
Microsoft Entra (Azure AD) Corporate identity backbone (Microsoft 365 mailbox accounts)
Authentik (auth.448.global) Federates with Azure AD; users sign into Authentik via their Microsoft 365 credentials
Apps that use Authentik OIDC GitLab, Vault, [INFO NEEDED] other apps
OCI IAM (EIDOSDev1 + ORA448Global) Not federated with Authentik today. Local OCI users only.

Strategic plan: every app that supports SSO eventually federates through Authentik for centralized password and revocation control. OCI IAM federation is a candidate but not yet done.

Inter-server reachability

Source Destination How Notes
Public internet E1, O1 (443) direct Caddy reverse proxies
Public internet E2 (443) via E1 Caddy [CONFIRM] E2 not directly proxied externally
Public internet E1 (22 SSH) direct unrestricted
Engineer laptop E2, O1 Tailscale (personal account)
Engineer laptop E1 public SSH
WG peers O1 + outbound to internet full-tunnel
E2 ↔ O1 only via Tailscale today no OCI VCN peering
Servers ↔ ADBs over public internet using Oracle wallet (mTLS) [CONFIRM]

Firewall posture

Layer Tool Rule summary
OCI Security Lists / NSGs manually managed ingress 22 closed on E2 + O1; open on E1; Phase-2: move to Terraform
Host firewall Ubuntu defaults: UFW + iptables [INFO NEEDED] actual ruleset per host
Application-layer Caddy + (planned) Authentik forward-auth not yet rate-limited
Fail2ban [INFO NEEDED] (possibly on one host)

DNS resolution

  • External DNS for the four domains: GoDaddy hosts the records.
  • No internal DNS server — apps resolve via public DNS. Tailscale provides MagicDNS for tailnet hosts.
  • No split-horizon DNS — the same hostname returns the same IP whether queried internally or externally.

Risks (consolidated)

  • Full-tunnel WG via Free A1 host (O1) — capacity headroom unknown, single host SPOF for VPN-routed traffic.
  • Tailscale on personal account — full bus-factor risk on Vishnu's account (KI-010).
  • E1 SSH publicly open — narrows once Tailscale is extended.
  • Two tenancies not networked — every cross-tenancy hop goes via the personal Tailscale.
  • Manually managed OCI Security Lists — drift / no audit trail / no review.
  • Full ADB public exposure — Free tier inherent (KI-011).
  • No internal DNS — host renaming / IP changes ripple to every config that references them.

Phase-2 actions

  1. Migrate Tailscale off Vishnu's personal account (Headscale self-hosted, or company-paid Tailscale subscription).
  2. Bring E1 onto the tailnet; close OCI port 22 on E1.
  3. Decide WireGuard vs Tailscale role-split clearly: WG for customer-facing security wrapper, Tailscale for admin overlay.
  4. Move OCI Security Lists into Terraform.
  5. Document VPN subnets, peer registry, revocation procedure.
  6. Plan ADB private-endpoint / mTLS-only access (requires upgrade from Free tier for some controls).
  7. Federate OCI IAM with Authentik OIDC for centralized identity.
  8. Harden WordPress / public dashboards: WAF, fail2ban-everywhere, Authentik forward-auth.