Multiple L2L VPN first one works, rest acting oddly

Answered Question
May 21st, 2012

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

I have this problem too.
0 votes
Correct Answer by Jennifer Halim about 1 year 11 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
Jennifer Halim Tue, 05/22/2012 - 04:21

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

vetsnowit1 Tue, 05/22/2012 - 12:25

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

Correct Answer
Jennifer Halim Tue, 05/22/2012 - 17:58

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.

vetsnowit1 Fri, 05/25/2012 - 08:34

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!

Actions

Login or Register to take actions

This Discussion

Posted May 21, 2012 at 4:08 PM
Stats:
Replies:5 Avg. Rating:5
Views:570 Votes:0
Shares:0
Tags: vpn, l2l, 1921
+

Related Content

Discussions Leaderboard