Troubleshooting IPsec Site-to-Site VPNs in Cisco IOS
When you implement a new VPN, there may be a problem or two. So, let’s walk through the verification of the tunnel, and if we discover it not working, I will show you some of my favorite commands to assist in the troubleshooting process.
Let’s first of all verify our configuration so that we can confirm that what we have running on the router is what we configured, starting with Example 7-4.
Example 7-4 Verifying the IPsec Configuration
! This verifies the IKEv1 Phase 1 policy or policies in place. The lower
! the number of the policy, the higher its priority.
R1# show crypto isakmp policy
Global IKEv1 policy
Protection suite of priority 1
encryption algorithm: AES - Advanced Encryption Standard (256 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #5 (1536 bit)
lifetime: 3600 seconds, no volume limit
! Next is my favorite command, as it shows virtually all of the rest of the
! config including the transform set and crypto ACLs involved, and where
! the crypto map is applied
R1# show crypto map
Crypto Map "MYMAP" 1 ipsec-isakmp
Peer = 209.165.201.1
Extended IP access list 100
access-list 100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0
0.0.0.255
Current peer: 209.165.201.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): Y
DH group: group2
Transform sets={
MYSET: { esp-aes esp-sha-hmac } ,
}
Interfaces using crypto map MYMAP:
GigabitEthernet1/0
Armed with this information, a packet from the 172.16.0.0 network destined to the 192.168.0.0 network should trigger the IPsec process. We can test this without even leaving the router console. Because R1 is connected to the 172.16.0.0 network, we can craft a ping request sourced from that network (interface g1/0) and destined for the 192.168.0.2 address or R2, as shown in Example 7-5.
Example 7-5 Interesting Traffic to Trigger IPsec
R1# ping 192.168.0.2 source g1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 209.165.200.225
U.U.U
Success rate is 0 percent (0/5)
R1#
The ping is being replied to with U.U.U messages. The U represents an ICMP unreachable message being sent to us from one of the Internet routers (probably our directly connected one). If our policy was not applied correctly, it may be possible that we are trying to send packets to 192.168.0.2, and when the service providers see these packets, they are denying them because they are addresses in the RFC 1918 address space (which are not being allowed on the Internet). If the packet had been successfully encapsulated into IPsec’s Layer 4 protocol 50 (ESP), the Internet would have seen a packet destined to the Layer 3 global address of 209.165.201.1, sourced from the global address of R1.
Let’s begin the troubleshooting! We may want to go to R2 and do the same show commands we did on R1. If R2 is not accessible via the CLI at the moment, we could also do some additional testing at R1 using debug commands specifically for IPsec Phase 1 and Phase 2. For IKEv1 Phase 1 debugging, we could use the commands shown in Example 7-6.
Example 7-6 Debug Used for Troubleshooting IKEv1 Phase 1
! debug the IKEv1 Phase 1 process
R1# debug crypto isakmp
Crypto ISAKMP debugging is on
! Generate interesting traffic that should match the ACLs used in the crypto map
R1# ping 192.168.0.2 source g1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 209.165.200.225
U.U.U
Success rate is 0 percent (0/5)
With the debugging of IKEv1 Phase 1 on, and then using the ping again, we see no output from the debug. This implies that either IKEv1 Phase 1 is already up and does not need to be negotiated, or if it is currently not up, no interesting traffic is triggering it. This could be due to a down interface, a misapplied crypto map, or routing that is not trying to forward traffic out the interface that has the crypto map applied. Let’s take a closer look, as shown in Example 7-7.
Example 7-7 Troubleshooting by Verifying Configuration
R1# show crypto map
Crypto Map "MYMAP" 1 ipsec-isakmp
Peer = 209.165.201.1
Extended IP access list 100
access-list 100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0 0.0.0.255
Current peer: 209.165.201.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): Y
DH group: group2
Transform sets={
MYSET: { esp-aes esp-sha-hmac } ,
}
Interfaces using crypto map MYMAP:
GigabitEthernet1/0
R1# show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
GigabitEthernet1/0 209.165.200.225 YES manual up up
GigabitEthernet2/0 172.16.0.1 YES manual up up
! Just as before, the crypto map appears to be applied to the correct
! interface, and the interfaces are both up. Let's next check to see if
! there is an IKEv1 Phase 1 tunnel already in place
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
! The output of the above command indicates that there is no current IKEv1
! Phase 1 tunnel in place. Let's check routing, to see if R1 would even
! try to forward packets to 192.168.0.2 through its G1/0 interface.
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 209.165.200.226 to network 0.0.0.0
C 172.16.0.0/16 is directly connected, GigabitEthernet2/0
209.165.200.0/24 is subnetted, 1 subnets
C 209.165.200.0 is directly connected, GigabitEthernet1/0
S* 0.0.0.0/0 [1/0] via 209.165.200.226
! The show IP route output indicates that R1 would use its G1/0 interface
! to use the default gateway of 209.165.200.226 We know that the internet router
! is there, because we received the U messages earlier from him.
! Sometimes, when making configuration changes regarding IPsec,
! the VPN device may become confused If there is no VPN traffic working,
! I have found that removing and re-applying the crypto map on the
! interface is often helpful in re-starting the IPsec process on the
! router. Let's try that next on R1.
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# int g1/0
R1(config-if)# no crypto map MYMAP
R1(config-if)# crypto map MYMAP
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
R1(config-if)# crypto map MYMAP
R1(config-if)#
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#
! I see that ISAKMP turned itself off, when the map was removed and was
! turned back on when the map was replaced, based on the console messages.
! ISAKMP stands for Internet Security Association Key Management Protocol
! Now let's try the ping again.
! Debugging is still on.
R1# show debug
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
R1# ping 192.168.0.2 source g1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 209.165.200.225
U.U.U
Success rate is 0 percent (0/5)
R1#
Same result as before. So, why are we going through the pain of troubleshooting? Because this is a skill that you deserve to have, and by going through it together, it will make your skills better for the real world. Before we go too much further, let’s pause and examine our test ping. A common mistake people make is assuming the VPN should come up, even if there is no interesting traffic (matching the crypto ACLs).
In our ping, we are sourcing the ping from the G1/0 interface (this interface is not the one in the 172.16.0.0/16 network), and therefore as a result the packet is not matching the crypto access control list (ACL). The router does not think it should apply IPsec to it, so it sends the ping out as a plain text. The original source and destination IP addresses have not changed, which would cause the service provider to deny that traffic.
Armed with the knowledge that our test ping had an issue, let’s leave the debug on and try the ping, as shown in Example 7-8.
Example 7-8 Test Ping Using the Correct Source Interface and Associated IP Address
R1# ping 192.168.0.2 source g2/0
! Although there is lots of interesting output, I will point out the
! more relevant information regarding our troubleshooting
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
! Note the correct source address, important if we want to match the crypto
! acls
Packet sent with a source address of 172.16.0.1
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 209.165.201.1, peer port 500
ISAKMP: New peer created peer = 0x6A76F7A0 peer_handle = 0x80000005
ISAKMP: Locking peer struct 0x6A76F7A0, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP:(0):insert sa successfully sa = 66570618
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):No pre-shared key with 209.165.201.1!
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKEv1_MESG_FROM_IPSEC, IKEv1_SA_REQ_MM
ISAKMP:(0):Old State = IKEv1_READY New State = IKEv1_I_MM1
ISAKMP:(0): beginning Main Mode exchange
! R1 is the initiator, and so he is sending the first packet, trying
! to negotiate a compatible IKEv1 Phase 1 policy with R2
ISAKMP:(0): sending packet to 209.165.201.1 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP:(0):Sending an IKEv1 IPv4 Packet.
ISAKMP (0): received packet from 209.165.201.1 dport 500 sport 500 Global (I)
MM_NO_STATE
ISAKMP:(0):Notify has no hash. Rejected.
ISAKMP (0): Unknown Input IKEv1_MESG_FROM_PEER, IKEv1_INFO_NOTIFY: state =
IKEv1_I_MM1
ISAKMP:(0):Input = IKEv1_MESG_FROM_PEER, IKEv1_INFO_NOTIFY
ISAKMP:(0):Old State = IKEv1_I_MM1 New State = IKEv1_I_MM1
! This line below is bad news. IKEv1 Phase 1 failed.
%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at
209.165.201.1
! And our pings didn't make it either (no VPN tunnel working yet).
.....
Success rate is 0 percent (0/5)
! The IKEv1 Phase 1 tunnel has a state of MM_NO_STATE which is not good
! We want to see a state of QM_IDLE, meaning the IKEv1 Phase 1 is up, in the
! output of the following command, that shows the state of the IKEv1 Phase 1
! tunnel
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
209.165.201.1 209.165.200.225 MM_NO_STATE 0 ACTIVE
Perhaps R2 is not configured correctly. If IKEv1 Phase 1 had completed, we could investigate IKEv1 Phase 2, but due to Phase 1 failing, that is the first thing to check on R2. If the IKEv1 Phase 1 policy matches on R2, we would also want to verify that R2 has a digital certificate to use with the RSA-Signatures. Let’s look at R2’s policy, as shown in Example 7-9.
Example 7-9 Verifying the Configuration on R2
R2# show crypto isakmp policy
Global IKEv1 policy
Protection suite of priority 1
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #5 (1536 bit)
lifetime: 3600 seconds, no volume limit
! Based on the output, it appears the encryption algorithm for R2's IKEv1
! Phase 1 is set for 3DES, and R1 was set for AES 256. That is a problem.
! Let's make the change on R2, enable debugging, and see if we get a better
! result.
! Change the policy on R2
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encryption aes 256
R2(config-isakmp)# end
! Enable debug of IKEv1 Phase 1 and issue the ping from R2 to trigger the
! crypto ACLs (which are in the crypto map, which is applied to the
! interface)
R2# debug crypto isakmp
Crypto ISAKMP debugging is on
R2# ping 172.16.0.1 source g2/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 209.165.200.225, peer port 500
ISAKMP: New peer created peer = 0x6816E21C peer_handle = 0x80000006
ISAKMP: Locking peer struct 0x6816E21C, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP:(0):insert sa successfully sa = 671E34DC
! The two modes for IKEv1 Phase 1 are aggressive, or main. R2 is going to
! use main mode.
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
! R2 won't be needing a pre-shared key with R1 for authentication, due to
! it using digital signatures
ISAKMP:(0):No pre-shared key with 209.165.200.225!
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKEv1_MESG_FROM_IPSEC, IKEv1_SA_REQ_MM
ISAKMP:(0):Old State = IKEv1_READY New State = IKEv1_I_MM1
ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 209.165.200.225 my_port 500 peer_port 500 (I)
MM_NO_STATE
ISAKMP:(0):Sending an IKEv1 IPv4 Packet.
ISAKMP (0): received packet from 209.165.200.225 dport 500 sport 500 Global (I)
MM_NO_STATE
ISAKMP:(0):Input = IKEv1_MESG_FROM_PEER, IKEv1_MM_EXCH
ISAKMP:(0):Old State = IKEv1_I_MM1 New State = IKEv1_I_MM2
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP : Scanning profiles for xauth ...
! Looks like these two peers have found a compatible policy. It is the
! contents of the policy that need to be compatible, not the literal policy
! priority number The debug shows the word "transform" but should not be
! confused with IKEv1 Phase 2 which occurs only after IKEv1 Phase 1 (whose
! policy is shown below) is complete.
ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy
ISAKMP: encryption AES-CBC
ISAKMP: keylength of 256
ISAKMP: hash SHA
ISAKMP: default group 5
ISAKMP: auth RSA sig
ISAKMP: life type in seconds
ISAKMP: life duration (basic) of 3600
! The peers have agreed on the IKEv1 Phase 1 policy.
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0):Acceptable atts:actual life: 0
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Basic life_in_seconds:3600
ISAKMP:(0):Returning Actual lifetime: 3600
ISAKMP:(0)::Started lifetime timer: 3600.
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unit.y/DPD but major 69 mismatch
ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP:(0):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKEv1_I_MM2 New State = IKEv1_I_MM2
! Next 40 or so lines include getting the certificate from the other side,
! so that this router will have a copy of the peer's public key, and
! performing RSA authentication with the peer.
ISAKMP (0): constructing CERT_REQ for issuer cn=CA
ISAKMP:(0): sending packet to 209.165.200.225 my_port 500 peer_port 500 (I)
MM_SA_SETUP
ISAKMP:(0):Sending an IKEv1 IPv4 Packet.
ISAKMP:(0):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKEv1_I_MM2 New State = IKEv1_I_MM3
ISAKMP (0): received packet from 209.165.200.225 dport 500 sport 500 Global (I)
MM_SA_SETUP
ISAKMP:(0):Input = IKEv1_MESG_FROM_PEER, IKEv1_MM_EXCH
ISAKMP:(0):Old State = IKEv1_I_MM3 New State = IKEv1_I_MM4
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(1004): processing CERT_REQ payload. message ID = 0
ISAKMP:(1004): peer wants a CT_X509_SIGNATURE cert
ISAKMP:(1004): peer wants cert issued by cn=CA
Choosing trustpoint CA as issuer
ISAKMP:(1004): processing vendor id payload
ISAKMP:(1004): vendor ID is Unity
ISAKMP:(1004): processing vendor id payload
ISAKMP:(1004): vendor ID is DPD
ISAKMP:(1004): processing vendor id payload
ISAKMP:(1004): speaking to another IOS box!
ISAKMP:received payload type 20
ISAKMP (1004): His hash no match - this node outside NAT
ISAKMP:received payload type 20
ISAKMP (1004): No NAT Found for self or peer
ISAKMP:(1004):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_MAIN_MODE
ISAKMP:(1004):Old State = IKEv1_I_MM4 New State = IKEv1_I_MM4
ISAKMP:(1004):Send initial contact
ISAKMP:(1004):My ID configured as IPv4 Addr, but Addr not in Cert!
ISAKMP:(1004):Using FQDN as My ID
ISAKMP:(1004):SA is doing RSA signature authentication using id type ID_FQDN
ISAKMP (1004): ID payload
next-payload : 6
type : 2
FQDN name : R2.cisco.com
protocol : 17
port : 500
length : 20
ISAKMP:(1004):Total payload length: 20
ISAKMP (1004): constructing CERT payload for hostnam.e=R2.cisco.com
ISAKMP:(1004): using the CA trustpoint's keypair to sign
ISAKMP:(1004): sending packet to 209.165.200.225 my_port 500 peer_port 500 (I)
MM_KEY_EXCH
ISAKMP:(1004):Sending an IKEv1 IPv4 Packet.
ISAKMP:(1004):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_COMPLETE
ISAKMP:(1004):Old State = IKEv1_I_MM4 New State = IKEv1_I_MM5
ISAKMP (1004): received packet from 209.165.200.225 dport 500 sport 500 Global (I)
MM_KEY_EXCH
ISAKMP:(1004): processing ID payload. message ID = 0
ISAKMP (1004): ID payload
next-payload : 6
type : 2
FQDN name : R1.cisco.com
protocol : 17
port : 500
length : 20
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(1004): processing CERT payload. message ID = 0
ISAKMP:(1004): processing a CT_X509_SIGNATURE cert
ISAKMP:(1004): peer's pubkey is cached
ISAKMP:(1004): Unable to get DN from certificate!
ISAKMP:(1004): Cert presented by peer contains no OU field.
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(1004): processing SIG payload. message ID = 0
ISAKMP:(1004):SA authentication status:
authenticated
! The IKEv1 Phase 1 authentication completed successfully
ISAKMP:(1004):SA has been authenticated with 209.165.200.225
ISAKMP: Trying to insert a peer 209.165.201.1/209.165.200.225/500/, and inserted
successfully 6816E21C.
ISAKMP:(1004):Input = IKEv1_MESG_FROM_PEER, IKEv1_MM_EXCH
ISAKMP:(1004):Old State = IKEv1_I_MM5 New State = IKEv1_I_MM6
ISAKMP:(1004):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_MAIN_MODE
ISAKMP:(1004):Old State = IKEv1_I_MM6 New State = IKEv1_I_MM6
ISAKMP:(1004):Input = IKEv1_MESG_INTERNAL, IKEv1_PROCESS_COMPLETE
ISAKMP:(1004):Old State = IKEv1_I_MM6 New State = IKEv1_P1_COMPLETE
! Now that IKEv1 Phase 1 is complete, IKEv1 Phase 2 (quick mode) can begin.
ISAKMP:(1004):beginning Quick Mode exchange, M-ID of -534639709
ISAKMP:(1004):QM Initiator gets spi
ISAKMP:(1004): sending packet to 209.165.200.225 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1004):Sending an IKEv1 IPv4 Packet.
ISAKMP:(1004):Node -534639709, Input = IKEv1_MESG_INTERNAL, IKEv1_INIT_QM
ISAKMP:(1004):Old State = IKEv1_QM_READY New State = IKEv1_QM_I_QM1
ISAKMP:(1004):Input = IKEv1_MESG_INTERNAL, IKEv1_PHASE1_COMPLETE
ISAKMP:(1004):Old State = IKEv1_P1_COMPLETE New State = IKEv1_P1_COMPLETE
ISAKMP (1004): received packet from 209.165.200.225 dport 500 sport 500 Global (I)
QM_IDLE
ISAKMP: set new node -325744431 to QM_IDLE
ISAKMP:(1004): processing HASH payload. message ID = -325744431
ISAKMP:(1004): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
spi 3138923289, message ID = -325744431, sa = 671E34DC
ISAKMP:(1004): deleting spi 3138923289 message ID = -534639709
ISAKMP:(1004):deleting node -534639709 error TRUE reason "Delete Larval"
ISAKMP:(1004):deleting node -325744431 error FALSE reason "Informational (in) state 1"
ISAKMP:(1004):Input = IKEv1_MESG_FROM_PEER, IKEv1_INFO_NOTIFY
ISAKMP:(1004):Old State = IKEv1_P1_COMPLETE New State = IKEv1_P1_COMPLETE
! Bad news, the IKEv1 Phase 2 (the IPsec tunnel) didn't come up and allow the
! pings to work. All 5 pings are lost. The missing 3 periods are
! embedded in the debug messages above.
..
Success rate is 0 percent (0/5)
R2#
With IKEv1 Phase 1 working, let’s focus on IKEv1 Phase 2 and see whether we can resolve the problem (because the pings did not make it through) by comparing the IKEv1 Phase 2 components on both R1 an R2, as shown in Example 7-10.
Example 7-10 Troubleshooting IKEv1 Phase 2, the IPsec Tunnel
R1# show crypto map
Crypto Map "MYMAP" 1 ipsec-isakmp
Peer = 209.165.201.1
Extended IP access list 100
access-list 100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0
0.0.0.255
Current peer: 209.165.201.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): Y
DH group: group2
Transform sets={
MYSET: { esp-aes esp-sha-hmac } ,
}
Interfaces using crypto map MYMAP:
GigabitEthernet1/0
! Let's check the other router
R2# show crypto map
Crypto Map "MYMAP" 1 ipsec-isakmp
Peer = 209.165.200.225
Extended IP access list 100
access-list 100 permit ip 192.168.0.0 0.0.0.255 172.16.0.0
0.0.255.255
Current peer: 209.165.200.225
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Transform sets={
MYSET: { esp-aes esp-sha-hmac } ,
}
Interfaces using crypto map MYMAP:
GigabitEthernet1/0
! Based on the output, it looks like R1 is configured to use PFS group 2,
! and R2 isn't. Let's correct this on R2, and retry the ping.
R2(config)# crypto map MYMAP 1 ipsec-isakmp
R2(config-crypto-map)# set pfs group2
R2(config-crypto-map)# end
! Now let's try that ping
R2# ping 172.16.0.1 source g2/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/38/44 ms
R2#
! The first ping may have timed out before the IPsec tunnel (Phase 2) had been
! established, but the rest of the pings and future pings can take
! advantage of the existing tunnel and should work.
R2# ping 172.16.0.1 source g2/0 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 100 percent (500/500), round-trip min/avg/max = 20/39/68 ms
R2#
! To verify the IKEv1 Phase 1 and 2 tunnels, we can use these commands:
R2# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
209.165.200.225 209.165.201.1 QM_IDLE 1004 ACTIVE
! QM_IDLE is the desired state for the output of the above command
R2# show crypto isakmp sa detail
Codes: C - IKEv1 configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
T - cTCP encapsulation, X - IKEv1 Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1004 209.165.201.1 209.165.200.225 ACTIVE aes sha rsig 5 00:55:54
! This verifies a functioning IKEv1 Phase 1 (QM_IDLE,ACTIVE) and the detail
! option reveals that the IKEv1 Phase 1 used RSA signatures for
! authentication, AES for encryption, SHA for hashing and DH group 5, with
! the remaining lifetime from what was initially agreed to by the peers.
! To verify the IPsec (IKEv1 Phase 2) tunnel, we can do so with the following
! command:
R2# show crypto ipsec sa
interface: GigabitEthernet1/0
Crypto map tag: MYMAP, local addr 209.165.201.1
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)
current_peer 209.165.200.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 504, #pkts encrypt: 504, #pkts digest: 504
#pkts decaps: 504, #pkts decrypt: 504, #pkts verify: 504
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 11, #recv errors 0
local crypto endpt.: 209.165.201.1, remote crypto endpt.: 209.165.200.225
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1/0
current outbound spi: 0x3BE5B517(1004909847)
PFS (Y/N): Y, DH group: group2
! Inbound Security Association (SA/tunnel) from traffic coming from the
! other peer
inbound esp sas:
spi: 0x87F1D10A(2280771850)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 9, flow_id: SW:9, sibling_flags 80000046, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4558182/3257)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
! Not using AH, so no inbound AH SA
inbound ah sas:
! Outbound Security Association (SA/tunnel) for traffic going to the other
! peer
outbound esp sas:
spi: 0x3BE5B517(1004909847)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 10, flow_id: SW:10, sibling_flags 80000046, crypto map: MYMAP
sa timing: remaining key lifetime (k/sec): (4558182/3257)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
! Not using AH, so no outbound AH SA
outbound ah sas:
! These outputs have been detailed in earlier chapters, but it is relevant
! to know that there are 2 SA (security associations) with the IKEv1 Phase 2
! (IPsec). One SA for outbound to the other peer, and another for the
! inbound from that peer. We can also see the encrypt and decrypt count for
! each of the SAs.
! One more command that is useful in seeing a bird's eye view of the
! cryptography is this:
R2# show crypto engine connections active
Crypto Engine Connections
ID Type Algorithm Encrypt Decrypt IP-Address
9 IPsec AES+SHA 0 504 209.165.201.1
10 IPsec AES+SHA 504 0 209.165.201.1
1004 IKEv1 SHA+AES256 0 0 209.165.201.1
There are other alternative site-to-site VPN technologies:
Dynamic Multipoint VPN (DMVPN)
FlexVPN
DMVPN is a Cisco solution for deploying highly scalable IPsec site-to-site VPNs. DMVPN uses a centralized architecture to enable the network administrator to deploy granular access controls. It enables branch locations to communicate directly with each other over the Internet without requiring a permanent VPN connection between sites.
FlexVPN is a unified VPN solution that can be deployed over either public Internet connections or a private Multiprotocol Label Switching (MPLS) VPN network. FlexVPN is designed for the concentration of both site-to-site and remote access VPNs. One FlexVPN deployment can accept both types of connection requests at the same time. It uses dynamic routing protocols for redundancy and path/head-end selection.