Link to home
Start Free TrialLog in
Avatar of dportabella
dportabella

asked on

how to create a tcp tunnel with "transparent reconnection"

ssh -f -N -L 2222:myremotemachine.com:3333 myremotemachine.com
Specifies that port 2222 on the local (client) host is to be forwarded to myremotemachine.com:3333.
This works by allocating a socket to listen to port 2222 on the local side. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to myremotemachine.com:3333 from myremotemachine.com.

This works pretty well.

However, my client machine is inside a firewall that closes all connections after two hours. This is a hard constraint and it cannot be changed, and sending keep alive messages or anything else does not help.


the question is:
is there an equivalent to this: ssh -f -N -L 2222:myremotemachine.com:3333 myremotemachine.com
with the option of "transparently reconnecting" whenever the tunnel connection is broken?

by "transparently reconnecting" I mean that when the tunnel connection is broken,
the connection of the local application to localhost:2222 is not closed, nor is the connection from myremotemachine.com to myremotemachine.com:3333,
so that the application does not even notice that the tunnel connection was broken.

ps: is this a standard feature? does it have a proper name?
pss: i would prefer to install a standalone light software to both machine for this,
instead of complex and heavy solutions as installing a real vpn.
psss: one computer is running osx and the other is running mswindows with cygwin and open ssh server.

Regards,
DAvid
Avatar of Rowley
Rowley
Flag of United Kingdom of Great Britain and Northern Ireland image

Take a look at http://www.harding.motd.ca/autossh/ or http://sourceforge.net/projects/rstunnel/ . I imagine using either of these solutions, you are trusting the application to retransmit unless its UDP based.

To get some kind of transparency, you'd need the connection to be handled at the IP layer, separate from the application itself. Something like a VPN.

hth.
Avatar of dportabella
dportabella

ASKER

autossh and rstunnel are not useful in this case.
that is, if the tunnel connection is broken (even if the tunnel will reconnect),
the connection from the local application to localhost:2222 will be closed. (and the connection from myremotemachine.com to myremotemachine.com:3333 will also be closed).


>To get some kind of transparency, you'd need the connection to be handled at the IP layer,
Yes, in the general case.
However, I do not agree with your conclusion for the concrete case I am talking about.


Regards,
DAvid
Disagree all you like, I think you're asking for something that isn't possible the way you want it. I hope for your sake I'm proved incorrect. I'll watch this space...
You can tunnel (ppp or tcp) over http like htc/hts does on Linux.
OpenVPN and most other IPSEC VPN's can be made to "redial" on disconnect
gheist,
htc/hts creates a tunnel, in the same way as the ssh example, through http instead of ssh.
ssh -f -N -L 2222:myremotemachine.com:3333 myremotemachine.com

that's ok.
however, the problem is still the same:
if the http tunnel connection is broken (even if the tunnel will reconnect),
the connection from the local application to localhost:2222 will be closed. (and the connection from myremotemachine.com to myremotemachine.com:3333 will also be closed).


What I am asking is a software that when the tunnel connection is broken,
the connection of the local application to localhost:2222 is not closed, nor is the connection from myremotemachine.com to myremotemachine.com:3333,
so that the application does not even notice that the tunnel connection was broken.


Regards,
DAvid
ASKER CERTIFIED SOLUTION
Avatar of gheist
gheist
Flag of Belgium image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
hello gheist,

you are right, htc/hts seems a very good solution for my task,
without the need of handling the connection at the IP layer.

Thanks,
DAvid