Re: Returning nat packets vanishing after mangle:PREROUTING and conntrack processing

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Scott Shambarger a écrit :
> 
> Fantastic, works great.  Changed to 'net.ipv4.conf.default.rp_filter = 0'
> in sysctl.conf (was set to 1).
> 
> Oddly, I had rp_filter enabled on the system in kernel 2.6.30 and it
> worked.  Has rp_filter changed somehow in the newer kernel (or is it now
> working 'correctly'?).

(Searching in kernel changelogs...)
Yes, rp_filter slighly changed in kernel 2.6.31 (commit
27fed4175acf81ddd91d9a4ee2fd298981f60295). IIUC it is the way that
net.ipv4.conf.<interface>.rp_filter and net.ipv4.conf.all.rp_filter are
combined together that changed from a logical AND to an arithmetic MAX.
This was a fix for a previous patch in kernel 2.6.30 (commit
c1cf8422f0512c2b14f0d66bce34abb0645c888a) which added support for
reverse path filtering "loose mode" (actually a route presence check),
changing rp_filter type from boolean to integer and assigning the value
2 to the new loose mode (see Documentation/networking/ip-sysctl.txt for
details).

Before kernel 2.6.31 :
Actual rp_filter for <interface> = net.ipv4.conf.<interface>.rp_filter
AND net.ipv4.conf.all.rp_filter
I.e. reverse path filtering is enabled in strict mode if rp_filter=1 for
both "all" and the interface.

Since kernel 2.6.31 :
Actual rp_filter for <interface> =
MAX(net.ipv4.conf.<interface>.rp_filter, net.ipv4.conf.all.rp_filter)
I.e. reverse path filtering is enabled in strict mode if rp_filter=1 for
either "all" or the interface.

If by "I had rp_filter enabled" you mean that only
net.ipv4.conf.default.rp_filter was set to 1 and
net.ipv4.conf.all.rp_filter was left to 0 (default), then with the
kernel 2.6.30 the resulting AND was 0, so the reverse path filtering was
disabled. But with the kernel 2.6.31 the resulting MAX is 1, so strict
reverse path filtering is enabled.

Notes :
1) "Loose" reverse path filtering may be a bit better than no reverse
path filtering and should work with your setup.
2) Reverse path filtering in kernel 2.6.32 uses the mark as in policy
routing, so strict reverse path filtering may work better in multihomed
setups like yours.