Cisco ASA Packet Tracer Encrypt Type:VPN Result:Drop

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.

Problem

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 185.15.10.14 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.

Mismatch Policies

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_MSG5 or 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: 185.15.10.1
    Type    : L2L             Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG5

Tunnel-Group Misconfiguration

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: 195.95.10.1
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG4

There are no IKEv2 SAs

ACL Mismatch

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 = 195.95.10.1, IP = 195.95.10.1, Removing peer from correlator table failed, no match!
Jun 05 09:00:42 [IKEv1]Group = 195.95.10.1, IP = 195.95.10.1, Session is being torn down. Reason: User Requested
Jun 05 09:00:48 [IKEv1]Group = 195.95.10.1, IP = 195.95.10.1, Removing peer from correlator table failed, no match!
Jun 05 09:00:48 [IKEv1]Group = 195.95.10.1, IP = 195.95.10.1, 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.