12-19-2002 11:27 AM - edited 02-20-2020 10:26 PM
Hello All I have the following situation on a PIX 520 running 6.2.2
I have three interfaces inside, outside, dmz
on the outside interface have an access-list which permits icmp from any to the IPs behind the DMZ interface, I have the following:
access-list external_access_in permit icmp any 1.1.1.0 255.255.255.0
nat (dmz) 0 1.1.1.0 255.255.255.0 0 0
access-group external_access_in in interface outside
1.1.1.0 are routed ip addresses in internet, the above permits outside hosts to ping my hosts behind the dmz interface
I am trying to do the same trying to permit the hosts behind the dmz to icmp ping the hosts behind the inside interface:
access-list dmz_in permit ip any any
nat (inside) 0 1.1.5.0 255.255.255.0 0 0
access-group dmz_in in interface dmz
The inside permits inbound by default.
But I have in the log :
305005: No translation group found for icmp src dmz:1.1.1.1 dst inside:1.1.5.1 (type 8, code 0)
According to me the situation is the same like pinging outside to dmz.
I have:
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
Does anyone could tell me where I am wrong, and how to permit the dmz hosts to icmp ping the hosts on the inside interface.
Thanks for your answers.
Solved! Go to Solution.
12-20-2002 09:41 PM
When using "nat 0" with a network after it, this does NOT work like a static/ACL combination that you normally need to go from a lower security interface to a higher security, like you're doing here. With "nat 0", traffic has to be initiated from the higher security interface first, THEN traffic can flow from the lower security interface. In your example, traffic would have to flow from inside to DMZ BEFORE traffic can flow from DMZ to inside. The reason it works with the DMZ to outside traffic is that traffic has probably flowed from DMZ to outside already, so traffic can then flow from outside to DMZ.
NAT 0 is probably something I would keep away from, cause it causes misinterpretations like this. IT IS NOT THE SAME AS A STATIC/ACL PAIR., although it is similar.
I would replace your "nat 0" statements with the following:
> static (dmz,outside) 1.1.1.0 1.1.1.0 netmask 255.255.255.0
> static (inside,dmz) 1.1.5.0 1.1.5.0 netmask 255.255.255.0
You still have a static, but you translate it to itself, effectively bypassing NAT (even though it does still go through the NAT process). Traffic will then be able to flow in both directions regardless. This is easier to read and follow to me also, but that's just my opinion.
12-20-2002 09:41 PM
When using "nat 0" with a network after it, this does NOT work like a static/ACL combination that you normally need to go from a lower security interface to a higher security, like you're doing here. With "nat 0", traffic has to be initiated from the higher security interface first, THEN traffic can flow from the lower security interface. In your example, traffic would have to flow from inside to DMZ BEFORE traffic can flow from DMZ to inside. The reason it works with the DMZ to outside traffic is that traffic has probably flowed from DMZ to outside already, so traffic can then flow from outside to DMZ.
NAT 0 is probably something I would keep away from, cause it causes misinterpretations like this. IT IS NOT THE SAME AS A STATIC/ACL PAIR., although it is similar.
I would replace your "nat 0" statements with the following:
> static (dmz,outside) 1.1.1.0 1.1.1.0 netmask 255.255.255.0
> static (inside,dmz) 1.1.5.0 1.1.5.0 netmask 255.255.255.0
You still have a static, but you translate it to itself, effectively bypassing NAT (even though it does still go through the NAT process). Traffic will then be able to flow in both directions regardless. This is easier to read and follow to me also, but that's just my opinion.
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