sshnet / sshnet/SSH.NET

ForwardedPortRemote not closing the local TCP socket.

Open
#326 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
4.4k
Forks
993
Avg merge
9d 21h
Merged PRs (30d)
1

Description

I am using SSH.NET to create a reverse tunnel to a Linux server so that I am able to connect to a VNC server behind a NAT. There is also a monitoring program running that checks whether someone is actually connected to the VNC server. This is checked using the following piece of code:

int clients = IPGlobalProperties
    .GetIPGlobalProperties()
    .GetActiveTcpConnections()
    .Where((c) => c.LocalEndPoint.Port == monitorPort)
    .Count();

(monitorPort is 5900, so the port VNC server is listening on)

Using our old reverse tunneling system, this worked fine. But with SSH.NET the amount of clients never decrease. It seems that SSH.NET keeps the socket to the VNC server open forever.

  • I can clearly see that when I connect to the VNC server through the tunnel, the amount of clients goes to 1, but when I disconnect the VNC client it never goes back to 0.
  • When I connect directly to the VNC server (over LAN, not through the tunnel) the amount of clients does immediately go back to 0 after disconnecting.
  • And when I use Plink for the reverse tunnel, the socket also closes immediately after a disconnect from the VNC client.

So I would say that this is a bug in SSH.NET right? The expected behavior would be that the socket closes immediately after the client disconnects.

If you need more info, please let me know. Will have a look at the source code myself tomorrow.
Kind regards,
LJ

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the ForwardedPortRemote implementation and reproduce the reverse-tunnel VNC disconnect described in the issue. Trace the local TCP socket lifecycle when the VNC client disconnects; done means the connection count returns to zero promptly, matching direct connections and Plink.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
40/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.