An annotated IPSEC example
IPSEC.. WTF? Isn’t this supposed to by SharePoint?
Well, yeah you got me.. but a few years back I was a Cisco nerd in the ISP industry and got pretty handy at it. I wrote this article 3 years ago but then forgot about it until recently.. so it may as well see the light of day because at the time I wrote it, there was very little info out there on this subject.
Linksys to Cisco IOS IPSEC Tunnel
The network
Site 1: (Linksys WAG54G)
- Inside Network: 172.18.30.0/24
- Gateway IP 200.100.1.1
- Inside IP 172.18.30.1
- NAT: Overloaded on Outside interface
- LinkSys WAG54G. Software Version: 1.02.9, Dec 22 2004Site2:
Site 2: (Cisco 3725)
- Inside Network: 192.168.100.0/24
- Gateway IP: 200.56.4.1
- Inside IP 192.168.100.1
- NAT: Overloaded on Outside interface
- Cisco 3725 Router. IOS. IOS ™ 3700 Software (C3725-IK9O3S-M), Version 12.3(6), RELEASE SOFTWARE (fc3)
System image file is "slot0:c3725-ik9o3s-mz.123-6.bin"
The IPSEC Parameters
Probably the most common combination for IPSEC is to use 3DES/SHA/DH Group 2. For transforms ESP-3DES-SHA
- 3DES, SHA1, ESP (no AH).
- PFS is OFF!
- DH Group 2 (Group1 and 2 only supported on the linksys)
The IKE Parameters
- 3DES, SHA, DH Group 2
- All IP traffic to traverse VPN tunnel.
Linksys Configuration
- Security Tab – Choose VPN
- You do not need to enable IPSEC passthrough. You would only do this if another device behind the linksys was actually doing the IPSEC tunnel.
- Create a new tunnel entry and give it a name. Specify a subnet for the local security group (the local subnet) and set 172.18.30.0 with a 255.255.255.0 subnet mask
- Specify a subnet for the remote security group. 192.168.100.0/255.255.255.0
- Now we have to specify the IP address of the remote IPSEC peer. In our example we are using an IP address not a domain name
- Encryption should be set to 3DES and hash (authentication) to SHA. This is Phase II encryption (as will be confirmed in advanced settings screen). Set PFS to OFF in this example (Cisco defaults to off). The Key Lifetime here actually is Phase II key lifetime. Phase 1 key lifetime is in the advanced screen.
- IKE is used, rather than manual. Cisco default setting for Key Lifetime is 86400 seconds. So change this end to match. Set the shared key as well.
- Now click the advanced tab. Here we configure the phase 2 config. Repeat 3DES and SHA everywhere with 1024bit group (DH Group 2)
Note how this says that the linksys will try and offer DES/MD5/768, 3DES/SHA/1024 and 3DES/MD5/1024. In fact proposal 1 and 3 are therefore identical. I have not looked deeply into this, although it increases the Phase 1 work required when the two peers negotiate phase 1.
CIsco Configuration
Note that this particular router has 6 IPSEC tunnels to different peers. In this example, the connection to the WAG54G is the latest IPSEC tunnel. Comments are in itallics
SITEB#sh run
Building configuration…
First we define the ISAKMP policies that this router will accept. 4 are defined here. This is because the other 5 IPSEC tunnels have unique IKE requirements. Each different IPSEC peers have different capabilities.
crypto isakmp policy 1 (3DES/SHA/DH Group 5)
encr 3des
authentication pre-share
group 5
!
crypto isakmp policy 2 (3DES/MD5/DH Group 5)
encr 3des
hash md5
authentication pre-share
group 5
!
crypto isakmp policy 3 (DES/SHA/DH Group 5)
authentication pre-share
group 5
!
This is the ISAKMP policy that will match the LINKSYS router at Site A.
crypto isakmp policy 4 (3DES/SHA/DH Group 2)
encr 3des
authentication pre-share
group 2
Note that all ISAKMP use pre-shared keys for authentication. These are defined below.
crypto isakmp key xxxxxxxxx address yyyyyy
crypto isakmp key xxxxxxxxx address yyyyyy
crypto isakmp key xxxxxxxxx address yyyyyy
crypto isakmp key xxxxxxxxxx address yyyyyy
crypto isakmp key xxxxxxxxxx address yyyyyy
crypto isakmp key thisisasecretpassword address 200.100.1.1
!
!
This is the IPSEC Parameters. (Phase II) – explain here..
crypto ipsec transform-set Default esp-3des esp-sha-hmac
!
Now we define the crypto map itself. We specify the ACL that needs to be matched for each peer and then the transform set to use. Remember the first 5 crypto map entires are for other VPN’s.
crypto map IPSEC 5 ipsec-isakmp
set peer yyyyyy
set transform-set Default
match address xxxxxx
crypto map IPSEC 10 ipsec-isakmp
set peer yyyyyy
set transform-set Default
match address xxxxxx
crypto map IPSEC 15 ipsec-isakmp
set peer yyyyyy
set transform-set Default
set pfs group5
match address xxxxxx
crypto map IPSEC 30 ipsec-isakmp
set peer yyyyyy
set transform-set Default
match address xxxxxx
crypto map IPSEC 40 ipsec-isakmp
set peer yyyyyy
set transform-set Default
match address xxxxxx
crypto map IPSEC 50 ipsec-isakmp
set peer yyyyyy
set transform-set Default
match address xxxxxx
crypto map IPSEC 60 ipsec-isakmp
set peer 200.100.1.1
set transform-set Default
match address SITEB_to_SITEA
!
!
!
!
interface FastEthernet0/0
no ip address
shutdown
speed auto
full-duplex
!
Now we apply the crypto map to the externally facing interface.
interface FastEthernet0/1
ip address 200.56.4.1 255.255.255.252
ip access-group Firewall in
no ip redirects
ip nat outside
duplex auto
speed auto
no cdp enable
crypto map IPSEC
!
interface FastEthernet1/0
description Inside
ip address 192.168.100.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
ip nat inside source list inside_net interface FastEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 200.56.4.2
!
This is the ACL that the policy map called IPSEC uses to identify traffic to be IPSEC encrypted
ip access-list extended SITEB_to_SITEA
permit ip 192.168.100.0 0.0.0.255 172.18.30.0 0.0.0.255
ip access-list extended Firewall
remark
remark Allow TCP replys
remark
permit tcp any any established
remark
remark For VPN IPSec
remark
permit esp host 200.100.1.1 host 200.56.4.1
permit udp host 200.100.1.1 host 200.56.4.1 eq isakmp
permit icmp any any parameter-problem
permit icmp any any source-quench
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any unreachable
deny ip any any log
This ACL is used to Network address translate all outgoing packets *except* the stuff for IPSEC. That has to stay with source address preserve. Therefore by using a deny entry we stop the router NATting any traffic from 192.168.100.0/24 to 172.18.30.0/24
ip access-list extended inside_net
deny ip 192.168.100.0 0.0.0.255 172.18.30.0 0.0.0.255
permit ip 192.168.100.0 0.0.0.255 any
!
end
Example 1: Tunnel initiated from Linksys end
Logs (linksys). Linksys logs are quite basic, but you can see the 3 IKE Phase 1 packet exchange and tell that its using Main Mode (eg MM_I1) and then the Phase II Quick Mode (QM_I1) exchange.
Main mode Phase 1 happens first
2005-02-06 22:29:39 IKE[1] Tx >> MM_I1 : 200.56.4.1 SA
2005-02-06 22:29:39 IKE[1] Rx << MM_R1 : 200.56.4.1 SA
2005-02-06 22:29:39 IKE[1] ISAKMP SA CKI=[9ddfe293 4d8be14b] CKR=[cca2f07a 9045af27]
2005-02-06 22:29:39 IKE[1] ISAKMP SA 3DES / SHA / PreShared / MODP_1024 / 86400 sec (*86400 sec)
2005-02-06 22:29:39 IKE[1] Tx >> MM_I2 : 200.56.4.1 KE, NONCE
2005-02-06 22:29:40 IKE[1] Rx << MM_R2 : 200.56.4.1 KE, NONCE, VID, VID, VID, VID
2005-02-06 22:29:40 IKE[1] Tx >> MM_I3 : 200.56.4.1 ID, HASH
2005-02-06 22:29:41 IKE[1] Rx << MM_R3 : 200.56.4.1 ID, HASH
Great – we got this far. Once you see QM you know you have made it to Phase II
2005-02-06 22:29:41 IKE[1] Tx >> QM_I1 : 200.56.4.1 HASH, SA, NONCE, KE, ID, ID
2005-02-06 22:29:42 IKE[1] Rx << QM_R1 : 200.56.4.1 HASH, SA, NONCE, KE, ID, ID, NOTIFY
2005-02-06 22:29:42 IKE[1] Tx >> QM_I2 : 200.56.4.1 HASH
2005-02-06 22:29:42 IKE[1] ESP_SA 3DES / SHA / 86400 sec / SPI=[c243f13f:a213c248]
2005-02-06 22:29:42 IKE[1] Set up ESP tunnel with 200.56.4.1 Success !
2005-02-06 22:29:42
Logs (Cisco). Below is the output from the commands Debug crypto ipsec and debug crypto isakmp
Now for Cisco logs there is a massive amount of detail for better or worse :-), So we will break it up. Recall that this sample setup has been taken from a live Cisco router that is loaded with 4 IPSEC policies. They are:
3DES/SHA/DH Group 5
3DES/MD5/DH Group 5
DES/SHA/DH Group 5
3DES/SHA/DH Group 2
Now also recall that in addition to the defined policy, the Linksys does:
3DES/SHA/DH Group 2
DES/MD5/DH Group 1
3DES/SHA/DH Group 2
3DES/MD5/DH Group 2.
Now the first part of the logs shows the linksys trying its 4 combinations against the 4 Cisco combinations. This takes a while.. Annotated comments inline
Feb 6 21:43:04.394 GMT: ISAKMP (0:0): received packet from 200.100.1.1 dport 500 sport 500 Global (N) NEW SA
Feb 6 21:43:04.394 GMT: ISAKMP: local port 500, remote port 500
Feb 6 21:43:04.394 GMT: ISAKMP: insert sa successfully sa = 64008FCC
Feb 6 21:43:04.394 GMT: ISAKMP (0:709): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
This is a MAIN MODE exchange. Not an aggressive mode exchange
Feb 6 21:43:04.394 GMT: ISAKMP (0:709): Old State = IKE_READY New State = IKE_R_MM1
Feb 6 21:43:04.394 GMT: ISAKMP (0:709): processing SA payload. message ID = 0
Feb 6 21:43:04.398 GMT: ISAKMP: Looking for a matching key for 200.100.1.1 in default : success
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): found peer pre-shared key matching 200.100.1.1
Feb 6 21:43:04.398 GMT: ISAKMP (0:709) local preshared key found
The preshared keys match and therefore the IKE peer is authenticated. Now we have to negotiate a common IKE SA policy between the peers to protect the IKE Exchange
Feb 6 21:43:04.398 GMT: ISAKMP : Scanning profiles for xauth …
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 1 against priority 1 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Diffie-Hellman group offered does not match policy!
The cisco’s policy 1 is 3DES/SHA/DH Group 5 and this does not match Linksys polic 1 of DES/SHA/DH2
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 2 against priority 1 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 1
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Encryption algorithm offered does not match policy!
The cisco’s policy 1 is 3DES/SHA/DH Group 5 and this does not match Linksys policy 2 of DES/MD5/DH2
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 3 against priority 1 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Diffie-Hellman group offered does not match policy!
Same as offer 1. The cisco’s policy 1 is 3DES/SHA/DH Group 5 and this does not match Linksys of 3DES/SHA/DH2
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 4 against priority 1 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Hash algorithm offered does not match policy!
The cisco’s policy 1 is 3DES/SHA/DH Group 5 and this does not match Linksys of 3DES/MD5/DH2
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 0
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 1 against priority 2 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Hash algorithm offered does not match policy!
The cisco’s policy 2 (note priority 2 policy above) is 3DES/MD5/DH Group 5 and this does not match Linksys of 3DES/SHA/DH2
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 2 against priority 2 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 1
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Encryption algorithm offered does not match policy!The cisco’s policy 2 is 3DES/MD5/DH Group 5 and this does not match Linksys of DES/MD5/DH1Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 3 against priority 2 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Hash algorithm offered does not match policy!The cisco’s policy 2 is 3DES/MD5/DH Group 5 and this does not match Linksys of 3DES/SHA/DH2Feb 6 21:43:04.398 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
Feb 6 21:43:04.398 GMT: ISAKMP (0:709): Checking ISAKMP transform 4 against priority 2 policy
Feb 6 21:43:04.398 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.398 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.398 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.398 GMT: ISAKMP: default group 2
Feb 6 21:43:04.398 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.398 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Diffie-Hellman group offered does not match policy!The cisco’s policy 2 is 3DES/MD5/DH Group 5 and this does not match Linksys of 3DES/MD5/DH2Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 0
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Checking ISAKMP transform 1 against priority 3 policy
Feb 6 21:43:04.402 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.402 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.402 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.402 GMT: ISAKMP: default group 2
Feb 6 21:43:04.402 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.402 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Encryption algorithm offered does not match policy!
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3The cisco’s policy 3 is DES/SHA/DH Group 5 and this does not match Linksys of 3DES/SHA/DH2
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Checking ISAKMP transform 2 against priority 3 policy
Feb 6 21:43:04.402 GMT: ISAKMP: encryption DES-CBC
Feb 6 21:43:04.402 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.402 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.402 GMT: ISAKMP: default group 1
Feb 6 21:43:04.402 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.402 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Hash algorithm offered does not match policy!
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
The cisco’s policy 3 is DES/SHA/DH Group 5 and this does not match Linksys of DES/MD5/DH1
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Checking ISAKMP transform 3 against priority 3 policy
Feb 6 21:43:04.402 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.402 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.402 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.402 GMT: ISAKMP: default group 2
Feb 6 21:43:04.402 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.402 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Encryption algorithm offered does not match policy!
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 3
The cisco’s policy 3 is DES/SHA/DH Group 5 and this does not match Linksys of 3DES/SHA/DH2
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Checking ISAKMP transform 4 against priority 3 policy
Feb 6 21:43:04.402 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.402 GMT: ISAKMP: hash MD5
Feb 6 21:43:04.402 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.402 GMT: ISAKMP: default group 2
Feb 6 21:43:04.402 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.402 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Encryption algorithm offered does not match policy!
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are not acceptable. Next payload is 0
The cisco’s policy 3 is DES/SHA/DH Group 5 and this does not match Linksys of 3DES/MD5/DH2
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): Checking ISAKMP transform 1 against priority 4 policy
Feb 6 21:43:04.402 GMT: ISAKMP: encryption 3DES-CBC
Feb 6 21:43:04.402 GMT: ISAKMP: hash SHA
Feb 6 21:43:04.402 GMT: ISAKMP: auth pre-share
Feb 6 21:43:04.402 GMT: ISAKMP: default group 2
Feb 6 21:43:04.402 GMT: ISAKMP: life type in seconds
Feb 6 21:43:04.402 GMT: ISAKMP: life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:04.402 GMT: ISAKMP (0:709): atts are acceptable. Next payload is 3
Aha! We finally Hit policy 4 on the Cisco! 3DES/SHA/DH Group 2.
(This illustrates how advantageous it is to agree on a common IKE policy. Since each end has multiple combinations, there can be an increased number of combinations! Can be difficult though when dealing with vendor interoperability and 3DES export restrictions)
Now we deal with the second Main Mode Exchange. This is a DH exchange to generate shared secret keys.
You will see MMx which is Cisco’s state transitions as each sequence is performed.
MM1 – send an SA setup packet.
Feb 6 21:43:04.434 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Feb 6 21:43:04.438 GMT: ISAKMP (0:709): Old State = IKE_R_MM1 New State = IKE_R_MM1
Feb 6 21:43:04.438 GMT: ISAKMP (0:709): sending packet to 200.100.1.1 my_port 500 peer_port 500 (R) MM_SA_SETUP
Feb 6 21:43:04.438 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Packet send successfully therefore transition to MM2
Feb 6 21:43:04.438 GMT: ISAKMP (0:709): Old State = IKE_R_MM1 New State = IKE_R_MM2
Feb 6 21:43:05.378 GMT: ISAKMP (0:709): received packet from 200.100.1.1 dport 500 sport 500 Global (R) MM_SA_SETUP
Feb 6 21:43:05.378 GMT: ISAKMP (0:709): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
We received the IKE packet back from the peer. Now we move from MM2 to MM3
Feb 6 21:43:05.378 GMT: ISAKMP (0:709): Old State = IKE_R_MM2 New State = IKE_R_MM3
Feb 6 21:43:05.382 GMT: ISAKMP (0:709): processing KE payload. message ID = 0
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): processing NONCE payload. message ID = 0
Feb 6 21:43:05.422 GMT: ISAKMP: Looking for a matching key for 200.100.1.1 in default : success
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): found peer pre-shared key matching 200.100.1.1
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): SKEYID state generated
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): Old State = IKE_R_MM3 New State = IKE_R_MM3
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): sending packet to 200.100.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
We received the DH key info from the peer and it checks out! Great. Now we do the thirsd MM exchange. We verify the peers identity uising IP address
Sending our packet out. Transition to MM4
Feb 6 21:43:05.422 GMT: ISAKMP (0:709): Old State = IKE_R_MM3 New State = IKE_R_MM4
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): received packet from 200.100.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Successfully received packet from peer. to MM5
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): Old State = IKE_R_MM4 New State = IKE_R_MM5
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): processing ID payload. message ID = 0
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): ID payload
next-payload : 8
type : 1
address : 200.100.1.1
protocol : 0
port : 0
length : 12
At this point, the peer (the Linksys) has sent its identity info as per the 3rd main mode exchange of IKE Phase 1. The error message below is a bit of a red herring. It relates to a specific IPSEC config the router checks for. See here for more info. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_vrfip.htm
It can be safely ignored..
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): peer matches *none* of the profiles
Now we need to check the hash of the identity data
Feb 6 21:43:06.942 GMT: ISAKMP (0:709): processing HASH payload. message ID = 0
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA authentication status:
Feb 6 21:43:06.946 GMT: authenticated
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA has been authenticated with 200.100.1.1
Great – everything checks out. Again, ignore the next message
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): peer matches *none* of the profiles
Now we send our ID info to the Linksys peer to complete the 3rd exchange of Main Mode Phase 1.
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_R_MM5 New State = IKE_R_MM5
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): ID payload
next-payload : 8
type : 1
address : 200.56.4.1
protocol : 17
port : 500
length : 12
Feb 6 21:43:06.946 GMT: ISAKMP (709): Total payload length: 12
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): sending packet to 200.100.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Great! It looks like it all has worked as expected.
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Feb 6 21:43:06.946 GMT: ISAKMP (0:709): Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Wohoo! Phase 1 is complete. Now we move to Phase 2 and do some real work. Now in Phase II, there is one mode called Quick mode and it is a 3 way exchange. First we get a packet from the originating peer – the Linksys. We check the hash and then the security association payload.
Feb 6 21:43:07.894 GMT: ISAKMP (0:709): received packet from 200.100.1.1 dport 500 sport 500 Global (R) QM_IDLE
Feb 6 21:43:07.894 GMT: ISAKMP: set new node -841765728 to QM_IDLE
Feb 6 21:43:07.894 GMT: ISAKMP (0:709): processing HASH payload. message ID = -841765728
Feb 6 21:43:07.894 GMT: ISAKMP (0:709): processing SA payload. message ID = -841765728
We have an IPSEC proposal to examine. Does it match our end?
Feb 6 21:43:07.894 GMT: ISAKMP (0:709): Checking IPSec proposal 1
Feb 6 21:43:07.894 GMT: ISAKMP: transform 1, ESP_3DES
Feb 6 21:43:07.894 GMT: ISAKMP: attributes in transform:
Feb 6 21:43:07.894 GMT: ISAKMP: SA life type in seconds
Feb 6 21:43:07.894 GMT: ISAKMP: SA life duration (VPI) of 0×0 0×1 0×51 0×80
Feb 6 21:43:07.898 GMT: ISAKMP: group is 2
Feb 6 21:43:07.898 GMT: ISAKMP: encaps is 1 (Tunnel)
Feb 6 21:43:07.898 GMT: ISAKMP: authenticator is HMAC-SHA
Yes this proposal matches! Now we send our proposal and acceptance!
Feb 6 21:43:07.898 GMT: ISAKMP (0:709): atts are acceptable.
Feb 6 21:43:07.898 GMT: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 200.56.4.1, remote= 200.100.1.1,
local_proxy= 192.168.100.0/255.255.255.0/0/0 (type=4),
remote_proxy= 172.18.30.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0×0(0), conn_id= 0, keysize= 0, flags= 0×22
Feb 6 21:43:07.930 GMT: ISAKMP (0:709): processing NONCE payload. message ID = -841765728
Feb 6 21:43:07.930 GMT: ISAKMP (0:709): processing KE payload. message ID = -841765728
Feb 6 21:43:07.974 GMT: ISAKMP (0:709): processing ID payload. message ID = -841765728
Feb 6 21:43:07.974 GMT: ISAKMP (0:709): processing ID payload. message ID = -841765728
Feb 6 21:43:07.974 GMT: ISAKMP (0:709): asking for 1 spis from ipsec
Feb 6 21:43:07.974 GMT: ISAKMP (0:709): Node -841765728, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Feb 6 21:43:07.974 GMT: ISAKMP (0:709): Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE
Feb 6 21:43:07.974 GMT: IPSEC(key_engine): got a queue event…
Feb 6 21:43:07.974 GMT: IPSEC(spi_response): getting spi 1387857340 for SA
from 200.56.4.1 to 200.100.1.1 for prot 3
Feb 6 21:43:07.974 GMT: ISAKMP: received ke message (2/1)
Feb 6 21:43:08.226 GMT: ISAKMP (0:709): sending packet to 200.100.1.1 my_port 500 peer_port 500 (R) QM_IDLE
Okay we have sent our Quick Mode reply packet to the Linksys
Feb 6 21:43:08.226 GMT: ISAKMP (0:709): Node -841765728, Input = IKE_MESG_FROM_IPSEC, IKE_SPI_REPLY
Feb 6 21:43:08.226 GMT: ISAKMP (0:709): Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2
We have received the acknoweledgement from the peer and can proceed to build the IPSEC Security Association!
Feb 6 21:43:09.758 GMT: ISAKMP (0:709): received packet from 200.100.1.1 dport 500 sport 500 Global (R) QM_IDLE
Feb 6 21:43:09.758 GMT: ISAKMP (0:709): Creating IPSec SAs
Feb 6 21:43:09.758 GMT: inbound SA from 200.100.1.1 to 200.56.4.1 (f/i) 0/ 0
(proxy 172.18.30.0 to 192.168.100.0)
Feb 6 21:43:09.762 GMT: has spi 0×52B905BC and conn_id 5810 and flags 23
Feb 6 21:43:09.762 GMT: lifetime of 86400 seconds
Feb 6 21:43:09.762 GMT: has client flags 0×0
Feb 6 21:43:09.762 GMT: outbound SA from 200.56.4.1 to 200.100.1.1 (f/i) 0/ 0 (proxy 192.168.100.0 to 172.18.30.0 )
Feb 6 21:43:09.762 GMT: has spi -841765728 and conn_id 5811 and flags 2B
Feb 6 21:43:09.762 GMT: lifetime of 86400 seconds
Feb 6 21:43:09.762 GMT: has client flags 0×0
Feb 6 21:43:09.762 GMT: ISAKMP (0:709): deleting node -841765728 error FALSE reason "quick mode done (await)"
Feb 6 21:43:09.762 GMT: ISAKMP (0:709): Node -841765728, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Feb 6 21:43:09.762 GMT: ISAKMP (0:709): Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE
Yay! Phase II completed as well. Build that SA then!
Feb 6 21:43:09.762 GMT: IPSEC(key_engine): got a queue event…
Feb 6 21:43:09.762 GMT: IPSEC(initialize_sas): ,
(key eng. msg.) INBOUND local= 200.56.4.1, remote= 200.100.1.1,
local_proxy= 192.168.100.0/255.255.255.0/0/0 (type=4),
remote_proxy= 172.18.30.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 86400s and 0kb,
spi= 0×52B905BC(1387857340), conn_id= 5810, keysize= 0, flags= 0×23
Feb 6 21:43:09.762 GMT: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= 200.56.4.1, remote= 200.100.1.1,
local_proxy= 192.168.100.0/255.255.255.0/0/0 (type=4),
remote_proxy= 172.18.30.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 86400s and 0kb,
spi= 0xCDD3ACA0(3453201568), conn_id= 5811, keysize= 0, flags= 0×2B
Feb 6 21:43:09.762 GMT: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and 200.100.1.1
Feb 6 21:43:09.762 GMT: IPSEC(add mtree): src 192.168.100.0, dest 172.18.30.0, dest_port 0Feb 6 21:43:09.762 GMT: IPSEC(create_sa): sa created,
(sa) sa_dest= 200.56.4.1, sa_prot= 50,
sa_spi= 0×52B905BC(1387857340),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 5810
Feb 6 21:43:09.762 GMT: IPSEC(create_sa): sa created,
(sa) sa_dest= 200.100.1.1, sa_prot= 50,
sa_spi= 0xCDD3ACA0(3453201568),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 5811
Done! Now lets use the Cisco show commands to have a look at the ISAKMP SA and IPSEC sa’s.
Checking IPSEC Status
RTCI01#sh cry
RTCI01#sh crypto isa
RTCI01#sh crypto isakmp sa
dst src state conn-id slot
xxxxxx 200.100.1.1 QM_IDLE 673 0
200.56.4.1 200.100.1.1 QM_IDLE 709 0
xxxxxx 200.100.1.1 QM_IDLE 697 0
xxxxxx 200.100.1.1 QM_IDLE 674 0
RTCI01#sh crypto ipsec sa
interface: FastEthernet0/1
Crypto map tag: IPSEC, local addr. 200.56.4.1
protected vrf:
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.18.30.0/255.255.255.0/0/0)
current_peer: 200.100.1.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 200.56.4.1, remote crypto endpt.: 200.100.1.1
path mtu 1500, media mtu 1500
current outbound spi: CDD3ACA0
inbound esp sas:
spi: 0×52B905BC(1387857340)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 5810, flow_id: 2827, crypto map: PIVoD
sa timing: remaining key lifetime (k/sec): (4573743/3565)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xCDD3ACA0(3453201568)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 5811, flow_id: 2828, crypto map: PIVoD
sa timing: remaining key lifetime (k/sec): (4573743/3562)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
Leave a Reply