05-21-2012 04:08 PM
Hi,
I am using a Cisco 1921. I have created 3 L2L VPNs. Although I can get the tunnel of all 3 up, I can in the case of one ping the LAN IP of the router, and the 2nd on from the peer subnet, but not the other way round. If any one can make sense of this that would be great.. I can see the ACL being fired,
Annoying as the first VPN is up and working fine, in both directions.. Would be really grateful of a fresh pair of eyes..
NAT blocking ACL working fine too..
Glasgow#show access-lists
Extended IP access list 101
10 permit ip 172.16.20.0 0.0.0.255 192.168.0.0 0.0.0.255 (966 matches)
Extended IP access list 104
10 permit ip 172.16.20.0 0.0.0.255 192.168.3.0 0.0.0.255 (3606 matches)
Extended IP access list 105
10 permit ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255 (3609 matches)
Extended IP access list 175
10 deny ip 172.16.20.0 0.0.0.255 192.168.0.0 0.0.0.255 (2109 matches)
20 deny ip 172.16.20.0 0.0.0.255 192.168.3.0 0.0.0.255 (3616 matches)
30 deny ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255 (3639 matches)
40 permit ip 172.16.20.0 0.0.0.255 any (1549 matches)
Here are the snippits (sanitised) Sorry I hate reading though lazy peoples config dumps..
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key demopassword address 146.xx.xx.xx
crypto isakmp key demopassword address 212.xx.xx.xx
crypto isakmp key demopassword address 188.xx.xx.xx
!
!
crypto ipsec transform-set esp-3des-sha1 esp-3des esp-sha-hmac
!
crypto map l2l 99 ipsec-isakmp
set peer 188.xx.xx.xx
set transform-set esp-3des-sha1
match address 101
crypto map l2l 100 ipsec-isakmp
set peer 212.xx.xx.xx
set transform-set esp-3des-sha1
match address 105
crypto map l2l 101 ipsec-isakmp
set peer 146.xx.xx.xx
set transform-set esp-3des-sha1
match address 104
!
interface GigabitEthernet0/1
description WAN
ip address 213.xx.xx.xx 255.255.255.xx
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
crypto map l2l
!
ip nat inside source list 175 interface GigabitEthernet0/1 overload
!
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 104 permit ip 172.16.20.0 0.0.0.255 192.168.3.0 0.0.0.255
access-list 105 permit ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 175 deny ip 172.16.20.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 175 deny ip 172.16.20.0 0.0.0.255 192.168.3.0 0.0.0.255
access-list 175 deny ip 172.16.20.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 175 permit ip 172.16.20.0 0.0.0.255 any
Solved! Go to Solution.
05-22-2012 05:58 PM
For the second tunnel (192.168.100.0/24), as you can see from the output, there is encaps, but no decaps counter that means, traffic is being sent out towards the remote end, however, nothing is coming back. So it could have been blocked at the remote end since your first tunnel works just fine, I assume that nothing is blocking it at your end.
05-22-2012 04:21 AM
The configuration on this end looks fine to me. Do you have access to config on the other end?
Also, can you please share the output of: show cry ipsec sa
05-22-2012 12:25 PM
No I don't have remote access to peer device. I actually think that might be the issue. The tunnel is coming up
But I get the following
Failure Reason(s)
A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets.
But I don't think the Cisco config professional is right..
If it helps though here is the debug info the first tunnel is working fine the second is where I am getting the errors
Cheers,
Alan
#show cry ipsec sa
interface: GigabitEthernet0/1
Crypto map tag: L2L, local addr 213.xx.xx.xx
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.20.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
current_peer 188.xx.xx.xx port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 170164, #pkts encrypt: 170164, #pkts digest: 170164
#pkts decaps: 153422, #pkts decrypt: 153422, #pkts verify: 153422
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 5, #recv errors 0
local crypto endpt.: 213.xx.xx.xx, remote crypto endpt.: 188.xx.xx.xx
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0x8468A979(2221451641)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xD5A52454(3584369748)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2023, flow_id: Onboard VPN:23, sibling_flags 80000046, crypto map: L2L
sa timing: remaining key lifetime (k/sec): (4599317/2704)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x8468A979(2221451641)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2024, flow_id: Onboard VPN:24, sibling_flags 80000046, crypto map: L2L
sa timing: remaining key lifetime (k/sec): (4599309/2704)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.20.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
current_peer 212.xx.xx.xx port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 218, #pkts encrypt: 218, #pkts digest: 218
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 3, #recv errors 0
local crypto endpt.: 213.xx.xx.xx, remote crypto endpt.: 212.xx.xx.xx
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
05-22-2012 05:58 PM
For the second tunnel (192.168.100.0/24), as you can see from the output, there is encaps, but no decaps counter that means, traffic is being sent out towards the remote end, however, nothing is coming back. So it could have been blocked at the remote end since your first tunnel works just fine, I assume that nothing is blocking it at your end.
05-25-2012 08:34 AM
This was the issue btw
from the hosting provider
"there was another tunnel configured that had been disabled but also utilised the same remote/local networks. The ASA must have been using this in the negotiation even though it was not enabled! It must be a bug in the ASDM console."
So ASA to Cisco 1900 if all else fails could be this.. Jennifer thanks for your help!
05-25-2012 04:49 PM
Thanks for your update and sharing the solution.
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