[Bug 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701

--- Comment #57 from Franco Fichtner <franco@opnsense.org> ---
In closing I'd like to add a few things.

It was made known that a proper bug report and steps to reproduce should be
raised. I think that's only fair.  This, however, requires the undesired
behaviour to follow established rules which do not readily apply here.

The core of the problem as we as OPNsense see it is that pf state tracking was
added to several ICMPv6 types that were not there before -- first and foremost
ND_NEIGHBOR_SOLICIT/ND_NEIGHBOR_ADVERT.  It can be said that the state tracking
is insufficient now in at least these two types of ICMPv6 communication which
results in intermittent package drops.  This also results in easily visible
ping drops as neighbour discovery fails intermittently.  The full scope of this
change is highly speculative and it has been hinted at in OPNsense and OpenBSD
that further issues exist with other ICMPv6 types contained within this change.
 The way forward in FreeBSD releases now should be treated with the appropriate
amount of foresight.

If you want to ask for easily reproducible steps please also ask how easily
reliable tests could have been added for this.  Testing all of this is very
difficult as I'm sure we all know now.  I think we are all here to help avoid
and remedy problems together.

It's not my place to question why adding state tracking to pf/ICMPv6 was a good
idea to everyone involved in bringing this to all FreeBSD releases immediately
so far.  Someone should ask that question internally probably.  A better target
for this would be FreeBSD 15.0 in my very humble opinion.

It would be beneficial now to have a real IPv6 expert inspect these state
tracking attempts because I think so far that hasn't happened.  OPNsense does a
lot of IPv6 and does it quite well, but we are in now way experts. My first
reaction to seeing the ICMP patches on stable/14 was to ignore them, but that
was made impossible by pushing them to SA state in the way they were.

Also to remind everyone what downstream does: we are trying to run projects
based on FreeBSD and we mostly build integration for other software.  Ideally
we do this on unmodified FreeBSD.  Yet upstreaming patches is increasingly
difficult and hostile.  Our kernels only diverge because of:

(1) Too strict errata policy on FreeBSD releases, and
(2) upstreaming patches and stable turnaround times are too long.

This causes friction with committers because they don't trust us or our
capabilities or reports and think things like kernel patches are our own
problems.  All of it only leads to more divergence.  I think that should be
said here once for emphasis.

And as a personal matter we should stop with the idea of "conspiracy
theorising" and "downstream is broken".  This will not advance FreeBSD in the
way that it should.

As far as this discussion goes I think FreeBSD has all the information that it
needs to progress this.  As downstream we certainly will make a move based on
what we found out so far, too.  Good luck.


Cheers,
Franco

-- 
You are receiving this mail because:
You are the assignee for the bug.