@philvuchetich @mwl if you are firewalling, allow fe80::/64 on all ipv6 interfaces. Neighbor discovery failures have weird side effects.
Discussion
Loading...
Post
Thanks again - the minor edit in pf.conf solved it - previously only echoreq, unreach were allowed, now all icmp6 is allowed.
For reference: current rule is
"pass inet6 proto icmp6 from fe:80::/64 to fe:80::/64"
I'll plan to allow on all interfaces within the LAN -
"pass inet6 proto icmp6"
And then evaluate what the firewall will do if some ICMP types should be blocked after reading the upcoming #BookOfPF by @pitrh . That part is more complex because my IPv6 connection is a tunnel via HE (neither the cable nor fiber ISP offers IPv6 native connectivity), so I need to read more first.
***
I just left the IPv4 and IPv6 ping running overnight, and the connectivity is resolved:
IPv6 --- ping statistics ---
54559 packets transmitted, 54557 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.070/0.251/0.760/0.076 ms
IPv4 --- ping statistics ---
54564 packets transmitted, 54564 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.061/0.230/0.468/0.027 ms
This is over a 1 Gb connection with 3 switches between hosts, so an average 250 ns ping time is fine.
@philvuchetich @phessler @pitrh
filtering ICMP is fraught, and tricky, and generally unwise.
It is, however, an education.
Thanks!
Both systems are using pf - In pf.conf would that look like this?
#testing neighbor discovery - 2 rows
pass inet6 proto icmp6 from fe80::/64 to any
pass inet6 proto icmp6 from any to fe:80::/64
or
# #testing neighbor discovery 1 row
pass inet6 proto icmp6 from fe:80::/64 to fe:80::/64
**
I disabled pf, then tried each of the 2 options above, and it appears that pings are working with all 3 options (disable pf, pass with 2 separate rows, pass with single row), so is is looking likely that neighbor discovery is the issue (after 10 minutes of pings with no loss with the 1 row option)
I looked at icmp6(4) man page - it would seem that for link local addresses, I wouldn't need to filter by ICMP types since this pf.conf is on the LAN devices (and not an internet-facing router).
Note - previously icmp-types were limited by pf.conf to { echoreq, unreach}. I probably should have looked more deeply into the PF4e advance draft that notes routeradv, routersol, neighborsol.
@philvuchetich @mwl the 1 row filter option is one of the better ones to use, as it is more specific. IIRC there are some even more specific rules in the "initial temporary rule set" in OpenBSD's /etc/rc but IMHO only do that if you desperately need to filter some of the icmpv6 types.
Allowing ICMP is normally safe and sane for a network.
@philvuchetich @mwl also check for multicast snooping buttons on the switches.
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled