Overlapping ICMP ID not handled by PF state

[franco]

Yes it seems to be confusing the ICMP ID with the type now. The state tracking uses a virtual_id / virtual_type idea for sport / dport faking. Formerly it would use the ICMP ID on both sport / dport and now it fails to properly guess the direction. virtual "sport" 8 and "dport" 8 is always the right direction ;)

[muchacha_grande]

I'm not sure but a change listed in 25.7 RC2 announcement could be the solution to this issue.

o src: pf: fix ICMP ECHO handling of ID conflicts

[patient0]

I'm not sure but a change listed in 25.7 RC2 announcement could be the solution to this issue.

Thanks for pointing that out! I did a test with two Debian clients, running 'ping -e 1 1.1.1.1' from both. It did fail on RC1 and did succeed on RC2! Excellent news.

[franco]

Yep. We were debating putting it into 25.1.11 but decided not to because stable commits from that direction have a chance to make things much worse.

This was a clear mistake in the initial FreeBSD ICMP state SA that we talked about 9 months ago and FreeBSD brushed off.  Inspecting the patch, FreeBSD didn't ever look into this bug as it was submitted by a user now.

https://github.com/opnsense/src/commit/a18d19bb2d


Cheers,
Franco

[patient0]

Yep. We were debating putting it into 25.1.11 but decided not to because stable commits from that direction have a chance to make things much worse.

Thanks a lot Franco for the explanation and keeping an eye on it. Let's assume the FreeBSD folks where very busy and did not ignore it willingly.

[franco]

To put it like it is: it was not worth their time.


Cheers,
Franco

[deajan]

Can confirm that 25.7rc2 fixes the issue for me.

Thank you guys, this made me question my network admin skills and/or sanity ;)

[muchacha_grande]

I confirm the issue gone on 25.7 RC2...

To put it like it is: it was not worth their time.

To me this is an important issue... I don't know what the priorities are for FreeBSD team, but having a sane IP stack is essential.

[franco]

Quite a few people inside and outside of FreeBSD talked about the state of the security advisory since August 2024 causing this problem amongst a significant number of others:

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

The only conclusion is nobody cared back then and nobody really cares now. Everyone is just a volunteer when it comes to responsibility.  :)


Cheers,
Franco