OpenSSH Patch Extends Tunneling Under OpenBSD

Jonatan Wallmander writes "We've written a small howto as well as produced a simple patch for OpenSSH that improves tunneling functionality in the ssh client on the OpenBSD platform (this should be OK on other platforms with some tweaking). It's a simple hack but works very good for us. We can have different IPs on the same BSD machine tunnel different hosts ... Without the patch you can only have one tunnel per BSD machine since it listens on INADDR_ANY.. Now all my computers on the LAN can access remote servers securely as if they were in the same room provided by a single BSD server. :)"

Comments

Balance of Perf and Ease?

[4of12]

I got educated on an earlier Slashdot story of how (a) how nice and easy it was to set up an encrypted tunnel using ssh instead of IPSec or a weird proprietary VPN product, (b) how TCP over TCP is a fundamentally bad idea and people were compensating by periodically restarting the tunnel service afresh to work around it.

How's the performance of this setup and does it address any of those problems?

Re:Balance of Perf and Ease?

[evilviper]

TCP over TCP a problem? I think not. You are probably thinking about OTHER things over TCP. UDP tunneling can have it's problems when there is a bandwidth crunch on the TCP connection.

TCP over TCP is just as good as regular TCP, even if it's a bit slower due to encryption (but compression makes it up to some extent).

Re:Balance of Perf and Ease?

[QuMa]

Depends on where the endpoints are. If you're generating the packets and stuffing them into a tcp tunnel on the same host you're fine. If your packets get out of order/dropped/whatever before they enter the tunnel you're still screwed though.

Re:Balance of Perf and Ease?

[Anonymous Coward]

ARG! All the replies to this post so far are so wrong that it's hurting my brain.

1. yes "TCP over TCP" is a bad effect. This is what happens when you tunnel an unreliable protocol (like IP encapsulated in PPP) over a reliable protocol (like TCP with something like SSH or SSL on top) The problem is that packet loss ends up causing retransmits both from the encapsulated TCP sessions and from the SSH/SSL layer on top. So you end up with a situation where it works perfectly when you're getting near zero packet loss, but as soon as there's even a moderate amount of packet loss the entire connection falls apart. Often the only way to recover from this is to restart the tunnel.

2. However, THIS ARTICLE ISN'T ABOUT THAT. It's using ssh'd builtin TCP forwarding to tunnel the data. So instead of "TCP-over-TCP" it's "TCP-to-TCP-to-TCP". At to point in the connection are there two TCP state machines both competing to retransmit. I'm sorry if this doesn't make much sense in text - I really need a whiteboard to explain it properly.

The short version is that the "TCP-over-TCP" problem is basically confined to schemes where they try to tunnel a PPP session over SSH (in order to get a full VPN). Just using SSH's port forwarding is _fine_.

Re:Balance of Perf and Ease?

[mindstrm]

No.. the reason tcp over tcp has issues is because you end up with both tcp layers trying to backoff and deal with congestion and retransmits rather than one, and things can happen such that the two layers start interfering with each other rather than helping. (one layer transmits, then another does, causing even more extra packets, etc)

Of VPN's and Legalities...

[bonsai_kitty]

This is an excelent idea and better yet sounds like it will work to bridge the OS gap. But is this considered a VPN? And if so should I be concerned about "The Long Arm" if I attempt it with a node in a state that prohibates such.

Null encryption?

[Euphonious Coward]

This is slightly off-topic...

The OpenSSH sources list a "null" cipher, but I have had no success in establishing a connection using it. Is there a trick to it, or do I need to patch the sources to get a connection that sends in plaintext?

(Why? The traffic is already encrypted via IPSEC; I just want to use SSH's cool port-forwarding apparatus and its authentication, and don't want to pay for for encrypting twice.)

Re:Null encryption?

[sedawkgrep]

While I haven't done this in YEARS, I think you need to add a Ciphers line to /etc/ssh/sshd_config that contains 'none'. Be sure to include all the ciphers you may want to use because this list is exclusionary.

Otherwise, you can always use blowfish, rc4, or even AES (I think...) as they are all *MUCH* faster than 3des.

sedawkgrep

Re:Null encryption?

[Deagol]

Holy crap... I didn't realize that openssh defaulted to 3des (at least in Redhat RPMs). I forced both my server and clients to use blowfish and the interactive lag over my 33.6 modem connection dropped considderably.

Thanks for the tip. You learn something every day on this board!

Re:Null encryption?

[Euphonious Coward]

Thanks, I had tried that. I have a Ciphers line in my /etc/ssh/sshd_config already, so it will default to aes128-cbc, fall back to blowfish-cbc, and finally 3des-cbc. When I add "none" or "null", sshd complains when it reads the file: Bad SSH2 cipher spec.

I wonder if a plaintext cipher would compromise authentication. (Not that it matters in this case.)

Re:Null encryption?

[Euphonious Coward]

Thanks, I guess I should have googled for it myself.

Re:Null encryption?

[evilviper]

Possibly, but you'd better make a checksum on the source, and verify it at the destination. Encryption (even if you only use 40-bit rc4, or something equally weak) allows the client and server to verify the data is not corrupted, as well as preventing casual evesdroping...

I would sugest you look into using some weaker encryption modes, rather than none at all. If CPU power is an issue, crypto accelerators seriously improve performance, and can often be very cheap.

Small error in the examples...

[Gruturo]

I don't wish to be pedantic, and it doesn't compromise the understandability of the article, but in the drawing under chapter 3 (The basic solution), the "brown" OpenBSD file server is available to the Windows PC as .200, and NOT .5 as suggested.
The green OpenBSD box just does a simple port forwarding (from its own 139 to port 139 on 127.0.0.1 seen from the other endpoint's perspective) and makes it available non-loopback-only via the "-g" option (which btw won't work if you don't have "GatewayPorts yes" in your sshd_config file, and the last time I checked this was not exactly well documented). Therefore, 192.168.0.200:139 (actually 0.0.0.0:139, esp. without this patch :-) ) gets mapped to 127.0.0.1:139 (but on the OTHER end of the tunnel - thus the brown box).

The next example is correct (and shows the use of the patch).

Just my 0.02

TCP over TCP OK

[bill_mcgonigle]

TCP over TCP is a fundamentally bad idea

There may be some theoretical basis to this mantra, but in the real world it doesn't apply. I develop a product that uses TCP/TCP communications and it transfers hundreds of gigs a week from dozens of sites without any performance problems.

I think the way the real world works around the theoretical problems is that it's not really possible to maintain a TCP connection on the 'net for a long period of time unless you control the entire path. In my case, customer sites are always rebooting their routers, NAT boxes, etc. and connections rarely last longer than a day, often only several hours.

Fortunately, Unix has nice mechanisms for keeping things up, i.e. inittab.

Re:TCP over TCP OK

[sporty]

I wouldn't be surprised if you saw like, a 1% increase if you used straight tcp/ip.

tcp over tcp incures an x% size of packet increase. Reminds me of that stupid commerial. "We saved a nickel for a transaction" The go on and on about this stupid nickel and then they talk about how they do "20 million in transactions a day."

But hey, if you have the bandwidth, knock yourself out. :) If it works, it works.

Obvious

[mindstrm]

Protocol overhead is obvious.. the real issue that people talk about is to do with how TCP deals with congestion... you end up with 2 layers of protocol trying to deal with a problem when only one needs to.. leading to some interesting issues... (things can theoretically get really slow)