Whit Blauvelt wrote:
Josef, the set of iptables modules is precisely the same whether or not ipv6
is enabled on the system (yes, I've looked). The only difference is whether
the ipv6 module is loaded. Blocking the ipv6 module from loading at boot
both prevents (of course) the /proc/sys/net/ipv6 space from being populated.
It also fully restores SNAT functionality.
There are no error messages from "iptables -t nat" commands. The nat rules
show up precisely the same in the resulting tables - they just don't count
any packets traversing them if ipv6 is also enabled. I haven't done packet
inspection to see what's happening, but the problem remains:
With _everything else_ unchanged, simply letting the ipv6 module load at
boot results in:
1) eth4 and eth5 not showing up as they should for ipv6 in
/proc/sys/net/ipv6/conf
and (whether related or a separate bug)
2) ipv4 Netfilter SNAT (in POSTROUTING in this case) becoming a black hole
Boxes behind the firewall can still ping the firewall. The firewall can
still ping the world. But just with the ipv6 module loaded, the boxes behind
the firewall cannot ping the world. Clearly ipv6 is not properly
provisioning its space. But why should ipv6's failing have any effect at all
on ipv4 functionality?
For me, not loading the ipv6 module is a totally fine workaround. It's
useless cruft in my context anyway. But even though my problem is fixed for
now, it will be a problem for other people (maybe only those with > 4
ethernet devices?) when the ipv6 transition finally happens. I remember in
the early 90s when we were expecting it by about 1998.
So in the spirit of open source development, I'm looking for for someone
with better knowledge of the underlying theory to help identify where the
bug here is. Then the responsible developers can have a chance to fix it
before a lot of other sysadmins also end up wasting many hours because of
the non-obviousness of having to look at ipv6 stuff to find why ipv4 SNAT
becomes a black hole.
Please post the list of modules loaded and the output of
/proc/net/nf_conntrack.
--
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
