Jozsef Kadlecsik wrote: >>> Try to upgrade to a newer kernel. >> I guess I'd do this as a last resort. I'm trying to keep the system in >> question on Debian Stable if possible. Is there reason to think a kernel >> upgrade would just fix it? > Just as a last resort. But the problem is so strange, I can't recall any > patch related to such a behaviour. Unfortunately, I just tried a kernel upgrade (which pulled in a new libc6) which totally hosed my RAID/LVM. It took me the better part of the evening to get the RAID working again on the old kernel, so now I'm quite wary of further kernel upgrades until/unless I figure out what happened there. Hopefully there's some way to get this working with the existing kernel. > So at least we know the packets are seen by the mangle table. As you tried > previously to match them with the 'INVALID' state and it proved to be > false, they are valid packets according to the conntrack. The filter table > is empty, so we can point our finger to nat alone. So are there no diagnostics, absent rebuilding with netfilters debugging on, for tracing a packet in between mangle PREROUTING and nat PREROUTING? When exactly does the packet get connection tracked? In between mangle and nat, or at the start of nat but before entering the PREROUTING chain? And how is it that conn_track thinks the connection is ASSURED when there actually hasn't been a single packet forwarded from the external server back to the internal client? Adam
Attachment:
signature.asc
Description: OpenPGP digital signature
