L2L and remote access VPN issues

Unanswered Question
Jan 16th, 2008
User Badges:

Hi,


I have an issue where vpn clients are unable to access any L2L vpn destinations. I can see the traffic encrypted / decrypted but the traffic is then not forwarded to the vpn client.


If anyone has some hints that would be awesome.


Cheers.


Aaron.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
smahbub Tue, 01/22/2008 - 11:50
User Badges:
  • Silver, 250 points or more

These dial access methods are supported for integration:

Layer 2 Tunnel Protocol (L2TP) dial in is designed for service providers who want to offer wholesale dial service to their customers. It allows the users or a CE router to dial to a Network Access Server (NAS) functioning as a L2TP Access Concentrator (LAC), which then builds a L2TP tunnel to the PE router functioning as L2TP Network Server (LNS). The LNS or PE router dynamically creates a virtual access interface for the user and includes it in the appropriate Virtual Routing and Forwarding (VRF) instance for the customer and integrates it with the MPLS VPN backbone.

AaronRiemer Tue, 01/22/2008 - 15:51
User Badges:

Hi there,


My problem does not relate to the L2TP protocol. when i refer to L2L i mean a site to site VPN IPSEC connection.


Cheers,


Aaron

attrgautam Tue, 01/22/2008 - 22:04
User Badges:
  • Silver, 250 points or more

Aaron


I am assuming you are forming Client Sssions to a hub which has the L2L sessions to the other locations. Do both the Client sessions and L2L terminate on the same interface on the hub? If yes, then you may need to enable hairpinning using a command same-security permit traffic(or some command to that effect) if you are using PIX/ASA - if it is a router, it would be nice to the exact configuration of the router - maybe some Crypto ACL issue ?

AaronRiemer Wed, 01/23/2008 - 00:01
User Badges:

Hi attrqautam,


You are absolutely correct. the command is 'same-security-traffic permit intra-interface' and is configured. The device is an ASA 5520 with OS ver 7.2.


I do not see any ACL drops it seems that the packet will not encrypt and send back to the VPN client.


I truly am at a loss as to why this is happening.


Any comments appreciated.


Cheers,


Aaron.

AaronRiemer Wed, 01/23/2008 - 00:01
User Badges:

Hi attrqautam,


You are absolutely correct. the command is 'same-security-traffic permit intra-interface' and is configured. The device is an ASA 5520 with OS ver 7.2.


I do not see any ACL drops it seems that the packet will not encrypt and send back to the VPN client.


I truly am at a loss as to why this is happening.


Any comments appreciated.


Cheers,


Aaron.

husycisco Wed, 01/23/2008 - 12:20
User Badges:
  • Gold, 750 points or more

Hi Aaron

If 'same-security-traffic permit intra-interface' is configured, there shouldnt be any problems. Also please check your exempt nat (inside_nat0_outbound) ACL if it includes the line for VPN clientpool as source and remote and of L2L as destination. If you like, post your running config


Regards

acomiskey Wed, 01/23/2008 - 12:26
User Badges:
  • Green, 3000 points or more

You only need a few things..


1. same-security-traffic permit intra-interface


2. The traffic from vpn client to vpn tunnel needs to be defined in the crypto acl for the tunnel. This needs defined in the main asa and remote asa.


3. Make sure you are tunneling the traffic for the remote lan subnet from the vpn client...not split tunneling.


4. The remote asa would need the vpn client subnet added to nat exemption acl.


AaronRiemer Wed, 01/23/2008 - 15:53
User Badges:

Hi Guys,


Many thanks for the advice. I have a nonat configured for traffic destined to the VPN client however this particular L2L VPN SA accepts our global public range that is being NAT'd by the same ASA.


So what happens is the vpn client attempts to access LAN resources at the remote L2L site and the ASA NAT's this traffic. The VPN tunnel destination is only expecting traffic from our public range and would be defined in their SA.


I have enabled the capture command on the ASA with relevant acl's and i only ever see the SYN packets of the TCP connection from the vpn clients.


Please see attachment for relevant configuration and syslogs. Note there are never any drops or denies in the logs. Maybe i need to add a specific deny to see them?


Many thanks,


Aaron.



Attachment: 
husycisco Wed, 01/23/2008 - 19:50
User Badges:
  • Gold, 750 points or more

I suggest the following modifications



ip local pool vpn_pool 10.250.1.1-10.240.1.254 mask 255.255.255.0

no access-list nonat extended permit ip any 10.240.1.0 255.255.255.0

access-list nonat permit ip 10.240.1.0 255.255.255.0 10.250.1.0 255.255.255.0

tunnel-group WEL general-attributes

no dhcp-server xxxxx

address-pool vpn_pool


In your configuration, your DHCP server in inside interface gives IPs from inside scope to the VPN clients which are actually end in outside interface. This will cause ASA malfunction in such cases. Always use different IP pool for VPN clients. Above config will correct this issue

Now your ASA knows that your VPN clients are in outside interface. Now second problem. You have the following options

1)Define a subinterface in ASA, perform VLAN tagging with suitable switch and request an additional IP subnet from your ISP. Then terminate your L2L tunnel and RA tunnel on different interfaces, so we can define policy NAT

2)Your inside network is translated to your outside interface IP. lets say that it is x.x.x.66. Request one more IP from your ISP (maybe you have it already) lets say that it is x.x.x.67. And then do the following modification


access-list RAtoL2L permit ip 10.250.1.0 255.255.255.0 host 172.16.50.18

nat (outside) 2 access-list RAtoL2L outside

global (outside) 2 x.x.x.67

access-list vpn permit ip x.x.x.67 host 172.16.50.18


And request other end to add x.x.x.67 to their config

3)Do not NAT the VPN traffic between sites


Regards


AaronRiemer Wed, 01/23/2008 - 20:09
User Badges:

Many thanks husycisco. I will attempt those changes over the next few weeks and let you know how i go.


You have been extremely helpful and i have rated your post accordingly :)

husycisco Wed, 01/23/2008 - 20:57
User Badges:
  • Gold, 750 points or more

You are welcome and thanks for rating. I will be monitoring this question in case you need assistance

Actions

This Discussion