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

Remove static IPv6 support from network role — all hosts use SLAAC
(method=auto). Simplifies NM templates, argument_specs, and resolved.conf.
gateway sysctl accept_ra=2 is now unconditional when gateway_enabled.

Co-authored-by: Claude.ai