11

I have an unreliable network connection between two machines: sometimes active TCP connections get dropped for reasons beyond my control. I want to establish a reliable TCP connection between the two machines.

If the network was reliable, I'd just run ssh -L 1234:localhost:1234 remotehost, with the server listening on port 1234 on remotehost, and point the client at localhost:1234. But if the ssh connection dies, so will the forwarded connection. How can I arrange to automatically restore the connection between the client and the server?

Non-solutions:

  • This isn't for interactive applications, so screen does not apply.
  • This isn't just about reconnecting an SSH tunnel automatically, � la autossh. I want to continue using the same tunneled TCP connection, not start a new one.
  • In principle, a VPN would do the trick. But it seems overkill when I just want one TCP connection, and I'd like a solution that works even if I don't have root permissions on either side.

I have a dim memory of a program called rocks that did just that, but it seems to have fallen off the face of the web. I'm mostly interested in Linux on both sides (though I'd expect a program at this level to be portable to other unices), but if you know of a program that works between QNX and VMS, all the better.

Improve this question
5
  • Gilles, are you using tcp keepalives with your ssh connections? If not, try this first... some NAT implementations time connections out quickly Commented May 30, 2011 at 23:12
  • @Mike: Thanks for the tip. I don't have an immediate need, but I've faced both situations where some intermediate route came and went (so TCP keepalives did more harm than good) and situations where a NAT overloaded and dropped me (so TCP keepalives might help). TCP keepalives wouldn't matter for a continuous stream anyway (e.g. scp), would they? In any case I'd like to keep this general: next time I'm faced with a flaky network of whatever flavor, what can I do? Commented May 30, 2011 at 23:19
  • Gilles, the solutions are different for constant streams like scp. I was responding w/ ssh keepalives based on your port-forwarding example. Re: flaky downstream hop, there isn't much you can do, other than create an ssh session with keepalives that are more tolerant (i.e. allow more dropped keepalives with ServerAliveInterval > 0 and ServerAliveCountMax > 3). NAT requires lower keepalives intervals. The key issue is to identify what the problem is and tailor accordingly. Put the options in .ssh/config so they are always there for you Commented May 30, 2011 at 23:26
  • @Mike: One of my use cases includes the client getting its IP from an overloaded NAT than randomly drops even active connections (think more P2P than there should be). After a few seconds, the client manages to reconnect but might get a different IP address. There's no way the TCP connection will survive in that case. Rocks copes, but I'd prefer something that compiles out of the box on today's systems. Commented May 30, 2011 at 23:31
  • in the case of the NAT giving you new IPs, there isn't much you can do than get the NAT fixed or hope for another rocks implementation... although this is obviously a real kludge Commented May 30, 2011 at 23:36

4 Answers 4

Reset to default
6
+50

Is the old an unmaintained Reliable Sockets (Rocks) what you're looking for ?

Improve this answer
3
  • 1
    Thank you, Rocks is indeed what I remembered. Of course I'd prefer something that's maintained. Commented May 30, 2011 at 20:47
  • @Gilles'SO-stopbeingevil' Not only is it unmaintaned, but it seems to have dropped off the face of the internet completely! Commented Apr 16, 2020 at 4:57
  • @Michael: There's a link on FSF's website that points to a, currently, functioning ftp server Commented Mar 15, 2021 at 11:18
2

The only standard protocol I know of with this capability is MPTCP. It is transparent to the application layer, so SSH on top of MPTCP should just work. It can run the underlying TCP connections over different paths with different IPs, so in principle it could be used to migrate your SSH connection in and out of the VPN connection depending on whether the VPN connection is up.

I don't know much about the maturity of MPTCP implementations, but the design of the protocol looks quite robust.

It should protect your SSH connections from getting lost due to flaky network connectivity. It won't protect you against a mitm who wants to break your SSH connection. A mitm can still inject corrupted data, which SSH will detect and break the connection.

An MPTCP like reconnect method build into the SSH protocol would be the method I could imagine keeping a connection alive for the longest possible time. But I don't think such a feature has been designed for the SSH protocol.

Improve this answer
0

You could use daemontools to keep the ssh port forward up; it won't necessarily keep programs depending on the connection alive while it's down (as presumably when ssh disconnects the local port will start refusing their connections), but it's a start.

I suspect there are some iptables tricks, like causing that port to DROP packets as soon as the ssh forward goes away, so the connecting programs just know that packets are disappearing, not being refused. I'm just learning daemontools myself (again) so I'm not sure if you can run a custom script when a service dies, but I suspect you can.

Improve this answer
-2

TCP does this automatically. You need only disable or weaken the typical practical cleanup hacks used to kill moribund TCP connections. Disable TCP keepalive for your connection, and greatly increase the limit for excessive retransmissions. On Linux, for example, write a large number into /proc/sys/net/ipv4/tcp_retries2.

However, in a modern network a stateful packet inspection firewall is likely to forget about a TCP connection which fails to exchange packets regularly, so it may rain on your parade.

Improve this answer
3
  • 2
    It is true that TCP can handle the situation, as long as each endpoint has a static IP address and there are no stateful middleboxes. The question mentions reasons beyond my control, which I read as dynamic IP or stateful middleboxes. In such scenarios TCP keepalive can help a little bit. But no matter how you configure TCP keepalive, it won't be enough to keep the connection alive when a middlebox lose state due to being restarted. Commented Aug 16, 2014 at 12:52
  • @kasperd I agree. However, it's futile to try to keep a TCP connection open in those cases. Therefore, I assumed the questioner is not facing those particular challenges. Commented Aug 16, 2014 at 14:34
  • 1
    It is not futile if you control both endpoints and can upgrade them to a stack with MPTCP support. Additionally an application layer solution could be implemented on top of TCP without needing MPTCP. Commented Aug 16, 2014 at 14:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.