Subject: uruk: incorrectly blocks and logs tcp RSET packets

From: Joost van Baal-Ilić <[email-masked]>
Date: Tue, 20 Aug 2013 11:21:38 +0200

Package: uruk
Version: 20130426-1
Tag: upstream

Hi,

Op Tue 20 Aug 2013 om 10:53:37 +0200 schreef Wessel Dankers:
> 
> Ik dacht dat dit gefixt was, maar ik zie nog steeds:
> 
> Aug 20 10:52:43 poisson postfix/smtp[28282]: B84AA367: to=<[email-masked]>, relay=aspmx.l.google.com[2a00:1450:400c:c03::1b]:25, delay=0.33, delays=0.02/0/0.08/0.23, dsn=2.0.0, status=sent (250 2.0.0 OK 1376988763 ib3si224878wjb.48 - gsmtp)
> Aug 20 10:52:43 poisson kernel: [435770.792996] ip6tables: IN=eth0 OUT= MAC=00:50:56:9a:1b:fc:00:0e:39:ff:ec:00:86:dd SRC=2a00:1450:400c:0c03:0000:0000:0000:001b DST=2001:0610:1410:0000:ef20:61d1:5f73:2857 LEN=60 TC=0 HOPLIMIT=57 FLOWLBL=0 PROTO=TCP SPT=25 DPT=42368 WINDOW=0 RES=0x00 RST URGP=0 
> 
> Die iptables-regel verschijnt na elk verstuurd mailtje.

сре 14 10:18 < thijs> overigens, ik krijg nog steeds veel van dit soort output in syslog: 
                      Aug 14 06:03:34 tnli005 kernel: [2554333.457013] iptables: IN=eth0 
                      OUT= MAC=00:50:56:b3:45:d4:00:0e:39:ff:ec:00:08:00 SRC=137.56.247.155 
                      DST=137.56.243.55 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP 
                      SPT=58041 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
сре 14 10:18 < thijs> 1 per minuut
сре 14 10:19 < Fruit> mja dat is die iptables bug
сре 14 10:19 < thijs> was daar niet een workaround voor aangebracht?
сре 14 10:21 < joostvb> zou gefixed moeten zijn in "uruk version 20120914 - The Sankt Goar 
                        Release
сре 14 10:21 < joostvb> "
сре 14 10:24 < thijs> ii  uruk   20130426-1
сре 14 10:25 < joostvb> misschien http://bugs.debian.org/687621 heropenen dan
сре 14 10:27 < Fruit> hmm dit is een RST-pakketje
сре 14 10:27 < Fruit> geen FIN|ACK

uruk now has:

 $iptables -A INPUT --protocol tcp --tcp-flags SYN,ACK,FIN,RST FIN,ACK -j ACCEPT
 $ip6tables -A INPUT --protocol tcp --tcp-flags SYN,ACK,FIN,RST FIN,ACK -j ACCEPT

would adding

 $iptables -A INPUT --protocol tcp --tcp-flags SYN,ACK,FIN,RST RST -j ACCEPT
 $ip6tables -A INPUT --protocol tcp --tcp-flags SYN,ACK,FIN,RST RST -j ACCEPT

fix it?  Is this yet another bug in iptables?

Bye,

Joost

---

From: Joost van Baal-Ilić <[email-masked]>
Date: Tue, 20 Aug 2013 12:03:20 +0200

> fix it?  Is this yet another bug in iptables?

the story behind this: we are client and initialize outgoing tcp session.
return traffic gets allowed since matching state.  incoming rset packet gets
received, apparently kernel doesn't recognize it as belonging to a tcp-session
being shut down, and can't match the state.

would tweaking one of net.ipv4.netfilter.ip_conntrack_tcp* sysctl flags be
better?