Re: DNS replies not RELATED/ESTABLISHED?
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.
Reply to: