ip rule with fwmark not working in 2.6.31?
Konstantinos Agouros
I have a setup where I do policy routing based on a mangle-table with
ip rule fwmark. This worked until 2.6.30 with 2.6.31 ip rule does work
eg with a source address
ip rule from 1.2.3.4 lookup 1
but not with
ip rule from all fwmark 0x01 lookup 1
The problem is, that the answer packets are dropped. I use CONNMARK in the
iptables rules. Anybody has an idea if there was a change from 2.6.30 to
2.6.31?
Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elw...@agouros.de
Altersheimerstr. 1, 81545 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres
Pascal Hambourg
Konstantinos Agouros a ï¿œcrit :
>
> I have a setup where I do policy routing based on a mangle-table with
> ip rule fwmark. This worked until 2.6.30 with 2.6.31 ip rule does work
> eg with a source address
> ip rule from 1.2.3.4 lookup 1
> but not with
> ip rule from all fwmark 0x01 lookup 1
> The problem is, that the answer packets are dropped. I use CONNMARK in the
> iptables rules. Anybody has an idea if there was a change from 2.6.30 to
> 2.6.31?
Maybe you have been hit by the same as this :
<http://www.spinics.net/lists/netfilter/msg47119.html>
If reverse path filtering is enabled (sysctl
net.ipv4.conf.<interface>.rp_filter=1), try to disable it for both "all"
and the involved interfaces.
Konstantinos Agouros
>Hello,
>Konstantinos Agouros a �crit :
I already fell back to 2.6.30 but will try in a VM if this is the issue
but it would make perfect sense, as the behaviour described in the link
matches perfectly what I have seen here. Was there a change in 2.6.31
on the default setting of this parameter?
Pascal Hambourg
>
>
>> If reverse path filtering is enabled (sysctl
>> net.ipv4.conf.<interface>.rp_filter=1), try to disable it for both "all"
>> and the involved interfaces.
>
> I already fell back to 2.6.30 but will try in a VM if this is the issue
> but it would make perfect sense, as the behaviour described in the link
> matches perfectly what I have seen here. Was there a change in 2.6.31
> on the default setting of this parameter?
Not AFAIK. But some distribution startup scripts may modify it, e.g.
through /etc/sysctl.conf (as a remainder, note that the current value
and changes of net.ipv4.conf.default.rp_filter are applied to newly
created and existing inactive, i.e. not UP, interfaces).
As I wrote in the last message of the thread, the change was in the way
net.ipv4.conf.<interface>.rp_filter and net.ipv4.conf.all.rp_filter are
combined to produce the functional value. It was a logical AND,
requiring that both are set to enable the feature on <interface>, and
became an arithmetic MAX, requiring that either is set to enable the
feature on <interface>. As a result, if only one is set, then changing
from kernel 2.6.30 to kernel 2.6.31 changes the functional behaviour.