Co-Authored-By: Claude.ai

Root cause: Pi, the ISP router (FritzBox), and LAN clients share the same
L2 segment. When Pi forwards a client's IPv6 packet to an external GUA
destination, the Linux kernel detects that the ISP router is a "better"
next-hop on the same link and sends an ICMPv6 Redirect (type 137) to the
client. The client obeys the redirect and sends its first SYN to the ISP
router directly — Pi never forwards the original packet. The ISP router
applies per-device content filtering to the unmasqueraded client GUA and
issues a RST. This produced the symptom of the first IPv6 request failing
with "Connection reset by peer" every ~30-60 seconds (matching the FritzBox
RA interval, after which clients re-resolve their default gateway).

Diagnosis method: tcpdump with MAC addresses (-e flag) on Pi's end0 caught
the ICMPv6 Redirect being sent immediately after the first SYN arrived.
Inserting a DROP rule for icmpv6-type redirect at position 1 in ip6tables
OUTPUT confirmed the fix — 0 failures across extended testing.

Fix:
- Drop ICMPv6 Redirect (type 137) in ip6tables OUTPUT as the first rule,
  before the ACCEPT rule, in both direct and VPN modes
- Flush ip6tables OUTPUT chain on clear_rules() instead of per-rule -D
  deletion, which was fragile and left stale rules accumulating across
  mode switches (previously caused duplicate/conflicting OUTPUT rules)
- Flush ip6tables nat POSTROUTING table instead of per-rule -D deletion
  for the same reason

Also documents the ICMPv6 Redirect issue and IPv6 masquerade rationale
in roles/gateway/README.md for future reference.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- Remove static network_ipv6_gateway from LAN hosts so they pick up
  Pi's radvd RA (pref high) instead of FritzBox (pref low)
- Add missing ip6tables FORWARD ACCEPT rule for new connections in
  direct mode (only ESTABLISHED was present, blocking new flows)
- Flush ip6tables nat POSTROUTING table on clear instead of fragile
  per-rule -D deletion to prevent stale rule accumulation

Add radvd to gateway role to advertise Pi as high-preference IPv6
default router using the stable ULA prefix (fd1e:.../64). With
FritzBox also sending RAs, devices end up with ECMP between Pi and
FritzBox. To solve this, add network_ipv6_gateway (Pi's link-local)
as a static route with metric 100 to all managed hosts — beats RA
metric 425, ensuring all IPv6 default traffic goes through Pi.

Fix IPv6 MASQUERADE in gateway-apply-rules:
- Direct mode: add MASQUERADE on end0 (LAN devices use ULA source
  addresses not known to FritzBox, so Pi must NAT them)
- FORWARD rules: restrict to RELATED,ESTABLISHED only — previously
  the broad ACCEPT rule passed un-NAT'd packets alongside masqueraded
  copies, causing duplicate SYNs, conntrack corruption, and RSTs
- MASQUERADE/clear rules: match by interface not by source subnet
  (devices may use any source address, not just the ULA prefix)
- VPN mode return traffic: explicitly restrict to wg+→end0 direction

Add network_ipv6_gateway var (optional) to network role NM templates
(ethernet, wifi, bridge) — injects a static IPv6 default route at
metric 100 when set. Add rpi5 static route to FritzBox link-local so
Pi keeps IPv6 after FritzBox RA is disabled.

Force SSH to IPv4 for *.local hosts (AddressFamily inet) — prevents
Ansible from hanging on mDNS returning multiple IPv6 addresses.

Update gateway and pihole READMEs with two-step IPv6 setup process.

Co-Authored-By: Claude.ai

After finding issues that vpn ip6 wasn't working reliably (which was
obvious over VPN)
Needed to add the VPN routing table support (similar to ipv4)

This together with disabling ssh (for github and sr.ht) over ipv6 makes
the vpn reliable again

Will test and see, since I saw that the archlinux machine wasn't working
properly over the vpn, but it could be due to the VPN ipv6 wasn't
resolving.