FWSM nat-control and outgoing access-lists

chris.smailes · ‎02-02-2010

Hi All, I wonder if anyone could clarify this for me, please ? We have a FWSM with interfaces Inside (sec level = 100), Outside (sec level = 0) and numerous Dmz's (various sec levels between 30 and 90). Nat-control is disabled. The FWSM is version 4.0(8) We have recently noticed that packets from private ip addresses (192.168.x.x) are getting from the Inside and the Dmz's through to the Outside and on to our perimeter router, i.e. the chassis MSFC, where they are being dropped by an outgoing ACL. But, this is despite the fact that the FWSM has an outgoing access-list on the Outside interface which should block this traffic and indeed does have a hitcount: access-list UNNToOutside line 1 extended deny icmp 192.168.0.0 255.255.0.0 any (hitcnt=2348) access-list UNNToOutside line 2 extended deny ip 192.168.0.0 255.255.0.0 any (hitcnt=270899) My question is: if nat-control is disabled, does that mean that outgoing access-lists are ignored for traffic from a higher to a lower rated interface ? The documentation is a bit vague on this point. Thanks for your time. Chris.

Panos Kampanakis · ‎02-02-2010

No, nat control does not have to do with ACL checks.

It only refers to having to implement nat for all traffic or identity translating what is not matched.

I hope it helps.

PK

chris.smailes · ‎02-03-2010

Hi PK,

Thanks for the reply. To spell it out for me, are you then saying that the outgoing ACL should definitely block the traffic ?

Ganesh Hariharan · ‎02-03-2010

Hi All, I wonder if anyone could clarify this for me, please ? We have
a FWSM with interfaces Inside (sec level = 100), Outside (sec level =
0) and numerous Dmz's (various sec levels between 30 and 90).
Nat-control is disabled. The FWSM is version 4.0(8) We have recently
noticed that packets from private ip addresses (192.168.x.x) are
getting from the Inside and the Dmz's through to the Outside and on to
our perimeter router, i.e. the chassis MSFC, where they are being
dropped by an outgoing ACL. But, this is despite the fact that the FWSM
has an outgoing access-list on the Outside interface which should block
this traffic and indeed does have a hitcount: access-list UNNToOutside
line 1 extended deny icmp 192.168.0.0 255.255.0.0 any (hitcnt=2348) 
access-list UNNToOutside line 2 extended deny ip 192.168.0.0
255.255.0.0 any (hitcnt=270899)  My question is: if nat-control is
disabled, does that mean that outgoing access-lists are ignored for
traffic from a higher to a lower rated interface ? The documentation is
a bit vague on this point. Thanks for your time. Chris.

Hi Chris,

Nat control command is not related to outgoing acl rather nat control in firewall are genrally specifies that all traffic through the firewall must have a specific translation entry (nat statement with a matching global or a static statement) for that traffic to pass through the firewall.

With nat-control disabled, the PIX/ASA forwards packets from a higher-security interface to a lower one without a specific translation entry in the configuration. In order to pass traffic from a lower security interface to a higher one, use access lists to permit the traffic. The PIX/ASA then forwards the traffic.

Hope that help

If helpful do rate the post

Ganesh.H

chris.smailes · ‎02-03-2010

Hi Ganesh,

Thanks for the reply. Are you then saying that the outgoing access-list should definitely block the traffic, as configured ?

Ganesh Hariharan · ‎02-03-2010

Hi Ganesh,

Thanks for the reply. Are you then saying that the outgoing access-list should definitely block the traffic, as configured ?

Hi Chris,

If NAT control is disabled (no nat-control), inside hosts can communicate with outside networks without the configuration of a NAT rule.If an ACL is present, then it must allow the source host access to the destination host with the use of the specific protocol and port.

Hope to help

If helpful do rate

Ganesh.H

size57 · ‎11-28-2011

Hi,

We have dynamic NAT configured from inside to outside interface, but still it

is showing NAT entry as below.

"NAT from inside:177.26.99.10 to outside:177.26.99.10 flags Ii"

Expected NAT entry should as below :

"NAT from inside:177.26.99.10 to outside:111.111.111.111 flags Ii"

Can you please explain this behaviour, and suggest if xlate-bypass can help

here. We were considering implementing "ip verify revert-path" .Hence here i

am thinking whether xlate-bypass is the issue here and implementing same

with "ip verify revert-path" woud be a good idea.