ASA 5520 LAN to LAN IPSEC - multiple local LAN

jan.klicka · ‎10-19-2009

Hello,

we've LAN to LAN IPSEC tunnel between Vigor 2700 (spoke) and ASA 5520 (hub, ASDM configured).

On the hub side we need to protect local LANS 172.27.0.0/16, 172.30.0.0/16, 172.31.0.0/16 and 192.168.0.0/16, on the spoke side we have 172.27.241.96/27.

We put all four subnets as "local LAN" on ASA.

The IPSEC tunnel is up, both isakmp a ipsec sa are active.

Vigor 2700 (spoke side) puts all necessary traffic to IPSEC tunnel (verified from routing table).

ASA accepts packets to LAN 172.27.0.0/16, communication to other LANs is dropped and following message appers in log

---

PSEC: Received an ESP packet (SPI= 0x8BF84462, sequence number= 0x939) from XX (user= A.B.C.D) to U.V.X.Y.

The decapsulated inner packet doesn't match the negotiated policy in the SA.

The packet specifies its destination as 172.30.5.220, its source as 172.27.241.101, and its protocol as 6.

The SA specifies its local proxy as 172.27.0.0/255.255.0.0/0/0 and its remote_proxy as 172.27.241.96/255.255.255.224/0/0

---

vpn# sh crypto ipsec sa user A.B.C.D

interface: INTERNET

Crypto map tag: VPNPEER, seq num: 26, local addr: U.V.X.Y

access-list CESNET_cryptomap_24 permit ip 172.27.0.0 255.255.0.0 172.27.241.96 255.255.255.224

local ident (addr/mask/prot/port): (172.27.0.0/255.255.0.0/0/0)

remote ident (addr/mask/prot/port): (172.27.241.96/255.255.255.224/0/0)

current_peer: A.B.C.D

#pkts encaps: 3114, #pkts encrypt: 3114, #pkts digest: 3114

#pkts decaps: 4015, #pkts decrypt: 4015, #pkts verify: 4015

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 3114, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#send errors: 0, #recv errors: 754

local crypto endpt.: 195.113.166.50, remote crypto endpt.: A.B.C.D

path mtu 1500, ipsec overhead 74, media mtu 1500

current outbound spi: 2894CA65

inbound esp sas:

spi: 0x8BF84462 (2348303458)

transform: esp-aes esp-sha-hmac no compression

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 962560, crypto-map: VPNPEER

sa timing: remaining key lifetime (sec): 10383

IV size: 16 bytes

replay detection support: Y

Anti replay bitmap:

0xFFFFFFFF 0xFFFFFFFF

outbound esp sas:

spi: 0x2894CA65 (680839781)

transform: esp-aes esp-sha-hmac no compression

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 962560, crypto-map: VPNPEER

sa timing: remaining key lifetime (sec): 10383

IV size: 16 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

vpn# sh access-list CESNET_cryptomap_24

access-list CESNET_cryptomap_24; 4 elements

access-list CESNET_cryptomap_24 line 1 extended permit ip object-group DM_INLINE_NETWORK_32 172.27.241.96 255.255.255.224 0x843e9221

access-list CESNET_cryptomap_24 line 1 extended permit ip 172.27.0.0 255.255.0.0 172.27.241.96 255.255.255.224 (hitcnt=16) 0x450ce1b4

access-list CESNET_cryptomap_24 line 1 extended permit ip 172.30.0.0 255.255.0.0 172.27.241.96 255.255.255.224 (hitcnt=0) 0x80691697

access-list CESNET_cryptomap_24 line 1 extended permit ip 172.31.0.0 255.255.0.0 172.27.241.96 255.255.255.224 (hitcnt=0) 0x455f3abc

access-list CESNET_cryptomap_24 line 1 extended permit ip 192.168.0.0 255.255.0.0 172.27.241.96 255.255.255.224 (hitcnt=0) 0x4b0e4ef9

Did I miss anythink during the configuration ? How should we fix this?

Thanks. Jan Klicka, SITMP

mike_guy29 · ‎10-19-2009

Hi,

If that is the only ouput that you are getting from viewing the ipsec SAs then there are problems with your phase 2 tunnels. There is only an active tunnel for one of the hub networks.

Based on the info that you have posted your ACL looks consistent so it may be a configuration error on the other side. I would check that the ACLs on the other side match exactly and its not something that says...

allow anything from 172.27.241.96/27 to 172.0.0.0/8 (or similar broad statement). Make sure they reflect the hub acls exactly (but in reverse) as I have seen similar problems in the past.

What if you initiate traffic from the other hub networks to the spoke network? Does the SA get created??

Regards

Mike

jan.klicka · ‎10-26-2009

Hi, Mike

thanks for idea. After a weeek of testing, I came to fact, that Vigor 2700 is probably able to hold only one IPSEC SA between two hosts - when IPSEC SA between 172.27.241.96/27 (spoke) and 172.27.0.0/16 (hub) was established and we needed to encrypt packet to 192.168.0.0/16, the IPSEC SA was dropped and new one between 172.27.241.96/27 and 192.168.0.0/16 was established.

After some other testing I changed Local LANs to 172.27.241.96/27 (spoke) and 0.0.0.0/0 (hub) and statically routed necessary traffic to IPSEC tunnel on Vigor and it started to work.

Jan Klicka, SITMP