Pix Errors (to 255.255.255.255)

Hello everyone,

We've been using our Pix 501 for a bit over a year now, but just recently aquired any sort of log analysis software to be able to break down the logs. In doing so, this error seemed particularly strange:

7-710005 UDP request discarded from 192.168.1.7/nnnn to inside:255.255.255.255/nnnn

192.168.1.7 is an active directory server inside out network with a static map to a public IP of .7, we're getting around 85,000 of these messages in the logs per day! It seems to be a ton of UDP requests going to port 20,000 and broadcasting to 255.255.255.255 and getting 'no service' responses/errors (but wouldn't the broadcast address be

192.168.1.255?). Port 20,000 seems to be DNP (Distributed Network Protocol).

I've done the usual administrative checks on the server for unnecessary services/spyware/viruses/trojans and it looks to be clean, so I'm lost for an answer at this point.

Here's the general config of the NAT on the pix:

global (outside) 1 interface nat (inside) 0 access-list inside_outbound_nat0_acl nat (inside) 1 192.168.1.0 255.255.255.0 0 0 static (inside,outside) 198.xxx.xxx.7 192.168.1.7 netmask

255.255.255.255 0 0

Any help would be greatly appreciated!

Michael Cox

Yup. Entirely plausible. One per second times 60 seconds per minute times 60 minutes per hour times 24 hours per day = 86400 times per day.

There are two different broadcast addresses with slightly different purposes. One is the subnet broadcast address you are thinking of (192.168.1.255), which is for broadcasting to all hosts in the same subnet. The other is 255.255.255.255 which is for broadcasting to all hosts in the same broadcast domain (i.e., the same side of the router).

255.255.255.255 gets used for non-routable protocols such as NETBIOS that want to be able to talk to all local resources. Your server is probably trying to advertise to all your local hosts (no matter what subnet) that it has DNP services available in case they are interested. *Sometimes* you can configure protocols like that to use multicast instead of broadcasts, and *sometimes* for some protocols you can configure an explicit client discovery instead of server advertisement, but in the general case your choices are either to put up with it or to turn off the service.

You might want to consider using the pix command no message logging 710005 which will turn off logging of the event completely, along with all other such events. That lowers your ability to catch intrusions a bit, but on the other hand if your logs are clogged with the extraneous messages you're not going to have fun processing the logs to find intrusions anyhow...