Permanent or automated SSH tunnel--possible?

[Galen Tackett]

We have three networks which for simplicity I'll call NetA, NetB, and NetC. There are router connections between NetA and NetB and between NetB and NetC, but not directly from NetA to NetC. On each of these is a host (HostA, HostB, HostC) running TCP/IP Services V5.4 or later, with SSH enable.

I've just figured out how to use SSH to tunnel Telnet between HostA and HostC through HostB.

Every time I want to do this, though, I have to first log in to HostB using a command like
(1) HostA$ ssh HostB -"L" 20023:HostC:23
to establish the tunnel. Then I can do
(2) HostA$ ssh localhost 20023
to log in to HostC from HostA.

Ideally I'd like for anyone on NetA to be able to telnet to HostC via an ssh tunnel through HostB. This is a small user community, only about 5-10 people, each with his own Alpha VMS workstation on NetA; both HostB and HostC are rx1620's with lots of extra resources, so I'm not terribly concerned about load on either of these.

Is there some way a more permanent tunnel can be established, or that (1) can be automated so the user doesn't have to issue this command manually every time he logs in? Having to enter a password for HostB complicates this.

Another issue that's peripherally related is how to get the best performance out of limited bandwidth. The links to NetB from both NetA and NetC run over quite slow connections, on the order of 56Kb/sec each. This of course makes for some noticeable pauses in I/O when you have to traverse both links to get from NetA to NetC.

The best solution, of course, would be a direct connection between NetA and NetC, or minus that possibility, a much higher speed over the existing links. Doing either involves politics between us and our USGov customers that is so far removed from me that the folks involved have no idea of the existence of such a lowly and rare creature as our single project's VMS system manager.

I'd like to hear any help or commentary on either of these areas.

Thanks,

Galen

[Robert Gezelter · Accepted solution]

Galen,

I am in the middle of working on something, but have you considered using stunnel directly?

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

You're establishing a gateway to get through to your target network. (Are these all private-address LANs?)

A reasonable firewall can provide VPN and sometimes VLAN services such as this, as can configurations built on various of the firewalls. (OpenVMS trails other OS options here, with limited VPN integration and no in-built firewall.) For some of the other out-board options here, see m0n0wall, smoothwall, dd-wrt and various mid-grade firewalls.

See what firewalls you have installed here (as most folks have firewalls), and see if the combination already in use can solve this matter for you.

As for speed, if you can't up the pipeline, you have to compress the data (if feasible) or reduce the load.

[Steven Schweda]

> [...] here are router connections between
> NetA and NetB and between NetB and NetC,
> but not directly from NetA to NetC. [...]

I assume that I'm missing something obvious,
but why not add a route to NetC (gateway =
RouterBC) on the systems on NetA? If the
systems on NetA can talk to systems on NetB,
then they should be able to talk to RouterBC,
and if they only knew that that was how to
get to NetC, then they should be able to do
so with no extra fooling around.

So, what am I missing?

[Galen Tackett]

Bob said,
> have you considered using stunnel directly?

Hoff said,
> See what firewalls you have installed here (as most folks have firewalls),
> and see if the combination already in use can solve this matter for you.


Steven said,
> I assume that I'm missing something obvious, but why not add
> a route to NetC (gateway = RouterBC) on the systems on NetA?

The govt. actually requires us to have ssh on our IP hosts. stunnel might be workable though open source means a harder sell. (Not needed for ssh since they require us to have it.) I also need to read up on stunnel, since I know nothing about it right now.

It's all bureaucracy and money--remember who the customer is.

If you aren't allergic to bureaucracy and want a more complete picture, read on. Otherwise you may wish to stop reading here. :-)

All the network infrastructure is govt. owned, though we operate the portion within our own facility.

Govt. security has to approve any network connections we make, even in our own facility; multipe customer security offices are probably involved; lots of paperwork, preceded by lots of oral discussion, is _definitely_ involved. Even getting them interested in listening isn't always easy.

New approvals would be required whether we used an existing firewall or added a routing entry on HostB. Adding a _new_ firewall would be even more difficult since customer money would also be involved.

Host B is about 20 miles away in a govt. facility. Hosts A and C are in our facility. Though we administer all three, we have considerably less flexibility with B.

[Steven Schweda]

> [...] we have considerably less flexibility
> with B.

So, what's the problem with "TCPIP route add"
on NetA hosts?

> So, what am I missing?

[Galen Tackett]

