Setting up a site-to-site VPN is easy on the ASA, but the problem starts when the tunnel doesn't come up. It gets even harder if we don't control both ends of the tunnel. Often, the other side is managed by a third party, and we can't just log in to check what's going on.
Even though it's tempting to blame the other side when there's a problem, it's important for us to do our own checks first. We need to ensure that our side of the connection is working as it should.
our-asa# packet-tracer input insIDE tcp 192.168.20.10 25000 172.16.10.10 80 Phase: 1 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 18.104.22.168 using egress ifc OUTSIDE Phase: 2 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information: Phase: 3 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 4 Type: QOS Subtype: Result: ALLOW Config: Additional Information: Phase: 5 Type: VPN Subtype: encrypt Result: DROP Config: Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
These are the common issues that can cause a Cisco ASA VPN to drop packets during the encryption phase. These issues can range from a mismatch in Phase-1 policy, missing or incorrectly configured tunnel-group settings, to mismatched Access Control Lists (ACLs) on both ends of the VPN tunnel.
Phase-1 of setting up a VPN involves creating a secure channel between two VPN devices. It's where your devices agree on how to safely exchange information. But if something goes wrong here, your VPN connection won't even get off the ground.
In my personal experience, a common issue during this stage is the misconfiguration of IKEv1 policies. It's so important to double-check your configurations and ensure there's at least one policy that matches on both ends.
Depending on which side of the ASA you are on, you will see either
MM_WAIT_MSG6message with mismatch policies as shown below.
remote-asa# show crypto isa sa IKEv1 SAs: Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: 22.214.171.124 Type : L2L Role : responder Rekey : no State : MM_WAIT_MSG5
In a VPN setup, the tunnel-group configuration is a key part of establishing a secure connection. It contains the details about the remote peer that your ASA needs to set up the VPN.
If the other side of your VPN is missing the tunnel-group configuration, or if it's set up incorrectly, you could run into problems. Specifically, you might find that the VPN gets stuck at
MM_WAIT_MSG4 status when you check with the
show crypto isakmp sa command. This is a clue that there's a problem with the tunnel-group configuration on the other side.
our-asa# show crypto isa sa IKEv1 SAs: Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 1 1 IKE Peer: 126.96.36.199 Type : user Role : initiator Rekey : no State : MM_WAIT_MSG4 There are no IKEv2 SAs
The interesting traffic should match on both sides of the VPN. This means that the traffic we want to protect should be the same at both ends. However, the way we write the ACLs for this traffic will be inverted.
For example, if you're setting up a VPN between Site-1 and Site-B, your ACL at Site-1 might say that the source is Subnet-A and the destination is Subnet-B. But when you go to write the ACL at Site-B, you'll flip that around. The source will be Subnet-B, and the destination will be Subnet-A.
If you have a mismatch Phase-2 policy or ACL, the debug should output something like this.
debug crypto ikev1 1
our-asa# Jun 05 09:00:42 [IKEv1]Group = 188.8.131.52, IP = 184.108.40.206, Removing peer from correlator table failed, no match! Jun 05 09:00:42 [IKEv1]Group = 220.127.116.11, IP = 18.104.22.168, Session is being torn down. Reason: User Requested Jun 05 09:00:48 [IKEv1]Group = 22.214.171.124, IP = 126.96.36.199, Removing peer from correlator table failed, no match! Jun 05 09:00:48 [IKEv1]Group = 188.8.131.52, IP = 184.108.40.206, Session is being torn down. Reason: User Requested
If you want to learn more about ASA IPSec VPN troubleshooting, please check out my other blog post below.