We have spent literally years working on IPsec in the FireBrick. It is a complex project but it is finally getting to an end, well, sort of - at least a major milestone and release.
IPsec is very much seen as an industry standard way to create Virtual Private Network (VPN) links, both point to point between offices, and "road warrior" roaming from mobile networks in to office networks.
The problem is that IPsec is a lot of layers, a lot of standards, and far from simple. There are the low level encryption and hashing algorithms. These take a lot of work to implement and test. They also need a lot of low level maths functions coding as well. There are then layers and layers of protocol on top.
For a long time the FireBrick has supported manual keying - that means the key (typically entered as a long hex string) is entered both ends and is fixed. This was the first layer and meant having all of the basic algorithms working. We recommend that anyone still using manual keying between FireBricks changes to using IKEv2 and a pre-shared key.
We then added IKEv2 (18 months ago), which is a key exchange protocol. This allowed keys to be negotiated dynamically rather than being fixed in the config at each end. This is a big improvement on the manual keying, and allows the key exchange based on a simple shared pass phrase. We did not implement IKEv1 as it was not quite such a clean standard and many devices are now doing IKEv2 (even apple).
This final stage involves EAP, which is complicated by the fact that certificates are used to authenticate the server (FireBrick) end. This has meant implementing the whole system for managing checking and signing using certificates and keys. The client can then authenticate using a simple username and password. It add to the fun, iPhones do not allow a simple manually entered config, but a profile file that is loaded. In some ways this helps as end users can just click on it from an email, but it makes it more complex for the sysadmin to set up.
The upshot of this that iPhones and Androids can connect in to an office LAN securely.
Now, when I say "we", I mean pretty much "Cliff". He has spent day and night working on this. The work we have done gives a good foundation using our own code (so no NSA/GCHQ back doors) and allows a lot more work to be done in encryption in the FireBrick. The next generation of hardware we are working on even has a true random number generator built in as well as some options for hardware encryption accelleration. We know people have asked about OpenVPN, and we are looking in to this as well.
Even so, the IPsec setup is still complex, and I have made a cheat sheet. But hey, if it was not complicated then my friends would not be able to sell consultancy :-)
The latest code is in beta now, and should be a factory release shortly. We suspect there will be a few more bits of work down the line on this and new releases in due course, but now we finally have it working with common mobile devices we can start working on some of the other new features in the FireBrick code. So, well done Cliff.
Its always struck me that IPSec is a horrible design for most "single-client" VPNs since it doesn't have any underlying mechanism for assigning suitable IP addresses to the endpoints. Fine if the endpoints are fixed networks (e.g. the networks of 2 separate offices talking to each other), but very messy in the case of a single laptop VPNing into a corporate network from a dynamic IP address. This leads to bodges like L2TP-over-IPSec, which just seems wrong to me...
ReplyDeleteThe other issue I've had with IPSec under Linux (no experience with IPSec under other OSes) is that it seems to have a habit of getting into a state where it just doesn't work, and none of the logging will tell you *why*. e.g. key exchange appears to happen ok and you can see the ESP packets arriving by tcpdumping, but no decrypted traffic appears anywhere and there's nothing to tell you why.
So whilst I do use IPSec at times, I've consigned it firmly to the "nice idea, but really terrible to work with" bucket. :( OpenVPN, on the other hand, seems to Just Work™ with very few issues.
Where IPSec really could shine is for doing ad-hoc encryption between endpoints. e.g. instead of using https, etc. IPSec would automatically set up a secure connection between your workstation and the web server and all traffic between the two would be encrypted irrespective of protocol. Of course, no one does this. :)
This is where the EAP and IKEv2 come in - they do allow endpoint IP assignment, and all sorts.
DeleteIt's massively over complicated. Everyone I've spoken to uses and recommends OpenVPN instead.
ReplyDeleteI used OpenVPN for a while, but then switched to L2TP over IPSec. The only thing I would like to have is "dial-on-demand", but it is not enough of an issue for me to dig into how feasible it might be...
DeleteIPsec isn't "massively over complicated." It's well standardized and well vetted, and the design is straight forward not to mention well understood by network security engineers. The most complex part of IPsec is figuring out the various different vendor config quirks with each one; the actual stack is very predictable. If you consider it complicated, I'm not sure what you think of other network protocols used daily, many of which are far more esoteric.
DeleteOpenVPN is ok but it has a far more limited usage scope, not to mention it has very limited vendor support.
> IPsec isn't "massively over complicated."
DeleteI think it depends on what you want to do. For a laptop out in the field connecting back to a network, we tend to use OpenVPN because it really does seem to Just Work with no issues. Comparatively, with IPSec there are a *lot* of options you have to consider (e.g. what key types you're using, whether you need NAT traversal, etc) - no problem if both endpoints are always using the same stack, but differing capabilities of different stacks means you have to to a bit of work to figure out the appropriate config, since the config you would usually use for (say) Linux talking to Linux may not be supported by a non-Linux device. Bearing in mind, a lot of the time when setting up VPNs, we are only setting up one end of it and we're having to talk someone who's probably not that technical through setting up the other end.
You're right that OpenVPN is more limited in its scope, but this is exactly what makes it good - it fits a single very common use well and you can basically set it up to do that without using your brain. If you don't fit within OpenVPN's scope then IPSec is of course the correct thing to use (although I must admit that I've often just chucked up a GRE tunnel in situations where I need a tunnel and don't care about it being unencrypted, because this is by far the easiest of all).
I've mentioned above, but IME the main problem with the Linux IPSec stack is the lack of debugging - I've been in plenty of situations where you can see the ESP packets arriving and you can see that the keys have been negotiated, but the stack is silently dropping the traffic and there's nothing telling you *why*. And most frustratingly, I've seen this happen spontaneously on VPNs that have been working fine for years and then suddenly break for no apparent reason.
For the record, I have been doing networking stuff for 15 years and used to work as a network protocol developer at Intel, so I do understand this stuff. I'm not saying I avoid IPSec because I don't understand it, I'm saying I avoid it because in the majority of cases there is an easier option; and in the cases where there isn't an easier option, I do of course fall back to IPsec.
All these comments about how to do VPNs et al and yet you're still offering insecure SSL conifugrations on your servers (E.G., https://www.ssllabs.com/ssltest/analyze.html?d=g.mail.aaisp.net.uk)
ReplyDeleteThe ops team are fully aware of that and it is being worked on.
Delete