L2L ESP error 402116

[charlie.ford]

I would like to ask your help solving a VPN issue with the device on the far end.

I have one established IPSec tunnel between the host at the far end. When they try to eatablise a second IPSec tunnel to our seconf IP we get this error

May  9 18:51:51 odc-np-gw %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x47995CC7, sequence number= 0xCF) from 23.24.138.185 (user= 23.24.138.185) to 205.144.144.4.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 205.144.158.29, its source as 23.24.138.189, and its protocol as icmp.  The SA specifies its local proxy as 205.144.158.30/255.255.255.255/ip/0 and its remote_proxy as 23.24.138.189/255.255.255.255/ip/0.

23.24.138.185 is the far end peer

205.144.144.4 is the local peer

23.24.138.189 is the remote configured protected host

205.144.158.29 is the local configured protected host

205.144.158.30 is the working local configured protected host

I can supply everything if you wish but I just need some direction. I believe we have a Cisco 5540 on the far end also.

[rizwanr74]

Hi Charlie,

Please post your config.

thanks

[charlie.ford]

Posted config

[rizwanr74]

which tunnel is causing issue "outside_1_cryptomap" or "outside_2_cryptomap" ?

[charlie.ford]

2

Charlie

402-963-8295

[rizwanr74]

Hi Charlie,

Your tunnel2's destination IP overlaps as you can see, IP "205.144.158.29" over lapping with policy nat.

This is found on tunnel two

object-group network VPN_Peakview_Local_Hosts

network-object host 205.144.158.29

access-list outside_2_cryptomap extended permit ip object-group VPN_Peakview_Local_Hosts object-group VPN_Peakview_Remote_Hosts

overlap with...

Now this found on the tunnel one

static (inside,outside) 205.144.158.29  access-list inside_nat_static

therefore remove this highlighted "network-object" above object-group and try it.

Let me know.

thanks

[charlie.ford]

I am sorry but I do not see the issue. I wish I did?

object-group network VPN_Peakview_Local_Hosts

network-object host 205.144.158.29 This IPSec tunnel will not come up

network-object host 205.144.158.30 This IPSec tunnel up

object-group network VPN_Peakview_Remote_Hosts

network-object host 23.24.138.189

access-list outside_2_cryptomap extended permit ip object-group VPN_Peakview_Local_Hosts object-group VPN_Peakview_Remote_Hosts

static (inside,outside) 205.144.158.29 access-list inside_nat_static

static (inside,outside) 205.144.158.30 access-list inside_nat_static_1

access-list inside_nat_static extended permit ip host 205.144.145.169 object-group VPN_Peakview_Remote_Hosts

access-list inside_nat_static_1 extended permit ip host 10.28.128.25 object-group VPN_Peakview_Remote_Hosts

What can I be missing?

Charlie

402-963-8295

[rizwanr74]

Regarding tunnel two.

your policy static-nat condition or criteria is source traffic from ip: 10.28.128.25 and destination is: 23.24.138.189 are condition to policy static-nat to ip:205.144.158.30, you agree?

If you answer is: yes. IPSec tunnel criteria is: if traffic is sourced (i.e. rather natted to) either the IP: 205.144.158.30 or IP: 205.144.158.29 and destined to IP: 23.24.138.189, then crypto engine will take over and send such traffic via IPSec tunnel.

Regarding tunnel one:

Your tunnel one: source or natted ip is: 205.144.158.29, which overlap with tunnel two, the crypto engine takes over the traffic to either tunnel destination (either destinations: 23.24.138.185 or 174.78.69.194) based up outside_x_cryptomap) ACL condition, therefore your interesting traffic condition (i.e. outside_x_cryptomap) overlaps as a result you will confuse the ASA FW from determining which tunnel-peer that it must send the traffic to, because outside_x_cryptomap are identical.

Therefore you cannot have identical outside_x_cryptomap condition or critiria. If you want to failover IPSec tunnel you must be go along with GRE over IPSec.

Look forward to hear from you.

[charlie.ford]

Here is what I have learned.

First, to avoid confusion I removed crypromap_1 configuration.

No change.

I configured a crypto_1 just like 2 but to our Lab peer, Cisco to Cisco with the same object-groups. Works like you would expect. Connectivity on all hosts in both directions.

Found out the far end VPN device is a Check Point firewall. This triggered a memory regarding subnets.

Reviewed all the our production firewall configurations. Most of the Check Points were configured with a subnet in the crypto-map, the ones that were not had single hosts configured ( no multiple hosts ). Oddly enough the single host we receiving the ESP error but working. The subnets were not receiving ESP errors.

Called my Check Point peer and suggested we switch to subnets. Cleared the IPSec sa and we now have connectivity and no ESP errors.

Thanks very much for your input, as always the Forum has assisted in problem resolution and in a timely manner.

Charlie