Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non graceful closing of remote connection #535

Open
liojacqs opened this issue Oct 22, 2024 · 2 comments
Open

Non graceful closing of remote connection #535

liojacqs opened this issue Oct 22, 2024 · 2 comments

Comments

@liojacqs
Copy link

(Note: not tried on a non-reverse scenario, but most probably the same)

In a reverse port forwarding scenario like:
R:localhost:9221:remote:9100/tcp
We are having an issue with a server which:

  • may try to return data on the connection after the client has requested the TCP connection to end (FIN packet), before sending its own FIN packet.
  • will get in a bad state when it can't...
    Unfortunately we don't have control on this server, but it has the merit to point out some possible improvement.

When using netcat to send a file to remote:9100 directly, like this:
nc -N remote 9100 < file
Then netcat is sending the FIN packet right after finishing to send the file.
But the connection does not drop instantly, as netcat is waiting for the remote end FIN packet, which is actually sent AFTER the remote has sent some data.
In this scenario the output looks like:

$ nc -v -N 10.12.14.16 9100 < file
Connection to 10.12.14.16 9100 port [tcp/*] succeeded!
0123456
$

And as the server was able to send back data, it's fine.

Doing the same thing through chisel, the output looks like:

$ nc -v -N localhost 9221 < file
Connection to localhost 9221 port [tcp/*] succeeded!
$

Feedback from the remote end is lost, and the server needs some manual operation because it's probably badly written, or didn't appreciate being censored...

What's happeining is the connection is closed directly on the input proxy side, which has no clue about how the remote end would behave, leaving no chance for the remote to delay it a little bit like in a direct TCP connection.

I don't know about the feasibility of this, but it would be nice, when a local or remote end is requesting to close the connection, not to close the connection on this side, but gracefully on the other side of the tunnel first, then only on the requesting side.

That way we would have no issue with such faulty servers...

@liojacqs
Copy link
Author

Issue can be reproduced with the attached code as remote end, and netcat:

  • Linux: nc -v -N listenIP listenPort < someFile
  • MacOS: nc -v listenIP listenPort < someFile

fake_server.go.zip

@liojacqs
Copy link
Author

liojacqs commented Nov 4, 2024

Fixed in PR #536.

@liojacqs liojacqs changed the title Non graceful closing of remote connection (reverse port forwarding) Non graceful closing of remote connection Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@liojacqs and others