Re: DNS replies not RELATED/ESTABLISHED?

[Tommi Lorry Jensen]

I have a firewall which allows ESTABLISHED,RELATED packets on INPUT,
and port 53/udp on OUTPUT. Now, if I query for a DNS name, the
packet leaves the machine, but the reply is usually dropped:
 

is it running a recursive dns server, or are you using $ISP's designated 
pair?

 [INPUT]: IN=ppp0 OUT= MAC= SRC=217.232.161.91 DST=62.159.154.42
 LEN=68 TOS=0x00 PREC=0x00 TTL=58 ID=9949 PROTO=UDP SPT=53
 DPT=16468 LEN=48 

Here are the relevant rules:
 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 

I'm not entirely certain, but I believe I've read that ctstate only 
applies to NAT - I could be wrong though (and the documentation at 
location listed below doesn't make it completely clear).
Anyhow - it looks like it `falls' through the first two rules, and gets 
pummeled by your LIMIT/LOG rule, and then a DROP into /dev/null, so - 
atleast something hints that connection tracking on udp has a few issues 
(not entirely unexpected on my behalf)

 -A INPUT -m conntrack --ctstate INVALID -j DROP
 

Do you do SNAT/Masquerade outbound? (perhaps unlikely, but it's 
possible), if so, you might need to use -j SNAT|DNAT on --ctstate
(http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-3.html#ss3.3)

 -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT]: 
"
 -P INPUT DROP
I always have to add specific udp sport rules for all nameservers,
which is a pain, and which should not be required.
What am I doing wrong?
(Note that I get the same results with '-m state' instead of '-m
ctstate').
 

that's even stranger - I've made drop policy firewalls with recursive 
dnscache's with the box accepting only ssh from $LAN, and a few select 
external ip's for maintenance, with -m state --state ESTABLISHED,RELATED 
-j ACCEPT - without any problems.

not much of a solution, but hopefully it raises a few questions that 
might make you go "aaaah".

hth.
/Tommi
--
Programmers love Unix and C because they are powerful, and they are powerful 
because programmers love them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]