Notice that none of the elements of the syntax include a real IP address. The real IP address is inherited from the object’s definition.
Now let’s take a look at Manual NAT and see the differences:
Auto NAT can only make a NAT decision based upon the Source of traffic.
Auto NAT can only translate the Source of traffic.
Manual NAT can make a NAT decision based upon the Source, or upon both the Source and Destination.
Manual NAT can translate the Source, the Destination, or even both the Source and Destination at the same time.
Manual NAT can do everything that Auto NAT can do, plus Policy NAT and Twice NAT, which both require the destination address to be involved in the process.
What is the best practice? Use Auto NAT whenever possible, because it is much simpler to configure. Also, Auto NAT places NAT statements automatically into a sensible order, while Manual NAT statement order must be manually considered.
The syntax of Manual NAT requires using an object for every reference to IP addresses and ports. Here is an example of Manual NAT configuration where only the source address is considered:
Notice that it is similar to Auto NAT except for the fact that Manual NAT is not configured within an object. It is configured directly in global configuration mode.
Here is an example of Manual NAT syntax where both source and destination are considered:
Hello all, I have always used the interface option for NAT/PAT and not the NAT_POOL that is suggested in this lesson. I’m wondering what are the benefits of using a pool of addresses for the translated address? I’m assuming a performance hit the way I’m perhaps doing it???
Also i’m thinking that if you have a pool of addresses then this pool of addresses needs to route; does tha ASA route this back out to the WAN interface which is on another subnet, of course, assuming I configure something lke this: nat (inside,outside) dynamic PUBLIC_POOL
where normally I just do this: nat (inside,outside) dynamic interface
The command nat (inside,outside) dynamic interface is employed in order for all NAT translations to use the IP address assigned to the outside interface as the translated address. In the case of a device connected to the Internet, this address would typically be a public IP address. This is convenient because that outside address is reachable from the Internet, and thus no additional routing is necessary to ensure it will be able to communicate with destinations on the Internet. Also, it delivers NAT to all inside hosts using the same outside address.
Alternatively, you can use the command nat (inside,outside) dynamic PUBLIC_POOL where PUBLIC_POOL is an ACL that defines a range of IP addresses to use. In this case, the NAT router will dynamically choose which outside address to use from that particular pool of addresses. The difference here is that those outside addresses are not the same as the address assigned to the outside interface. For this reason, routing must be configured such that the ISP will be able to route traffic destined for those addresses to your outside interface.
Now what are the benefits of each choice? Well, there is no benefit for either solution as far as resource usage goes. The same number of NAT translations will consume memory within the NAT router whether they use the same or different IP addresses.
The only benefit of using the address pool is that you have a theoretically larger number of translations than you can achieve using the interface alone. NAT typically uses transport layer ports ranging from 49125 to 65535 (the dynamic or private port range) for translation, a range of over 16000 ports. Thus, each IP address can theoretically translate up to 16000 internal hosts. By employing more outside IP addresses, you can multiply this limit. In most implementations, memory and CPU resources of the NAT router will be exhausted well before the number of ports will be consumed. Only in situations where we have carrier-grade NAT where thousands of devices use NAT will this actually play a role.
Conversely, using the interface is beneficial due to the fact that you don’t need to worry about routing. So unless you have very specific parameters that you need to fulfill, using the interface will be more than enough to serve even the largest enterprise networks with NAT.
Hello Laz, thank you for such a well considered and detailed response. This is great and answers my question well. It does change my thinking particularly with the config for a 5585-SSP-40! Have a great weekend.