Slashdot Mirror

A MPTCP VPN would not work in the real world. When you tunnel TCP through it, you end out having to send ACKs for the ACKs. The end result is that the effects of even a tiny bit of packet loss is a performance meltdown: http://sites.inka.de/~W1011/de... To build Speedify, we needed to implement a new multipath protocol over UDP. But that let us do clever stuff with NACKing and retransmitting lost packets before TCP ever noticed, and we were actually able to reduce the effect of loss: http://speedify.com/blog/speed...

As much as I like SSH (it's probably my most used tool), an IPSEC based VPN should give better performance. Have a look at http://sites.inka.de/bigred/devel/tcp-tcp.html/ for a brief explanation of the problems with tunnelling TCP over TCP.

My favourite SSH trick is using SSHFS along with AUTOFS to automagically connect to other servers' filesystems. Again, not the best performance, but as long as the server is running an SSH daemon, you're good to go.

That's a good thought, but the problem is that tunneling TCP over TCP (such as HTTP over SSH) is subject to the TCP retransmission cascading effect, a.k.a. TCP-over-TCP meltdown, which is particularly likely to be a problem for him given the kind of Internet connections he may be stuck with on his travels.

It would be better to tunnel over a protocol that does not attempt to ensure reliable transport, such as UDP or pure IPsec. So I agree with you that he should find some inexpensive, reputable host to use as his endpoint, but I recommend that he use OpenVPN over UDP rather than SSH over TCP for his tunnel. OpenVPN is easy to set up, penetrates NATs well, and will be compatible with pretty much any inexpensive VPS provider (but be sure to check with potential hosts' terms of services first to make sure they're OK with tunneling your personal web browsing traffic through their servers).

Why TCP over TCP is a bad idea

That way lies madness...

I'm curious if you ever have problems like this:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

Essentially transporting TCP over TCP has serious timeout problems... a small glitch in the outer TCP can cause major hiccups on the inner TCP.

Kirby

I fear if they are, Charlie Pelligrino might have been right in The Killing Star http://sites.inka.de/mips/reviews/TheKillingStar.html

that is:Paraphrased from the book:

1. Any species will place its own survival before that of a different species.
2. Any species that has made it to the top on its planet of origin will be intelligent, alert, aggressive, and ruthless when necessary.
3. They will assume that the first two rules apply to us.

Add to this the facts of relativistic bombardment. A missile approaching at a speed close to that of light is hard to detect, leaves very little time to react, is next to impossible to intercept, and is utterly devastating on impact. In short, once a civilization has achieved the technological level necessary for relativistic bombardment it can erase a neighboring civilization in a single strike.

This book scared the hell out of me. And from such a neat, amusing fellow.

Well, I see it as the original article poster plagarizing a review from 11 years ago.

http://sites.inka.de/mips/reviews/TheKillingStar.html

"The Killing Star is one of the most terrifying books I have read in a long time. It paints a frightening picture of civilizations exterminating their interstellar neighbors, not from malice, but simply because it is the most logical action. A universe, where successful genocide is the norm, the "right" way. The novel illustrates its premise in frightening ways."

That's the first result I found searching for "The Killing Star". Is this guy so stupid he doesn't think people know how to use the same search engine he used?

I really like OpenVPN. It works as a client or a server on Windows, Linux, FreeBSD, Mac OS X, and other operating systems, and it is pretty easy to install, configure, and run. I just followed the how-to. It operates over UDP or TCP, you can tunnel it through HTTP or SOCKS proxies, and the server can use any cipher or hash available in the OpenSSL library. PPTP is ubiquitous, but it has serious flaws. IPSEC is supposed to be standard, but interoperability is a configuration nightmare (especially if you try to do something complex, like use X.509 certificates, or something non-standard, like authenticate users against RADIUS). Firewall/NAT traversal can present serious challenges in some cases as well, as some firewalls can't handle non-TCP/UDP protocols. CIPE requires special support in the operating system kernel and only works on Linux and Windows, and tunneling TCP over TCP (when running PPP over SSH) is a really bad idea.

I'm using OpenVPN to tie routers running OpenWRT (Linux), routers running FreeBSD, and workstations/laptops running Windows, FreeBSD, and Mac OS X together. It works flawlessly.

I really like OpenVPN. It works as a client or a server on Windows, Linux, FreeBSD, Mac OS X, and other operating systems, and it is pretty easy to install, configure, and run. I just followed the how-to. It operates over UDP or TCP, you can tunnel it through HTTP or SOCKS proxies, and the server can use any cipher or hash available in the OpenSSL library. PPTP is ubiquitous, but it has serious flaws. IPSEC is supposed to be standard, but interoperability is a configuration nightmare (especially if you try to do something complex, like use X.509 certificates, or something non-standard, like authenticate users against RADIUS). Firewall/NAT traversal can present serious challenges in some cases as well, as some firewalls can't handle non-TCP/UDP protocols. CIPE requires special support in the operating system kernel and only works on Linux and Windows, and tunneling TCP over TCP (when running PPP over SSH) is a really bad idea.

I'm using OpenVPN to tie routers running OpenWRT (Linux), routers running FreeBSD, and workstations/laptops running Windows, FreeBSD, and Mac OS X together. It works flawlessly.

Sun did indeed release an i386 based box, the Sun 386i. After they realized what a piece of shit x86 was the project was discontinued and they went SPARC only.

I work in a large telco who's security policy is to restrict everything unless explicitly allowed, and the process to get anything allowed is a 3 month long waste of time.

I also have an ssh tunnel established from my work PC to my home connection, and I run pppd over that to create a VPN between my home network and the network at work. I realise that this is probably completely against company policy, but the "official" VPN solution only lets me hit the Exchange server, and doesn't let me actually do any work. Most of the company's "work" involves forwarding emails, so it's probably fine for them.

Unfortunately tcp over tcp is really quite nasty (http://sites.inka.de/sites/bigred/devel/tcp-tcp.h tml) but as nothing else but ssh is allowed out of the firewall at work, I don't have a lot of choice.

A howto that I found quite helpful is at http://www.tldp.org/HOWTO/ppp-ssh/

Anyway.. on to my anecdote (not required reading):

Part of my job involves working on a distributed monitoring system which is deployed in a star topography around the country. All the remote sites send & receive data from one central site (with one redundant central site) using a variety of protocols, like ssh, xmlrpc, dns, telnet, snmp, syslog, etc.

The network was designed by people who were given a set of instructions like "You will use these 2 vendor's systems" and "You must follow these corporate security policies which were written 10 years ago for phone networks", so it's terrible by today's standards (and for an ISP in general).

There are firewalls between all of my boxes, even though all my boxes are on the management lan, and they only allow a very small set of protocols through - not enough to let my software work. That wasn't the worst part. The worst was that the firewalls are also protecting the billing network so have very low tolerances for intrusion detection and flood protection and such. Basically I can only establish 5 connections per second *across the entire network*. This is clearly not enough for a busy monitoring system. So we decided to build a VPN between all of my boxes using ppp on ssh tunnels.

I now have a separate ppp interface from the central server to each of the remote datacenter servers, all on the 10.0.0.0/16 network. ip forwarding is enabled on the central site, so now remote datacenters can talk to each other (also blocked by the firewalls) and I can use all the connections I need to. I'm running quagga ( http://www.quagga.net/ ) on every remote datacenter and the central servers (along with the redundant one) so I can distribute routes to remote datacenter devices and cope with the death of one of the central servers without major service interruption.

However it really is quite slow. I can only get around 200kb/s over each ppp interface even though the physical links are 100+mbit each. But I really don't need huge bandwidth, just some that isn't firewalled.

This "solution" has been in production for 6 months now, and I'm sure as soon as the corporate security people find out they will shut it down and I'll go back to not being able to do my job.

I haven't used GPGrelay myself but it looks very promising. It intercepts POP3 and SMTP so it's email client-neutral, and does everything automatically. I've been wanting to write a program like this for years but never had the time.

http://sites.inka.de/tesla/gpgrelay.html

the better security gets, the more it will interfere with usability

On the other hand, if TCP-over-TCP is your only option (eg. due to the lame firewall my employer set up), then SSH is a great option.

But what does that have to do with increasing security again?

Anyone remember the Sun 386i? Intel 386 based. Ran SunOS 4. Not successful - worked OK, but not price competitive with PCs and not compatible with Sun's other product lines.

Wouldn't it be better implemented at the network transport level instead of only tunneling TCP? I'm thinking more like how CIPE is based on UDP packets.

...or why we tunnel PPP over SSH to create VPNs (because IPSec and PPTP are for lusers).

The linux desktop is already here, I've been using it for a few years now. Nero just recently became aware of it and find itself competing in a very crowded arena with some very good players. Joe Schmoe isn't going to have trouble finding a CD burner on this platform. Which ever distro he chooses will, more than likely, come with a very capable burner with a good GUI. You mentioned giving Nero a little support, my question is why? Their app doesn't bring anything new to this platform.

...and, indeed, there are quite a lot of folks using OpenVPN in UDP mode for moving VoIP traffic.

Trying to tunnel a protocol which has its own reliability layer through another protocol which also implements a reliability layer makes bad things happen.

Also, what about GPGRelay?

more here.

Not if you're Bruce Willis

This machine isn't Sun's first x86 machine. The 386i was an early attempt by Sun to use a cheap Intel processor to make a lower-price Unix machine. All of this was before Sun abandoned 3rd-party processors (Motorola and Intel) to concentrate on the SPARC architecture.

You may try to filter/block with squid. Try this sites:

http://www.squid-cache.org/related-software.html

http://sites.inka.de/sites/bigred/devel/squid-filt er.html

There is a proxy called Privoxy with some advanced filtering capabilities.

If this interests you, be sure to check out Erik Demaine's work at MIT, Issei Yoshino's Super Complex Origami, HOYJO Takashi, Biruta Kresling's Keikki Bamboo folds, Robert Lang's Design Secrets of Origami, Robert Hull's Origami^3 compilation. Not all computational origami looks mathematical but the methods for getting to and end are clearly designed from step one. Quite frankly I understand very little of the math, but I can appreciate the elegance of an efficient fold.

It is really cool that this can be done at the application layer, because it will allow applications to be developed to take advantage of it with out even changing the drivers for your wi-fi card.

But, what happens when product X that you totally depend on applies this at the application layer, and then product Y, which your business is "betting the farm" on, requires that it be applied at the protocol layer?

Does implementing it twice at different places in the software heap cause problems?

An example of this at work could be tunneling IP over IP. It all works fine, as long as there is *no* packet loss. As soon as a packet is lost at the protocol layer (not the virtualized protocol layer) you end up with a cascading set of timeouts that cause total failure. See Why TCP Over TCP Is A Bad Idea.

So, sounds good. Obviously, nobody's going to complain about 2x the performance. But, can this technology actually withstand the real world?

See eg. GPG Relay. It's a nice proxy for transparent encryption of email.

these products typically only rely on simple TCP streams so they have a higher success rate than IPsec in some network environments.

Ahem. *cough*bullshit*cough*

Anything that uses TCP as a transport is inherently going to have poorer performance than something that uses a non-stream based protocol (such as IPSec, which uses ESP, or even PPTP, which uses GRE.)

This is because of the error-correcting overhead involved with a TCP stream. See this for more information.

Setting up Samba over SSH Tunnel

For a quick-and-dirty solution for one or two users, over a reliable connection, this might be sufficient, but for the poster's problem, it would be a nightmare.

TCP over TCP is a bad idea because it amplifies the effect of lost packets.. two or three dropped packets in a short period of time will result in a cascade failure as each TCP stream attempts to compensate for the loss.

You can find all the gory details here.

Of course, the author of that article went on to write CIPE, which is one of the problem protocols under discussion.

I use freeswan IPsec for securing wifi. The biggest problem with IPsec is that it suffers from "committee bloat" and is very complicated to use. Freeswan partially mitigates this complexity by implementing only a narrow subset of the RFCs (in fact, it is not even RFC compliant, because they deliberately removed some required features that might compromise security).

The good thing about IPsec, and freeswan in particular, is that they were openly developed with actual expert input and nobody has yet cast any doubt on the security of either.

The CIPE FAQ claims that CIPE is "Industry Strength".

Aye, but the webpages for CIPE have been updated in 2003.

The "ssh tunnels are very bad performance" statement may be elaborated a bit more on this page titled "Why TCP Over TCP Is A Bad Idea".

Sounds interesting but is there any reason why a standard VPN bridge wouldn't do the trick?

I found cipe much easier to configure and set up. See the linux and win32 sites for more information.

But the point is that we don't have nothing. We have a choice between running TCP-on-TCP or a real VPN solution like CIPE or Free/SWAN. A PPP over SSH tunnel is quite easy to set up, but as people have already said, even the slightest amount of packet loss in the physical layer will cripple the upper TCP layer - and if you're connecting from home to work across the Internet, you can expect packet loss.

Here's a good document about it.

Well...

One comparison can be found in the essay BSD: Linux With a Twist. The FreeBSD Manual also has a section on the differences primarily focused on the development model.

But just as a summary

Support

Linux has more users, more books, more groups, more mailing lists and more newsgroups. Whether this is good or bad depends on your point of view. I find comp.unix.freebsd.misc to have generally very good advice.

What you get

Most Linux distros seem to be headed towards a "complete desktop in a box" approach. In contrast, BSD just gives you a bare-bones distribution with most other applications available as packages or ports. Under BSD the kernel and core programs are treated as a coherent unit.

Flavors

Linux seems to spawn off a new distribution about once a month. There just seems to be three main BSDs that focus on different things. (FreeBSD, OpenBSD, NetBSD.)

Java

The BSDs lag behind Linux in Java support a bit. I don't have any problems with Java 1.3 but I'm told Java 1.4 is not production quality yet.

License

The BSD license permits incorporation into proprietary systems. Depending on your needs and politics this is either a good thing or a bad thing.

Hardware

Linux has support for more peripherals. NetBSD has support for more CPUs.

Learning Curve

Hrm. BSD pretty much forces you to master command-line unix. The text-based install assumes a pretty good understanding of basic concepts, and while the Handbook is excellent, it also assumes a bit of knowledge.

We used 802.11 to make a secure office home network, and like any insecure medium for IP, you can secure it against sniffing by layering a secure tunnelling protocol on top of it. This probably wasn't necessary since most sensitive information goes over ssh or SSL connections anyhow, but the way to do it is to use a encrypted network device tunnelling driver thingy.

I'm used to CIPE and like it because it has a Windows NT/2K/XP implementation as well as a Linux module. VTUN does much the same job, is slightly easier to set up, although instead of a Windows driver, runs on Solaris and various BSDs. We used the latter to make a link between mine & my partner's house and managed to use the Linux bridging features to bridge his home wireless network to the office ethernet-- the bridge is over a vtun interface which sits on top of the 802.11 link between our office and his house. Complicated but it seems to work :)

Anyone else have a similar setup? I'd be interested to know how to grow this kind of setup manageable (not that we have a need for it, but ... )

There are few aspects of SSH vs. IPsec that you seem to be missing:

* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal. Drafts are in their 5th revision, and Cisco, SSH, Nortel and some other manifacturers already support NAT-T and are quite interoperable with each other. Keep in mind though that it's UDP based, and that's the way it must be, because ...

* TCP-based VPNs (and SSH/SSL tunneling in particular) are prone to a trivial DoS attacks, which severely depricates their robustness. I put a quick paper together that provides a bit more details on the subject.

* keep also in mind that tunneling over SSH leads to TCP-over-TCP encapsulation, which is considered by many 'a bad idea' in general due to the induced TCP retransmission problems.

* you may also consider that SSH comes with a higher average per-packet overhead (due to TCP ACKs), which may require more frequent re-keying when compared to IPsec, which in turn may bring overall VPN performance down.

The bottom line is I would not recommend SSH over IPsec unless it's a time-critical project .. or you dont have a budget for a decent IPsec client :)

Eventually, the TCP over TCP factor will kick in, and your VPN will be slow

Here's what he means:

Why TCP Over TCP Is A Bad Idea

Bad idea.

However, I was not referring to the same kinds of VPNs the AC mentions. I understand why TCP over TCP is a bad idea.

I was thinking of these kinds of products:

• HOB
• Citrix Secure Gateway
• Netilla
• Aventail
• Neoteris

If you have a shell account, they probably allow ssh through the firewall and so you can tunnel the NTP ports over SSH.

Read Why TCP Over TCP Is A Bad Idea by Olaf Titz:

A frequently occurring idea for IP tunneling applications is to run a protocol like PPP, which encapsulates IP packets in a format suited for a stream transport (like a modem line), over a TCP-based connection. This would be an easy solution for encrypting tunnels by running PPP over SSH, for which several recommendations already exist (one in the Linux HOWTO base, one on my own website, and surely several others). It would also be an easy way to compress arbitrary IP traffic, while datagram based compression has hard to overcome efficiency limits.

Unfortunately, it doesn't work well. Long delays and frequent connection aborts are to be expected. Here is why.

Very interesting read.

Why TCP Over TCP Is A Bad Idea
If you want to try it, consult the VPN PPP-SSH Mini-HOWTO

Our HR director is scared to death of these new HIPAA Rules. Main thing that worries him is that we are going to overlook something and that it will come down on him.

We spoken with our "insurance managers" and since we are a small group (less than $5 Mil/yr) we have that extended deadline to be in full compliance. Still, we were asked to find a simple and convenient way to encrypt email.

What I ended up using, even though our provider isn't ready for it yet, is a little tool called GPGRelay. This tool allows you to use GPG transparently of the email client. It might be easier to use a server based product to do this, but then you'd have to have some way for the server to authenticate the sender without a password being sent plain text across the network.

Anyhow, thats what we'll probably do unless our provider makes us do otherwise.

Hope this Helps...

How do they avoid the meltdown problem that tcp over tcp has?

I thought that was inherent in any implementation of TCP over TCP. I guess they could do ACK spoofing like satellites do, but that's lame, and means it probably won't ever be compatible with anything but Windows.

From the page:
"Imagine what happens when, in this situation, the base connection starts losing packets. The lower layer TCP queues up a retransmission and increases its timeouts. Since the connection is blocked for this amount of time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will also queue a retransmission. Because the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them. This makes the upper layer connection stall very quickly and every retransmission just adds to the problem - an internal meltdown effect. "

I agree. IP over SSH is a bad idea for the same reasons why TCP over TCP is a bad idea.

I also agree that a server makes the most sense. I would amplify these recommended transport mechanisms to include a few others that will allow remote connectivity.

First is a secure IMAP server for centralized email. This will allows any SSL-enabled IMAP client to access your mailbox. Also, Squirrelmail running on an SSL web server can give your access to your centralize mail repository from any web browser.

SMB and NFS are the obvious choices for LAN-based access, but WAN access needs more care. I think that a VPN setup using CIPE is a good approach. One the CIPE links are build, you can use most services as if you were located on your wired LAN.

The other need might be for file access from "arbitrary" locations. In addition to the normal scp and sftp apps in OpenSSH, there is a nice SCP client for windows, WinSCP. Lastly, if you have a SSL web server there already, Web-FTP will give you access to your files via https.

This sounds like a lot. In the end, you would need to expose SSH, SSL IMAP, SSL Apache, and CIPE servers. I am midway through this deployment myself, but it has stalled a bit because one of primary Internet access points started disallowing outgoing SSH.

Those security holes you are speaking of are only found in the free software version of SSH, OpenSSH, hacked together by Theo de Rat and his National Socialist friends.

The commercial version of SSH by Tatu Ylönen, OTOH, is completely secure and bugfree.

If only the rest of the world realized this and used commercial software instead of open source...

I am member of a club which is a fully fledged ISP including its own independent IP address space, high bandwidth, backup connections, enough room for co-located servers, and even commercial customers which help to finance our toys. We do not just offer dial-in via modems or ISDN but also plan to provide DSL (not an easy task in Germany). Interesting projects like voice over IP are also supported. All this works thanks to volunteers. They payoff is that we have a great freedom and services that are not to be found everywhere like static IP addresses (if necessary, in connection with CIPE tunnels), incredibly cheap co-location, and the option of sharing. What's more, we meet each other every week in our own cellar and enjoy some beer :-)

Windows Privacy Tray seems to be the best Windows GPG GUI, I use it as my PGP replacement at the moment. I also have Mozilla, which doesn't have such great PGP integration, so I relay through GPGrelay, which checks all incoming POP mail for PGP stuff, then decrypts and verifies or encrypts and signs behind the scenes. Mozilla only sees the mail after GPGrelay has dealt with it, so it's the closest I get to seamless integration. I don't have any problems with it.