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.
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...
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...
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...