I work in an organization with (unnecessarily) stringent security requirements. Last year, we set up an SVN server on a cloud machine. The requirements for this machine dictated that the only approved method of access was two-factor authentication through an RSA token.

This meant that we could not use svn+ssh://, because developers would have to use their inconvenient RSA tokens for every single SVN action. But we could not naively use svn:// either, because (heaven forbid) people could access the data on the SVN server without using a two-factor token.

Eventually, we developed a complex system of port-forwarding. The server had a typical svnserve daemon process listening to connections on 3690, but the firewall blocked all connections to that port except from localhost. If the user is not on-center, they must VPN into the network first. The user would create an SSH tunnel to the server and forward port (say) 6789 to port 3690 (the SVN port) on the server (in other words, ssh user@server -L 6789:localhost:3690). As long as the SSH session remained open, the user could use regular svn URLs by referencing that port: e.g., svn://localhost:6789/path/to/repository/trunk.

This has worked for about a year, for both *nix systems and Windows (with PuTTY and TortoiseSVN). Now, we have an issue with a new team member who uses Windows/TortoiseSVN. She can VPN in and start the SSH session with port forwarding, but when she goes to actually check something out (see the example path above), she gets the following message: "Network connection closed unexpectedly." The PuTTY session does not display any error messages or end, so I'm not so sure it's the server's fault. And I have independently tested the ability of her machine to listen to itself over the 6789 port.

I am unsure what component in the system is at fault here: TortoiseSVN, PuTTY, her computer's firewall settings, her network's firewall settings, our server's firewall settings, or the svnserve process. I suspect its something about her firewall settings, because that's the only thing that she has differently than everybody else. But how could the firewall prevent traffic through an SSH port-forwarded tunnel? It should all appear to go through port 22, so it should go through if the SSH connection can be successfully established in the first place. I am stumped.


  1. Have any of you observed similar behavior with SVN over a tunnel or had a similar situation? If so, what was the cause of the problem and how was it resolved? (I am doubting there will be many people with similar problems, so the following are more general questions.)
  2. Is it possible for the firewall to be blocking traffic through an already-established SSH tunnel?
  3. If not, what component might be at fault?
  • I realize this is old, but did you ever solve this? I started having the same issue recently when using RDP and VNC through the tunnel. – Jesse Dec 19 '18 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.