December 14, 2016
Internet Key Exchange (IKE) has gone through a lot of changes in the last 20 years. The last major change was the introduction of IKEv2 and communication via port 8500 rather than ports 500 and/or 4500 for setting up what is known as Phase 1 Tunnels.
A Quick Historical Perspective
More than 20 years ago, IKE did not exist. To setup a VPN tunnel you had to find a secure way to pass the keys to the tunnel--and pray they stayed secure--because to change the keys you still had to manually distribute tunnel end-point keys. IKE is a protocol that can secure, and automatically exchange keys. The initial setup can be "old-school" manual, secret distribution for the initial secret used to setup a new secret, or PKI, using the other side’s public key to encrypt a secret with its private key. This initial setup, and the exchanges that take place over time to manage the keys used for data transport, is commonly referred to as Phase 1 keys. In short, Phase 1 tunnels are used for key management for all tunnels.
Obviously, when there is a Phase 1 of something, there is a Phase 2 of something. Phase 2 tunnels are also known as the "data-transport" tunnels. These tunnels are the tunnels that are set up for transporting the data; replacing what used to be set up by a manual tunnel. In other words, manual tunnels were Phase 2 tunnels; the Phase 1 part being performed via external, secure transport (e.g., surface-mail, courier, telephone, etc.). See bit.ly/2gMwbTd
Issues We Face Today
Sometimes there is a difference of opinion on what port number to use to set up the Phase 1 tunnel. AIX accepts ports 500 and 4500 for incoming requests and and uses port 8500 for outgoing IKEv2 requests. Situations occur where AIX requests are not accepted because port 8500 is not accepted – contrary to the RFC specification. One of the key changes in IKEv2 (see https://tools.ietf.org/html/rfc4306#section-2.11
) is the change from the requirement to use the same port numbers for listening (500 and 4500) and requesting. In short, if port number 8500 is not supported (recognized) for an incoming request IKEv2 communication from AIX will very hard – read impossible for AIX to initiate connections. In those cases you may not be able to use IKEv2 for key management - the default for modern AIX systems.
Do not be overly concerned if IKEv2 is not supported. It happens. The key is to know what easy steps can be taken to get something up and running using automated key exchange – not being overly focused on using IKEv2. Get IKEv1 working – and then dig into why IKEv2 is not functioning.
To the point…
So, what is the point of today's blog? To point out something that took me way to long to discover because I continued to test and evaluate the wrong aspects.
By default AIX 6.1 and later use IKEv2, and the IKE daemons are started using "startsrc -g ike"
. If IKEv2 is not working, reconfigure to use IKEv1 and start the daemons using /etc/rc.ike
. If only I had known that months ago, a project I have worked many hours (read: days) would have been finished in a single call of less than four hours. Sigh. (It was that simple.)
I hope this helps. I highly recommend using IKE and VPN. They’re a very nice way to secure application communication (data in transit) without changing a thing in the application.
Posted December 14, 2016 | Permalink