Solved: RA VPN to L2L VPN via policy NAT

Sharkey13 · ‎04-11-2008

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

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

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

acomiskey · ‎04-14-2008

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.

View solution in original post

acomiskey · ‎04-28-2008

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.

View solution in original post

acomiskey · ‎04-11-2008

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)

Sharkey13 · ‎04-14-2008

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.

acomiskey · ‎04-14-2008

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.

Sharkey13 · ‎04-14-2008

Thank you. Worked perfectly.

acomiskey · ‎04-14-2008

Good to hear, thanks for the rating.

Sharkey13 · ‎04-28-2008

Adam - when I added the configuration "nat (OUTSIDE) 2 to the configuration, RA VPN to RA VPN communication is no longer working, i.e., one VPN client can no longer connect to another VPN client.

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

acomiskey · ‎04-28-2008

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.

Sharkey13 · ‎04-28-2008

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.