ops: adopt AES-128 on both Anaheim tunnels and close public admin

Both tunnels now negotiate AES-128 for ESP, applied make-before-break so neither dropped waiting on its far end: the FortiGate was widened to accept the new cipher alongside the old one first, then each UniFi gateway was flipped. Single-stream throughput moves from 245 to 270 on the NH3 tunnel and from 268 to 304 on the ESH tunnel. Both network objects were diffed against pre-change snapshots and the only field that moved on either is the ESP cipher. The proposal lists are left accepting AES-256 as well. The peers offer only AES-128 so the extra entries are inert, and retaining them means a gateway reverting cannot strand a tunnel. With that up, the WAN administrative surfaces are closed. The interface is back to permitting only ping, and the infra-ops account is again restricted to RFC1918 space. Ports 443 and 22 were confirmed closed from two separate sites and management over the tunnel still works. The close was issued over the tunnel rather than over the WAN, since withdrawing SSH from the interface while connected through it would sever the session mid-command. The box now has no out-of-band path, which the memory records explicitly. Also captured: the two UniFi vault items have different shapes, one a bare key and one a documentation note requiring extraction, which produces an opaque nginx rejection if missed, and the ESH key's first confirmed write.
2026-08-23 15:44:32 -07:00
parent 6edebe4864
commit 7bc9754e40
2 changed files with 66 additions and 1 deletions
@@ -501,3 +501,68 @@ Worth doing, but it is **a project, not a config tweak** — routing, failover a
 policy all need deciding. The cheap wins remain available meanwhile and are
 independent: `nconnect=8` on NFS mounts (approved by brokkr-smithy-dev, pending
 the FortiGate work settling) and AES-128 for ~20%.
+
+---
+
+## LANDED (2026-08-23): AES-128 on both tunnels; FortiGate public admin closed
+
+Operator directed: adopt AES-128 on **both** Anaheim tunnels, make-before-break,
+then close the FortiGate's WAN and SSH admin surfaces. All done and verified.
+
+**Context that retires the WireGuard-in-a-VM design work:** the FortiGate is
+being **replaced by OPNsense on a Dell R420**, which gives **WireGuard on the
+edge device itself**. The downstream-terminator architecture (FOLLOW-UP 4) is
+therefore moot — do not scope it. This also **un-parks the OPNsense migration**,
+which auto-memory recorded as PARKED pending "hardware acquisition"; the R420
+is that trigger.
+
+### What changed
+
+Make-before-break on the FortiGate first, so neither tunnel dropped waiting on
+a far end:
+
+| phase2 | proposal now |
+|---|---|
+| `pfi-ana-nh3` | `aes256-sha1 aes256gcm aes128-sha1` |
+| `ana-eshudm-dyn` | `aes256-sha1 aes128-sha1` |
+
+Then each UDM flipped to `ipsec_esp_encryption: aes128`:
+
+| tunnel | UDM object | before | after |
+|---|---|---|---|
+| NH3 ↔ ANA | `pfi-nh3-ana` `697d64414c85dd2b6669b00a` @ 10.100.0.1 | 245 Mbit/s | **269.7** |
+| ESH ↔ ANA | `esh-ana` `697723b9b9d4266dddf2bcc7` @ 10.0.0.1 | 268 Mbit/s | **304.3** |
+
+Single-stream gain ~10–13% here, against 16–20% in the earlier controlled A/B —
+the difference is live-link variance, not a different result. Both UDM objects
+were diffed field-by-field against pre-change snapshots: **the only field that
+moved on either is `ipsec_esp_encryption`.**
+
+The FortiGate proposal lists were deliberately **left permissive** (still
+accepting aes256). The peers offer only aes128 so the extra entries are inert,
+and keeping them means a UDM reverting does not strand the tunnel. Narrowing to
+`aes128-sha1` alone is a one-liner if the looser list is unwanted.
+
+### Admin surfaces closed
+
+`wan1 allowaccess` → **`ping`** (https + ssh removed) and `infra-ops` trusthost
+→ **10.0.0.0/8 only** (the 8 wide-open ranges unset). Verified 443 and 22 closed
+from both NH3 and ESH; management over the tunnel at 10.250.0.1 still works.
+**Sequencing that matters: the close was executed over the TUNNEL path, not over
+WAN** — removing `ssh` from allowaccess while connected over WAN kills the
+session mid-command.
+
+**Consequence to hold in mind: ana-gw now has no out-of-band management path.**
+If both tunnels drop it is console-only until someone is on site.
+
+### Gotcha: the two UDM vault items have DIFFERENT shapes
+
+- `unifi/pfi-udmse-api-key` → a **bare 32-char key**. `secret get` output is the key.
+- `unifi/esh-udmpm-api-key` → a **19-line documentation note** with the key on a
+  `key:` line. `secret get` piped straight into a header yields a 1396-byte
+  value and the UDM answers **`400 Bad Request` from nginx**. Extract with
+  `grep '^key:' | awk '{print $2}'`.
+
+**The ESH key's first-ever confirmed WRITE happened here** (auto-memory recorded
+it as read-verified only): a control PUT of the unchanged object returned
+`rc:ok`, then the real change did too. That key has a full read+write admin role.