ASA S2S VPN to AWS - The decapsulated inner packet doesn't match the negotiated policy in the SA

[Max Kalachov]

Hi guys,

I have an S2S VPN between an ASA 5506 (9.8) and AWS VPC that's partially working.

Office network: 192.168.0.0/24 | AWS network: 172.30.0.0/16 and 172.31.1.0/24

The tunnel has been created via ASDM, these days I'm almost not working with tunnels in CLI.

Once the tunnel is configured I have connectivity to machines on 172.31.1.0/24, but once I'm trying to connect to machines on 172.30.0.0/16, I lost connectivity to 172.31.1.0/24 and have connectivity to 172.30.0.0/16.

So let's say the tunnel is down, and I start running a continuous ping to 172.31.1.213, the tunnel goes up and I have a ping. Then I run a continuous ping to 172.30.1.94, it works, but I immediately lost ping to 172.31.1.213.

In the logs I see the following:

IPSEC: Received an ESP packet (SPI= 0xCD2A74CC, sequence number= 0x1F) from AWS-IP (user= AWS-IP) to AWS-IP. The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 68d1:xxxx:a9bf:4524:xxxx:5114:xxxx:bfd8, its source as e82a:xxxx:4a65:1138:xxxx:677f:xxxx:fb0a, and its protocol as 255. The SA specifies its local proxy as 192.168.0.0/255.255.255.0/ip/0 and its remote_proxy as 172.30.0.0/255.255.

IPSEC: Received an ESP packet (SPI= 0xCD2A74CC, sequence number= 0x1E) from AWS-IP (user= AWS-IP) to AWS-IP. The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as f9a9:xxxx:7bff:13b6:xxxx:d0df:xxxx:5403, its source as 1051:xxxx:bc0c:adf1:xxxx:bf38:xxxx:dc79, and its protocol as 255. The SA specifies its local proxy as 192.168.0.0/255.255.255.0/ip/0 and its remote_proxy as 172.30.0.0/255.255.0

The configuration (hopefully I don't miss anything)

access-list WAN_cryptomap_11 extended permit ip object new-lan object-group DM_INLINE_NETWORK_36

crypto map WAN_map 8 match address WAN_cryptomap_11
crypto map WAN_map 8 set pfs 
crypto map WAN_map 8 set peer X.X.X.X 
crypto map WAN_map 8 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map WAN_map 8 set nat-t-disable

group-policy GroupPolicy_X.X.X.X internal
group-policy GroupPolicy_X.X.X.X attributes
 vpn-tunnel-protocol ikev1 

tunnel-group X.X.X.X type ipsec-l2l
tunnel-group X.X.X.X general-attributes
 default-group-policy GroupPolicy_X.X.X.X
tunnel-group X.X.X.X ipsec-attributes
 ikev1 pre-shared-key *****

nat (MainNet,WAN) source static MainNet MainNet destination static DM_INLINE_NETWORK_37 DM_INLINE_NETWORK_37 no-proxy-arp route-lookup

object-group network DM_INLINE_NETWORK_36
 network-object object AWS-West-01
 network-object object AWS-West-02
object-group network DM_INLINE_NETWORK_37
 network-object object AWS-West-01
 network-object object AWS-West-02

What am I missing and doing wrong?

Thank you

Max

[Marius Gunnerud]

The ASA side looks fine at first glance.  I am wondering though if the AWS side is establishing a separate tunnel per SA which might explain the behavior you are experiencing.  However, I am not well versed in how AWS works so I this is just a best guess.

[eduardo.silva@fr]

I'm having the same problem and so far it looks like a Cisco ASA limitation.
I also have two subnets on the match address access-list:

access-list outside_cryptomap line 1 extended permit ip object-group DM_INLINE_NETWORK_11 object Amazon_subnet (hitcnt=598) 0x0df0ad38
  access-list outside_cryptomap line 1 extended permit ip 10.50.10.0 255.255.255.0 11.10.0.0 255.255.0.0 (hitcnt=593) 0x716d51b6
  access-list outside_cryptomap line 1 extended permit ip 10.40.0.0 255.255.0.0 11.10.0.0 255.255.0.0 (hitcnt=7) 0x316b6b47

The first traffic to match the access-list will trigger the tunnel to connect and set local ident:

# show crypto ipsec sa
interface: outside
    Crypto map tag: outside_map, seq num: 3, local addr: xx.xx.xx.xx

      access-list outside_cryptomap extended permit ip 10.50.10.0 255.255.255.0 11.10.0.0 255.255.0.0
      local ident (addr/mask/prot/port): (10.50.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (10.11.0.0/255.255.0.0/0/0)
      current_peer: xx.xx.xx.xx

And the other subnet's traffic will fail with the same error as yours. If I initiate the traffic with the other subnet, then it gets the local ident and the error swapped around.