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

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?

[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.

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: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)

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)