TCP FIN Packets Missing While Using tsh ssh -L
#3749
Comments
awly
pushed a commit
that referenced
this issue
Jun 4, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
awly
pushed a commit
that referenced
this issue
Jun 11, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
|
Still need to backport to 4.3 branch. |
awly
pushed a commit
that referenced
this issue
Jun 15, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
awly
pushed a commit
that referenced
this issue
Jun 17, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
awly
pushed a commit
that referenced
this issue
Jun 24, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
awly
pushed a commit
that referenced
this issue
Jun 25, 2020
When a client terminates, it should propagate over to the server on remote host without it attempting to write. The defered cleanup wasn't closing all the right connections to make this happen. When a server terminates, re-execed teleport might not notice until client sends new data. Re-execed teleport should exit on first observed error in either direction and not wait for both ends. Fixes #3749
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
What happened:
When using
tsh ssh -L <local_port>:localhost:<remote_port> <user>@remote_server, it seems that tcp fin packets are sent from client to the local port, but are not transmitted to the remote port on the remote server.What you expected to happen:
tcp fin packets should be transmitted, so the remote server properly closes the connection.
How to reproduce it (as minimally and precisely as possible):
On a Teleport node, connected to a Teleport cluster, run server.py.
On the client side, create a client.py.
On the client side, run
tsh ssh -d -L 65432:localhost:65432 root@<remote_host>and now executeclient.pyObserve that the server.py process did not terminate. The socket is still open waiting for fin packet.
Remove Teleport from the equation... scp client.py to the remote machine. Run server.py and client.py and observe that server.py terminates properly.
Environment
Teleport version (use
teleport version): v4.2.9Tsh version (use
tsh version): v3.2.14OS (e.g. from
/etc/os-release): Client - Ubuntu 18.04, Server - Ubuntu 16.04.6Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware): GCP
Relevant Debug Logs If Applicable
tcpdump: https://gist.github.com/travelton/39b216602a34bf1229cad2b43d3272d3
The text was updated successfully, but these errors were encountered: