SITE to SITE IPSEC VPN PHASE-1 And PHASE-2 Troubleshooting step
Troubleshooting ---------->>>
Four most common issue we generally face --
--> Phase 1 (ISAKMP) security associations fail
--> Phase 2 (IPsec) security associations fail
--> VPN Tunnel is established, but not traffic passing through
--> Intermittent vpn flapping and disconnection
Phase-1 and Phase-2 configuration should be identical of both side of the tunnel. It would be helpful if we can use a common vpn template and exchange the Phase-1 and Phase-2 SA between both parties before setting up the vpn tunnel.
Phase 1 (ISAKMP) security associations fail -->
Phase-1 of the tunnel not comes up. Make sure your encryption setting, authentication, hashes, and lifetime etc. should be same for both ends of the tunnel for the phase 1 proposal
Checklist of Phase 1 below -
ISAKMP parameters match exactly.
Pre-shared-keys match exactly.
Peer IP should be reachable/ping from your Firewall.
Enable ISAKMP on the outside interfaces.
ESP traffic permitted through the outside interface
UDP port 500 open on the outside ACL
Some situations UDP port 4500 need to open for the outside
in Phase-I 6 message share between both peer find all below message below (this is very import question for interview also)
Message 1 -
Negotiations States and Messages MM_WAIT_MSG1
Messages 2 -
Initiator sent encryption, hashes and DH ( Diffie–Hellman) to responder and Awaiting initial reply from other end gateway. If Initiator stuck at MM_WAIT_MSG2 means the remote end is not responding to Initiator,
This happen below issue
-->Routing issue at remote end
--> Remote end does not have configured ISAKMP enabled on the outside.
--> remote gateway ip is incorrect
--> Firewall is blocking connectivity somewhere between the two
--> Firewall blocking ISAKMP (usually UDP port 500)
--> Remote end peer is down
Messages 3 --
Initiator Received back its IKE policy to the Receiver. Initiator sends encryption, hash, DH and IKE policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from Receiver.
If tunnel stuck in this state may be following reason -
--> Mismatch in device vendors
--> Firewall in the way
--> ASA version mismatch
--> No return route to the initiating device
Message 4 -
Now the Initiator has received the IKE policy and sends the Pre-Shared-Key to Receiver and waiting preshared key from reciver until it get preshared key
If stuck in this state , below are the reason -
--> Missing a tunnel group
--> Pre-Shared-Key mismatched
Message 5 - Initiator Received its Pre-Shared-Key hash from Receiver. If receiver has a tunnel group and PSK configured for the initiators peer address, it sends its PSK hash to the initiator
if tunnel stuck in this face, below are the reason-
--> Initiator sees the Pre-Shared-Key do not match
--> NAT-T on and should be off
Message 6 - Initiator see if Pre-Shared-Key hashes match. If Pre-Shared-Key match, Initiator state becomes MM_ACTIVE
if tunnel stuck in this face , below are the follwoing reason
--> Pre-Shared-Key don’t match
--> NAT-T on and should be off
MM_ACTIVE - MM_ACTIVE means got acknowledge from initiator and negotiation has completed successfully
below are some screen shot of issue for phase 1- use debug
Mismatch Encryption in the ISAKMP policy
Mismatch Hash algorithm in the ISAKMP policy
Phase 2 (IPsec) security associations fail -- >
--> Check the phase 2 proposal encryption algorithm, authentication algorithm or hash, and lifetime are the same on both sides.
--> Check VPN Encryption Domain (Local and remote subnet) should be identical.
--> Check correct ACL should binding with Crypto Map
--> Check Firewall Inside local route to reach inside hosted network/servers
--> Make sure remote subnet should not overlap with your local Lan
--> Check NAT Exemption.
--> Check the PFS (perfect forward secrecy) if you are using.
--> tunnel is bound to the public facing interface (crypto map outside_map interface outside)
once both phases completed , we need to generate some traffic for tunnel up like ICMP or packet tracer.
you can see the Packet encap and Packet decap in the phase -II
VPN Tunnel is established, but traffic not passing through --
If the traffic not passing thru the vpn tunnel or packet #pkts encaps and #pkts decaps not happing as expected, and number should we zero.
due to below reason may be traffic not passing --
--> Check firewall policies and routing.
--> Run packet tracker from Firewall and check vpn traffic flow.
--> Check Firewall Inside local route to reach inside hosted network/servers
--> Make sure remote subnet should not overlap with your local Lan
--> Make sure new vpn policy should not overlap with existing policy
you can try to resolve above below issue after traffic will passing but if still issue not fix, there are other more step you may be change some encryption setting or you can upgrade your firmware.
intermittent vpn flapping and discontinuation --
--> Make sure there is no change done at remote end which you are not being notified.
--> Validate the encryption domain (Local and Remote subnet in the vpn) both end should have identical match and exact subnet.
--> Validate the Phase-1 and Phase-2 Lifetime settings at both ends of the tunnel (Phase-1 life time should be higher than Phase-2)
--> verify the DPD (Dead Peer Detection) setting (If you are using different vendor firewall DPD should be disabled.)
--> verify configuration in detail and make sure Peer IP should not be NATTED.
Make sure internet link should be stable and there is no intermittent drop in the connectivity.
Two most important commands when troubleshooting any vpn tunnel on a cisco device:
1. "show crypto isakmp sa" or "sh cry isa sa"
2. "show crypto ipsec sa" or "sh cry ips sa"
Below are the some screen shot of debug for phase-II
use this command for debug - debug crypto ipsec
mismatch of proposal set
Remote address not found
No comments