Archive for March 2012
IKE main mode, aggressive mode, & phase 2.
Just like GRE tunnels, IPSec is found in every single network, whether it’s in the form a Lan2Lan tunnel or a client side remote access VPN. We all know IPSec secures communication between two endpoints using ISAKMP, Diffie-Hellman, and various other encryption and hashing algorithms but how exactly do these protocols work together. We know IPSec will form its tunnel after IKE Phase 1 and Phase 2 so let’s take a look at what goes on during this process:
IKE Phase 1
IKE Phase 1 works in one of two modes, main mode or aggressive mode now of course both of these modes operate differently and we will cover both of these modes.
Main Mode:
IKE Phase 1 operating in main mode works with both parties exchanging a total of 6 packets, that’s right 6 packets is all it takes to complete phase 1.
- The first packet is sent from the initiator of the IPSec tunnel to its remote endpoint, this packet contains the ISAKMP policy
- The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information matching the ISAKMP policy sent by the initiator.
- The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key
- This fourth packet as you would expect comes from the remote endpoint back to initiator and contains the remote endpoints Key Exchange and Nonce payload.
- The fifth packet is from the initiator back to the remote endpoint with identity and hash payloads, the identity payload has the device’s IP Address in, and the hash payload is a combination of keys (including a PSK, if PSK authentication is used)
- The sixth packet from the remote endpoint to the initiator contains the corresponding hash payloads to verify the exchange.
First packet in the IKE Phase 1
Second packet of the IKE Phase 1 process
Third packet in IKE Phase 1
Fourth packet in the IKE Phase 1 process
Fifth packet in the IKE Phase 1 process
Sixth and final packet in IKE Phase 1
Aggressive Mode:
IKE Phase 1 operating in aggressive mode only exchanges 3 packets compared to the 6 packets used in main mode. One downside in aggressive is the fact it not as secure as main mode.
- The first packet from the initiator contains enough information for the remote endpoint to generate its DH secret, so this one packet is equivalent to the first four packets in main mode.
- The second packet from the remote endpoint back to the initiator contains its DH secret
- The third packet from the initiator includes identity and hash payloads. After the remote endpoint receives this packet it simply calculates its hash payload and verifies it matches, if it matches then phase one is established.
IKE Phase 2
Now let’s look at IKE Phase 2, IKE Phase 2 occurs after phase 1 and is also known as quick mode and this process is only 3 packets.
- Perfect Forward Secrecy PFS, if PFS is configured on both endpoints the will generate a new DH key for phase 2/quick mode.
- Contained in this first packet from the initiator to the remote device are some of the hashes/keys negotiated from phase 1, along with some IPSec parameters IE: Encapsulation (ESP or AH), HMAC, DH-group, and the mode (tunnel or transport)
- The second packet contains the remote endpoint’s response with matching IPSec parameters.
- The last packet is sent to the remote device to verify the other device is still there and is an active peer.
That last packet concludes the forming an IPSec tunnel and the phase 1/2 process.
- Note: These 3 quick mode packets are encrypted
Quick Mode packets with encrypted payload.
All 9 packets of the Phase 1 (Main Mode) and Phase 2 process.
First Hop Redundancy Protocol: VRRP
First hop redundancy protocols are important to any network, after all why should any carefully designed network be dependent on any single IP address or any single device for that matter? A FHRP allows us to make the default gateway for any subnet a virtual address that can float between multiple physical devices. However some of our FHRP choices are Cisco proprietary (IE: HSRP & GLBP), and recently I had to setup a FHRP between a Cisco router and Red Hat box, so VRRP was my FHRP of choice.
Now the configuration for VRRP for the Cisco side:
The VRRP 5 commands are what makes this happen. VRRP 5 is the VRRP group (and the router ID) this instance belongs to, next we have VRRP 5 IP 10.0.1.1 this where we specify the virtual IP address. This is going to the IP Address we want to ensure is available to our clients such as a default gateway. The VRRP 5 timers learn command tells this router to learn the VRRP advertisement timers from the master router. Next we have the VRRP 5 preempt delay minimum 60 this specifies a set of time in seconds before the master role is taken back.
Delaying the preempt may not appear to be inviting at first but it is useful. Let’s say the master comes back online and it resumes the role of the default gateway before it has had time to re-converge it’s routing table, well the VRRP master is now going to black hole traffic until your routing protocol re-converges.
Next we have VRRP 5 priority 150 this allows us to specify the priority of each router to control who will be the master router and who will be the backup router. The device with the highest priority is the device that will be the master router for VRRP. The final line in this configuration is the VRRP 5 track 1 decrement 100 command, this allows us to tie some type of tracking or IP SLA monitoring into the VRRP configuration. This way if the IP SLA or tracking mechanism goes down the VRRP priority will automatically be decremented ensuring this device will not be the master. After all, if the master VRRP router looses connectivity to the rest of the network due to an interface failure or link failure we don’t want it to be the master router anymore.
Let’s also go a step further an think about the preempt delay we spoke about earlier, lets say we set the preempt delay to 60 seconds and we are tracking the outside interface the preempt delay will make sure the outgoing interface is stable for at least 60 seconds before taking back its master role, now that preempt delay isn’t looking so bad now is it?
Now let’s verify our VRRP configuration using the show vrrp command:
This will show the current state of this router in the VRRP process, that state will either be Init, backup, or master. The Init state just mean VRRP is not running or is starting up. Next we see the virtual IP and the virtual MAC address, a VRRP virtual MAC address will start with 00:00:5E:00:01:XX where XX is going to be the Virtual Router ID (or VRRP process ID) Then we will see the preemption settings and our advertisement intervals. So the Show VRRP command provides us a nice summary of our VRRP configuration.
Now let’s check out some debug logs for VRRP:
The first message in there states the router received an advertisement with a priority of 150 from IP 10.0.1.92, then the VRRP event states that this priority is higher or equal to it’s own priority, the next advertisement has a priority of 0, and then the Master down timer expires, which causes the this router to become the master. The last few VRRP message show advertisements going with checksums, which is normal for VRRP operations.
I also figured I would show a VRRP Packet:
From here we can see the VRRP version currently running on the router. This will also show us the Virtual Router ID, and the IP address we are advertising along with the priority of the 10.0.1.92 host. Also check out the Layer 2 information Wireshark identifies that the MAC address is associated with VRRP and knows the Router ID is 5. Now check out the Layer 3 IP destination, it’s 224.0.0.18 so these advertisements are sent out via Multicast to all VRRP routers on this LAN.
More information on VRRP can be found in RFC 3768, note this RFC is for VRRPv2. RFC 5798 covers VRRPv3, but this post covers VRRPv2 running on Cisco routers. Cisco also has few articles to go over the configuration: VRRP & Configuring VRRP
CCIE or Null! 