Re: NPF (mis?)behaviour vs. distant site (mis?)behaviour ...

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

On Wednesday  4 Oct 2023, at 17:58, Mouse wrote:
> I've never seen this myself.  But I'd hazard a guess that
> 90.102.115.81 - or, in that particular case, perhaps more likely some
> kind of firewall in front of it - is trying to do OS fingerprinting of
> the connection-initiating host.

(sorry, I did not see your reply before posting a follow-up to myself).

Well, this does not happen 100% of the time. So that would be a bit
weird, and not really compliant, no?

> I don't really know NPF, but I'd guess that it's actually the
> out-of-window ACK, not the RST, that's getting eaten

Yes, I actually figured that out too.

> I'd further guess
> that it's getting eaten because your "stateful" is causing npf to pass
> only packets that make sense as traffic belonging to an
> interior-established connection (and that ACK doesn't belong).

Yes, makes sense. But then the RST never happen, which is an issue, no?
Shouldn't the ACK be considered as part of the SYN_SENT connection, and
later detected as invalid, so that it can be RST?

I noticed that in the SYN_RECEIVE case, a bare ack reply is considered
OK (with an XXX comment "ACK of late SYN in simultaneous case?").

> Remember, tcpdump - and bpf captures in general - normally take place
> _outside_ any firewalling done on the capturing host.  So, using
> tcpdump, you can't really tell the difference between the weird ACK
> getting eaten and the RST getting eaten.

I did the tcpdump on the "npflog0" interface, logging either passed or
blocked packets, to track down NPF behaviour.