02-02-2010 09:11 AM - edited 03-09-2019 10:48 PM
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.
02-02-2010 10:20 PM
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
02-03-2010 01:33 AM
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 ?
02-03-2010 12:29 AM
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
02-03-2010 01:35 AM
Hi Ganesh,
Thanks for the reply. Are you then saying that the outgoing access-list should definitely block the traffic, as configured ?
02-03-2010 01:51 AM
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
11-28-2011 09:42 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide