04-11-2008 12:22 PM - edited 02-21-2020 03:40 PM
Scenario: we have remote access VPN users who need to access a L2L VPN through the same ASA outside interface. This particular L2L VPN is to a partner who requires us to NAT our addresses (192.168.x.x) to another private address (172.20.x.x). We also access the L2L VPN from internal hosts. NATing for the partner is accomplished through a policy NAT.
Our remote VPN users cannot access the L2L VPN. It appears that the VPN host address (assigned through RADIUS) is not being NAT'd, even though it is in the object-group.
"Hairpinning" is configured and working for other VPN's.
NO-NAT ACL does not seem to be involved (which it shouldn't), as the internal host address (192.168.60.x) is not being NAT'd to the public address.
Internal hosts can access the VPN tunnel just fine.
Here is the relevant config:
same-security-traffic permit intra-interface
object-group network OURHosts
network-object host 192.168.1.x
network-object host 192.168.2.x
<other host entries>
network-object 192.168.60.0 255.255.255.0
object-group network PartnerHosts
network-object host 10.2.32.a
network-object host 10.2.32.b
network-object host 10.2.32.c
<other host entries>
access-list NAT2 extended permit ip object-group OURHosts object-group PartnerHosts
global (OUTSIDE) 2 172.20.x.x
nat (INSIDE) 2 access-list NAT2
The syslog error we receive:
%ASA-4-402117: IPSEC: Received a non-IPSec packet (protocol= ICMP) from 10.2.32.a to 192.168.60.x
Solved! Go to Solution.
04-14-2008 06:20 AM
Yes. According to the config you posted, there is no command currently in place to nat the RA vpn clients to hairpin them over the tunnel.
The inside clients work because of "nat (INSIDE) 2 access-list NAT2". But, because your RA VPN clients are coming from "OUTSIDE", this nat statement would have no effect on them.
04-28-2008 08:48 AM
Hmmm...let's see.
You could try something like this.
nat (outside) 0 access-list nonat_outside
access-list nonat_outside extended permit ip
Let me know if that works.
04-11-2008 04:00 PM
You need a "nat (OUTSIDE)" command to nat the vpn clients to the 172.20 address to go over the tunnel.
nat (OUTSIDE) 2
or
nat (OUTSIDE) 2 access-list NAT2 (as long as the vpn client subnet is in OURHosts)
04-14-2008 06:08 AM
Thanks for the reply. However, I could use some elaboration.
Is the nat (OUTSIDE) for the hairpinning on the RA VPN to L2L VPN? The reason I ask is that internal clients can access the L2L VPN just fine.
Thanks.
04-14-2008 06:20 AM
Yes. According to the config you posted, there is no command currently in place to nat the RA vpn clients to hairpin them over the tunnel.
The inside clients work because of "nat (INSIDE) 2 access-list NAT2". But, because your RA VPN clients are coming from "OUTSIDE", this nat statement would have no effect on them.
04-14-2008 07:02 AM
Thank you. Worked perfectly.
04-14-2008 07:21 AM
Good to hear, thanks for the rating.
04-28-2008 08:29 AM
Adam - when I added the configuration "nat (OUTSIDE) 2
I suspect that the nat outside statement is causing the RA VPN client to be nat'd to the 172 address, but I do not know why, since my no-nat policy is policy 0. Why is the nat outside statement affecting RA to RA connectivity, and how can I fix this?
Thanks in advance, Patrick
04-28-2008 08:48 AM
Hmmm...let's see.
You could try something like this.
nat (outside) 0 access-list nonat_outside
access-list nonat_outside extended permit ip
Let me know if that works.
04-28-2008 11:25 AM
I entered:
nat (OUTSIDE) 0
This solved the issue related to RA-VPN to RA-VPN access, and I am still able to successfully connect on the RA-VPN to L2L-VPN.
That's two for two. Thank you very much.
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: