Advance types of NAT

In a previous post (NAT order of operation on Cisco ASA firewall) we took a look how many NAT configuration types Cisco ASA supports and what the differences are. In  advance (firewall) configuration there can be other types of address and port translation that may obey more or less restrictive rules. Examples and a short listing of them can be found bellow (a full description can be found in reference section):

• Symmetric NAT

Standard, very restrictive. Only the original source and destination hosts can communicate together.

• Full-cone NAT

Any external host can use the NAT binding (the entry from the connection table about the NAT) and communicate with the internal server. Neither external IP or external port are checked when processing TCP/UDP packets.

• Restricted-cone NAT 

Only the single remote host can use the NAT binding. The port is irrelevant.

• Port-restricted-cone NAT

Upside down to the "Restricted-clone NAT". Every host can reuse the NAT binding as long as it is using the original destination port number that was used when the NAT binding was 

created and stored in the NAT table in the FW memory. Take a look at the "X" and "V" paths at the illustration bellow:

Despite a good theoretical explanation that you can find on Cisco I wasn't able to find a working example for ASA. Found only some spare documents for the wireless routes in the context of SIP protocol. Does ASA supports these NAT types?

References

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html
https://supportforums.cisco.com/thread/2178132

NAT order of operation on Cisco ASA firewall

There are many types of NAT you can configure on the ASA FW. This is a short summary with examples for ASA 8.2/8.3 software.

• Dynamic NAT

! The pool-number parameter ( 2, in this case) binds the 'global' and 'nat' commands
nat (dmz) 2 10.10.10.128 255.255.255.128
global (out) 2 172.16.16.129-172.16.16.254 netmask 255.255.255.128

• Dynamic PAT

! Configuring PAT using the global address 172.16.16.126
ASA2(config)# nat (dmz) 1 10.10.10.0 255.255.255.0
ASA2(config)# global (out) 1 172.16.16.126

• Identity NAT

! Configuring Identity NAT
ASA2(config)# nat (dmz) 0 10.10.10.128 255.255.255.192

• Static NAT

! Static translation for an individual host (/32 is the default netmask)
ASA2(config)# static (dmz,out) 172.16.16.140 10.10.10.140

• Static Policy NAT

ASA2(config)# access-list STATIC-POLICY1 extended permit ip host 10.10.10.148 host 172.16.16.200
ASA2(config)# static (dmz,out) 172.18.18.148 access-list STATIC-POLICY1

! For other destinations source address 10.10.10.148 is translated to 172.16.16.148
ASA2(config)# static (dmz,out) 172.16.16.148 10.10.10.148 netmask 255.255.255.255

• Dynamic Policy NAT

! Packets from 10.10.10.128/27 travelling to host 172.16.16.200 undergo Policy NAT
access-list DYN-POLICY1 extended permit ip 10.10.10.128 255.255.255.224 host 172.16.16.200
!
nat (dmz) 4 access-list DYN-POLICY1
global (out) 4 172.17.17.129-172.17.17.158 netmask 255.255.255.224
!

• Dynamic Policy PAT

! Policy PAT for source subnet 10.10.10.128/26 going to host 172.16.16.200
access-list DYN-POLICY2 extended permit ip 10.10.10.128 255.255.255.192 host 172.16.16.200
!
ASA2(config)# nat (dmz) 3 access-list DYN-POLICY2
ASA2(config)# global (out) 3 172.16.16.125

• NAT Exemption

! Connections between 10.10.10.128/28 and 172.16.16.0/24 are exempted from NAT
access-list NONAT extended permit ip 10.10.10.128 255.255.255.240 172.16.16.0 255.255.255.0
!
nat (dmz) 0 access-list NONAT

Problem

In what order and precedence is ASA firewall processing various NAT configurations.

NAT precedence rules 

Step 1.
NAT Exemption: This is always the first to be checked and has precedence over any other type of NAT rule that eventually conflicts with it.

