10-19-2009 12:50 AM - edited 02-21-2020 04:21 PM
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
10-19-2009 03:52 AM
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
10-26-2009 10:50 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide