Whit Blauvelt wrote:
On Tue, Mar 25, 2008 at 04:53:19PM +0100, Patrick McHardy wrote:
Please post the list of modules loaded and the output of
/proc/net/nf_conntrack.
First here is the list by the system in question, working once the ipv6
module is blocked from loading at boot. Next is the list from a system with
identical hardware and near-identical configuration (same firewall rules),
but with ipv6 loading - and which also has only 4 of the 6 NICs showing up
in the ipv6 proc conf space, and also has NAT (in this case DNAT is what I
tested) failing - also where the NICs on the Internet side of things are
those coincidentally not showing up with proc ipv6 conf settings.
The firewall rules appear to be different between the two systems,
the first one has a lot more references to the IPv4 conntrack module.
As to the output of /proc/net/nf_conntrack, you just want to see anything,
or under specific load? I'm not going to just publicly post the raw data -
although both systems have some there - since IPs can identify my client and
their clients, which would violate confidentiality.
I'm mainly interested in one or more of the conntrack entries that
should get NATed but don't. One entry should be enough, feel free
to replace IPs as long as similar IPs still are similar.
Okay, the fixed system:
Module Size Used by
...
> iptable_nat 8708 1
> nf_nat 20012 2 nf_nat_ftp,iptable_nat
> nf_conntrack_ipv4 19724 374 iptable_nat
Here's the list from a nearly identical sytem that's still got the ipv6
module loading, and that's also failing at both populating the proc ipv6
space fully (same thing - just four of the 6 NICs) and also failing at NAT
(in this case DNAT was what I tried):
iptable_nat 8708 1
nf_nat 20012 2 nf_nat_ftp,iptable_nat
nf_conntrack_ipv4 19724 94 iptable_nat
Could you figure out whats causing the different amount of references
to nf_conntrack_ipv4? "-m state" rules, "-m conntrack" etc. take
references, maybe something fails during load?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
