| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 <[email protected]>
|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
The gateway-direct-mode.service was never triggering when WireGuard
interfaces were removed, leaving VPN iptables rules active even when
VPN was disconnected. This caused internet connectivity to fail in
direct mode.
Root cause: SYSTEMD_WANTS in udev rules only works for ACTION=="add"
events. When a device is removed, the device unit is already gone
before systemd can process the SYSTEMD_WANTS dependency, so the
service never starts. This is a documented systemd limitation.
Fix: Replace SYSTEMD_WANTS with RUN+ for the remove action, which
executes systemctl directly during udev event processing without
requiring a device unit to exist.
References:
- https://stackoverflow.com/questions/72208534/why-does-systemd-wants-not-pass-a-parameter-to-a-service-file-from-a-udev-remov
- https://stackoverflow.com/questions/73148448/how-to-start-systemd-user-service-when-device-is-removed-and-stop-it-when-devic
- https://bugzilla.redhat.com/show_bug.cgi?id=871074https://bugzilla.redhat.com/show_bug.cgi?id=871074
- https://unix.stackexchange.com/questions/528803/systemd-doesnt-stop-the-service-when-the-device-is-removed
The VPN mode (ACTION=="add") continues to use SYSTEMD_WANTS as it
works correctly for device addition events.
|
|
|
