Incoming packet in wrong chain
Hi!
I got Kernel 2.6.22 und do some Masquerade for my Windows boxes.
My problem get visible in this rule:
Chain INPUT (policy DROP 0 packets, 0 bytes)
113 87963 DROP_LOG 0 -- ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW
This rule is at bottom of my INPUT-Chain.
Kernel says:
DROP: IN=ppp0 OUT= MAC= SRC=217.13.68.183 DST=91.xx.xx.xx LEN=58 TOS=0x00 PREC=0x00 TTL=59 ID=55058 DF PROTO=TCP SPT=80 DPT=2409 WINDOW=14520 RES=0x00 ACK URGP=0
This ACK packet belongs to surfing WWW and should never get into INPUT-Chain. The problem occurs randomly. Is this a bug? A why hit a rule for SYN packets at ACK packets?
Signature · 2 lines
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Quoted 8 lines · Tim Ritberg
Hi!
I got Kernel 2.6.22 und do some Masquerade for my Windows boxes.
My problem get visible in this rule:
Chain INPUT (policy DROP 0 packets, 0 bytes)
113 87963DROP_LOG0 -- ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW
Quoted 7 lines
This rule is at bottom of my INPUT-Chain.
Kernel says:
DROP: IN=ppp0 OUT= MAC= SRC=217.13.68.183 DST=91.xx.xx.xx LEN=58 TOS=0x00 PREC=0x00 TTL=59 ID=55058 DF PROTO=TCP SPT=80 DPT=2409 WINDOW=14520 RES=0x00 ACK URGP=0This ACK packet belongs to surfing WWW and should never get into INPUT-Chain. The problem occurs randomly. Is this a bug? A why hit a rule for SYN packets at ACK packets?
For Netfilter connection tracking, a NEW TCP connection does not have to start with a SYN packet. If /proc/sys/net/netfilter/nf_conntrack_tcp_loose is set to 1 (default), Netfilter will try to pick up connection. By this mean, it is possible to recover a connection (in some fail-over case for example), but it introduces this looking-weird-at-first behaviour.
BR,
- --
Eric Leblond <[email protected]>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
EdenWall: http://www.edenwall.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJj05dnxA7CdMWjzIRAk2BAJ4p7uOUzgNsTrOrGbg2sVTYEa8bjwCeLowc tJssXCPP3rJk/isR9cnynvg=
=hb1D
-----END PGP SIGNATURE-----
Quoted 10 lines
For Netfilter connection tracking, a NEW TCP connection does not have to start with a SYN packet. If
/proc/sys/net/netfilter/nf_conntrack_tcp_looseis set to 1 (default), Netfilter will try to pick up connection. By this mean, it is possible to recover a connection (in some fail-over case for example), but it introduces this looking-weird-at-first behaviour.BR,
- --
Eric Leblond <[email protected]>
because of that netfilter put it in INPUT-Chain?
and I wonder why it occurs randomly.
Should I switch to nf_conntrack_tcp_loose 0?
Signature · 1 line
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Hi,
Quoted 7 lines · Tim Ritberg
Quoted 7 lines
For Netfilter connection tracking, a NEW TCP connection does not have to start with a SYN packet. If
/proc/sys/net/netfilter/nf_conntrack_tcp_looseis set to 1 (default), Netfilter will try to pick up connection. By this mean, it is possible to recover a connection (in some fail-over case for example), but it introduces this looking-weird-at-first behaviour.
Quoted 6 lines
Quoted 3 lines
BR,
- --
Eric Leblond <[email protected]>because of that netfilter put it in INPUT-Chain?
and I wonder why it occurs randomly.
These packets are often due to ghost connections:
- packet from a connection "closed" in the middle due to link failure
- packet from connection open by the people having the IP before you
- ...
Quoted 1 line
Should I switch to
nf_conntrack_tcp_loose0?
You can, there should be no problem with that.
BR,
Signature · 3 lines
Eric Leblond <[email protected]> INL: http://www.inl.fr/ NuFW: http://www.nufw.org/