The security effects of tearing down my GRE tunnel on IPSec failure

December 24, 2014

When I described how I'd gotten IKE to work for my IPSec setup, I said that I was now tearing down my GRE tunnel when the IKE daemon declared an IPSec shutdown (or negotiation failure) and that this decision has some security implications. Today I want to talk about those implications and why I'm comfortable with them at the moment.

First off, lets talk about why I have security issues here and normal people don't. The difference is that normal people use IPSec based GRE tunnels to reach private resources that cannot be reached from the outside world. Assuming that unprotected GRE traffic is blocked in various ways, a non-functional GRE tunnel is essentially the same as one that doesn't exist; in each case, your packets are not getting to their destination. Tearing down the GRE tunnel probably helps slightly in that your connection attempts now get 'network unreachable' responses instead of stalling for a long time.

Some of the IPs I reach through my IPSec and GRE setup are private IPs that are not reachable from outside. But some of them are public IPs, where I actually can reach them when my GRE tunnel is down. This is where the security impact comes in: when my GRE tunnel goes down, my new connections are transparently diverted over the unencrypted Internet. Connections that were previously only subject to snooping inside the university (where they traveled from my internal GRE endpoint to their target) are now subject to snooping anywhere along the path from my home machine to the university. I may not even realize that my IPSec link is down and this is happening (although in practice I almost certainly will).

But does this exposure actually matter? There are two ways it could; traffic intelligence and connections that are now unencrypted. Traffic intelligence comes about because an outside listener can now see what university IPs I connect to (and with what protocols), where before all they saw was a mostly undifferentiated IPSec stream. I don't worry too much about traffic intelligence for various reasons. As for newly plaintext connections, obviously this doesn't happen if the connection itself has its own encryption; for example, my ssh connections are encrypted whether or not they travel through IPSec or go straight over the Internet. My exposure there is limited to whatever I do from home to university IPs that uses plaintext protocols, and honestly there isn't much (especially things that would keep working without an inside IP address). I think it's basically HTTP website visits to work websites, and I don't think that those are all that sensitive (our sensitive websites are all HTTPS, of course).

The result is that so far, I think I'm okay with this. Almost everything I do from home to work is just ssh connections, and those are encrypted whether or not they go over IPSec. But I'm not completely confident and I can't help but be a little bit nervous about whether I have some exposure I just haven't thought about and realized.

(It's not mail submission, for multiple reasons including that our user mail submission server doesn't take connections from outside IPs; if my GRE tunnel is down, I can't connect to it at all from my home machine.)

Written on 24 December 2014.
« The future of OmniOS here if we can't get 10G-T working on it
DNSSec in the real world: my experience with DNSSec »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 24 02:25:25 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.