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

> I have a NPF question.  I (82.65.226.80) am currently fighting with a
> remote host (90.102.115.81) that is behaving strangely, and this is
> most of the time not working with npf enabled.

> First, a tshark dump of a https connection with curl, _without_ npf
> running, to show the weird(?) behaviour of the remote host:

>     1   0.000000 82.65.226.80 â?? 90.102.115.81 TCP 74 53349 â?? https(443) [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=1 TSecr=0
>     2   0.029969 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP ACKed unseen segment] https(443) â?? 53349 [ACK] Seq=1 Ack=27097879 Win=16384 Len=0
>     3   0.029984 82.65.226.80 â?? 90.102.115.81 TCP 54 53349 â?? https(443) [RST] Seq=27097879 Win=0 Len=0
>     4   5.999511 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] [TCP Port numbers reused] 53349 â?? https(443) [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=13 TSecr=0
>     5   6.038370 90.102.115.81 â?? 82.65.226.80 TCP 78 [TCP Previous segment not captured] [TCP Port numbers reused] https(443) â?? 53349 [SYN, ACK] Seq=0 Ack=1 Win=4140 Len=0 MSS=1380 WS=1 TSval=4230795670 TSecr=13 SACK_PERM=1
>     6   6.038388 82.65.226.80 â?? 90.102.115.81 TCP 66 [TCP ACKed unseen segment] 53349 â?? https(443) [ACK] Seq=1 Ack=1 Win=33576 Len=0 TSval=13 TSecr=4230795670
>     7   6.040516 82.65.226.80 â?? 90.102.115.81 TLSv1 583 Client Hello

> Packet #2 is a bare ACK, not sure what that means, but it happens
> most of the time.  This causes the #3 RST and then the connection
> flows as normal.

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.

> Now, with my npf.conf configured roughly as follow, I'm just putting
> the two relevant rules here:

>   pass stateful out final all apply "log"
>   block final all apply "log"

> And the traffic capture:
>     1   0.000000 82.65.226.80 â?? 90.102.115.81 TCP 124 [pass re1/0] 53351 â?? https(443) [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=1 TSecr=0
>     2   0.029993 90.102.115.81 â?? 82.65.226.80 TCP 104 [block re1/0] [TCP ACKed unseen segment] https(443) â?? 53351 [ACK] Seq=1 Ack=1669644097 Win=16384 Len=0
>     3   5.997559 82.65.226.80 â?? 90.102.115.81 TCP 124 [pass re1/0] [TCP Retransmission] [TCP Port numbers reused] 53351 â?? https(443) [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=13 TSecr=0
>     4   6.028038 90.102.115.81 â?? 82.65.226.80 TCP 108 [block re1/0] [TCP Previous segment not captured] [TCP Port numbers reused] https(443) â?? 53351 [SYN, ACK] Seq=0 Ack=2751935152 Win=16384 Len=0 MSS=1460

> Same #2 bare ACK, but this time the RST packet seems to be swallowed,
> neither passed nor blocked (all my block rules have a "log"
> procedure). Is this a NPF bug?

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; 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).

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.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B