Error 710003 UDP access denied by ACL

[solfitadm]

After upgrading from PIX 6.3 to 7.0(2), we have the following error message:

%PIX-3-710003: UDP access denied by ACL from X.X.X.X/138 to inside:Y.Y.Y.255/138

which are broadcasts from the MS systems...

But as we didn't setup such an ACL and we where not able to find this definition, we are wondering, how can avoid this error message (as we do not want to ignore it...)

We thought that this has something to do with the netbios inspection, but we've still had this error after disabling the inspection option.

Where is this ACL set ?

[nkhawaja]

do a "show run access-group"

it will tell you if an ACL is applied or not.

perhaps the error message you are getting is due to the fact that there is an implicit ACL,

just a thought.

[solfitadm]

Dear Nkhawaja,

the command shows the following:

# show run access-group

access-group outside_in in interface outside

access-group inside_in in interface inside

access-group dmz_in in interface dmz

As the error message does not include the message like "denied by access-list inside_in", I don't believe that this has something to do with my access-list. However, I'll try to open everything to see if this helps, but normally, the PIX reports the name of the access-list which dines something....

Cheers,

Remo

[ciscopixguy]

Hi,

710003 is actually an existing logg message from the 6.x code. You should have been seeing these messages previously.

The way I read the error message is that the PIX is interpreting the the broadcast with destination port 138 as a request to connect to UDP/138 on the inside interface.

The PIX allows only a few protocols on the interfaces. As an example, when you issue the command below, the PIX adds a "virtual permit" to its interface ACL. This ACL is seperate and distinct from an ACL that filters traffic THROUGH the PIX.

ssh 10.10.10.0 255.255.255.255 inside

I recognize this is a tad confusing. The access-group command binds an ACL to an interface for traffic going through the PIX. The ssh command binds a permit statement for access TO the inside interface.

In short, you cannot change the fact that the inside interface disallows UDP/138. You COULD supress the message, but I would not recommend it.

One workaround would be to put a 2-port router between the inside interface and the inside subnet. Since the router will not forward a broadcast, you will not see the message. Unfortunately, this has the same effect as "no logging message 710003".

Hope this helps,

Dave