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
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
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:
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
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
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
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :