Performance testing sshuttle over IPv4 vs. a Back to My Mac-based IPSec tunnel
Christopher
I wrote up how I use sshuttle with IPv6 and Back to My Mac last week
(http://confusatory.org/post/3787027508/), but I realized that I may
be paying a performance penalty since I’m routing my traffic over an
ssh tunnel over an IPSec tunnel (this is basically TCP over TCP,
yeah?) I’ve also got a dyndns hostname set up for my home machine, so
I’m in a good position to do a good test of naïve IPv4 sshuttle vs.
the IPv6-based IPSec setup. Do you have any advice for how to test the
performance of each of these setups?
(Alternatively: wouldn’t it be cool to just piggyback on the IPSec
tunnel instead of starting another ssh connection for routing traffic
over? I have no idea how to do this, but it seems possible on some
level…)
—cbowns
Avery Pennarun
> I wrote up how I use sshuttle with IPv6 and Back to My Mac last week
> (http://confusatory.org/post/3787027508/), but I realized that I may
> be paying a performance penalty since I’m routing my traffic over an
> ssh tunnel over an IPSec tunnel
Well, you're definitely paying a performance penalty by encrypting
twice. However, on a modern CPU the CPU penalty is probably minimal,
and the network overhead of IPsec or ssh, while nonzero, aren't a
*very* big deal.
I would be interested to hear specific results. You might want to try timing:
- a simple HTTP file transfer from one end to the other, eg. with curl
+ a web server (skipping BtMM)
- a simple scp from one end to the other (skipping BtMM)
- a simple HTTP file transfer *with* BtMM
- a simple scp *with* BtMM
- HTTP and scp transfers over sshuttle with/without BtMM.
My guess is the encryption overhead is probably less than 10%, unless
you have an incredibly fast network and CPU becomes a problem.
> (this is basically TCP over TCP, yeah?)
No, IPsec tunnels are not TCP, so they don't encounter or cause the
TCP-over-TCP weirdness. tcp-over-sshuttle-over-ipsec is no worse, TCP
sanity wise, than tcp-over-ipsec or just plain tcp.
I usually find sshuttle tunnels to be easier to set up, though :)
> I’ve also got a dyndns hostname set up for my home machine, so
> I’m in a good position to do a good test of naïve IPv4 sshuttle vs.
> the IPv6-based IPSec setup. Do you have any advice for how to test the
> performance of each of these setups?
Hopefully the above list will give some good suggestions. Doing a
simple file transfer will test your bandwidth, which is probably what
you were thinking about when it comes to network overhead. If you
care about latency, you'd need some kind of different test, but I
wouldn't worry about it too much - it's even less likely that your
setup hurts latency than that it hurts bandwidth.
When testing sshuttle performance, you might want to try playing with
the --no-latency-control option. If you want to maximize benchmark
results, using that option usually helps (at the expense of
interactive latency when you're transferring large files at the same
time).
> (Alternatively: wouldn’t it be cool to just piggyback on the IPSec
> tunnel instead of starting another ssh connection for routing traffic
> over? I have no idea how to do this, but it seems possible on some
> level…)
I've often thought there should be an ssh-like service that just does
ssh-like *authentication*, but doesn't bother encrypting the link, for
people who know their link is sufficiently hard to eavesdrop, or who
don't care about people eavesdropping. For example, if I want to do
ssh-over-ssh to hop from one computer to another, the outer one really
doesn't need to be encrypted. Or in your example, if you know you're
using IPsec anyway, you don't need ssh to encrypt anything at all, so
you ought to be able to turn it off.
Once upon a time, older versions of ssh used to have a "null
encryption" mode that did exactly that. I used to use to to improve
transfer speeds of scp on a fast LAN, and it was great. But security
weenies apparently protested this one too much, so it was eventually
removed. Boo :( It may be that you can recompile ssh with some
compile-time option and get it back, though. (Then again, that was
for large file transfers on a fast LAN on 5-year-ago computers; it
probably doesn't matter in any realistic situation with modern
computers and a normal-speed WAN, since you're probably not limited by
CPU speed.)
We could provide an "unencrypted plain TCP server" in sshuttle just
like we recently added to bup. However, this would defeat one of
sshuttle's greatest features, ie. the fact that you don't need to
install or configure anything on the server, so I think it wouldn't be
worth it for a few percentage points of speed increase.
Just as a note, I've never liked IPsec or non-application-layer
security in general. The fundamental problem is that it's too hard to
be *sure* you're secure. You "know" your session is going over IPsec,
and you configure ssh/sshuttle to not encrypt stuff because it's
already encrypted. Great, right? But what if you're right today, but
after changing a random setting someday, it's no longer true?
Suddenly you're sending a lot of key traffic unencrypted, and your
apps don't know any better. This is a huge danger of VPNs (including
sshuttle), and it's why most people are better off using ssh and HTTPS
even when they *do* have encryption at the VPN level. 2x encryption
doesn't technically make anything more secure, but it *does* make it
harder to accidentally make a mistake and use 0x encryption by
accident.
So in short... I'd love to see a summary of your performance tests,
just to make sure my hypothesis ("it's not seriously impacting
performance") is true. However, I suspect I'm right, and there's no
need to optimize anything further.
Oh, also, it might be interesting to add a sshuttle feature to let it
auto-lookup BtMM hostnames using the command you listed in your
article. You could have a prefix to the -r parameter, eg. "-r
btmm:whateverhostname:port" and just have sshuttle run that dns-sd
thing for you. Maybe btmm isn't the right prefix and dns-sd is more
general than that; I don't know anything about dns-sd. But making it
easier to get back into your PC from elsewhere sounds like a fun
feature, so if you want to send a patch, I'd probably accept it.
(Bonus points for also adding it to the sshuttle MacOS GUI :))
Have fun,
Avery