On Wed, 25 Jul 2018 11:19:39 -0400 Eric Garver <[email protected]> wrote: > On Wed, Jul 25, 2018 at 07:33:17PM +0500, Roman Mamedov wrote: > > Hello, > > > > I have a machine which is a DHCPv6 client on a PPPoE connection. It also > > has: > > > > sysctl -w net.netfilter.nf_conntrack_tcp_loose=0 > > ip6tables -t raw -A PREROUTING ! -i lo -m rpfilter --invert -j DROP > > > > After commits: > > > > netfilter: don't set F_IFACE on ipv6 fib lookups > > http://patchwork.ozlabs.org/patch/873574/ > > > > netfilter: ip6t_rpfilter: provide input interface for route lookup > > https://patchwork.ozlabs.org/patch/919290/ > > > > ...the DHCPv6 client no longer sees any replies from the server. They are > > now > > filtered out by rpfilter. Removing the ip6tables rule shown above, or > > rolling > > back both of these commits, makes it all work fine again. > > > > From commit messages it doesn't appear like this would be a "by design" > > behavior of these changes. > > > > I did not test if other kernel branches (4.17 et al) are affected, but if > > they > > also have both of these, I guess they likely are. > > I believe this was fixed by: > > cede24d1b21d ("netfilter: ip6t_rpfilter: provide input interface for route > lookup") > > which landed in 4.18.
It's also in the same 4.14.54 and as you can see I listed it in my message (sorry for not including commit hashes). It does not help. Only rolling back both, fixes the issue. From a non-expert guess, perhaps it misses also restoring the lookup_flags |= RT6_LOOKUP_F_IFACE; line? -- With respect, Roman -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
