SSH forwarding Connection State

[Damien Miller]

On Mon, 21 Aug 2023, Jeremy Guthrie wrote:

> We have an issue where we’re using SuSE provided OpenSSH 8.4 and we
> have an application using Local Port Forwarding where TCP state does
> not appear to be working right.
>
> In our problem, we have a separate Linux box app server[192.168.0.10]
> using a TCP forward listening on another box[192.168.0.11],
> let’s say port 8000. That port 8000 forward is through another
> system(172.16.0.12) that goes to the actual forwarded host fo
> 172.16.0.13 on port 80. Hopefully that makes sense? :)
>
> The problem itself: 1. 172.16.0.13 sends a TCP RST to the 172.16.0.12
> for the forwarded connection. 2. The connection needing to be close
> appears to get to the 192.168.0.11 host (as we would expect) but
> it doesn’t send an RST, it sends an FIN to 192.168.0.10. 3. The
> 192.168.0.10 host sends and ACK but no FIN leaving the 192.168.0.11 in
> the FIN_WAIT2 state. Since SSH itself hasn’t closed, this connection
> stays in this state.
>
> We have the vendor of the software pushing back that because their
> 172.16.0.13 host sent an RST, SSH should as part of its forward also
> be sending an RST.
>
> Any thoughts on this behavior? This started a few months ago and we
> aren’t sure of the exact change that may have caused it to crop up.

SSH doesn't attempt to exactly mirror the TCP connection state-machine
but rather roughly approximate graceful half/full close semantics.
AFAIK the SSH channel protocol (RFC4254) offers no way to pass a RST
through a forwarding.

-d