ccnet-WI site VPN: no backup path when blaze's Frontier link is down (T-Mobile is CGNAT'd) #23

New issue

Open

opened 2026-07-14 02:31:39 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-14 02:31:39 +00:00

Collaborator

That transparency doesn't hold for ccnet-WI's tunnel, because of direction: blaze dials OUT to the Hetzner box (which has a real public IP), so CGNAT on blaze's T-Mobile link doesn't matter for that tunnel — outbound isn't blocked by CGNAT, only unsolicited inbound is. But ccnet-WI's tunnel is the other way around: ccnet-wi-fw dials IN to blaze's WAN IP, which requires blaze to be reachable inbound on that link. T-Mobile 5G home internet is carrier-grade NAT'd, so when blaze fails over to T-Mobile, ccnet-wi-fw has no way to re-establish the tunnel — the backup WAN doesn't back up this particular tunnel.

Idea to scope out: route ccnet-WI's backup path through the Hetzner edge box (ccnet-wireguard-ub-caddy-2gb-ash-1, real static public IP, no CGNAT) instead of dialing blaze directly — e.g. ccnet-wi-fw peers with the Hetzner box, which relays to blaze over its own existing (outbound-initiated, CGNAT-proof) tunnel. Needs design work: routing/AllowedIPs on three boxes, whether the Hetzner box becomes a always-on relay or only a failover path, and whether that box's currently-narrow role (edge ingress + mail relay) should take on site-to-site transit too.

Not urgent — Frontier has been the stable primary link. Flagged after confirming CGNAT is not a hypothetical here, this session, while auditing the new ccnet-WI site.

ccnet-wi-fw (the OPNsense firewall at the ccnet-WI remote site, see docs/ccnet-wi-site.md) dials outbound to blaze.coppercore.net's WAN IP to establish its WireGuard tunnel. blaze has two WAN uplinks (Frontier Fiber primary, T-Mobile 5G home internet backup — see docs/homelab-architecture.md's 'WAN uplinks' section), and that section documents the Hetzner edge box's tunnel as failover-transparent across both links. That transparency doesn't hold for ccnet-WI's tunnel, because of *direction*: blaze dials OUT to the Hetzner box (which has a real public IP), so CGNAT on blaze's T-Mobile link doesn't matter for that tunnel — outbound isn't blocked by CGNAT, only unsolicited inbound is. But ccnet-WI's tunnel is the other way around: ccnet-wi-fw dials IN to blaze's WAN IP, which requires blaze to be reachable inbound on that link. T-Mobile 5G home internet is carrier-grade NAT'd, so when blaze fails over to T-Mobile, ccnet-wi-fw has no way to re-establish the tunnel — the backup WAN doesn't back up this particular tunnel. Idea to scope out: route ccnet-WI's backup path through the Hetzner edge box (ccnet-wireguard-ub-caddy-2gb-ash-1, real static public IP, no CGNAT) instead of dialing blaze directly — e.g. ccnet-wi-fw peers with the Hetzner box, which relays to blaze over its own existing (outbound-initiated, CGNAT-proof) tunnel. Needs design work: routing/AllowedIPs on three boxes, whether the Hetzner box becomes a always-on relay or only a failover path, and whether that box's currently-narrow role (edge ingress + mail relay) should take on site-to-site transit too. Not urgent — Frontier has been the stable primary link. Flagged after confirming CGNAT is not a hypothetical here, this session, while auditing the new ccnet-WI site.

claude-bot added the

infra

p:low

labels

2026-07-14 02:31:39 +00:00

claude-bot referenced this issue from a commit

2026-07-14 02:51:40 +00:00

Document ccnet-WI remote site (Wisconsin) and its WireGuard link to blaze