On 12-02-21 10:36 AM, Teodor MICU wrote:
> 2012/2/21 Simon Deziel <[email protected]>:
>> The proposed changes are about _disabling_ ICMP redirects for tun-based
>> VPNs. Generally disabling send_redirects is something that should be
>> handled at the distro level IMO.
>
> Right, your proposal is to disable them. Even so why
> net.ipv4.conf.all.send_redirects and not specific tun/tap devices?
> Indeed all net devices have send_redirects=1 by default.
Both the all and the device specific settings need to be turned off (=0)
to avoid sending ICMP redirects. That seems to be backed by the kernel
documentation [1]:
send_redirects - BOOLEAN
Send redirects, if router.
send_redirects for the interface will be enabled if at least one of
conf/{all,interface}/send_redirects is set to TRUE,
it will be disabled otherwise
Default: TRUE
>> FWIW, on Ubuntu, net.ipv4.conf.all.accept_redirects = 0 by default;
>> don't know on Debian though.
>
> On Debian this entry is commented in /etc/sysctl.conf. Anyone can
> remove # to disable it, but it seems this doesn't have any effect if
> it is enabled on specific net devices (ie. I get ICMP redirects from
> ovpn tap device). Could this be a bug in kernel?
A similar logic seems to apply to the accept_redirects too :
accept_redirects - BOOLEAN
Accept ICMP redirect messages.
accept_redirects for the interface will be enabled if:
- both conf/{all,interface}/accept_redirects are TRUE in the case
forwarding for the interface is enabled
or
- at least one of conf/{all,interface}/accept_redirects is TRUE
in the case forwarding for the interface is disabled
accept_redirects for the interface will be disabled otherwise
default TRUE (host)
FALSE (router)
My previous comment saying that Ubuntu was disabling accept_redirects by
default is probably wrong and I got confused by the fact that my boxes
are "routers".
[1]:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/networking/ip-sysctl.txt
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
