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

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

On Wednesday  4 Oct 2023, at 20:46, Mouse wrote:
> And, while I didn't go back to check, as I recall, that RST is
> apparently not critical to your connection - I think your traces showed
> the connection being established apparently fine in either case.

The whole point of my questions is that the RST _is_ critical to this
particular host.
Without it, the SYN-ACK is not recognized, the dump indicates
apparently random sequence numbers, and the connection eventually times out.

Another capture with the SYN retransmissons:
    1   0.000000 82.65.226.80 → 90.102.115.81 TCP 74 53505 → 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=1 TSecr=0
    2   0.031213 90.102.115.81 → 82.65.226.80 TCP 62 443 → 53505 [ACK] Seq=1 Ack=2722589159 Win=16384 Len=0
    3   5.990620 82.65.226.80 → 90.102.115.81 TCP 74 [TCP Retransmission] 53505 → 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=13 TSecr=0
    4   6.022537 90.102.115.81 → 82.65.226.80 TCP 62 [TCP ACKed unseen segment] [TCP Retransmission] [TCP Port numbers reused] 443 → 53505 [SYN, ACK] Seq=3330557921 Ack=1758179783 Win=16384 Len=0 MSS=1460
    5  17.990532 82.65.226.80 → 90.102.115.81 TCP 74 [TCP Retransmission] 53505 → 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=37 TSecr=0
    6  18.022124 90.102.115.81 → 82.65.226.80 TCP 62 [TCP Previous segment not captured] [TCP Port numbers reused] 443 → 53505 [SYN, ACK] Seq=354568170 Ack=1 Win=16384 Len=0 MSS=1460
    7  41.990326 82.65.226.80 → 90.102.115.81 TCP 74 [TCP Retransmission] 53505 → 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=85 TSecr=0
    8  42.020440 90.102.115.81 → 82.65.226.80 TCP 62 [TCP Retransmission] [TCP Port numbers reused] 443 → 53505 [SYN, ACK] Seq=3720531063 Ack=1 Win=16384 Len=0 MSS=1460

This capture does not make sense to me at all.

> It's out-of-window.  An RST is the correct response from a TCP spec
> point of view.  The firewalling you have enabled appears to disagree; I
> didn't design or write it, so I'm not comptent to speak to its choices.

I'm also largely incompetent to comment on this behaviour.  The fact
that it happens to works with other firewalls (e.g. OpenBSD pf) let me
think that something may be done to mitigate the issue. Wether it
would be a hack or an actual fix, I've no idea ...

> Well, don't forget that a "bare ack" is not the whole story.  A bare
> ack can be in-window or out-of-window, and I expect (but have not
> checked) that the behaviour prescribed by the TCP specs differ.

This diagram on page 11 seems to detail it (link from the TCP page in
Wikipedia), but I can't really figure out myself in what branch my
"bare ack" falls:
https://www.medianet.cs.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf

In any case, it seems to me that the ack is either "acceptable" or
triggers RST.

Also from RFC 793 (section 3.4 Establishing a connection):
  « If the connection is in any non-synchronized state (LISTEN,
    SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
    something not yet sent (the segment carries an unacceptable ACK),
    [...] a reset is sent. »