Page MenuHomePhabricator

Disabling rp_filter don't work
Closed, ResolvedPublicBUG

Description

Hello!
In VyOS vyatta-cfg-firewall repository is a wrong definition of rp_filter options, that lead to problems with disabling this option on the fly.
In node.def we have:

rp_filter
default value - 0
conf/all/rp_filter and conf/[interface]/rp_filter both must be set to
a value greater than 0 to do source validation on the interface

But, at kernel.org information is different:

The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.

So, when we disabling rp_filter with current way:

... [skipped part] ...

        else
           sudo sh -c "echo 0 > \
               /proc/sys/net/ipv4/conf/all/rp_filter"
	fi

delete:
	sudo sh -c "echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter"

we actually don't do this.

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0-rolling+201812130337
Why the issue appeared?
Will be filled on close

Event Timeline

zsdc created this task.Dec 13 2018, 10:42 AM
zsdc updated the task description. (Show Details)Dec 13 2018, 10:44 AM
hagbard changed the task status from Open to On hold.Dec 13 2018, 6:26 PM
hagbard claimed this task.
hagbard added a subscriber: hagbard.

Unless I misunderstood you, int(0) does disable (no source validation) rp_filter.

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path

	    Each incoming packet is tested against the FIB and if the interface
	    is not the best reverse path the packet check will fail.
	    By default failed packets are discarded.

2 - Loose mode as defined in RFC3704 Loose Reverse Path

	    Each incoming packet's source address is also tested against the FIB
	    and if the source address is not reachable via any interface
	    the packet check will fail.

Can you please clarigy?

Ahh, I think I found it. Usually sysctl sets it to 1, or at least it must have that done in 1.1. I think the command should be called then enable-arp-filter to correct it.

zsdc added a comment.Dec 14 2018, 3:12 PM

Here what I mean.
Before enabling rp_filter:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 0
net.ipv4.conf.l2tpeth1.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0

After enabling:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

After disabling:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

We don't change values for interfaces. Manual at kernel.org says:

The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}.

So, as interface value (2) is bigger than all (0), then rp_filter is actually enabled for all interfaces.

Uh, yeah, that sucks. I'm implementing the kernel variables for wireguard at the moment and have a look into the other interfaces after that.

pasik added a subscriber: pasik.Dec 16 2018, 11:16 AM
hagbard changed the task status from On hold to In progress.Dec 18 2018, 6:08 PM
hagbard closed this task as Resolved.Dec 18 2018, 7:16 PM

Next rolling release tonight will have the bugfix in place. Thanks for reporting.