CCIE Security Blog

8.3 introduced network objects to the configuration where you can to define a single host a range of ip addresses or single subnet. It is within this objects definition where the NAT is configured.

For auto NAT or Dynamic PAT:

#object network inside-net
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) dynamic interface

– In this case we specified how the ASA will translate the source ip address in the IP packet for the networks subnet when traversing from the local interface or the inside interface to the mapped interface or the outside interface. We’ve also stated that this is dynamic nat and we’re going to translate all of the hosts to the interface IP address of the firewall by using port address translation. Notice that we entered NAT command within the object definition so this configuration tells a firewall how to perform address translation on this specific object which in this case is inside network.
– If we look at the running configuration of the the firewall you’ll see that the ASA splits the object configuration into two parts:
first defines the object subnet and the second identifies the NAT configuration for the object so the object will appear twice in the configuration.
– In version 8.3 static and global commands are gone and all that configuration is done within NAT command

-/- -/- -/- -/- -/- -/- -/-

DMZ

Lets specify translation so that the server in the DMZ is statically translated to a global ip on the outside of the ASA. In this case we’ll translate the DMZ server 192.168.1.23 to 209.165.201.28.

1. define an object for the server and specify ip address for this particual host and configure NAT command within the object to provide a static one to one mapping

#object network dmz-webserver
host 192.168.1.23
nat (dmz.outside) static 209.165.201.28

now users on the internet can send packets to the global ip address of 209.165.201.28 and the ASА will provide translation and change the destination ip address in the packet to the local 192.168.1.23 server ip on the DMZ .

ASA still has to be specifically configured with ACL and access-group commands. ACL permitting the inbound access need to define the real ip address not the mapped IP address.

#access-list outside_in permit ip any host 192.168.1.23
#access-group outside_in in int outside

Now, check NAT config on ASA (display object definitions and then the NAT configurations applied within those objects):

# show run object
# show run nat

#show nat – display the nat table of the ASA

-/- -/- -/- -/- -/- -/- -/-

A new feature of 8.3 is that you can specify the translation for an object between multiple interfaces in just one line.

for example if we want ASA to perform address translation for DMZ server on any mapped interface of the ASA, then we could just use the any keyword in the map command.

#object netwrok dmz-webserver
nat (dmz,any) static 209.165.201.28

Now when hosts on any interface on the firewall need to have access to dmz server, they can connect directly to the mapped interface of 209.165.201.28. So our inside host can connect to this server using mapped interface if they have access.

-/- -/- -/- -/- -/- -/- -/-

Here we have two servers in DMZ hosting different services (http, ftp). We can use the same outside global mapped ip if we use pat to specify port address translation. In this case we use outside interface of ASA as mapped IP.

First create a object for dmz server and apply a NAT configuration to the object specifying that ASA should perform a static translation from dmz interface to the outside interface as the mapped ip, then we specify the local and mapped service port. In this case both are www since we dont change port in the translation:

#object network dmz-webserver
host 192.168.1.25
nat (dmz,outside) static interface service tcp www www

After doing this for www we will do the same for ftp server:

#object network ftp-webserver
host 192.168.1.25
nat (dmz,outside) static interface service tcp ftp ftp

#show run object
#show run nat

-/- -/- -/- -/- -/- -/- -/-

So far we’ve defined objects and specified how to translate their source ip addresses when they traverse certain interfaces of the ASA. However when using autonat you cannot specify that the ASA should only perfrom translation when host access certain destinations and you cannot specify how the ASA might translate the destination ip of the packet.

To do this we need to use manual nat or twice nat. Manual nat is not configured under an object definition; instead is configured separately in the configuration and takes objects as arguments to specify the translation.

#nat (real,mapped) source static object1 object2 destination _

Looking back at our diagram let’s say whenever internal users on the inside interface access http://www.cisco.com, the ASA should translate their source address to 209.165.201.10.
This differs from case when internal users access any other web site on the internet when they should be translated to the ASA outside interface ip of 209.165.201.2

To accomplish this we first need to create an object for each argument in the nat command one for the translated ip that we want to translate the users to:

#object network translated-ip
host 209.165.201.10

One for the ip address of cisco.com

#object network cisco-dot-com
host 198.133.219.25

We already have one for inside user subnet. Then to configure the manual NAT entry will add it in a base configuration of the ASA and not under an object:

#nat (inside,outside) source dynamic inside-nat translated-ip destination static cisco-dot-com cisco-dot-com

#sho run nat

This command specify that we provide translation from inside (inside) to the mapped ip of outside (outside) interface; in this case we will translate source of the packet (source), we are going to do dynamic port translation (dynamic) when the source of the packet matched inside network (object inside-nat) we’re going to translate it to the global ip specified in the translated-ip object (translated-ip).
With manual NAT you can specify the destination of the ip packet that you want to match and that is why we have cisco-dot-com as a destination ip

With this in place you can use packet tracert to inject a simulated packet thru the inside interface of the firewall. and send it to cisco.com and then to another ip address to see how firewall is going to translate packets differently.

# packet-tracer input inside tcp 10.0.0.40 4444 198.133.219.25 80

sending packet from inside interface sourced from 10.0.0.40 on port 4444, destined to cisco.com on port 80. Enter will inject this packet to firewall and show us exactly what is happening with packet. At the end of window, check NAT and note how ASA will translate source ip of the packet destined to cisco.com

Then, change last octet to something other then 25 and ASA will not match manual nat rule and should change ip from auto nat:

# packet-tracer input inside tcp 10.0.0.40 4444 198.133.219.31 80

-/- -/- -/- -/- -/- -/- -/-

Policy NAT exemption when ASA is asked not to translate IP address when traffic is destined to certain destinations (like thru VPN tunnel) so it does not translate any VPN packets from the internal network that it’s destined to our remote VPN subnets.

We have to use manual NAT.
Create object for remote vpn subnets with range of ip addresses of our remote subnets:

#object network vpn-subnets
range 10.1.0.0 10.5.255.255

Manual nat will tell the ASA to simply maintain the internal network ip address when accessing the remote vpn subnets. Now when internal user accessing remote hosts their packets will go across vpn tunnel without any translation,

#nat (inside,outside) source static inside-net inside-net destination static vpn-subnets vpn-subnets