cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9746
Views
4
Helpful
7
Replies

Order of NAT operation over Site to Site VPN Cisco ASA

Raj Kumar
Level 1
Level 1

Hi,

I have a question regarding the order of NAT operation over Site to Site VPN Cisco ASA 8.2.x. I have a Scenario where the internal IP address of range 10.17.128.x are being NATTED to public IP 31.10.10.x. Below is the config:

Tunnel is passing traffic traffic normally for dmz servers - 31.10.11.10, 31.10.11.11.

But NATTED Servers (10.17.128.x <-> 31.10.10.x) does not work.

crypto map inside_map 50 set transform-set ESP-3DES-SHA

tunnel-group 100.1.1.1 type ipsec-l2l

tunnel-group 100.1.1.1 general-attributes

default-group-policy PHX_HK

tunnel-group 100.1.1.1 ipsec-attributes

pre-shared-key ********

group-policy PHX_HK internal

group-policy PHX_HK attributes

vpn-filter none

vpn-tunnel-protocol IPSec svc webvpn

crypto map inside_map 50 match address outside_cryptomap_50

crypto map inside_map 50 set peer 100.1.1.1

crypto map inside_map 50 set transform-set ESP-3DES-SHA

crypto map inside_map 50 set reverse-route

object-group network PHX_Local

network-object host 31.10.11.10

network-object host 31.10.11.11

network-object host 31.10.10.10

network-object host 31.10.10.11

network-object host 31.10.10.12

network-object host 31.10.10.13

network-object host 10.17.128.20

network-object host 10.17.128.21

network-object host 10.17.128.22

network-object host 10.17.128.23

object-group network HK_Remote

network-object host  102.1.1.10

access-list inside_nat0_outbound extended permit ip object-group PHX_Local object-group HK_Remote

access-list ACL_INSIDE extended permit ip object-group PHX_Local object-group HK_Remote

access-list ACL_OUTSIDE extended permit ip object-group HK_Remote object-group PHX_Local

access-list outside_cryptomap_50 extended permit ip object-group PHX_Local object-group HK_Remote 

route outside 102.1.1.10 255.255.255.255 30.1.1.1 1

static (inside,outside) 31.10.10.10    10.17.128.20    netmask 255.255.255.255

static (inside,outside) 31.10.10.11    10.17.128.21    netmask 255.255.255.255

static (inside,outside) 31.10.10.12    10.17.128.22    netmask 255.255.255.255

static (inside,outside) 31.10.10.13    10.17.128.23    netmask 255.255.255.255

It started working when I made another object group by name PHX_Local1 and added that to access-list inside_nat0_outbound, instead of object group PHX_Local, as below:

object-group network PHX_Local1

network-object host 31.10.10.10

network-object host 31.10.10.11

network-object host 31.10.10.12

network-object host 31.10.10.13

no access-list inside_nat0_outbound extended permit ip object-group PHX_Local object-group HK_Remote 

access-list inside_nat0_outbound extended permit ip object-group PHX_Local1 object-group HK_Remote

Can you please help me understand why object group PHX_Local didnt work with access-list inside_nat0_outbound, however it started working with object group PHX_Local1.

Also if you could tell me the order of NAT operation over Site to Site VPN, that would be helpful.

Thanks

Regards,

Harshit

1 Accepted Solution

Accepted Solutions

Hi,

I think you might have stated the original question in a way that might be missleading. That is, if I understood it now.

From what I gather now, you have DMZ server which are direcly configure with public IP address on the actual servers. And for those you have configured NAT0.

Then you have some other servers which dont have the public IP addresses themselves but they are NATed on the ASA.

If this is the case then the next question would be. Should the server with the NAT go to the L2L VPN connection with their real IP address or with the NAT IP address.

Naturally if you are configuring NAT0  and Static NAT for the same servers the NAT0 will always win.

You have these hosts that werent able to use the L2L VPN

31.10.10.10    10.17.128.20

31.10.10.11    10.17.128.21

31.10.10.12    10.17.128.22

31.10.10.13    10.17.128.23

IF you want them to go to the L2L VPN with their original IP address then you should configure

object-group network LOCAL

network-object host 10.17.128.20

network-object host 10.17.128.21

network-object host 10.17.128.22

network-object host 10.17.128.23

object-group network REMOTE

network-object host 102.1.1.10

access-list inside_nat0_outbound extended permit ip object-group LOCAL object-group REMOTE

