I am fairly familiar with ASA 8.4+ NAT rules but was wondering what is considered the best practise when an ASA is an Internet edge device that is doing NAT/PAT for Internet access as well as Site-to-Site VPN with RFC1918 addressing on either side of the tunnels.
In an effort to keep configurations as neat as possible is it good practise to create a generic NAT rule at the top of the list that says 'any source interface, any destination interface, source 10.0.0.0/8 destination 10.0.0.0/8, do identity NAT (assuming you are using subnets from 10.0.0.0/8 on your inside/DMZ interfaces). I know there are likely to be exceptions but my logic here is any 10.0.0.0/8 source that is attempting to communicate with any 10.0.0.0/8 destination will not need to be NAT'd as this will be our internal 'private' traffic. If the destination is not 10.0.0.0/8 then its (probably) destined for a public IP host so should be NAT'd.
Obviously the ACLs used for the crypto-maps will be more specific - i.e. source=10.1.0.0/20, destination 10.1.16.0/20 is for VPN traffic from this site to site X etc, as well as ACLs applied to the Interfaces that apply our security policy.
It seems to me a simple way but haven't seen it configured like this anywhere so wondered if this just isn't how you would do it, or there are big security concerns in doing it this way?
I would always recommend you to use specific interfaces in the NAT statements as we have seen many unexpected results when you use (any,any) keywords as it will use the same NAT for every interface on the ASA device.
Also , on the ASA 8.3 +, you don't need any NAT statements to communicate between the interfaces on the ASA device as there is no concept of nat-control which used to be there on ASA 8.2 and below.
So , pm;ly create NAT statements for the traffic that needs to be translated and VPN traffic which needs to be exempted.
I have been playing around with this in the lab and if I specify specific source and destination interfaces but have an 'any' as the destination address (i.e. this would be an outbound Internet connection) then this would match either my L2L or RA VPN traffic unless I had an Identity NAT statement before it. I also hit the issue where the routing decision was made based on the NAT'd packet and not the routing table.
I understand that if I have several Inside/DMZ interfaces I don't need NAT rules covering these as they all speak 'Natively', however traffic from any of my Inside/DMZ interfaces to the Outside interface where NAT/PAT should occur (but only for 'Internet' based addresses and not my VPN traffic) will require several lines in the configuration. If I do it the way I suggest then I need one network object and one identity NAT statement:
Your suggestion seems to make more sense but will I not get hit with the forwarding decision being made based on NAT with 'any' as the destination address and this would be hit first without any more specific NAT rules before it?
To my understanding the above example configuration should be fine. Traffic should still match the routing table information and this configuration should simply make sure that there is no translation for hosts when connections are made by hosts behind different interfaces but all fitting to the network 10.0.0.0/8. If either of the interfaces were specified in the "nat" command (instead of any) I think it could potentially affect the connections through the firewall (NAT overriding the routing table)
Even though this might work (I have not tested it or used it) I probably would not use this configuration myself even if it brought down the amount of NAT configurations. I rather have specific configurations matching the VPN connections.
Then again we dont have any environments with that many VPN connections that would warrant this kind of configuration. For example we have some separate ASA Failover pairs doing VPN connections in which case the ASA NAT configuration can be left completely blank an no such configuration is needed. If there is some specific NAT need its handled on another device thats meant purely for the firewalling purpose.
As Vibhor already stated, you wont need Static Identity NAT or NAT0 configurations in the new software for traffic between your local networks/interfaces. If no NAT is needed between your local networks connected to the ASA then you simply dont configure any NAT.
So I think if your only aim was to configure this NAT because of the traffic between your local networks then its not really needed. If you had several L2L VPN and VPN Client connections then it might make sense if you wanted to apply Static Identity NAT / NAT0 to all traffic between local networks and the VPN networks. Since you would be configuring both the source and destination interface as "any" this should mean that the ASA would make the traffic forwarding choice according to the routing table instead of the NAT configuration.
If you want to read some more about the new NAT configuration format you could take a look at a document I wrote in 2013
I am still waiting for the extra motivation to revise the document to reflect all the things that happened with the ASA NAT since the time of the writing but current work situation is making that hard. :)
But if I were to list my own preferences regarding NAT shortly this would be my points
Use Section 1 for
NAT0 configurations related to VPN
Static NAT for whole subnets (if you for example have dedicated link/interface to a 3rd party)
Static Policy NAT
Dynamic Policy PAT/NAT in situations where the Dynamic PAT/NAT has to be performed also for hosts/servers which have Static NAT configured (in Section 2)
Use Section 2 for
Use Section 3 for
All the Dynamic PAT/NAT configurations
Majority of Dynamic Policy PAT/NAT configurations (see comment on Section 1). Place these Dynamic Policy PAT/NAT configurations before any other NAT configurations for the source interface in question.
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 :