SITE to SITE IPSEC VPN PHASE-1 And PHASE-2 Troubleshooting step

Aug 30, 20224 min read

Updated: Jan 21

Troubleshooting

Four most common issues we generally face:

Phase 1 (ISAKMP) security associations fail
Phase 2 (IPsec) security associations fail
VPN Tunnel is established, but no traffic passing through
Intermittent VPN flapping and disconnection

Phase-1 and Phase-2 configuration should be identical on both sides 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 does not come up. Make sure your encryption setting, authentication, hashes, and lifetime, etc. should be the same for both ends of the tunnel for the Phase 1 proposal.

Checklist for Phase 1:

ISAKMP parameters match exactly.
Pre-shared keys match exactly.
Peer IP should be reachable/pingable from your firewall.
Enable ISAKMP on the outside interfaces.
ESP traffic permitted through the outside interface.
UDP port 500 open on the outside ACL.
In some situations, UDP port 4500 needs to be open for the outside.

In Phase-I, 6 messages are shared between both peers. Find all the messages below (this is very important for an interview as well):

Message 1:

Negotiation States and Messages MM_WAIT_MSG1

Message 2:

Initiator sent encryption, hashes, and DH (Diffie–Hellman) to responder and awaiting the initial reply from the other end gateway. If initiator is stuck at MM_WAIT_MSG2, it means the remote end is not responding to initiator.This happens due to the following issues:

Routing issue at remote end.
Remote end does not have 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.

Message 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 the receiver.If tunnel is stuck in this state, it could be due to the following reasons:

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 is waiting for the Pre-shared key from the receiver until it gets the pre-shared key.If stuck in this state, below are the reasons:

Missing a tunnel group.
Pre-shared key mismatch.

Message 5:

Initiator received its Pre-Shared-Key hash from the receiver. If the receiver has a tunnel group and PSK configured for the initiator's peer address, it sends its PSK hash to the initiator.If tunnel is stuck in this phase, below are the reasons:

Initiator sees the Pre-Shared-Key does not match.
NAT-T on and should be off.

Message 6:

Initiator sees if Pre-Shared-Key hashes match. If Pre-Shared-Key matches, initiator state becomes MM_ACTIVE.If tunnel is stuck in this phase, below are the reasons:

Pre-Shared-Key doesn't match.
NAT-T on and should be off.

MM_ACTIVEMM_ACTIVE means acknowledgment from initiator and negotiation has completed successfully.

Below are some screenshots of issues for Phase 1—use debug commands to troubleshoot.

Mismatch Hash algorithm in the ISAKMP policy

Mismatch Diffie-Hellman Group in ISAKMP policy

Mismatch Authentication type in ISAKMP policy

Preshared key mismatch

Phase 2 (IPsec) Security Associations Fail

Check that the Phase 2 proposal encryption algorithm, authentication algorithm (or hash), and lifetime are the same on both sides.
Ensure the VPN Encryption Domain (local and remote subnet) is identical.
Verify that the correct ACL is bound with the Crypto Map.
Check the firewall inside local route to reach the inside hosted network/servers.
Ensure the remote subnet does not overlap with your local LAN.
Verify NAT Exemption.
Check the Perfect Forward Secrecy (PFS) setting if you're using it.
Confirm that the tunnel is bound to the public-facing interface (crypto map outside_map interface outside).

Once both phases are completed, generate some traffic to bring the tunnel up, such as an ICMP ping or a packet tracer.

You can view the Packet Encapsulation and Packet Decapsulation in Phase 2.

VPN Tunnel is Established, But Traffic is Not Passing Through

If traffic is not passing through the VPN tunnel or if the #pkts encaps and #pkts decaps are not happening as expected (and the numbers show zero), it could be due to the following reasons:

Check firewall policies and routing.
Run a packet tracer from the firewall and check VPN traffic flow.
Check the firewall inside local route to reach inside-hosted networks/servers.
Ensure the remote subnet does not overlap with your local LAN.
Make sure the new VPN policy does not overlap with existing policies.

You can try to resolve these issues with the above steps, and traffic should start passing. If the issue persists, you may need to change some encryption settings or consider upgrading your firmware.

Intermittent VPN Flapping and Disconnection

Ensure there have been no uncommunicated changes at the remote end.
Validate the encryption domain (local and remote subnets in the VPN); both ends should have identical and exact subnets.
Validate the Phase 1 and Phase 2 Lifetime settings on both ends of the tunnel (Phase 1 lifetime should be higher than Phase 2).
Verify the DPD (Dead Peer Detection) setting (if you're using a different vendor firewall, DPD should be disabled).
Carefully review the configuration and ensure the peer IP is not being NATTED.
Ensure the internet link is stable and there are no intermittent drops in connectivity.