Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
594
Views
0
Helpful
2
Replies

No NAT convertion to 9.x from 8.0 question

Go to solution
burleyman
Level 8
Level 8

‎01-27-2015 06:07 AM - edited ‎03-11-2019 10:24 PM

I had something like this on the 8.0

nat (inside) 0 access-list 100

access-list 100 extended permit ip 10.239.1.0 255.255.255.0 10.239.125.0 255.255.255.0
access-list 100 extended permit ip 10.239.1.0 255.255.255.0 10.239.126.0 255.255.255.0

access-list 100 extended permit ip 10.239.17.0 255.255.255.0 10.239.125.0 255.255.255.0
access-list 100 extended permit ip 10.239.17.0 255.255.255.0 10.239.126.0 255.255.255.0

I know I create objects and this is what it would look like in the 9.x config

object network OBJ-10.239.1.0_24
 subnet 10.239.1.0 255.255.255.0

object network OBJ-10.239.17.0_24
 subnet 10.239.17.0 255.255.255.0

object network OBJ-10.239.125.0_VPN
 subnet 10.239.125.0 255.255.255.0

object network OBJ-10.239.126.0_VPN
 subnet 10.239.126.0 255.255.255.0

nat (inside,outside) source static OBJ-10.239.1.0_24 OBJ-10.239.1.0_24 destination static OBJ-10.239.125.0_VPN OBJ-10.239.125.0_VPN

nat (inside,outside) source static OBJ-10.239.1.0_24 OBJ-10.239.1.0_24 destination static OBJ-10.239.126.0_VPN OBJ-10.239.126.0_VPN

nat (inside,outside) source static OBJ-10.239.17.0_24 OBJ-10.239.17.0_24 destination static OBJ-10.239.125.0_VPN OBJ-10.239.125.0_VPN

nat (inside,outside) source static OBJ-10.239.17.0_24 OBJ-10.239.17.0_24 destination static OBJ-10.239.126.0_VPN OBJ-10.239.126.0_VPN

 

Now I have a bunch of subnets in the 10.239.X.0 space so rather than creating a bunch of NAT lines for each one could I do this.

object network OBJ-10.239.0.0_16
 subnet 10.239.0.0 255.255.0.0

object network OBJ-10.239.125.0_VPN
 subnet 10.239.125.0 255.255.255.0

object network OBJ-10.239.126.0_VPN
 subnet 10.239.126.0 255.255.255.0

nat (inside,outside) source static OBJ-10.239.0.0_16 OBJ-10.239.0.0_16 destination static OBJ-10.239.125.0_VPN OBJ-10.239.125.0_VPN

nat (inside,outside) source static OBJ-10.239.0.0_16 OBJ-10.239.0.0_16 destination static OBJ-10.239.126.0_VPN OBJ-10.239.126.0_VPN

 

or would this cause a problem because the 10.239.125.0 and the 10.239.126.0 would overlap with the source 10.23.0.0 /16

 

Mike

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Jouni Forss
VIP Alumni
VIP Alumni

‎01-27-2015 08:34 AM

Hi,

 

The overlap in this case should not cause any problems as this NAT configuration only applies to traffic between "inside" and "outside" interface. So I don't see a situation where it would for example forward traffic in a wrong way.

 

It would possibly become a problem if for example you had some subnets fitting the 10.239.0.0/16 behind some other interface than "inside". In that situation you might face a problem if a remote VPN user should be able to connect to that subnet. It might then match this NAT configuration and get forwarded to "inside" interface rather than that other interface.

 

You should however be able to avoid the above problem by either adding NAT configuration for those subnets behind another interface on the ASA on a higher priority in the NAT configuration or perhaps you could have the above NAT configurations you mention with the parameter "route-lookup" at the end. The "route-lookup" should force the ASA to check the routing table and not apply the NAT configuration if the route lookups destination interface did not match the one the NAT configuration had. It should therefore prevent traffic from getting forwarded to the wrong interface by the NAT. The ASA would then to my understanding go through the other NAT configurations to see if there is any other matching configuration that it could apply.

 

I guess you have many options how to do the above NAT configurations.

 

I typically use "object-group" configurations to group the subnet related to the NAT0 configurations. If you wanted you could for example group all your internal subnets under one "object-group" and the VPN subnets under their own "object-group".

 

object-group network VPN-NAT0-LOCAL
 network-object 10.239.x.0 255.255.255.0
 network-object 10.239.y.0 255.255.255.0

 

object-group network VPN-NAT0-REMOTE
 network-object 10.239.125.0 255.255.255.0
 network-object 10.239.126.0 255.255.255.0

 

nat (inside,outside) source static VPN-NAT0-LOCAL VPN-NAT0-LOCAL destination static VPN-NAT0-REMOTE VPN-NAT0-REMOTE

 

Naturally this approach might narrow down your ability to name the objects in a meaningful way but I personally prefer to keep the amount of objects to a minimum.

 

Hope this helps :)

 

- Jouni

View solution in original post

0 Helpful
2 Replies 2

Go to solution
Jouni Forss
VIP Alumni
VIP Alumni

‎01-27-2015 08:34 AM

Hi,

 

The overlap in this case should not cause any problems as this NAT configuration only applies to traffic between "inside" and "outside" interface. So I don't see a situation where it would for example forward traffic in a wrong way.

 

It would possibly become a problem if for example you had some subnets fitting the 10.239.0.0/16 behind some other interface than "inside". In that situation you might face a problem if a remote VPN user should be able to connect to that subnet. It might then match this NAT configuration and get forwarded to "inside" interface rather than that other interface.

 

You should however be able to avoid the above problem by either adding NAT configuration for those subnets behind another interface on the ASA on a higher priority in the NAT configuration or perhaps you could have the above NAT configurations you mention with the parameter "route-lookup" at the end. The "route-lookup" should force the ASA to check the routing table and not apply the NAT configuration if the route lookups destination interface did not match the one the NAT configuration had. It should therefore prevent traffic from getting forwarded to the wrong interface by the NAT. The ASA would then to my understanding go through the other NAT configurations to see if there is any other matching configuration that it could apply.

 

I guess you have many options how to do the above NAT configurations.

 

I typically use "object-group" configurations to group the subnet related to the NAT0 configurations. If you wanted you could for example group all your internal subnets under one "object-group" and the VPN subnets under their own "object-group".

 

object-group network VPN-NAT0-LOCAL
 network-object 10.239.x.0 255.255.255.0
 network-object 10.239.y.0 255.255.255.0

 

object-group network VPN-NAT0-REMOTE
 network-object 10.239.125.0 255.255.255.0
 network-object 10.239.126.0 255.255.255.0

 

nat (inside,outside) source static VPN-NAT0-LOCAL VPN-NAT0-LOCAL destination static VPN-NAT0-REMOTE VPN-NAT0-REMOTE

 

Naturally this approach might narrow down your ability to name the objects in a meaningful way but I personally prefer to keep the amount of objects to a minimum.

 

Hope this helps :)

 

- Jouni

0 Helpful

Go to solution
burleyman
Level 8
Level 8
In response to Jouni Forss

‎01-27-2015 09:51 AM

Thanks I forgot about grouping them thanks for that. Thanks for your help.

 

Mike

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card