02-27-2008 07:54 AM - edited 02-21-2020 03:35 PM
Summary:
We are trying to establish a two-way L2L VPN tunnel with a partner. VPN traffic is a many-to-many towards our partner, and from our partner they need a many-to-one towards us (they need to access just one host on our network). Furthermore, our partner has numerous VPNs, so they require us to use a separate NAT to two private host addresses, one for each direction of the tunnel.
My initial configuration of the tunnel on my side brought up Phase 1, but no IPSec. Partner ran debug which revealed that my host was not being NAT'd in the policy NAT. We are using a ASA5520, ver 7.0.
Here is the config:
####List of OUR hosts
object-group network OURHosts
network-object host 192.168.x.y
<additional host entries>
####List of PARTNER hosts
object-group network PARTNERHosts
network-object host 10.2.a.b
<additional host entries>
####ACL's for NAT
####Many-to-many outbound
access-list NAT2 extended permit ip object-group OURHosts object-group PARTNERHosts
####One-to-many inbound
access-list NAT3 extended permit ip host 192.168.c.d object-group PARTNERHosts
####NAT
nat (INSIDE) 2 access-list NAT2
nat (OUTSIDE) 2 172.20.n.0
nat (INSIDE) 3 access-list NAT3
nat (OUTSIDE) 3 172.20.n.1
####ACL for VPN
access-list VPN extended permit ip object-group OURHosts object-group PARTNERHosts
access-list VPN extended permit ip host 192.168.c.d object-group PARTNERHosts
####Tunnel
tunnel-group <partner public IP> type ipsec-l2l
<IPSEC attributes - pre-shared-key>
crypto map <NAME> <#> match address VPN
crypto map <NAME> <#> set transform-set VPN
crypto map <NAME> <#> set peer <partner public IP>
I realize that the ACL for the VPN should read:
access-list VPN extended permit ip host 172.20.n.0 object-group PARTNERHosts
access-list VPN extended permit ip host 172.20.n.1 object-group PARTNERHosts
...if the NAT was working properly, but when this ACL is used, Phase 1 does not even negotiate, so I know the NAT is never being translated.
What am I missing in order to NAT our hosts to the 172.20 host addresses when trying to access their internal addresses via the VPN?
Thanks in advance.
Solved! Go to Solution.
02-27-2008 01:57 PM
Patrick
Here is the order of operations for NAT on the firewall:
1. nat 0 access-list (nat-exempt)
2. Match existing xlates
3. Match static commands
a. Static NAT with and without access-list
b. Static PAT with and without access-list
4. Match nat commands
a. nat [id] access-list (first match)
b. nat [id] [address] [mask] (best match)
i. If the ID is 0, create an identity xlate
ii. Use global pool for dynamic NAT
iii. Use global pool for dynamic PAT
So you could try
1) a static NAT with an access-list which will take precendence over a dynamic NAT statement
2) As you can see from 4a it uses first match with NAT and access-list so in theory swapping them around should do the trick.
Can i think of any negative consequences ? - well yes you could lose all connectivity. I don't think this will happen but i can't promise so you absolutely would want to do this out of hours.
Jon
02-27-2008 11:14 AM
Hi
nat (INSIDE) 2 access-list NAT2
nat (OUTSIDE) 2 172.20.n.0
should this not read
nat (INSIDE) 2 access-list NAT2
global (OUTSIDE) 2 172.20.n.0
and the same for your other NAT statement.
You need a global to match your NAT.
Jon
02-27-2008 11:54 AM
Jon - thank you for replying. I apologize for the typo - the config is:
nat (INSIDE) 2 access-list NAT2
global (OUTSIDE) 2 172.20.n.0
and
nat (INSIDE) 2 access-list NAT3
global (OUTSIDE) 2 172.20.n.1
Upon further analysis, what is happening is that we also have a NAT policy for our internal clients to access the internet. Therefore, when the internal host tries to access the partner network via the VPN, the internal host is translated to our public ip. The config for this is:
nat (INSIDE) 1 access-list NAT-LIST
global (OUTSIDE) 1 interface
access-list NAT-LIST extended permit ip 192.168.0.0 255.255.0.0 any
So, to better frame my issue, how do I get traffic destined for the partner network to bypass the NAT1 policy, and be translated by the NAT2 or NAT3 policy? Thanks, and I do apolgize for the typo. Patrick
02-27-2008 12:00 PM
Patrick
No problem with the typo, i do it all the time :)
I haven't got access to my lab at the moment but i would suggest trying 2 things
1) change the NAT order so nat (inside) 1 is for your VPN and nat (inside) 2 is for the internet.
2) Probably a better bet
access-list NAT-LIST deny up 192.168.0.0 255.255.0.0 172.20.n.0 255.255.255.0
access-list NAT-LIST permit ip 192.168.0.0 255.255.0.0 any
The only thing i am unsure of without testing is whether because it hits a deny in the NAT-LIST access-list it will then move on to the next policy NAT setup.
Jon
02-27-2008 01:29 PM
Jon - thanks for the reply.
I tried #2. What I think happened was that the deny statement was processed but not applied (as it should be), and the next statement (permit 192.168.0.0 255.0.0 any) was processed, which resulted in the same outcome.
I am seriously considering trying #1, but I want to consider all possible outcomes first, whether intended or not. Can you think of any negative consequences that might occur by doing that?
Patrick
02-27-2008 01:57 PM
Patrick
Here is the order of operations for NAT on the firewall:
1. nat 0 access-list (nat-exempt)
2. Match existing xlates
3. Match static commands
a. Static NAT with and without access-list
b. Static PAT with and without access-list
4. Match nat commands
a. nat [id] access-list (first match)
b. nat [id] [address] [mask] (best match)
i. If the ID is 0, create an identity xlate
ii. Use global pool for dynamic NAT
iii. Use global pool for dynamic PAT
So you could try
1) a static NAT with an access-list which will take precendence over a dynamic NAT statement
2) As you can see from 4a it uses first match with NAT and access-list so in theory swapping them around should do the trick.
Can i think of any negative consequences ? - well yes you could lose all connectivity. I don't think this will happen but i can't promise so you absolutely would want to do this out of hours.
Jon
02-27-2008 02:49 PM
Jon -
I tried #1, but I received an error:
access-list NAT1 permit ip 192.168.0.0 255.255.0.0 10.2.0.0 255.255.0.0
static (inside,outside) 172.20.n.1 access-list NAT1
global address overlaps with mask
I am unable to figure out what the error message means....
I had also tried #1 using a NAT with the object-groups, but that failed too, although with a different error message.
Using a static NAT config would be my preferred solution.
Thanks for your time. Patrick
02-28-2008 12:01 AM
Patrick
Can you send me your config minus any senstive info as i have access to our work lab now.
I will run a few quick tests.
Jon
02-28-2008 03:25 AM
Patrick
Apologies, there were a few typo's in previous post. Have amended them but please check on web site rather than reading from your e-mail.
Jon
02-28-2008 03:18 AM
Patrick
I kind of missed the wood for the trees here. The static policy NAT is failing because you are trying to map a network 192.168.0.0 to a single IP address 172.20.n.1.
However it's just occured, why are you doing policy NAT for the Internet. I tested in lab and if you do this
nat (INSIDE) 1 192.168.0.0 255.255.0.0
global (OUTSIDE) 1 interface
access-list NAT-LIST permit ip 192.168.0.0 255.255.0.0 10.2.x.x 255.255.255.0
nat (INSIDE) 2 access-list NAT-LIST
global (OUTSIDE) 1 172.20.n.1
ie. only do policy NAT for VPN traffic. This works as expected in my lab.
Is there a reason why you need policy NAT for general Internet access ?
Jon
02-28-2008 07:56 AM
Jon - thanks again for your posts.
Here is the relevant config:
object-group network OURHosts
network-object host 192.168.x.x
object-group network PartnerHosts
network-object host 10.2.x.x
access-list NAT-LIST extended permit ip 192.168.0.0 255.255.0.0 any
access-list NAT-LIST extended permit ip host 10.a.b.c any
access-list NAT-LIST extended permit ip host 10.d.e.f any
access-list NAT-LIST extended permit ip 172.x.x.0 255.255.255.0 any
access-list NAT2 extended permit ip object-group OURHosts object-group PartnerHosts
access-list NAT3 extended permit ip host 192.168.a.b object-group OURHosts
nat (INSIDE) 0 access-list NO-NAT
nat (INSIDE) 1 access-list NAT-LIST
global (OUTSIDE) 1 interface
nat (INSIDE) 2 access-list NAT2
global (OUTSIDE) 2 172.20.n.o
static (INSIDE,OUTSIDE)
static (INSIDE,OUTSIDE) 172.20.n.1 access-list NAT3
Host 192.168.a.b is a specific server; all other references to 192.168.x.x addresses are variables.
I inherited the policy NAT config for the internet access, it worked and I just didn't think about it very much.
For my own clarity, let me re-phrase what I think you are suggesting: convert the policy NAT (NAT 1, GLOBAL 1) for the internal host access to the internet to a static NAT command, and only use policy NAT for VPN tunnel purposes, - is that a correct and concise summary?
If that is correct, is this what I need to do this:
static (INSIDE,OUTSIDE) INTERFACE access-list NAT-LIST
Again, if that is correct, I would like to change the static command "static (INSIDE,OUTSIDE) 172.20.n.1 access-list NAT3" to a policy NAT as well.
Thanks again. Patrick
03-06-2008 09:21 AM
Jon - reversing the order of the policy NAT statements worked very well. The tunnels come up fine, and internet access is just as robust as before.
Thanks for your time and input.
Patrick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide