From: Karl Juchen <karl.juchen@gmx.de>
To: netfilter@lists.netfilter.org
Subject: traceroute, state, bug?
Date: Wed, 09 Oct 2002 19:27:55 +0200 [thread overview]
Message-ID: <3DA4671B.10704@gmx.de> (raw)
Hello!
I'm using iptables 1.2.6a, kernel 2.4.18 and have a problem with the
connection tracking state extension.
I want to allow traceroute from my local network, so I configured my
firewall to accept outgoing UDP packets on ports 33434+x.
I also accept certain types of ICMP packets to pass, especially
time-exceeded:
iptables -A chain -p icmp -m state ESTABLISHED -j ACCEPT
iptables -A chain -p icmp -m state RELATED -j ACCEPT
...
iptables -A chain -p icmp [-s source] [-d destination] --icmp-type
time-exceeded -m state NEW -j ACCEPT
...
I read at
http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
that the state NEW does not exist for time-exceeded packages.
So the last rule will never be matched and seems to be abundant.
However, at this time a traceroute from my local network to an external
host looks like that:
1 * * *
...
9 scratchy.onlinekosten.de (217.172.162.11) 66 ms 66 ms 66 ms
So only the time-exceeded answers originating from the firewall are
blocked. I found out, that's because these answers have the state
INVALID, instead of RELATED like corresponding packets from other hops.
I manually added certain logging rules to check what happens:
Oct 9 20:10:31 mg1000-2 kernel: ***PREROUTING*** IN=eth2 OUT= MAC=
SRC=192.168.0.2 DST=62.153.159.89 LEN=40 TOS=0x00 PREC=0x00 TTL=1
ID=24178 PROTO=UDP SPT=33883 DPT=33435 LEN=20
Oct 9 20:10:31 mg1000-2 kernel: out-INTERN REJECT IN= OUT=eth2
SRC=192.168.0.1 DST=192.168.0.2 LEN=68 TOS=0x00 PREC=0xC0 TTL=255
ID=50358 PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.0.2 DST=62.153.159.89
LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=24178 PROTO=UDP SPT=33883 DPT=33435
LEN=20 ]
...
Oct 9 20:10:40 mg1000-2 kernel: ***PREROUTING*** IN=eth2 OUT= MAC=
SRC=192.168.0.2 DST=62.153.159.89 LEN=40 TOS=0x00 PREC=0x00 TTL=2
ID=24181 PROTO=UDP SPT=33883 DPT=33438 LEN=20
Oct 9 20:10:40 mg1000-2 kernel: INTERN-EXTERN ACCEPT IN=eth2 OUT=ppp0
SRC=192.168.0.2 DST=62.153.159.89 LEN=40 TOS=0x00 PREC=0x00 TTL=1
ID=24181 PROTO=UDP SPT=33883 DPT=33438 LEN=20
Oct 9 20:10:40 mg1000-2 kernel: ***POSTROUTING*** IN= OUT=ppp0
SRC=192.168.0.2 DST=62.153.159.89 LEN=40 TOS=0x00 PREC=0x00 TTL=1
ID=24181 PROTO=UDP SPT=33883 DPT=33438 LEN=20
Oct 9 20:10:40 mg1000-2 kernel: EXTERN-INTERN RELATE IN=ppp0 OUT=eth2
SRC=217.5.98.70 DST=192.168.0.2 LEN=56 TOS=0x00 PREC=0x00 TTL=59 ID=0
PROTO=ICMP TYPE=11 CODE=0 [SRC=80.135.184.250 DST=62.153.159.89 LEN=40
TOS=0x00 PREC=0x00 TTL=1 ID=24181 PROTO=UDP SPT=33883 DPT=33438 LEN=20 ]
The first entry shows, that the request goes through the nat PREROUTING
chain and seems to be dropped afterwards because of TTL=1.
The answer from the firewall box is REJECTED by my rules because the
packet is not recognized as RELATED but INVALID, altough iptables seems
to remember the original request.
A traceroute to the firewall itself looks like this:
1 192.168.0.1 (192.168.0.1) 0 ms 0 ms 0 ms
This time the destination-unreachable answer is treated correctly as
RELATED.
So why does the time-exceeded answer in the first case have the state
INVALID, though it should be RELATED as far as i can see it?
Am I doing something wrong or is it even an iptables bug?
Thanks for any ideas,
Karl
reply other threads:[~2002-10-09 17:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DA4671B.10704@gmx.de \
--to=karl.juchen@gmx.de \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox