FWSM unable to build translation slot

[jgtheodor]

Hi I have a 6509-E chassis with a FWSM [FWSM Firewall Version 3.2(5) and I have enabled NAT control. In configuration file there are the following commands:

nat (inside) 1 10.10.0.0 255.255.0.0 tcp 0 300

nat (inside) 5 10.10.10.5 255.255.255.255 tcp 0 300

global (dmz1) 1 192.168.4.10

global (dmz2) 5 192.168.6.10

Whenever a host from 10.10.0.0 inside network tries to pass in dmz1 interface, FWSM is building a translation slot based on global (dmz1) entry. Whenever the host 10.10.10.5 from inside network tries to pass in dmz2 interface, FWSM is building a translation slot based on global (dmz2) entry.

However when the same host 10.10.10.5 tries to pass in dmz1 interface, FWSM is not building a translation slot based on global (dmz1) entry and produce the following log message:

Mar 02 11:14:03 172.16.14.2 %FWSM-3-305006: regular translation creation failed for tcp src inside:10.10.10.5/28742 dst dmz1:192.168.4.100/80

Am I missing something, or this behavior is normal? When I configure a second entry for this host : global (dmz1) 5 192.168.4.11 the traffic pass through without any problem. Can someone tell me if this behavior is normal, because I think that in PIX or ASA this phenomenon does not happen.

Thanks in advance!!!

[Federico Coto Fajardo]

There's a caveat:

1. %FWSM-3-305006: Regular translation creation failed for protocol src interface_name:source_address/source_port dst interface_name:dest_address/dest_port

A protocol (UDP, TCP, or ICMP) failed to create a translation through the module. This message appears as a fix to caveat CSCdr0063 that requested that the module not allow packets that are destined for network or broadcast addresses. The module provides this checking for addresses that are explicitly identified with static command statements. With the change, for inbound traffic, the module denies translations for a destined IP address identified as a network or broadcast address. The module utilizes the global IP and mask from configured static command statements to differ regular IP addresses from network or broadcast IP addresses. If the global IP address is a valid network address with a matching network mask, then the module does not create a translation for network or broadcast IP addresses with inbound packets. For example: static (inside,outside) 10.2.2.128 10.1.1.128 netmask 255.255.255.128. Global address 10.2.2.128 is responded to as a network address and 10.2.2.255 is responded to as the broadcast address. Without an existing translation, the module denies inbound packets destined for 10.2.2.128 or 10.2.2.255, and logs this syslog message. When the suspected IP is a host IP, configure a separated static command statement with a host mask in front of the subnet static (first match rule for static command statements). The following static causes the module to respond to 10.2.2.128 as a host address: static (inside,outside) 10.2.2.128 10.2.2.128 netmask 255.255.255.255. static (inside,outside) 10.2.2.128 10.2.2.128 netmask 255.255.255.128. The translation may be created by traffic started with the inside host with the questioned IP address. Because the FWSM views a network or broadcast IP address as a host IP address with overlapped subnet static configuration, the network address translation for both static command statements must be the same.

I'm not sure if its with your specific version, might be...

Federico.

[Kureli Sankar]

What are the security levels on these interfaces? same security?

Take a look at CSCta74788 resolved in 3.2.14

http://tools.cisco.com/Support/BugToolKit/

you can go to the above link login with your CCO ID and then key in this defect ID

-KS

[jgtheodor]

These two interfaces have not the same security level.The  bug CSCta74788 is for the same security traffic between interfaces. The configuration is exactly these lines and nothing more. It seems that FWSM wants a more specific NAT entry to work for this host...

[charrellc011699]

This appears to be expected behavior.  As you have assigned the host to a NAT group on the inside interface (5) but not created a global group (5) on interface dmz1, then the FWSM does not know how to NAT the connection.  I had run into a similar problem and resorted to 2 solutions:

Create a policy-static-nat for the one host -or- create global group (1) on dmz2, then limit access to the one host by interface ACL.

hth