1. Home
  2. Networking Firewalls
  3. Netscreen: Lots of extraneous "denied" packets in log

Netscreen: Lots of extraneous "denied" packets in log

I'm seeing a considerable number of Denied packets in my log, all coming from outside my network with source port 53. They're all coming from root and top-level name servers (such as g.gtld-servers.net).

I've seen this on other firewalls I've used in the past and it's almost always been caused by my local name server sending a UDP packet out to a remote name server to resolve an address and not getting a response before the NAT translation timeout expires, or getting multiple replies.

Is there a way to set the NAT translation timeout for UDP on a 5GT? I'm running firmware 5.3. I've already tried "set flow allow-dns-reply", but this didn't help.

Thanks.

Reply to
Jerry Gardner
Loading thread data ...

A well-known problem with the same effect is that people and some implementations don't assume the answer to be sent with TCP instead of UDP (if the answer doesn#t fit into a single UDP packet).

Don't know, but a usual workaround it simply forward all DNS answers from an authorized set of DNS servers and deny any others.

Maybe you can add a rule to ignore / not log such particular events?

Reply to
Sebastian Gottschalk

Better use a forwarding DNS outside. You could work on the timeouts.

Yours, VB.

Reply to
Volker Birk

set service dns timeout

Does it really take more than 1 minute to get answer back from DNS? (that's the default)

-Russ.

Reply to
Somebody.

Can you show a packet dump of such behaviour? Maybe you want to re-read RFC1035 and 1035 again.

1034 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035) (Also STD0013) (Status: STANDARD) 1035 Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035) (Also STD0013) (Status: STANDARD)

DNS servers do not spontaneously reply using TCP to a UDP request. If the UDP request results in a reply to large, the TC flag is set in the reply, and the querying station may elect to repeat the request using TCP. ONLY THEN will there be a TCP packet exchange. See section 4.2 of RFC1035.

Old guy

Reply to
Moe Trin

Procedure to dump port 53 traffic for old guy et al to look at:

undebug all clear db unset ffilter

set ffilter dst-port 53 debug flow basic

get db st

-Russ.

Reply to
Somebody.

[compton ~]$ whatis undebug undebug: nothing appropriate [compton ~]$ help undebug No help topics match `undebug'. Try `help help'. [compton ~]$ which undebug [compton ~]$ locate undebug [compton ~]$
[compton ~]$ whatis clear clear (1) - clear the terminal screen clear [curs_clear] (3x) - clear all or part of a curses window [compton ~]$ which clear /usr/bin/clear [compton ~]$

Sorry Russ - your instructions don't work on a *nix box. All I need do is run a sniffer like tcpdump or ethereal

Old guy

Reply to
Moe Trin

Not likely. I believe the 5GT, by default, only lets one reply back in. I suspect that the logged entries are due to multiple reply packets.

Time to fire up Ethereal and start looking at the name server traffic.

Reply to
Jerry Gardner

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.