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

Anthony Mallet <[email protected]>
Newsgroups gmane.os.netbsd.devel.network
Organization LAAS/CNRS - Toulouse - France
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.