cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1380
Views
0
Helpful
11
Replies

Policy NAT for L2L VPN

pdriscoll
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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

View solution in original post

11 Replies 11

Jon Marshall
Hall of Fame
Hall of Fame

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

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

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

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

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

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

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

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

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

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) 192.168.a.b netmask 255.255.255.255

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

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