vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(mesh): CrowdSec CGNAT false-ban incident — mesh bypasses it

Browse Source
This commit is contained in:
vh
2026-09-05 23:28:36 -07:00
parent 7382fdaa7b
commit e88ec01726
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/pfi/headscale-mesh-plan.md
+10
View File
@@ -198,3 +198,13 @@ Operator's MacBook enrolled via the GUI (Option-click → Debug → Custom Login
node 5 `vhlk-mba26` (100.64.0.5), "Use Tailscale subnets" on. From ESH: `ping 100.64.0.3` node 5 `vhlk-mba26` (100.64.0.5), "Use Tailscale subnets" on. From ESH: `ping 100.64.0.3`
and `ssh infra-ops@ana-docker.ana.internal` both work → colo subnet route + split DNS for and `ssh infra-ops@ana-docker.ana.internal` both work → colo subnet route + split DNS for
`*.internal` proven from a client. (Path was still via the ESH LAN / old tunnels.) `*.internal` proven from a client. (Path was still via the ESH LAN / old tunnels.)
### Note — the mesh is also the durable fix for CGNAT CrowdSec false-bans
2026-09-06: CrowdSec on ana-docker banned ESH's shared CGNAT egress (23.164.40.160,
`custom/gitea-aggressive-crawl`) and the fortigate-mirror bouncer pushed it to the colo
edge, blackholing Matrix/gitea/chat for the whole ESH site (see
`~/.claude/.../memory/incident_crowdsec_cgnat_false_ban.md`). Once ESH consumes colo
services over the mesh (100.64/10 via ana-scale) rather than the public FortiGate VIP,
that traffic never reaches CrowdSec — a concrete win beyond replacing the tunnels, worth
weighing when prioritising the cut-over.