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.
My air-con can have a temperature set and aim for it. It has a wide range of ± a few degrees which I don't like. It is not setting tempe...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo...
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...