Cisco ASA firewall basics

I am nearly at the stage for configuring the ASAs in my CCIE Security lab, well, the HQ part at least.

Before we do that though it would probably be a good idea to go through some of the more basic aspects of the Cisco ASA firewall.

Cisco ASA firewall fundamentals

Cisco ASA models

Cisco ASAs come in a two flavors, physical and virtual. The virtual one is relatively new, and is known as the ASAv ("v" for virtual, it makes sense). The physical range of ASA firewalls (5500 series) has been around for a number of years, and replaced the PIX firewalls.

The current product range starts with the 5505, which would be your typical SOHO router firewall combo, and then the range moves into the -X models, starting with the 5506-X.

The X denotes that these models are the next-generation of ASA, and come with FirePOWER, which we'll look at in a different post. So, what is the difference between the 5505 and the 5506-X? It's pretty big actually.

Despite the minor number jump, the 5506 is a far more uprated device. Here are some of the comparative stats from the Cisco website:

Cisco ASA Model	ASA 5505 / Security Plus	ASA 5506-X / Security Plus
Image
Stateful inspection throughput (max)	Up to 150 Mbps	750 Mbps
Maximum concurrent sessions	10,000 / 25,000	20,000/50,000
Packets per second (64 byte)	85,000	246,900
Maximum site-to-site and IPsec IKEv1 client VPN user sessions	10 / 25	10 / 50
Maximum Cisco AnyConnect IKEv2 remote access VPN or clientless VPN user sessions	25	2 / 50
VLANs	3 (trunking disabled) / 20 (trunking enabled)	5 / 30
High-availability support	Stateless A/S only (active / standby)	A / S
Integrated I/O	8-port FE with 2 Power over Ethernet (PoE) ports	8 x 1 Gigabit Ethernet (GE)

As you can see, you can push a far greater amount of traffic through the 5506-X than the 5505.

Prices for the 5505 start at about £250, and go up to around £800, the one above falls into the latter price range. The 5506-X range is not much more expensive, prices start at around £400.

As you move higher up the model line, naturally the prices start to enter enterprise kind of money (lots of zeros at the end). But, again, you do get more bang for your buck.

Sizing a firewall is tricky business. You need to look at the number of users you have, both on site and remote, the number that will be connecting via VPN, both site to site, and client VPN, such as AnyConnect. You also need to look at what kind of application traffic the firewall will be passing.

For example the 5512-X could easily support around 2000 users, with around 500 of those being remote users. Prices for this are around £2300.

Basic Cisco ASA firewall configuration

Cisco ASA firewalls are anything but basic. But don't be put off by their complexity. Getting them up and running can be done in a short space of time.

Let's start off with our interfaces, and how they relate to firewall function. A firewall separates traffic between different areas. The ASA interfaces can be assigned to different areas, we will need one on the outside, connecting us to our upstream service provider, one on the inside for our users, and maybe one for our public facing servers, which is known as a DMZ, or Demilitarised Zone.

In our example below, we have an ISP, our ASA (ASAv), and our client (user) machine:

We will, for a little while, need to use VNC to control the ASA.

Our Gi0/0 interface will be our "Outside" interface, and our Gi0/1 interface will be our "Inside" interface. There is a reason we name them these, and that is because the ASA will automatically assign a security level to these interfaces, as we will see in a moment.

Let's get started.

ISP:

Router(config)#ho ISP
ISP(config)#int fa0/0
ISP(config-if)#ip add 10.1.1.1 255.255.255.252
ISP(config-if)#no shu
ISP(config-if)#int lo0
ISP(config-if)#ip add 8.8.8.8 255.255.255.255    
ISP(config-if)#ip route 0.0.0.0 0.0.0.0 10.1.1.2
ISP(config)#

User-PC:

Router(config)#ho User1
User1(config)#int fa0/0
User1(config-if)#ip add 192.168.1.17 255.255.255.0
User1(config-if)#no shu
User1(config-if)#ip route 0.0.0.0 0.0.0.0 192.168.1.254
User1(config)#

