Cisco ASA and NAT configuration with Twice

NAT & Object NAT

June 2, 2018adminIT LABS, Networking & Security

NAT on ASA differs to NAT on IOS routers regarding

configuration.At first glance may seems to be very
confusing, but as we see in a while the crucial is
understanding where particular types of NAT takes
place, then configuration is easy.

!!!This article relates only to ASA 8.3 and

higher, some issues may also be valid regarding 8.2, but not configuration!!!
The NAT table on ASA consists of 3 sections that determine the order of proceeding. It is
similar to ACLs, the more specific and accurate entry or important rule should be placed
higher. For example if you are going to make a NAT rule based on source and destination
(Policy NAT) or exempt VPN traffic from being natted (NAT examption) then you should
put them into Manual NAT (section 1), if you are using simple Dynamic NAT or PAT then
you may put this rules into After-Auto Manual NAT in Section 3. If you want to create a
rules regarding Static NAT or PAT then you should consider Auto NAT section 2. Each
section contains specified type of NAT:
1st Manual NAT / Twice NAT
2nd Auto NAT / Object based NAT
3rd After-Auto NAT
This is how NAT tabel on ASA looks :
Here I collected information about Manual NAT and Auto NAT and compared them:
The key elements of NAT on ASA.
To compare with ASA 8.2 and earlier we don’t use ACLs anymore to mark the interested
traffic. From now on, we use “object network”, “object service” and “object group” to
describe interested traffic. Also naming of interfaces has a huge meaning.
Regarding particular NAT types we will be using different “objects” name :
Manual NAT /Twice NAT
object-group network [name] – to define a couple of networks, hosts etc
object-group service [name] – to define particular source and destination services (tcp,
udp etc)
object network [name] – under ‘object-group’ to define a single network, host or range
of addresses
Auto NAT / Object NAT
object network [name] – to define a single network, host or range of addresses
The names of “object network” and “object service” may be easily renamed with command
“object network [name] rename [new_name]” or “object service [name] rename
[new_name]“

Ok, so let’s configure something!

I created the lab with simple topology, on ASA I enabled the whole traffic in each
direction with simple ACL and applied its globaly
access-list 101 extended permit tcp any4 any4
access-list 101 extended permit icmp any any
access-group 101 global
also I had to add “inspect icmp” to the “global_policy map” and class
“inspection_default“. Make sure you are able to ping each network from ASA before
you go over configuration of NAT.

AUTO NAT / OBJECT NAT

STATIC NAT

object network [NAME]

host [REAL_IP]
nat (source,dest) static [MAPPED_OUTSIDE_IP]
object network static_nat_172.16.32.32
host 172.16.32.32
nat (inside,outside) static 1.1.1.100
NAT from INSIDE:172.16.32.32 to OUTSIDE:1.1.1.100
STATIC PAT
object network [NAME]
host [REAL_IP]
nat (source,dest) static interface/[or OUT_IP_ADDRESS] service [TCP/UDP]
[REAL_PORT] [MAPPED_PORT]
object network static_pat_172.32.32.35
host 172.32.32.35
nat (inside,outside) static interface service tcp 23 23
TCP PAT from INSIDE:172.32.32.35 23-23 to OUTSIDE:1.0.0.252 23-23
DYNAMIC PAT

object network [NAME]

subnet [REAL_SUBNET]
nat (source,dest) dynamic interface
object network subnet_172.16.100.0
subnet 172.16.100.0 255.255.255.0
nat (inside,outside) dynamic interface
ICMP PAT from INSIDE:172.16.100.1/1 to OUTSIDE:1.0.0.252/1
DYNAMIC NAT

object network [OUTSIDE_POOL]

range [START_RANGE] [END_RANGE]
object network [NAME]
subnet [REAL_SUBNET]
nat (source,dest) dynamic [OUTSIDE_POOL]
object network OUT_POOL
range 1.0.0.10 1.0.0.20
object network INSIDE_SUBNET
subnet 172.16.150.0 255.255.255.0
nat (inside,outside) dynamic OUT_POOL
NAT from INSIDE:172.16.150.1 to OUTSIDE:1.0.0.17

