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. -- Jeremy Guthrie Sr Technical Architect - DevOps, Automation & Orchestration 5525 Nobel Dr Suite 200 | Fitchburg, WI 53711 Time Zone: US-Central Phone: 608.298.1061 ECC: 888.793.2480 or 608.288.4000
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