cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1258
Views
0
Helpful
2
Replies

ASA - using Object-groups for NAT exclusions

martens72
Level 1
Level 1

I am working on tying several subnets together via VPN. I recently began using object-groups in our 8.2 config, but before actually applying the config, we updated to 8.4. I'll try not to complicate it further.

I have object-groups successfully applied to the ingress ACL, tying many hosts to specific ports. I also incorporated the object-groups into VPN crypto acls, and so far all is testing well. An example would be as follows:

*Note: Two companies that require seperate internal access for their subnets, but both access a common management subnet

object-group network Management

network-object 172.16.31.0 255.255.255.0

network-object 172.16.32.0 255.255.255.0

object-group network Remote_Management

network-object 172.16.100.0 255.255.255.0

network-object 172.16.200.0 255.255.255.0

object-group network Customer1-Site

network-object 192.168.1.0 255.255.255.0

object-group network Customer2-Site

network-object 192.168.200.0 255.255.255.0

object-group network All_Remote_Sites

group-object Remote-Site_1

group-object Remote-Site_2

object-group network Company1_internal

network-object 10.1.0.0 255.255.255.0

network-object 10.2.0.0 255.255.255.0

object-group network Company2_internal

network-object 10.100.0.0 255.255.255.0

network-object 10.200.0.0 255.255.255.0

object-group network All_Internal

group-object Company1_internal

group-object Company2_internal

access-list remote_1_crypto extended permit ip object-group Company1_internal object-group Customer1-Site

access-list remote_1_crypto extended permit ip object-group Management object-group Customer1-Site

access-list remote_1_crypto extended permit ip object-group Remote_Management object-group Customer1-Site

access-list remote_2_crypto extended permit ip object-group Company2_internal object-group Customer2-Site

access-list remote_2_crypto extended permit ip object-group Management object-group Customer2-Site

access-list remote_2_crypto extended permit ip object-group Remote_Management object-group Customer2-Site

My question is in regards to what used to be NAT Exclusion. Assuming we were still using 8.2, I would apply the following to NAT 0 ACL to permit local and remote management to the customer remote and local subnets (and vice versa):

access-list nat0 extended permit ip object-group Management object-group All_Remote_Sites

access-list nat0 extended permit ip object-group All_Remote_Sites object-group  Management

access-list nat0 extended permit ip object-group Remote_Management object-group All_Internal

access-list nat0 extended permit ip object-group All_Internal object-group Remote_Management

access-list nat0 extended permit ip object-group Remote_Management object-group All_Remote_Sites

access-list nat0 extended permit ip object-group All_Remote_Sites object-group Remote_Management

In 8.4 code, I would want to apply the following to perform the same fucntion:

nat (inside, outside) source static All_Remote_Sites All_Remote_Sites destination static Management Management no-proxy-arp route-lookup

nat (inside, outside) source static Management Management destination static All_Remote_Sites All_Remote_Sites no-proxy-arp route-lookup

nat (inside, outside) source static All_Internal All_Internal destination static Remote_Management Remote_Management no-proxy-arp route-lookup

nat (inside, outside) source static Remote_Management Remote_Management destination static All_Internal All_Internal no-proxy-arp route-lookup

nat (inside, outside) source static All_Remote_Sites All_Remote_Sites destination static Remote_Management Remote_Management no-proxy-arp route-lookup

nat (inside, outside) source static Remote_Management Remote_Management destination static All_Remote_Sites All_Remote_Sites no-proxy-arp route-lookup

Concern:

Will the ASA, using either code, be able to handle the object groups correctly? My main concern is that each group contains multiple subnets, and it will begin NATing one subnet into another (Customer 1 subnet to Customer 2 subnet) on the source translation. While I see no issue to exclude one internal subnet to many remote subnets, I am concerned when it comes to multiple subnets on each end being handled correctly. I have looked online for examples of object-group usage in NAT exclusions or in the 8.4 code example, but am not seeing any at the moment. In 8.4, the device accepts the command and displays the subnets appropriately using the following command:

sh nat object-group Management translated object-group All_Remote_Sites detail

The output would display as follows:

    translate_hits = 1978, untranslate_hits = 426

    Source - Origin: 172.16.31.0/24, 172.16.32.0/24, Translated: 172.16.31.0/24, 172.16.32.0/24,

    Destination - Origin: 10.1.0.0/24, 10.2.0.024, 10.100.0.0/24, 10.200.0.0/24 Translated: 10.1.0.0/24, 10.2.0.024, 10.100.0.0/24, 10.200.0.0/24

Everything "appears" to be functioning correctly, but I am concerned I am just asking for trouble as we get into groups of possibly hundreds of internal subnets.

Any help or comments would be appreciated.

2 Replies 2

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

To me it seems like you are adding "extra" NAT statements with the old NAT0/NAT Exempt configurations.

It seems like you have done the NAT0 to both directions? Have you done NAT0 on both outside/inside interfaces on your ASA?

There should be no need to do that (if youre doing it). Usually in a simple setup you only have an "nat (inside) 0 access-list " statement on your "inside" interface for remote access VPN and L2L VPN. If you have access from the VPN to other internal interfaces, you can do the same for those interfaces.

It also seems to me like you've done the same in the new software configurations. You have NAT0 configurations to both directions, yet you have the source and destination interface the same way in each statement. To my understanding it would be enough to have the statements only once and the direction beeing "inside -> outside"

Otherwise your configurations seems to be fine and the same way as I would do them. .Though a small thing, I tend to name all my objects and object-groups with all capital letters so they are easy to make out from the configurations in CLI (I don't really use ASDM). So they dont look the same as the actual configurations statements (which are all in lower case letters) Then again when you've reached the point where you have alot of configurations on a single device it will still get confusing to look at even with capital letters.

I'm not sure if I understood you correctly on the Concern part, but I guess you have some concern about the NAT statemtents starting to overlap with eachother or somehow mix the networks up?

To my understanding, as long as you keep the NAT statements "source/destination static " identical in the NAT statements, you will be fine.

All of the above configurations should just tell the ASA to keep the source and destination address unchanged when you are connection from the source networks to the destination networks in the NAT statements.

Atleast this is the way I'm going to do them until I face some problem

- Jouni

Thanks for the feedback Jouni,

My concern I guess, was that I was not finding any cisco command documentation actaully showing the use of object-groups in the twice-nat, or nat exclusions. It seems to be working, so I am happy for that.

In regards to applying the config in both directions, I found that in 8.2 code, with traditional NAT exemption, it is not necessary to have the config in both directions. In 8.4 code, however, there is no nat-control, and the new config seems more of a double nat (internal local to internal global | external local to external global). I have found issues with not applying the permissions in both directions. I had a remote subnet that was able to reach all internal subnets except one. The internal was part of an object-group which included the other internals that were reachable. I added the reverse directional config and it started working. I was told during deployment that the 8.4 should automatically permit the reverse path based on ACL entries, but that in practice, it does not always work. I experienced this during testing, so I have just hardcoded the reverse paths so I don't run into issues later.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: