Fix IPv6 reachability for ccnet-wv-mailcow (mail VM has no outbound IPv6 route) #19

New issue

Open

opened 2026-07-09 14:22:23 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-09 14:22:23 +00:00

Collaborator

The new DMZ-isolated mail VM (ccnet-wv-mailcow, 10.10.50.10) has no global
IPv6 route at all — only link-local addresses and its own private docker
overlay (fd4d:6169:6c63:6f77::/64). Confirmed 2026-07-09 via ip -6 route show (no default route) and by testing curl -6 from inside the
acme-mailcow container, which failed immediately with "Network
unreachable".

This was first flagged during Phase 4 of the mail migration (checking
whether the wg-box's public IPv6, 2a01:4ff:f0:f3d7::/64, is involved in
mail sending/receiving) and deliberately deferred. It became a live blocker
during Phase 3/entry-into-service work: mailcow's own acme-mailcow
container prefers AAAA over A whenever a AAAA record exists for
MAILCOW_HOSTNAME (mail.coppercore.cc, which now has a real public AAAA
record for Gmail's IPv6-PTR deliverability requirement, set in Phase 4) and
has no fallback to IPv4 if the IPv6 challenge path fails — so Let's Encrypt
issuance broke until worked around.

Current workaround (in place, not a real fix): added a local-zone
override in mailcow's own internal unbound-mailcow resolver
(data/conf/unbound/unbound.conf on the mail VM) that answers
mail.coppercore.cc with only the A record (178.156.194.104) and no AAAA,
scoped entirely to DNS resolution inside the mailcow stack -- public DNS is
untouched. This unblocks ACME but doesn't give mailcow itself (Postfix,
Dovecot, etc.) any real IPv6 send/receive capability, and doesn't address
whatever else inside mailcow might expect real IPv6 reachability.

Planned real fix (not yet scheduled): route real IPv6 to the mail VM
over the existing WireGuard tunnel from the wg-box, so the DMZ mail VM has
genuine outbound/inbound IPv6 connectivity instead of the internal-resolver
workaround. Once that's in place, the unbound local-zone override above
should be removed.

Related: mail migration plan (Phase 3/4), docs/hetzner-vps.md.

The new DMZ-isolated mail VM (`ccnet-wv-mailcow`, 10.10.50.10) has no global IPv6 route at all — only link-local addresses and its own private docker overlay (`fd4d:6169:6c63:6f77::/64`). Confirmed 2026-07-09 via `ip -6 route show` (no default route) and by testing `curl -6` from inside the `acme-mailcow` container, which failed immediately with "Network unreachable". This was first flagged during Phase 4 of the mail migration (checking whether the wg-box's public IPv6, `2a01:4ff:f0:f3d7::/64`, is involved in mail sending/receiving) and deliberately deferred. It became a live blocker during Phase 3/entry-into-service work: mailcow's own `acme-mailcow` container prefers AAAA over A whenever a AAAA record exists for `MAILCOW_HOSTNAME` (`mail.coppercore.cc`, which now has a real public AAAA record for Gmail's IPv6-PTR deliverability requirement, set in Phase 4) and has no fallback to IPv4 if the IPv6 challenge path fails — so Let's Encrypt issuance broke until worked around. Current workaround (in place, not a real fix): added a local-zone override in mailcow's own internal `unbound-mailcow` resolver (`data/conf/unbound/unbound.conf` on the mail VM) that answers `mail.coppercore.cc` with only the A record (178.156.194.104) and no AAAA, scoped entirely to DNS resolution inside the mailcow stack -- public DNS is untouched. This unblocks ACME but doesn't give mailcow itself (Postfix, Dovecot, etc.) any real IPv6 send/receive capability, and doesn't address whatever else inside mailcow might expect real IPv6 reachability. Planned real fix (not yet scheduled): route real IPv6 to the mail VM over the existing WireGuard tunnel from the wg-box, so the DMZ mail VM has genuine outbound/inbound IPv6 connectivity instead of the internal-resolver workaround. Once that's in place, the unbound local-zone override above should be removed. Related: mail migration plan (Phase 3/4), docs/hetzner-vps.md.

claude-bot added the

p:medium

infra

labels

2026-07-09 14:22:23 +00:00