access-list outside_cryptomap_50 extended permit ip object-group LOCAL object-group REMOTE

IF you want them to use the L2L VPN with the public IP address then you should configure

object-group network LOCAL

network-object host 31.10.10.10

network-object host 31.10.10.11

network-object host 31.10.10.12

network-object host 31.10.10.13

object-group network REMOTE

network-object host 102.1.1.10

access-list outside_cryptomap_50 extended permit ip object-group LOCAL object-group REMOTE

EDIT: In this case you naturally dont configure any NAT0 for the real IP addresses as we specifically want the IP addresses to be visible to the L2L VPN with the NAT IP Address.

Or you can naturally use the same "object-group" as currently but modify the contents appropriately

Remember to mark the question as answered if it was answered.

Ask more if needed

- Jouni

View solution in original post

7 Replies 7

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I am not sure why you originally have both NAT0 and Static NAT configured for the hosts?

Wasnt the aim to specifically have the Static NAT to public IP address and then forward to the L2L VPN connection?

ASA matches the traffic against NAT before any VPN operations take effect.

NAT0 comes before Static NAT when it comes to ordering of NAT configurations.

You can test what rules certain traffic hit with "packet-tracer" command

packet-tracer input inside tcp

- Jouni

Thanks Jouni for your response, we had to do static nat on our end for

10.17.128.x to 31.10.10.x, as the other end had issues accepting 1918 addresses over tunnel.

My question is why it didnt work with : object-group PHX_Local

access-list inside_nat0_outbound extended permit ip object-group PHX_Local object-group HK_Remote

And worked with: object-group PHX_Local1

access-list inside_nat0_outbound extended permit ip object-group PHX_Local1 object-group HK_Remote

Hi Harshit,

As your configuration

object-group network PHX_Local

network-object host 31.10.11.10

network-object host 31.10.11.11

network-object host 31.10.10.10

network-object host 31.10.10.11

network-object host 31.10.10.12

network-object host 31.10.10.13

network-object host 10.17.128.20

network-object host 10.17.128.21

network-object host 10.17.128.22

network-object host 10.17.128.23

the translated as well as the real ip in the same object group

May i know what we are trying to achieve by puting the real as well as the tranlated IP  as the source in the same access-list ?

Thanks

Raj

rkumar5
Level 1
Level 1

Hi Harshit,

please find below the order of the Nat rule on ASA

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)

Thanks

Raj

So am i right in expecting

'access-list inside_nat0_outbound extended permit ip object-group PHX_Local object-group HK_Remote'  to work...?

and why it stared working with: object-group PHX_Local1

Thanks

Hi,

I think you might have stated the original question in a way that might be missleading. That is, if I understood it now.

From what I gather now, you have DMZ server which are direcly configure with public IP address on the actual servers. And for those you have configured NAT0.

Then you have some other servers which dont have the public IP addresses themselves but they are NATed on the ASA.

If this is the case then the next question would be. Should the server with the NAT go to the L2L VPN connection with their real IP address or with the NAT IP address.

Naturally if you are configuring NAT0  and Static NAT for the same servers the NAT0 will always win.

You have these hosts that werent able to use the L2L VPN

31.10.10.10    10.17.128.20

31.10.10.11    10.17.128.21

31.10.10.12    10.17.128.22

31.10.10.13    10.17.128.23

IF you want them to go to the L2L VPN with their original IP address then you should configure

object-group network LOCAL

network-object host 10.17.128.20

network-object host 10.17.128.21

network-object host 10.17.128.22

network-object host 10.17.128.23

object-group network REMOTE

network-object host 102.1.1.10

access-list inside_nat0_outbound extended permit ip object-group LOCAL object-group REMOTE

access-list outside_cryptomap_50 extended permit ip object-group LOCAL object-group REMOTE

IF you want them to use the L2L VPN with the public IP address then you should configure

object-group network LOCAL

network-object host 31.10.10.10

network-object host 31.10.10.11

network-object host 31.10.10.12

network-object host 31.10.10.13

object-group network REMOTE

network-object host 102.1.1.10

access-list outside_cryptomap_50 extended permit ip object-group LOCAL object-group REMOTE

EDIT: In this case you naturally dont configure any NAT0 for the real IP addresses as we specifically want the IP addresses to be visible to the L2L VPN with the NAT IP Address.

Or you can naturally use the same "object-group" as currently but modify the contents appropriately

Remember to mark the question as answered if it was answered.

Ask more if needed

- Jouni

Thanks alot Jouni for details explanation