UDP Deny issue...is this correct?

[jp]

We are getting thousands of snmp logs per day and 99% of it is like:

Jul 29 2004 14:45:37: %PIX-4-106023: Deny udp src outside:128.242.107.15/53 dst inside:x.x.x.x/35554 by access-group "incoming"

x replaces real ip's. We have DNS servers inside the firewall for Active Directory that foward out to the internet, but there should be no reason for dns traffic coming in. I have fixup dns maxlength 1500 command in the pix. everyone of the packets have 53 source and 35554 destination. source is an external ip and destination is the outside interface ip. Not all the source IP's are the same. There is usually a few in a row from one address and then a few from another, etc. Is this truely suppose to be blocked? What is this traffic? I feel like I am missing important errors on the syslog server, since I am getting thousands of these per day. Thanks for any help!

[nkhawaja]

what is x.x.x.x , is it a specific IP or is it changing? the incoming is applied to outside? 35554 always as destination seems strange.

what you are seeing is a return traffic of DNS session initiation. But if the traffic initiates from inside the firewall, then it should be allowed in. Are there any redundant paths in your network to internet?

Thanks

Nadeem

[jp]

x.x.x.x are different IP's. The source IP changes. The destination is our public IP, and it does not change. access-group incoming in interface outside. 35554 seems to always be the destination IP on our interface. The source IP is always from port 53.

another example:

Jul 29 2004 16:28:38: %PIX-4-106023: Deny udp src outside:128.242.107.15/53 dst inside:12.31.192.158/35554 by access-group "incoming"

[nkhawaja]

Hi,

Just to clarify, 12.31.192.158/35554 always remains the same, where as src is y.y.y.y/53, right?

and 12.31.192.158 is your interface address?

can you check in the xlat table to see which inside PC is gettting PATTEd to 12.31.192.158/35554

you can try "show xlat | inc 12.31.192.158/35554"

Thanks

Nadeem

[mnlatif]

What version of PIX you are running ?

We saw a similar issue , when upgraded to 6.3. In my opinion this is the scenario

Your Server initiates a DNS query (random source port) to any outside server (port 53).

PIX firewall will allow the return UDP traffic and then "delete the translation slot".

Now if there was a slight delay before the outside DNS server replied, your inside server might initiate another query (for the same address) but if you get a response right after this for your first (original query) then the xlate will be deleted. So the response to the second query will be denied and you will see the log message.

I had a case opened with Cisco TAC (can't find the case number) and we captured a lot of ethereal\PIX traces to troubleshoot this, in the end TAC wasn't that responsive and we didn't have any problems besides all these false entries, so i closed the case.

\\ Naman