PIX - "No translation group found for udp src outside..." port 137

Someone is trying to access your network on port 137 (TCP I presume) and your pix doesn't have a translation slot for that traffic. The Pix always checks for a NAT translation slot for all traffic.

Chris.

A small amplification: the PIX checks translation status -before- it checks access-lists . (Or at least that was the case for 6.2; I did not check to see if they fixed this for 6.3; it was handled differently in 6.1)

WHy does it do that, when I haven't configured ANY NAT commands on it at all?

I just want it to be applying the access-lists I have defined.

I can see plenty of stuff hitting my DENY rule at the bottom of the access list, but the above packets should be matching to one of the higher ALLOW lines in my access list.

(I have got 6.3, btw - it's a new PIX 506E).

I think I'm missing something really basic about PIXs & NAT here. Like it's on by default or something. Stupid thing.

"Because".

No, address translation is off by default on the PIX {*}. But the normal order of operations for incoming packets to the PIX is to check first whether there is a translation that would potentially allow the packet through. If there is no translation defined for that (external) source to that (internal) destination, then PIX 6.2 or 6.3 will reject the packet with a "no translation group" message, without having looked at the access-group {**}. Only once a packet has passed translation muster is the access-group checked to see if the packet is really allowed or not. {***}

{*} Unless, that is, you have a PIX 501 or 506E that you did "configure factory" on: the "factory" settings for those two write nat into the configuration, where you can see it in the configuration.

{**} I filed a bug report about this order of operations, on the grounds that the "no translation" message given implied (directly, as part of the message) that not having a translation group was a probable configuration mistake. That implication is downright wrong when one has deliberately configured translations only for the public IPs authorized to talk to the outside world, with the lack of translation acting as an additional security layer -- security in depth rather than relying just on the access-group . Sounds like they didn't get around to fixing the issue yet, at least not for 6.3 (I have never had PIX 7 / ASA access to test on.)

{***} If you happened to have a PIX 501, this order of operations results in gobbling up license slots if someone scans your public IP range and you -have- defined translations but blocked via access-group (e.g., to shut up the 'no translation' message or to get the more detailed information provided when something is blocked by access-group instead of by translation.) Host slots on the 501 are filled when the translation is requested, before the access-group is checked :(