Cisco ASA interface configuration

OK, let's configure the ASA up, starting with setting the hostname and the outside interface:

Now we configure the Inside interface:

Notice how the ASA will set the security levels according to the interface names, with 0 for the Outside interface, and 100 for the Inside interface. 0 is a "least trusted" level and 100 is the "most trusted" level. We can set these manually if we want to, using the command "security-level <0-100>".

At this stage we should have connectivity from the User1 "PC", and from the ISP:

User1#ping 192.168.1.254 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/7/12 ms
User1#

ISP#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
ISP#

The ASAv needs to be aware of the 8.8.8.8 "server", so we can create a default route on the ASAv to do this:

Notice that unlike traditional IOS based devices, the ASA is actually a little less clever here, we need to specify the interface, or direction, that the route affects.

Allowing SSH access to Cisco ASA

Now, let's set ourselves up to manage the ASA from our User1 "PC". Firstly we need to generate our general-keys, using the command "crypto key generate rsa modulus 1024", ideally (in production), you should use 2048:

Notice that I also set the domain name, and the version.

The rest of the commands are being shown through show commands, once I have successfully connected from User1:

User1#ssh -l stu 192.168.1.254
Password: 
Type help or '?' for a list of available commands.
ASAv> en
Password: ******
ASAv# sh run | i username
username stu password QFwZO2R.a0n6RaA/ encrypted privilege 15
ASAv# sh run | i aaa
aaa authentication ssh console LOCAL 
aaa authentication enable console LOCAL 
ASAv# sh run | i ssh
aaa authentication ssh console LOCAL 
ssh stricthostkeycheck
ssh 192.168.1.0 255.255.255.0 Inside
ssh timeout 5
ssh version 2
ssh key-exchange group dh-group1-sha1
ASAv# sh run | i management
 management-only
management-access Inside
ASAv#

We will need a user to connect with. Notice the the password gets automatically encrypted. We have two AAA commands, one for SSH access, another for enable level access. We also enable ssh access from the 192.168.1.0/24 subnet, and have allowed management access from anything behind the Inside interface.

Now we can work a little easier. The final step it to get the User1 PC to access the 8.8.8.8 server out on the Internet. To do this the ASA needs to perform a bit of Network Address Translation (NAT).

Internet access for inside hosts on a Cisco ASA

Let's give access for our inside hosts. To do this does not take many steps, we just need to create a network to match everything, and then NAT this:

ASAv(config)# object network OBJ_OUTSIDE
ASAv(config-network-object)# subnet 0.0.0.0 0.0.0.0
ASAv(config-network-object)# exi
ASAv(config)# nat (Inside,Outside) source dynamic OBJ_OUTSIDE interface
ASAv(config)# 

Although ping does not work, telnet does:

ASAv(config)# exi
ASAv# exi
[Connection to 192.168.1.254 closed by foreign host]
User1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
User1#telnet 8.8.8.8
Trying 8.8.8.8 ... Open


Password required, but none set

[Connection to 8.8.8.8 closed by foreign host]
User1#

We can prove that this works, by setting a password on the ISP router:

ISP(config)#line vty 0 4
ISP(config-line)#password 802101
ISP(config-line)#exi
ISP(config)#enable password 802101
ISP(config)#

User1#telnet 8.8.8.8
Trying 8.8.8.8 ... Open


User Access Verification

Password: 
ISP>en
Password: 
ISP#who
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:00:24   
*  2 vty 0                idle                 00:00:00 10.1.1.2

  Interface    User               Mode         Idle     Peer Address

ISP#

So, you can see that the ASAv has performed NAT for User1. We can check this on the ASAv:

So, telnet worked fine, what about http requests? Well, the ASAv will perform NAT (well, PAT to be precise) for us. We can see this by setting up the ISP router to be an HTTP server:

ISP(config)#ip http server
ISP(config)#

User1#telnet 8.8.8.8 80
Trying 8.8.8.8, 80 ... Open
get
HTTP/1.1 400 Bad Request
Date: Sat, 05 Sep 2015 14:28:30 GMT
Server: cisco-IOS
Accept-Ranges: none

400 Bad Request
[Connection to 8.8.8.8 closed by foreign host]
User1#

As you can see, it does not take long to get up and running with an ASA. Now that we have had our little introduction to ASAs, I can start configuring them up in my lab (in a day or two).

How to NAT private IP address within a VPN

Continuing from the little lab I built up in the last post, where I looked at how to get Windows 7 running natively in UNetLab, I now am looking at how we can perform NAT inside of an IPSec tunnel.

I am using the following for this:

2x Windows 7 (Pro), with VLC, Putty, JRE and ASDM installed
2x IOSv Layer 2 switches (running 15.2)
2x ASAv (running 9.4(1))
1x IOSv (running 15.5) - AKA "Internet".

All of these are within UNetLab, which is, so far, coping nicely with just the 8GB ram that Fusion seems to allow, but I really should put it on my ESXi server. I have seen ways to get around the 8GB limit, but every time I try, Fusion says its unsupported, and drops it down to 32Kb. It's a challenge.

The topology looks like this (note not everything is started just yet):

The end goal is that we have a VPN between the two ASAs, with HQ performing NAT to mask the traffic inside the VPN tunnel. You may be asking "Why the hell would you ever need to do that?", and it's a very good question, really it's not something you'd have to do often, but there are those times when someone doesn't like RFC1918 addresses going across a VPN tunnel, or (more commonly) you need to VPN to another site that has overlapping internal subnets.

Basic IP addressing (all /24):

Interface	IP Address
DMZ-Server	10.1.1.10 (default gateway 10.1.1.254)
HQ Gi0/3	10.1.1.1
HQ Gi0/1	1.1.1.2
Internet Gi0/0	1.1.1.1
Internet Gi0/1	2.2.2.1
Client Gi0/1	2.2.2.2
Client Gi0/3	10.200.1.1
Client-PC	10.200.1.10 (default gateway 10.200.1.254)

HQ Switch configuration

Very basic, just one vlan, and a VIF:

Switch#sh vlan | i VLAN0011
11   VLAN0011                         active    Gi0/0, Gi0/1, Gi0/2, Gi0/3
Switch#sh ip int bri | e unas
Interface              IP-Address      OK? Method Status                Protocol
Vlan11                 10.1.1.254      YES manual up                    up      

Switch#

Basic (HQ) ASA setup.

Below is enough to get us started, and onto ASDM from our DMZ-Server:

hostname HQ
!
interface GigabitEthernet0/1
 nameif Outside
 security-level 0
 ip address 1.1.1.2 255.255.255.0 
!
interface GigabitEthernet0/3
 nameif DMZ
 security-level 50
 ip address 10.1.1.1 255.255.255.0 
!
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
!
route Outside 0.0.0.0 0.0.0.0 1.1.1.1 1
!
user-identity default-domain LOCAL
aaa authentication enable console LOCAL 
aaa authentication http console LOCAL 
aaa authentication ssh console LOCAL 
http server enable
http 10.1.1.0 255.255.255.0 DMZ
!
ssh 1.1.1.1 255.255.255.255 Outside
ssh 10.1.1.0 255.255.255.0 DMZ
ssh timeout 5
ssh version 2
ssh key-exchange group dh-group1-sha1
!
username stuart password p60UDLdMNnbR8IQ. encrypted
!

The set-up for the Client ASA is not much different, and similarly, on the Client switch we have one VLAN (200), and a VIF of 10.200.1.254:

Switch#sh vlan | i VLAN0200  
200  VLAN0200                         active    Gi0/0, Gi0/1, Gi0/2, Gi0/3
Switch#sh ip int bri | e unas
Interface              IP-Address      OK? Method Status                Protocol
Vlan200                10.200.1.254    YES manual up                    up      

Switch#

So far we should be able to ping from our Windows PCs to our ASAs:

Basic Internet access (our first NAT).

On the Internet router, we have a loopback interface with the IP address 8.8.8.8/32. We should be able to give ourselves access to this. It's working directly from the HQ ASA at the moment:

HQ# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/10/10 ms
HQ# 

The first NAT rule "connects" the DMZ interface to the Outside interface:

HQ(config)# nat (DMZ,Outside) after-auto source dynamic any interface 
HQ(config)# 

If we follow it through, we can see that the rule will be placed last in the NAT rules table (after-auto). We match the DMZ and the Outside interfaces (our source network and the one we want to get to). We set a source of dynamic, meaning we can have more than one host behind this network, and we allow any source using the "any" keyword. Lastly we nat this through to the interface IP address given to our Outside interface.

I did have to use the command "fixup protocol icmp" in order to get the ping to work. The ASA will convert this into the following command:

HQ(config)# policy-map global_policy
HQ(config-pmap)# class inspection_default
HQ(config-pmap-c)# inspect icmp
HQ(config-pmap-c)# 

So now we also have "Internet" access (to a loopback on the Internet router):

Let's go ahead and set up the other side, and make sure that they can also ping the "Internet":

Client# ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/14/30 ms
Client#conf t
Client(config)# policy-map global_policy
Client(config-pmap)# class  inspection_default
Client(config-pmap-c)# inspect icmp
Client(config-pmap-c)# exit
Client(config-pmap)#exit
Client(config)# nat (Inside,Outside) source  dynamic any interf
Client(config)# 

Great! Now the client should have access:

Now we can begin to create our VPN between the two sides.

Site-to-Site (L2L) IPSec VPN on Cisco ASAs

We start with a couple of network objects, and an access-list:

Client(config)# object network MyInsideNetwork
Client(config-network-object)# subnet 10.200.1.0 255.255.255.0
Client(config-network-object)# exit
Client(config)# object network TheirRemoteNetwork
Client(config-network-object)# subnet 10.1.1.0 255.255.255.0
Client(config-network-object)# exit
Client(config)# access-list Outside_cryptomap extended permit ip object MyInsideNetwork object TheirRemoteNetwork

Now we can start to define how we are going to talk to other peers:

Client(config)# nat (Inside,Outside) source static MyInsideNetwork MyInsideNetwork destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
Client(config)#crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
Client(config)# crypto ipsec ikev2 ipsec-proposal AES256
Client(config-ipsec-proposal)# protocol esp encryption aes-256
Client(config-ipsec-proposal)# protocol esp integrity sha-1 md5
Client(config-ipsec-proposal)# exi
Client(config)# crypto ikev2 policy 1 
Client(config-ikev2-policy)# encryption aes-256
Client(config-ikev2-policy)# integrity sha
Client(config-ikev2-policy)# group 2
Client(config-ikev2-policy)# prf sha
Client(config-ikev2-policy)# lifetime seconds 86400
Client(config-ikev2-policy)# exi
Client(config)# crypto ikev1 policy 10
Client(config-ikev1-policy)# authentication pre-share 
Client(config-ikev1-policy)# encryption aes-256 
Client(config-ikev1-policy)# hash sha
Client(config-ikev1-policy)# group 2
Client(config-ikev1-policy)# lifetime 86400
Client(config-ikev1-policy)# exi
Client(config)# crypto ikev2 enable Outside
Client(config)# crypto ikev1 enable Outside
Client(config)# 

Then we create the VPN, trying to keep it as generic as possible so that it is nice and easy to paste onto our other ASA:

Client(config)# crypto map Outside_map 1 match address Outside_cryptomap
Client(config)# crypto map Outside_map 1 set peer 1.1.1.2               
Client(config)# crypto map Outside_map 1 set ikev1 transform-set ESP-AES-128-SHA
Client(config)# crypto map Outside_map 1 set ikev2 ipsec-proposal AES256
Client(config)# crypto map Outside_map interface Outside               
Client(config)# group-policy MyPeer internal             
Client(config)# group-policy MyPeer attributes 
Client(config-group-policy)# vpn-tunnel-protocol ikev1 ikev2
Client(config-group-policy)# tunnel-group 1.1.1.2 type ipsec-l2l   
Client(config)# tunnel-group 1.1.1.2 general-attributes 
Client(config-tunnel-general)# default-group-policy MyPeer
Client(config-tunnel-general)# exi
Client(config)# tunnel-group 1.1.1.2 ipsec-attributes 
Client(config-tunnel-ipsec)# ikev1 pre-shared-key MyKey
Client(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key MyKey
INFO: You must configure ikev2 local-authentication pre-shared-key
      or certificate to complete authentication.
Client(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key MyKey
Client(config-tunnel-ipsec)# 

Moving on to the other (HQ) ASA, we can (with a minor edit here and there) paste in the same config:

HQ(config)# object network MyInsideNetwork
HQ(config-network-object)# subnet 10.1.1.0 255.255.255.0
HQ(config-network-object)# exit
HQ(config)# object network TheirRemoteNetwork
HQ(config-network-object)# subnet 10.200.1.0 255.255.255.0
HQ(config-network-object)# exit
HQ(config)# access-list Outside_cryptomap extended permit ip object MyInsideNetwork object TheirRemoteNetwork
HQ(config)# nat (Inside,Outside) source static MyInsideNetwork MyInsideNetwork destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
HQ(config)# crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
HQ(config)# crypto ipsec ikev2 ipsec-proposal AES256
HQ(config-ipsec-proposal)# protocol esp encryption aes-256
HQ(config-ipsec-proposal)# protocol esp integrity sha-1 md5
HQ(config-ipsec-proposal)# exi
HQ(config)# crypto ikev2 policy 1 
HQ(config-ikev2-policy)# encryption aes-256
HQ(config-ikev2-policy)# integrity sha
HQ(config-ikev2-policy)# group 2
HQ(config-ikev2-policy)# prf sha
HQ(config-ikev2-policy)#  lifetime seconds 86400
HQ(config-ikev2-policy)# exi
HQ(config)# crypto ikev1 policy 10
HQ(config-ikev1-policy)# authentication pre-share 
HQ(config-ikev1-policy)# encryption aes-256 
HQ(config-ikev1-policy)# hash sha
HQ(config-ikev1-policy)# group 2
HQ(config-ikev1-policy)# lifetime 86400
HQ(config-ikev1-policy)# exi
HQ(config)# crypto ikev2 enable Outside
HQ(config)# crypto ikev1 enable Outside
HQ(config)# crypto map Outside_map 1 match address Outside_cryptomap
HQ(config)# crypto map Outside_map 1 set peer 2.2.2.2               
HQ(config)# crypto map Outside_map 1 set ikev1 transform-set ESP-AES-128-SHA
HQ(config)# crypto map Outside_map 1 set ikev2 ipsec-proposal AES256
HQ(config)# crypto map Outside_map interface Outside               
HQ(config)# group-policy MyPeer internal             
HQ(config)# group-policy MyPeer attributes 
HQ(config-group-policy)# vpn-tunnel-protocol ikev1 ikev2
HQ(config-group-policy)# tunnel-group 2.2.2.2 type ipsec-l2l   
HQ(config)# tunnel-group 2.2.2.2 general-attributes 
HQ(config-tunnel-general)# default-group-policy MyPeer
HQ(config-tunnel-general)# exi
HQ(config)# tunnel-group 2.2.2.2 ipsec-attributes 
HQ(config-tunnel-ipsec)#  ikev1 pre-shared-key MyKey
HQ(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key MyKey
INFO: You must configure ikev2 local-authentication pre-shared-key
      or certificate to complete authentication.
HQ(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key MyKey
HQ(config-tunnel-ipsec)# 

And boom! We have a working VPN:

Traffic works the other way as well.

OK, so now that we have a working VPN, let's see if we can NAT on the HQ side.

NAT and Site-to-Site VPNs

In order that we can hide our 10.1.1.0/24 network behind a new network (192.168.1.0/24), we need to add another network object to HQ, add a NAT rule, an access-list, and finally edit our crypto map to reference the access-list:

HQ(config)# object network YouSeeMeAs
HQ(config-network-object)# subnet 192.168.1.0 255.255.255.0
HQ(config-network-object)# exi
HQ(config)#nat (DMZ,Outside) source static MyInsideNetwork YouSeeMeAs destination static TheirRemoteNetwork TheirRemoteNetwork
HQ(config)#access-list Hidden_CryptoMap extended permit ip object YouSeeMeAs object TheirRemoteNetwork
HQ(config)#crypto map Outside_map 1 match address Hidden_CryptoMap

Now we need to change the other side to look towards the 192.168.1.0 traffic (instead of the 10.1.1.0/24 network):

Once we send some traffic between the two sites, our VPN should get established.

Quite nicely, it's preserving (or reserving) the final octet for us. However, we are now only good for being called into. Our pings from HQ to the Client fail:

OK, so how do we get both sides working, instead of this one-way traffic that we have? Well, let's try and work out what's happening.

HQ# sh nat detail 
Manual NAT Policies (Section 1)
1 (DMZ) to (Outside) source static MyInsideNetwork MyInsideNetwork   destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
    translate_hits = 32, untranslate_hits = 32
    Source - Origin: 10.1.1.0/24, Translated: 10.1.1.0/24
    Destination - Origin: 10.200.1.0/24, Translated: 10.200.1.0/24
2 (DMZ) to (Outside) source static MyInsideNetwork YouSeeMeAs   destination static TheirRemoteNetwork TheirRemoteNetwork
    translate_hits = 7, untranslate_hits = 7
    Source - Origin: 10.1.1.0/24, Translated: 192.168.1.0/24
    Destination - Origin: 10.200.1.0/24, Translated: 10.200.1.0/24

Manual NAT Policies (Section 3)
1 (DMZ) to (Outside) source dynamic any interface  
    translate_hits = 66, untranslate_hits = 59
    Source - Origin: 0.0.0.0/0, Translated: 1.1.1.2/24
HQ# 

This is our NAT table. And here is a very long packet-tracer output:

HQ# packet-tracer input DMZ icmp 10.1.1.10 1 7 10.200.1.10 detailed 

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 1.1.1.1 using egress ifc  Outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork MyInsideNetwork destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface Outside
Untranslate 10.200.1.10/0 to 10.200.1.10/0

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group DMZ_access_in in interface DMZ
access-list DMZ_access_in extended permit object-group DM_INLINE_SERVICE_1 any any 
object-group service DM_INLINE_SERVICE_1
 service-object ip 
 service-object icmp 
 service-object icmp echo
 service-object icmp echo-reply
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcd5403e0, priority=13, domain=permit, deny=false
        hits=48, user_data=0x7fffd8e59d00, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=any

Phase: 4
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork MyInsideNetwork destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
Additional Information:
Static translate 10.1.1.10/0 to 10.1.1.10/0
 Forward Flow based lookup yields rule:
 in  id=0x7fffce1821f0, priority=6, domain=nat, deny=false
        hits=29, user_data=0x7fffce14e060, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=10.1.1.0, mask=255.255.255.0, port=0, tag=any
        dst ip/id=10.200.1.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=Outside

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcd2d74f0, priority=0, domain=nat-per-session, deny=true
        hits=270, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype: 
Result: ALLOW 
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcdabbd30, priority=0, domain=inspect-ip-options, deny=true
        hits=522, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=any

Phase: 7
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcd9ecd50, priority=70, domain=qos-per-class, deny=false
        hits=191, user_data=0x7fffcd9eca20, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=any, output_ifc=any

Phase: 8      
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect icmp 
service-policy global_policy global
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcda4d390, priority=70, domain=inspect-icmp, deny=false
        hits=44, user_data=0x7fffce13f110, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
        src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=any

Phase: 9
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:       
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffcdabb5e0, priority=66, domain=inspect-icmp-error, deny=false
        hits=128, user_data=0x7fffcdabab40, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
        src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=any

Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork MyInsideNetwork destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7fffce182df0, priority=6, domain=nat-reverse, deny=false
        hits=29, user_data=0x7fffce14e160, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=10.1.1.0, mask=255.255.255.0, port=0, tag=any
        dst ip/id=10.200.1.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
        input_ifc=DMZ, output_ifc=Outside

Phase: 11     
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 376, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_inspect_icmp
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow

HQ# 

In Phase 1 we find out egress interface.  We only have one, so it's no surprise. In Phase 2 we hit our first NAT rule - out 10.1.1.0/24 to their 10.200.1.0/24.

In Phase 3 we check (and pass) out ACLs, and in Phase 4 we perform NAT, again we hit the first NAT rule, translating our 10.1.1.10/24 client address to itself.

In Phases 5, 6 and 7 we perform per-session NAT, check the IP-Options and any QoS - all of these pass.

Phases 8 and 9 are np-inspects, these pass.

Phase 10 is a RPF (Reverse Path Forwarding) check, and this passed, so then its on to the final flow-creation.

So all looks good there, we don't see any failures. However, we can see that the ACL we are hitting is the original one - before we implemented NAT within our VPN tunnel. Therefore the Client ASA will be seeing traffic come over the VPN with an incorrect endpoint address. So lets just pop over to ASDM (because it's much easier) and try moving the order of our NAT statements around.

Before:

After:

Now (thankfully), our DMZ-Client PC can access the Guest-PC:

As a final note, let's have a look at the packet tracer again and see the difference (I have truncated the output this time to make it a bit easier):

HQ# sh nat detail                                                   
Manual NAT Policies (Section 1)
1 (DMZ) to (Outside) source static MyInsideNetwork YouSeeMeAs   destination static TheirRemoteNetwork TheirRemoteNetwork
    translate_hits = 15, untranslate_hits = 15
    Source - Origin: 10.1.1.0/24, Translated: 192.168.1.0/24
    Destination - Origin: 10.200.1.0/24, Translated: 10.200.1.0/24
2 (DMZ) to (Outside) source static MyInsideNetwork MyInsideNetwork   destination static TheirRemoteNetwork TheirRemoteNetwork no-proxy-arp route-lookup
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.0/24, Translated: 10.1.1.0/24
    Destination - Origin: 10.200.1.0/24, Translated: 10.200.1.0/24

Manual NAT Policies (Section 3)
1 (DMZ) to (Outside) source dynamic any interface  
    translate_hits = 66, untranslate_hits = 59
    Source - Origin: 0.0.0.0/0, Translated: 1.1.1.2/24
HQ# packet-tracer input DMZ icmp 10.1.1.10 1 7 10.200.1.10 detailed 

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork YouSeeMeAs destination static TheirRemoteNetwork TheirRemoteNetwork
Additional Information:
NAT divert to egress interface Outside
Untranslate 10.200.1.10/0 to 10.200.1.10/0

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group DMZ_access_in in interface DMZ
access-list DMZ_access_in extended permit object-group DM_INLINE_SERVICE_1 any any 
object-group service DM_INLINE_SERVICE_1
 service-object ip 
 service-object icmp 
 service-object icmp echo
 service-object icmp echo-reply

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork YouSeeMeAs destination static TheirRemoteNetwork TheirRemoteNetwork
Additional Information:
Static translate 10.1.1.10/0 to 192.168.1.10/0

Phase: 4
Type: NAT     
Subtype: per-session
Result: ALLOW

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW

Phase: 6
Type: QOS
Subtype: 
Result: ALLOW

Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW

Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
              
Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW

Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DMZ,Outside) source static MyInsideNetwork YouSeeMeAs destination static TheirRemoteNetwork TheirRemoteNetwork

Phase: 11
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 392, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_inspect_icmp
snp_fp_translate
snp_fp_adjacency
snp_fp_encrypt
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
              
Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow

HQ# 

So, here we can see that the order of NAT is extremely important.

Hope you have enjoyed the post!