Step 2.
Static Policy NAT: The motivation for this type of rule is to allow the selection of distinct global addresses for a given laddr, depending on the destination address (faddr) being contacted. This can be thought of as an exception to a generic static statement and, as such, needs to be configured before regular statics.

Step 3.
Static NAT: This is checked before all the Dynamic, Dynamic Policy, and Identity NAT rules. If some hosts that fall within a NAT Exemption range require static translation, the pertinent exceptions in the nat 0 access-list command need to be created, as previously illustrated in Example 8-14.

Step 4.
Dynamic Policy NAT/PAT: These rules are checked before the Dynamic and Identity NAT rules. If two rules of this category exist, the precedence is given by the order in which they were configured (does not matter if is a Policy PAT or Policy NAT).

Step 5.
Identity NAT: This unidirectional translation bypass method is evaluated before any Dynamic NAT or Dynamic PAT rule.

Step 6.
Dynamic NAT: This category has precedence over Dynamic PAT only.

Step 7.
Dynamic PAT: If after running through all the previous NAT types, ASA does not find a match, it still searches for a Dynamic PAT. If no matching rule is located, the implicit deny rule that characterizes the NAT-control model is enforced.

References

• Cisco Firewalls By: Alexandre M.S.P Moraes, chapter "Outbound NAT Analysis" 
• http://blog.ciscoinferno.net/you-me-and-nat-8-3
• Network Address Translation (NAT) order of operation in the PIX Firewall
• Packet Flow through Cisco ASA Firewall
• Order of NAT Commands Used to Match Real Addresses

How to find the public IP address for my rackconnected cloud server

Every cloud server that belongs to a cloud account that was linked with Rackconnect is going to have a static NAT created on the external network device like ASA firewall or F5 loadbalancer. At the moment there is a problem that there is not an easy way to find out what this IP actually is.

When you first create a cloud server it will have assigned an IP from the cloud public IP address pool. You can find it the example output below.

$ cloudservers --username user --apikey  key  boot rctest --flavor 1 --image 112
+-----------+------------------------------------------------------------------+
|  Property |                              Value                               |
+-----------+------------------------------------------------------------------+
| addresses | {u'public': [u'31.222.163.128'], u'private': [u'10.177.69.211']} |
| adminPass |                         rrrrrrrrrrrr                          |
|  flavorId |                                1                                 |
|   hostId  |                 0652da292b44004e3aa76dc80bd912d5                 |
|     id    |                             10209889                             |
|  imageId  |                               112                                |
|  metadata |                                {}                                |
|    name   |                              rctest                              |
|  progress |                                0                                 |
|   status  |                              BUILD                               |
+-----------+------------------------------------------------------------------+

The initial IP of 31.222.163.128 is going to be changed as soon as all  RackConnect task will be run again this cloud server. A next problem is that all subsequent API calls still may return the original IP address instead of the new one assigned by the RackConnect system.

$ cloudservers --username user  --apikey  key show 10209889
+------------+----------------------------------+
|  Property  |              Value               |
+------------+----------------------------------+
|   flavor   |            256 server            |
|   hostId   | 0652da292b44004e3aa76dc80bd912d5 |
|     id     |             10209889             |
|   image    |         Ubuntu 10.04 LTS         |
|  metadata  |                {}                |
|    name    |              rctest              |
| private ip |          10.177.69.211           |
|  progress  |                0                 |
| public ip  |          31.222.163.128          |
|   status   |              BUILD               |
+------------+----------------------------------+

Problem

How do I find the external IP address that Rackconnect assigns to my cloud server.

Solution

Once the cloud server is built you can open a browser from the cloud server (may by a bit of a problem) and try to google for: what's my IP.

Alternatively you can have a bastion server that you know how to login over SSH and from there try run run over internal IP address of your new cloud server his command:

mybastion$ ssh root@10.177.69.211 "curl  http://icanhazip.com"
11.138.183.11