MANUAL NAT / TWICE NAT

DYNAMIC PAT
object-group network [INSIDE_NETWORK_NAME]
network-object [REAL_IP_ADDRESS]
nat (source,dest) after-auto source dynamic [INSIDE_NETWORK_NAME] interface
object-group network INSIDE_NETWORK
network-object 172.16.100.0 255.255.255.0
nat (inside,outside) after-auto source dynamic INSIDE_NETWORK interface
ICMP PAT from INSIDE:172.16.100.1/0 to OUTSIDE:1.0.0.252/1471
DYNAMIC NAT

object-group network [INSIDE_NETWORK_NAME]

network-object [REAL_IP_ADDRESS]
object network [OUTSIDE_IP_POOL]
range [NAT_POOL]
nat (source,dest) after-auto source dynamic [INSIDE_NETWORK_NAME]
[OUTSIDE_IP_POOL]
object-group network INSIDE_NETWORK
network-object 172.16.150.0 255.255.255.0
object network OUTSIDE_POOL
range 1.0.0.90 1.0.0.100
nat (inside,outside) after-auto source dynamic INSIDE_NETWORK
OUTSIDE_POOL
NAT from INSIDE:172.16.150.1 to OUTSIDE:1.0.0.96

DYNAMIC POLICY PAT

object-group network [INSIDE_NETWORK]

network-object [REAL_IP_ADDRESS]
object-group network [DESTINATION]
network-object [REAL_IP_NETWORK_ADDRESS]
network-object host [REAL_IP_ADDRESS]
nat (source,dest) source dynamic [INSIDE_NETWORK] interface destination static
[DESTINATION] [DESTINATION]
object-group network INSIDE_NETWORK
network-object 172.16.200.0 255.255.255.0
object-group network DESTINATION
network-object 3.3.3.0 255.255.255.0
network-object host 2.2.2.2
nat (inside,outside) source dynamic INSIDE_NETWORK interface destination
static DESTINATION DESTINATION
NAT from OUTSIDE:3.3.3.0/24, 2.2.2.2 to INSIDE:3.3.3.0/24,
2.2.2.2
ICMP PAT from INSIDE:172.16.200.1/0 to OUTSIDE:1.0.0.252/63179
DYNAMIC POLICY NAT
object-group network INSIDE_NETWORK
network-object 172.16.200.0 255.255.255.0
object-group network DESTINATION
network-object 3.3.3.0 255.255.255.0
network-object host 2.2.2.2
object network OUTSIDE_NAT_POOL
range 1.0.0.100 1.0.0.110
nat (inside,outside) source dynamic INSIDE_NETWORK OUTSIDE_NAT_POOL
destination static DESTINATION DESTINATION
NAT from OUTSIDE:3.3.3.0/24, 2.2.2.2 to INSIDE:3.3.3.0/24, 2.2.2.2
NAT from INSIDE:172.16.200.1 to OUTSIDE:1.0.0.100

NAT EXEMPTION \ IDENTITY NAT

object network [SOURCE_EXEMPTED_TRAFFIC]

subnet [SOURCE_EXEMPTED_SUBNET]
object network [DEST_EXEMPTED_TRAFFIC]
subnet [DEST_EXEMPTED_SUBNET]
nat (source,dest) source static [SOURCE_EXEMPTED_TRAFFIC]
[SOURCE_EXEMPTED_TRAFFIC]
destination static [DEST_EXEMPTED_TRAFFIC] [DEST_EXEMPTED_TRAFFIC]
object network SOURCE_EXEMPTED_TRAFFIC
subnet 172.16.250.0 255.255.255.0
object network DEST_EXEMPTED_TRAFFIC
subnet 3.3.3.0 255.255.255.0
nat (inside,outside) source static SOURCE_EXEMPTED_TRAFFIC
SOURCE_EXEMPTED_TRAFFIC destination static DEST_EXEMPTED_TRAFFIC
DEST_EXEMPTED_TRAFFIC
NAT from INSIDE:172.16.250.0/24 to OUTSIDE:172.16.250.0/24
NAT from OUTSIDE:3.3.3.0/24 to INSIDE:3.3.3.0/24

