01-16-2008 10:15 PM - edited 02-21-2020 03:29 PM
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.
01-22-2008 11:50 AM
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.
01-22-2008 03:51 PM
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
01-22-2008 10:04 PM
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 ?
01-23-2008 12:01 AM
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.
01-23-2008 12:01 AM
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.
01-23-2008 12:20 PM
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
01-23-2008 12:26 PM
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.
01-23-2008 03:53 PM
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.
01-23-2008 07:50 PM
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
01-23-2008 08:09 PM
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 :)
01-23-2008 08:57 PM
You are welcome and thanks for rating. I will be monitoring this question in case you need assistance
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: