Destination NAT (Outside NAT) on Cisco and xlate flags

The task was extremely simple. The packet with: SRC: 10.111.0.0/24, DST: 192.168.252.10, needs to be translated to: SRC: 10.111.0.0/24, DST: 10.100.252.10. Having extensive amount of all kinds of NAT done on Checkpoint (you can do that with 3 clicks on Checkpoint), I thought this will be piece of cake. It took me 4-6 hours, going through many Cisco FWSM examples and I had to write to IPexpert CCIE Security mailing list for help.

I started to look for a way to use static (outside, inside) I as thought the first interface is the interface which will hit the packet. It turn out that I'm totally wrong, and it doesn't matter the order in the static statement as long the first statement match the real interface and the second interface match the mapped interface.

At the end the config was:

static (inside,outside) 192.168.252.10 10.100.252.10

We can use: show xlate debug to verify the NAT:

NAT from inside:10.100.252.10 to outside:192.168.252.10 flags si idle 0:00:33 timeout 0:01:00 connections 0

Note the "si" flag above. The list of all flags:

Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
       o - outside, r - portmap, s - static

For explanation for each flag, check the table named: Translation Flags in the command refference for the version of the FWSM/ASA.

Also few days ago, Cisco announced that they will do changes also on NAT in ASA version 8.3.

NAT on FWSM and not good syslog message

Syslog is absolutely my best friend in troubleshooting Cisco firewalls. Today, I got surprised by getting so "usual" message for such unpredictable issue. I hope Cisco can add new syslog message for this issue. I've checked version 4.1 documentation of syslog messages, and I wasn't able to find syslog message when traffic is dropped due to passing between interfaces with same security levels.

Today I was doing some NAT setup on FWSM 3.1. I wasn't sure that the config will work as there is no example on configuration guide for 2 nat statements with same number on same interface with different source addresses. However there was an example of this in the config guide for version 4.0 (Figure 15-15), so I wanted to try it if it will work. The configuration is below:

nat (if1) 1 192.168.16.0 255.255.240.0
nat (if1) 1 192.168.32.0 255.255.224.0
nat (if1) 1 192.168.64.0 255.255.192.0
nat (if1) 1 10.101.0.0 255.255.0.0
nat (if1) 1 10.114.0.0 255.255.0.0
nat (if1) 1 10.128.0.0 255.128.0.0
nat (if2) 1 10.216.0.0 255.255.0.0
nat (if3) 1 10.100.0.0 255.255.0.0
global (if4) 1 8.8.8.8

Everything worked as expected except the connections from if2. Looking at the log I got this message:

Mar  2 16:07:12 10.100.255.20 %FWSM-3-106011: Deny inbound (No xlate) tcp src if2:10.216.20.1/37377 dst if4

I've checked the access-list, and the hitcounts were there, so next step in the traffic flow is matching of xlate table. I've removed the specific nat statement, re-tried and same message. I've added it again and re-tried, and again the same message. It took some time until I got the idea to check the security levels on the interfaces, and I got this:

FWSM/context#show nameif
Interface                Name                     Security
ethernet2                if1                       25
ethernet4                if2                       20
ethernet3                if4                       20
ethernet1                if3                      100
ethernet5                if5                       20

After permitting traffic on same security levels interface, I got the connection:

FWSM/context# show runn same-security-traffic
same-security-traffic permit inter-interface

FWSM/context# show xlate debug | grep 10.216.20.1
TCP PAT from if2:10.216.20.1/34305 to if4:8.8.8.8/1039 flags ri idle 0:00:20 timeout 0:00:30 connections 1

FWSM/context# show conn detail | grep 10.216.20.1
TCP out 10.111.0.1:23 in 10.216.20.1:54785 idle 0:00:02 Bytes 64 FLAGS -

nat-control

There are times when you think that access-list have some problems, and then you'll find out that the hitcounts are increasing. You're almost sure that the traffic is passing, but you cant find connection in the connection table? You've checked syslog and you've found one of those beautiful syslog messages:

%ASA-3-305005: No translation group found for tcp src inside:10.1.1.9/11039 dst outside:198.133.219.25/80

%ASA-3-305006: regular translation creation failed for tcp src inside:10.1.1.9/11040 dst outside:198.133.219.25/80

%FWSM-3-305005: No translation group found for tcp src inside:10.1.1.9/11039 dst outside:198.133.219.25/80

%FWSM-3-305006: regular translation creation failed for tcp src inside:10.1.1.9/11040 dst outside:198.133.219.25/80

We'll most probably you have nat-control enabled. You can verify it using the following command:

FWSM/CONTEXT# show runn nat-control
nat-control

Well, what is nat-control then? Nat-control is feature on Cisco firewalls to maximise the security. When it is enabled, each packet MUST match a NAT rule in order to pass the firewall. It is important to keep in mind that even packets initiated from HIGHER security level interface (inside) MUST match a NAT rule in order for the packet to be processed to lower security interface (outside). Nat-control is disabled by default.

Summary of all PUBLIC IP addresses

Recently we had to allow all public IP addresses through Cisco FWSM. I was googling for the list, but I wasn't able to find it. It took me approximately 2 hours to have that list compiled, and I decided to share it. Hopefully someone out there will find it useful. Here is the list. Feel free  to copy paste it.

network-object 1.0.0.0 255.0.0.0
network-object 2.0.0.0 254.0.0.0
network-object 4.0.0.0 252.0.0.0
network-object 8.0.0.0 254.0.0.0
network-object 11.0.0.0 255.0.0.0
network-object 12.0.0.0 252.0.0.0
network-object 16.0.0.0 240.0.0.0
network-object 32.0.0.0 224.0.0.0
network-object 64.0.0.0 192.0.0.0
network-object 128.0.0.0 224.0.0.0
network-object 160.0.0.0 248.0.0.0
network-object 168.0.0.0 252.0.0.0
network-object 172.0.0.0 255.240.0.0
network-object 172.32.0.0 255.224.0.0
network-object 172.64.0.0 255.192.0.0
network-object 172.128.0.0 255.128.0.0
network-object 173.0.0.0 255.0.0.0
network-object 174.0.0.0 254.0.0.0
network-object 176.0.0.0 240.0.0.0
network-object 192.0.0.0 255.128.0.0
network-object 192.128.0.0 255.224.0.0
network-object 192.160.0.0 255.248.0.0
network-object 192.169.0.0 255.255.0.0
network-object 192.170.0.0 255.254.0.0
network-object 192.172.0.0 255.252.0.0
network-object 192.176.0.0 255.240.0.0
network-object 192.192.0.0 255.192.0.0
network-object 193.0.0.0 255.0.0.0
network-object 194.0.0.0 254.0.0.0
network-object 196.0.0.0 252.0.0.0
network-object 200.0.0.0 248.0.0.0
network-object 208.0.0.0 240.0.0.0

Note: Excluded ranges from the list are: 0.0.0.0/8,  10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3. If you decide to include 0.0.0.0/8 on the list you'll save 2 lines by summarizing: 0.0.0.0/5.

Maybe for your needs you need to reconsider bogons (http://www.cymru.com/Documents/bogon-bn-agg.txt), but then this list will become much bigger.