Solved: PIX NAT Translation Problem

veno77 · ‎12-19-2002

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.

gfullage · ‎12-20-2002

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.

View solution in original post

gfullage · ‎12-20-2002

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.