cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
57211
Views
1
Helpful
7
Replies

IPSec l2l packet tracer type vpn subtype encrypt result DROP

StevieOliver_2
Level 1
Level 1

Hi

I've added a new subnet to an ACL for l2l VPN traffic.  I am not in control of the other end but the 3rd party assures me their acl matches.  However the new traffic does not cross the VPN.

When I do a packet tracer on the new subnet traffic I see the following error.

Phase: 9

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

out id=0x79c14270, priority=70, domain=encrypt, deny=false

        hits=1, user_data=0x0, cs_id=0x7929fcb8, reverse, flags=0x0, protocol=0

        src ip/id=172.26.22.0, mask=255.255.255.0, port=0

        dst ip/id=Remote_server_1, mask=255.255.255.255, port=0, dscp=0x0

        input_ifc=any, output_ifc=outside

However, I have checked the inside ACL, the crypto ACL and the No NATs and all seem fine.

When I do a debug crypto isa sa I see the following error

Received non-routine Notify message: Invalid ID info (18)

Most research I've done on this suggests the remote crypto ACL may not match.

If so that implies that packet tracer actually makes a connection to the far end to check that the traffic is allowed and because of an ACL mismatch

it gets the DROP message above.

Does packet tracer actually connect to the far end ?  I assumed it only checked your local end and as such if your VPN config would allow the packet then packet tracer would show an allow result.

Many thanks, Stephen.

7 Replies 7

andrew.prince
Level 10
Level 10

did you also add the new subnet to your no-nat lists? The error for the encryption could be that it is being natted and then does not match the VPN acl.

Sent from Cisco Technical Support iPad App

Andrew

Doesn't look like a NAT issue.  A previous step in the trace shows the traffic being no-natted

I have a rule matching a whole load of internal networks going to the required destinations and applying a no nat.  During the trace it matches this rule.

I then created a specific rule for a test source and moved it to the top of the nat rules.  Trace then matches that NAT rule but still drops at the same stage as in my initial post.

It does seem it's a failure to match the ACL for encrypting traffic but again I have checked and the source and destination are in that ACL.

As a test I labbed a tunnel with mismatching ACL entries at each end.  The test was on PIX's but when I had an ACL at one end with a host to host entry and the ACL at the other end with /24 subnets as source and destination the traffic got matched and passed through the tunnel.

Thanks, Stephen.

mudjain
Level 1
Level 1

Hello,

you were able to negotiate the tunnel as it had a subset of crypto ACL on remote side. In such a case the tunne; could be initiated from only one side.

However recommended design is to have crypto ACL to be mirror image of each other on either side:

http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/rel_2_x/fm/configuration/guide/ipsec.html#wp1229596 

From my knowledge I cannot guide you to a fixed direction with provided information. Please make sure that following conditions are met:

when final packet reaches the outside interface policy and crypto engine its source, destination IP, port, protocol match with correct crypto map entry. What I mean is:

recheck you NAT exempt or nating(depending upon your crypto acl)

recheck that crypto ACL of another crypto map entry doesnt include same remote network as teh one you are trying to add.

It should be permitted in VPN filter if there are any.

Please check show vpn-sessiondb detail L2L filter ipadd to check which group-policy is used for this VPN connection. show run all group-policy . VPN-filter would, I believe, be there in show crypto IPSEC as well as vpn-sessiondb as well.

Unless the tunnel comes up it will stil show drop in packet tracer. if none of these are the reason, after verifying crypto ACL with remote site. clear ipsec sa for this tunnel is definitely one thing you can try.

Regards,

Mudit

Thank you for the reply Mudit

There are no VPN filters so that is not an issue.

This is simply an existing tunnel that we are allowing a new subnet to go down.  The tunnel is always up as there is always other traffic on it.

During the packet trace the NAT is working as expected.  See below;

Phase: 8

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (any,outside) source static any any destination static Server_name_here Server_name_here

Additional Information:

Static translate 172.26.22.252/1234 to 172.26.22.252/1234

Forward Flow based lookup yields rule:

in  id=0x79e3f848, priority=6, domain=nat, deny=false

        hits=7578, user_data=0x79e3c3f8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=ScoLocate_Thistle3_1, mask=255.255.255.255, port=0, dscp=0x0

        input_ifc=any, output_ifc=outside

So this is a no nat on the test address I am using in the new subnet, 172.26.22.0

I can see the no nat translation hits incrementing as I send test traffic.  I can also see the inside ACL and crypto ACL entries incrementing with test traffic.  Is the trace misleading ?  If I do a trace on traffic already using the tunnel I get a success but if I do it on traffic allowed on the tunnel but not currently using it I get the VPN drop.  So this takes me back to the debug error

Received non-routine Notify message: Invalid ID info (18)

Does that mean I received the message from the IPSec peer and it is not allowing the tunnel to come up with the new traffic ?

Thanks again, Stephen.

ignoring the packet trace for a moment, does a normal ping from server to server work using the new ip subnet?

Sent from Cisco Technical Support iPad App

Thanks for all your replies but this has been a red herring.  My customer has just told be it is a different VPN that we should have applied the config to.

Thanks again, Stephen.

terrell_e
Level 1
Level 1

Here's what I've usually found the problem with

Phase: (Don't Care what phase)

Type: VPN

Subtype: encrypt

Result: DROP

The problem is usually this.  Either you have something in your encryption domain that doesn't belong there or you have something in your encryption domain that needs to be routed out someplace else outside of ur tunnel.  IE; I just had the same problem for a week, I sit down tonight & it occurs to me that Host A is coming from 192.168.X.X & needs to get to a AWS_VPC that's in the cloud.  In my environment that means the traffic would have to traverse 2 firewalls.  The first is the VPN FW, however adding an acl with just the host that Host A needs by creating another group Remote_host(object-group network 192.168.27.15; object-group network 192.168.27.16). Then traffic was able to pass through just fine.  Don't forget to add a route for your remote host back to the fw the acl resides.  In my case both fw's.  Hope this helps someone out.  While I agree with what others have said here somewhat.  But my experience has been, ya got something wrong in ur encryption domain.  To prove it 2 urself just run on ur ASA sh crypto IPsec sa peer xxx.xxx.xxx.xxx (where x's are ur peer's ip) If u don't see an ip for something the remote side is trying to reach theres ur answer.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: