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

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

Hello all,

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.

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 looked at the TCP state machine in npf_state_tcp.c, line #144 with
the npf_tcp_fsm definition, and I don't see any RST flag handling
there. Is this expected? Missing?

Any help / hint appreciated!
Best,
Anthony