Upgrading from hardened-sources-3.15.10-r1 to hardened-sources-3.17.7-r1 result in partially breaking openvpn tunnel - reply to ping is dropped between mangle PREROUTING and nat PREROUTING. It turns out this happens because /proc/sys/net/ipv4/conf/tun0/rp_filter is set to 1. I've boot both kernels with init=/bin/bash and checked default value for /proc/sys/net/ipv4/conf/default/rp_filter: it was changed from 0 to 1. I don't know is this issue with vanilla too or only hardened kernel, but according to /usr/src/linux-3.17.7-hardened-r1/Documentation/networking/ip-sysctl.txt default value should be 0.
Can you please test on vanilla and see.
I've checked vanilla-sources-3.17.7 - it defaults to 0. So, this is bug in hardened.
These should be set in sysctl.conf: $ grep rp_filter /etc/sysctl.conf net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 Those are the defaults that ship with baselayout-2.2.
(In reply to Michael Orlitzky from comment #3) > Those are the defaults that ship with baselayout-2.2. Sure, but I had to comment it out because it breaks openvpn. I'm using openvpn to connect to network of several servers, one of which is actually running openvpn-server service. So, I've configured iptables on my workstation to send packets to this server using tun0 except packets sent to UDP port of openvpn-server itself. Because of this part of traffic between my workstation and this server use eth0 (default interface to internet) and other part use tun0. rp_filter=1 in this setup doesn't work, it result in dropping incoming packets from tun0 sent from this server - so I've disabled it and implemented anti-spoof rules manually in iptables. Anyway, this issue isn't about defaults in /etc/sysctl.conf, it's about kernel defaults.
Oh, sorry, I didn't realize you had commented it out. But if the kernel default is (now) the same as the Gentoo default, this might not be seen as a bug. You could have just set it to zero instead of commenting it out =) I do exactly the same thing, so if I can hijack a bit, here's an explanation for @hardened, and the solution I came up with -- maybe you'd find it easier. We have a server mmmc2.viabit.com on 65.246.80.51 which runs OpenVPN. The purpose of OpenVPN is primarily to access the server itself. Without the VPN, there's no external SSH (or anything else) access to mmmc2.viabit.com. When I connect to the VPN, I connect to mmmc2.viabit.com:1194. The routes for the VPN itself (some internal 172 addresses) then get pushed to my client. But this isn't all I want -- for example, I want to be able to SSH to mmmc2.viabit.com and have it just work, even though mmmc2.viabit.com doesn't resolve to a VPN address. So the first thing you'd try would be to push a route to the client that says "route traffic for 65.246.80.51 through the VPN." Except now all hell breaks loose, because the OpenVPN packets destined for mmmc2.viabit.com:1194 attempt to go through the VPN. And the VPN doesn't exist anymore, because you can't send those packets... Alex's solution makes an exception with iptables on the client for the OpenVPN traffic. What I wound up doing was creating a second entry in DNS for vpn.mmmc2.viabit.com, which I use for everything *except* OpenVPN. That name resolves to the VPN address of the server, which is static. The name "mmmc2.viabit.com" really only gets used in one place: the OpenVPN config. It's not too much worse to type, and yes, it reveals "internal" info in DNS, but nothing private really. It's also easier to explain if you ever need to let someone else use the VPN.
(In reply to Alex Efros from comment #4) > Anyway, this issue isn't about defaults in /etc/sysctl.conf, it's about > kernel defaults. (In reply to Michael Orlitzky from comment #5) > Oh, sorry, I didn't realize you had commented it out. But if the kernel > default is (now) the same as the Gentoo default, this might not be seen as a > bug. You could have just set it to zero instead of commenting it out =) > This doesn't sound like a bug to me but a configuration issue. Hardened is just inheriting this issue from Gentoo sources which has this default. Comments from the kernel team?
I don't see us releasing a new 3.17 kernel. Might be worth checking a later version.
Can someone point out where something from genpatches is setting this?
(In reply to Mike Pagano from comment #8) > Can someone point out where something from genpatches is setting this? It's not set in genpatches, it's done in grsecurity: --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -69,7 +69,8 @@ static struct ipv4_devconf ipv4_devconf = { .data = { - [IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 1, + [IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 0, + [IPV4_DEVCONF_RP_FILTER - 1] = 1, [IPV4_DEVCONF_SEND_REDIRECTS - 1] = 1, [IPV4_DEVCONF_SECURE_REDIRECTS - 1] = 1, [IPV4_DEVCONF_SHARED_MEDIA - 1] = 1 FWIW I think the default of "1" is fine. The kernel docs recommend it, and it's the better option in all but the craziest cases. Plus, it's easy to change. Kernel docs quoted below. 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. Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}. Default value is 0. Note that some distributions enable it in startup scripts.
(In reply to Michael Orlitzky from comment #9) > (In reply to Mike Pagano from comment #8) > > Can someone point out where something from genpatches is setting this? > Sorry guys, I don't know why I thought htis was in genpatches. Having said that, I'm not going to carry a specific patch for this since they payback is small. Just change the behavior in sysctl.conf.
