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.

CCSP ASA exams

2 months ago I got my CCSP, the last 2 exams were the ASA ones. Materials that I've used:

1. Cisco Firewall Mentor Video lessons by David Hucaby
2. Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance, by Jazib Frahim
3. CCSP SNAF Quick Reference, by Andrew Mason
4. CCSP SNAA Quick Reference, by Ryan Lindfield
5. CCIE Professional Development Series Network Security Technologies and Solutions, by Yusuf Bhaiji
6. Demo Version of ASDM version 6.0.3 - There are several scenarios and different setups. It is a demo but it helped me to be more oriented with the ASDM. In SNAF there a many ASDM questions.

Good Luck on the exams!