On Tue, Aug 20, 2013 at 11:21:38AM +0200, Joost van Baal-Ilić wrote: > 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 protected]>, > > 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?
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? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
