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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