STATIC POLICY NAT

object network [INSIDE_NETWORK]
subnet [REAL_IP_ADDRESS]
object network [INSIDE_NETWORK_MAPPED]
subnet [MAPPED_IP_ADDRESS]
object network [DESTINATION]
subnet 3.3.3.0 255.255.255.0
nat (source,dest) source static [INSIDE_NETWORK] [INSIDE_NETWORK_MAPPED]
destination static [DESTINATION] [DESTINATION]
object network INSIDE_NETWORK
subnet 172.16.250.0 255.255.255.0
object network INSIDE_NETWORK_MAPPED
subnet 192.168.1.0 255.255.255.0
object network DESTINATION
subnet 3.3.3.0 255.255.255.0
nat (inside,outside) source static INSIDE_NETWORK
INSIDE_NETWORK_MAPPED destination static DESTINATION DESTINATION
NAT from INSIDE:172.16.250.0/24 to OUTSIDE:192.168.1.0/24
NAT from OUTSIDE:3.3.3.0/24 to INSIDE:3.3.3.0/24

STATIC POLICY PAT

object network [INSIDE_NETWORK]
subnet [REAL_IP_ADDRESS]
object network [INSIDE_NETWORK_MAPPED]
subnet [MAPPED_IP_ADDRESS]
object network [DESTINATION]
subnet 3.3.3.0 255.255.255.0
object service [SERVICE_SOURCE_TO_DESTINATION]
service [TCP/UDP] source/destination eq [SERVICE_PORT]
nat (source,dest) source static [INSIDE_NETWORK] [INSIDE_NETWORK_MAPPED]
destination static [DESTINATION] [DESTINATION
[SERVICE_SOURCE_DESTINATION] [SERVICE_SOURCE_DESTINATION]
object network INSIDE_NETWORK
subnet 172.16.250.0 255.255.255.0
object network INSIDE_NETWORK_MAPPED
subnet 192.168.1.0 255.255.255.0
object network DESTINATION
subnet 3.3.3.0 255.255.255.0
object service SERVICE
service tcp destination eq 80
nat (inside,outside) source static INSIDE_NETWORK
INSIDE_NETWORK_MAPPED destination static DESTINATION DESTINATION
service SERVICE SERVICE
TCP PAT from INSIDE:172.16.250.0/24 0 to OUTSIDE:192.168.1.0/24 0
TCP PAT from OUTSIDE:3.3.3.0/24 80-80 to INSIDE:3.3.3.0/24 80-80
SSO = Stateful switchover , establish a relation of active / passive between 2 supervisor
engines in a chassis to provide uninterrupted L2 functionality in case of a hardware
failure. Imagine that you have 2 SUP in one chassis and one of them is the active one
taking care of all operation, while the second one has the same configuration, but it is in
standby mode. In case the the first SUP fails, the standby one take care of all
operations without any interruption

NFS = Non-stop forwarding, works together with SSO, but this protocol offer support for
L3 uninterrupted operations. Protocol like BGP, OSPF are NFS capable, able to detect
a failure and react to have no operation interruption.

More about SSO+NFS here (operation and configuration details on a C6500, but the
basics are the same on all platforms):

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configur
ation/guide/nsfsso.html#wp1097378

Now, VSS rely on SSO+NFS to offer High Availability services:

Q. What high-availability mechanisms are available with a VSS?

A. A VSS uses interchassis NSF/SSO as the primary mechanism for high availability
between the two chassis. One virtual switch member chassis will act as the active
virtual switch member, while the other member will be in hot standby state for the
control plane. Note that the data planes of both chassis are active and hence forward
traffic at full combined capacity of 1440 Gbps. When one of the virtual switch members
fails, there is no reconvergence of protocols in the network. The access layer or core
layer switches continues to forward traffic because they only detect a link failure in an
EtherChannel bundle and hence do not need to reconverge any protocols. No disruption
occurs to the traffic flowing through the VSS. The VSS mechanism during switch failure
is far superior when comparison with the traditional model where one switch failure
results indeterminist convergence of multiple control protocols like STP, HSRP and
routing protocol.