Tobias Klausmann wrote:
Hi!
(I've now subscribed to netdev@, so no more CCs to me are necessary).
On Tue, 27 Jan 2009, Patrick McHardy wrote:
That sounds plausible, but we only discard the new conntrack
entry on clashes. The packet should be fine, unless you drop
INVALID packets in your ruleset.
The ruleset currently does not contain any rules regarding
INVALID. Consequently, we opted for the TRACE approach.
Try tracing the packet using the TRACE target. That should show
whether it really disappears within netfilter and where.
I've removed the irrelevant fields like TTL, PREC etc and timing
info from syslog from the trace after making sure nothing funky
was going on there.
Apart from the ID field, I ended up with two identical traces.
So, as far as rule-matching is concerned, the two packets are
handled identically. Whatever happens after this:
Jan 27 11:00:39 fw2 kernel: TRACE: nat:POSTROUTING:policy:3 IN=
OUT=eth2.188 SRC=194.97.7.116 DST=194.97.3.83 LEN=66 TOS=0x00
PREC=0x00 TTL=63 ID=46964 DF PROTO=UDP SPT=53452 DPT=53 LEN=46
is making this very packet go away. The policy of nat/PR is
ACCEPT.
This just means it passed through the last table/chain. The
only one following is conntrack confirmation.
Damn it :) I just noticed, we do indeed drop packets from
duplicate new connections in conntrack confirmation.
You should see the insert_failed conntrack counter show this
(/proc/net/stat/nf_conntrack).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