> So, what's the problem with "TCPIP route add"
on NetA hosts?

I've tried just this but forgot to mention it.

With such a routing entry on NetA, traceroutes from NetA to NetC look like a firewall is blocking them somewhere in the govt. infrastructure in between, but I don't know for certain. That part of it is just a big cloud to me, unfortunately.

[Steven Schweda]

> I've tried just this but forgot to mention it.

Lacking any details, I might guess that you'd
also need to do something similar on the NetC
hosts, adding a route through RouterAB to
NetA. That is, it might help if the guys at
the far end knew how to get a reply back to
the guys at the near end, too.

[Richard Whalen]

You could eliminate the need to enter a password for HostB by setting up public key authentication between HostA and HostB. This doesn't automate or make permanent the tunnel, but does make setting it up a bit easier.

[Galen Tackett]

I now have stunnel working for telnet connections between A and C by way of B.

I tried out the option to use rle compression and for normal interactive use it seemed faster.

I wanted to try zlib compression too but ssl has to be rebuilt to support zlib. I'm going to look into that. Any tips will be welcome.

Thanks, Bob, for mentioning stunnel.

In our environment we really don't need all the strong encryption that you get with stunnel (by way of ssl), but at least it solves the problem of getting from A to C.

Now, since ftp won't work through stunnel I'm going to be looking for a way to do ftp's as well.

Thanks for everyone's input. This topic is almost to the point where I can close it, at which time I will assign points too.

[Robert Gezelter]

Galen,

Re: Your last posting.

C-Kermit (http://www.columbia.edu/kermit ) provides KERMIT protocol file transfers and you can use the TELNET protocol within the stunnel context.

- Bob Gezelter, http://www.rlgsc.com

[Joseph Huber_1]

>> Now, since ftp won't work through stunnel I'm going to be looking for a way to do ftp's as well.

This Your conclusion astonishes me:
why does ftp not work through stunnel ?
Although I don't need it on a regular basis, I have setup stunnel for ftp, and it worked well.
As far I remember, the only requirement was support of PASV on both, the client and server side.
And as far I see, stunnel is the only option which can be automated in the sense, that one can establish the stunnel ftp port at system startup, and afterwards it can be used (almost) transparently, only the clients port number has to be changed from the default.

[Steven Schweda]

I'm a bit dense, so don't mind me, but I'm
still wondering why adding a couple of routes
on the accessible systems at both ends (A, C)
doesn't solve the whole problem.

[Galen Tackett]

Steve,

It would definitely solve the problem if I were allowed to do it.

It's silly, I know, but I can get it past the authorities easier with a tunnel than with a route.

Essentially, there's an understanding that we monkey with TCP/IP routes on the Bnet hosts except to fix customer problems. The difficulty for a couple of our developers to reach C from A is not a problem that's even on this customer's radar.

Using stunnel doesn't constitute adding a TCP/IP route, so it wouldn't be a violation of this understanding.

SOME of the 3-4 developers have a direct connection to Cnet in their offices; but I don't and there aren't any more drops available to Cnet here. (In addition to development work, I'm also the system manager for the A and C systems, and sort of co-manager for B.)

If you're really interested in the minutiae I could go on and on. But if I say too much someone might come around and terminate us both with extreme prejudice. :-)

[Steven Schweda]

My point was that it seemed to me that one
could get the desired effect by adding routes
on only the NetA and NetC systems, not on the
NetB systems (which already seem to be able
to find the NetA and NetC systems).

But if you're happy, ...

[Galen Tackett]

Joseph,

> This Your conclusion astonishes me:
> why does ftp not work through stunnel ?

I believe I've read that stunnel will handle command connection of an ftp session but not the data connection. This appears to be borne out by the error I get.

I've set up stunnel_client.conf on my HostA to accept an ftp connection on port 921, "forwarding" to 921 on HostB. HostB's stunnel_server.conf is set to accept a connection on port 921, "forwarding" to port 21 on HostC.

ftp localhost 921
220 HostC FTP Server (Version 5.6) Ready
FTP> passive on
Passive is ON.
dir
227 Entering Passive Mode (nn,nn,nn,nn,203,26)
%TCPIP-E-FTP_DATACONF, cannot establish data connection with remote host
-SYSTEM-F-REJECT, connect to network opject rejected

Maybe I'm missing a bit of setup somewhere?

[Galen Tackett]

Oops. I forgot to mention that nn,nn,nn,nn was meant to represent the IP address of HostC as displayed by FTP.