Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
2012/2/22 Simon Deziel simon.dez...@gmail.com: On 12-02-22 08:38 AM, Teodor MICU wrote: I like this idea. However, I think you should change a few things: 1) default.send_redirects=0 and all.send_redirects=0 should be done only if necessary (is not 0) and the original value reverted back after the device was created Adding more logic would result in calling sysctl more times which is suboptimal IMHO unless there are some advantages I'm not aware of ? This is not about advantages but for keeping the previous configuration (default or explicitly set by the user). I saw you have the logic for one but not for both. That's why I though if you already have to get the current value why not check if =0 to avoid two sysctl call for each parameter. Thus, this would be more optimal. 2) I'm not sure the tunX is up when you revert the above changes (if necessary). Above is the call for start-stop-daemon but is there any guarantee that it will finish starting the oVPN service in time for the next command in the script? I haven't looked in the OpenVPN sources to confirm that the daemon forks after the tun creation but my tests showed no problem regarding this. The tun (dynamically or statically named) was always present right after the call to the daemon returned and the send_redirects setting was properly configured for it. This is good then. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-23 10:53 AM, Teodor MICU wrote:
2012/2/22 Simon Deziel simon.dez...@gmail.com:
On 12-02-22 08:38 AM, Teodor MICU wrote:
I like this idea. However, I think you should change a few things:
1) default.send_redirects=0 and all.send_redirects=0 should be done
only if necessary (is not 0) and the original value reverted back
after the device was created
Adding more logic would result in calling sysctl more times which is
suboptimal IMHO unless there are some advantages I'm not aware of ?
This is not about advantages but for keeping the previous
configuration (default or explicitly set by the user). I saw you have
the logic for one but not for both.
I'm not sure what you imply by both here so I maybe missing your
point. In the patch, 2 sysctl keys are altered: the default and the all
ones.
The default is only altered to allow the tun to derive its own
send_redirects based on the default one (that is to have it =0). Once
the tun is up, the default is restored to its original value so in
effect the user's setting is retained.
Now for the all key, this has to be =0 as otherwise the tun one wouldn't
have any effect.
That's why I though if you already have to get the current value why
not check if =0 to avoid two sysctl call for each parameter. Thus,
this would be more optimal.
OK, that would avoid uselessly calling sysctl -w to set/restore the
default key to its current value when it is already disabled.
You convinced me, your suggestion is cleaner. Here is the fixed patch
(which is now based on the Debian package as my previous ones were based
on the one from Lucid).
This was tested on OpenVPN 2.2.1-4 (Sid) and 2.1.0-1ubuntu1.1 (Lucid).
Thanks,
Simon
--- openvpn.orig 2012-02-08 08:32:48.0 -0500
+++ openvpn 2012-02-23 11:11:46.0 -0500
@@ -56,6 +56,25 @@
STATUSARG=--status /var/run/openvpn.$NAME.status $STATUSREFRESH
fi
+# tun using the subnet topology confuses the routing code that wrongly
+# emits ICMP redirects for client to client communications
+if grep -q '^[[:space:]]*dev[[:space:]]*tun' $CONFIG_DIR/$NAME.conf \
+ grep -q '^[[:space:]]*topology[[:space:]]*subnet' $CONFIG_DIR/$NAME.conf ; then
+# When using client-to-client, OpenVPN routes the traffic itself without
+# involving the TUN/TAP interface so no ICMP redirects are sent
+if ! grep -q '^[[:space:]]*client-to-client' $CONFIG_DIR/$NAME.conf ; then
+sysctl -w net.ipv4.conf.all.send_redirects=0 /dev/null
+
+# Save the default value for send_redirects before disabling it
+# to make sure the tun device is created with send_redirects disabled
+SAVED_DEFAULT_SEND_REDIRECTS=$(sysctl -n net.ipv4.conf.default.send_redirects)
+
+if [ $SAVED_DEFAULT_SEND_REDIRECTS -ne 0 ]; then
+ sysctl -w net.ipv4.conf.default.send_redirects=0 /dev/null
+fi
+fi
+fi
+
log_progress_msg $NAME
STATUS=0
@@ -66,6 +85,11 @@
--config $CONFIG_DIR/$NAME.conf || STATUS=1
[ $OMIT_SENDSIGS -ne 1 ] || ln -s /var/run/openvpn.$NAME.pid /run/sendsigs.omit.d/openvpn.$NAME.pid
+
+# Set the back the original default value of send_redirects if it was changed
+if [ $SAVED_DEFAULT_SEND_REDIRECTS -ne 0 ]; then
+ sysctl -w net.ipv4.conf.default.send_redirects=$SAVED_DEFAULT_SEND_REDIRECTS /dev/null
+fi
}
stop_vpn () {
kill `cat $PIDFILE` || true
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Thu, Feb 23, 2012 at 11:23:07AM -0500, Simon Deziel wrote: On 12-02-23 10:53 AM, Teodor MICU wrote: 2012/2/22 Simon Deziel simon.dez...@gmail.com: On 12-02-22 08:38 AM, Teodor MICU wrote: I like this idea. However, I think you should change a few things: 1) default.send_redirects=0 and all.send_redirects=0 should be done only if necessary (is not 0) and the original value reverted back after the device was created Adding more logic would result in calling sysctl more times which is suboptimal IMHO unless there are some advantages I'm not aware of ? This is not about advantages but for keeping the previous configuration (default or explicitly set by the user). I saw you have the logic for one but not for both. I'm not sure what you imply by both here so I maybe missing your point. In the patch, 2 sysctl keys are altered: the default and the all ones. The default is only altered to allow the tun to derive its own send_redirects based on the default one (that is to have it =0). Once the tun is up, the default is restored to its original value so in effect the user's setting is retained. Now for the all key, this has to be =0 as otherwise the tun one wouldn't have any effect. That's why I though if you already have to get the current value why not check if =0 to avoid two sysctl call for each parameter. Thus, this would be more optimal. OK, that would avoid uselessly calling sysctl -w to set/restore the default key to its current value when it is already disabled. You convinced me, your suggestion is cleaner. Here is the fixed patch (which is now based on the Debian package as my previous ones were based on the one from Lucid). Nice! If we all agree in -try5.diff, I'll apply it and upload the package with the fix. Thanks both! -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
2012/2/23 Simon Deziel simon.dez...@gmail.com: On 12-02-23 10:53 AM, Teodor MICU wrote: This is not about advantages but for keeping the previous configuration (default or explicitly set by the user). I saw you have the logic for one but not for both. I'm not sure what you imply by both here so I maybe missing your point. In the patch, 2 sysctl keys are altered: the default and the all ones. both: net.ipv4.conf.all.send_redirects, net.ipv4.conf.default.send_redirects The default is only altered to allow the tun to derive its own send_redirects based on the default one (that is to have it =0). Once the tun is up, the default is restored to its original value so in effect the user's setting is retained. Now for the all key, this has to be =0 as otherwise the tun one wouldn't have any effect. I think I understand what you're trying to do now. You want net.ipv4.conf.all.send_redirects to remain disabled and to be actively disabled by every execution of oVPN init script. That's why I though if you already have to get the current value why not check if =0 to avoid two sysctl call for each parameter. Thus, this would be more optimal. OK, that would avoid uselessly calling sysctl -w to set/restore the default key to its current value when it is already disabled. You convinced me, your suggestion is cleaner. Here is the fixed patch (which is now based on the Debian package as my previous ones were based on the one from Lucid). This was tested on OpenVPN 2.2.1-4 (Sid) and 2.1.0-1ubuntu1.1 (Lucid). The implementation appears correct with the desired action. However, this would require at least a note on README.Debian and preferably a NEWS entry to warn users that openvpn actively disables all.send_redirects on configurations with tun + topology subnet. I think that all.send_redirects should be disabled by default. But this is not the case nor in Debian nor in Ubuntu. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Tue, Feb 21, 2012 at 07:49:58PM -0500, Simon Deziel wrote: 1) Set net.ipv4.conf.all.send_redirects = 0 2) Save net.ipv4.conf.default.send_redirects value 3) Set net.ipv4.conf.default.send_redirects = 0 4) Call the daemon to create the tun 5) Restore net.ipv4.conf.default.send_redirects initial value Is this better ? Sounds good :-) Could you try it, please? I don't have a setup with that issue right now. This new patch implements the above pseudo code and rely only on sysctl for kfreebsd compatibility. I tested it with dynamically and statically named tun devices. Please let me know if something should be reworked/improved. Hi Simon, Looks beautiful, thanks a lot for your work on this. I'll apply it on my next upload. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
2012/2/22 Simon Deziel simon.dez...@gmail.com: This new patch implements the above pseudo code and rely only on sysctl for kfreebsd compatibility. I tested it with dynamically and statically named tun devices. Please let me know if something should be reworked/improved. I like this idea. However, I think you should change a few things: 1) default.send_redirects=0 and all.send_redirects=0 should be done only if necessary (is not 0) and the original value reverted back after the device was created 2) I'm not sure the tunX is up when you revert the above changes (if necessary). Above is the call for start-stop-daemon but is there any guarantee that it will finish starting the oVPN service in time for the next command in the script? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-22 08:38 AM, Teodor MICU wrote: 2012/2/22 Simon Deziel simon.dez...@gmail.com: This new patch implements the above pseudo code and rely only on sysctl for kfreebsd compatibility. I tested it with dynamically and statically named tun devices. Please let me know if something should be reworked/improved. I like this idea. However, I think you should change a few things: 1) default.send_redirects=0 and all.send_redirects=0 should be done only if necessary (is not 0) and the original value reverted back after the device was created Adding more logic would result in calling sysctl more times which is suboptimal IMHO unless there are some advantages I'm not aware of ? 2) I'm not sure the tunX is up when you revert the above changes (if necessary). Above is the call for start-stop-daemon but is there any guarantee that it will finish starting the oVPN service in time for the next command in the script? I haven't looked in the OpenVPN sources to confirm that the daemon forks after the tun creation but my tests showed no problem regarding this. The tun (dynamically or statically named) was always present right after the call to the daemon returned and the send_redirects setting was properly configured for it. Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Mon, Jan 30, 2012 at 12:13:35PM -0500, Simon Deziel wrote: Tag: patch Here is an improved patch that only touches the proc files associated with the tun device after the daemon was launched as the tun can be dynamically created. Hi Simon, Thanks for the patch. I was reviewing it when a couple of questions arose: What happens if the .conf contains dev tun instead of dev tunX? +TUN_DEVNAME=$(sed -n 's/^[[:space:]]*dev[[:space:]]*\(tun.*\)$/\1/p' $CONFIG_DIR/$NAME.conf) +echo 0 /proc/sys/net/ipv4/conf/$TUN_DEVNAME/send_redirects It looks like that echo would fail since /proc/sys/net/ipv4/conf/tun/send_redirects does not exist. Is this line really necessary?? +echo 0 /proc/sys/net/ipv4/conf/all/send_redirects Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 05:41 AM, Alberto Gonzalez Iniesta wrote: On Mon, Jan 30, 2012 at 12:13:35PM -0500, Simon Deziel wrote: Tag: patch Here is an improved patch that only touches the proc files associated with the tun device after the daemon was launched as the tun can be dynamically created. Hi Simon, Hi Alberto, Thanks for the patch. I was reviewing it when a couple of questions arose: Thanks for the review. What happens if the .conf contains dev tun instead of dev tunX? Hmm, that would fail to find the dynamically allocated tun device number. I'm not sure how to handle this (probably frequent) use case. Maybe I could disable ICMP redirects on the tun that was created last based on proc file timestamps of all tun devices ? Do you have a better idea ? +TUN_DEVNAME=$(sed -n 's/^[[:space:]]*dev[[:space:]]*\(tun.*\)$/\1/p' $CONFIG_DIR/$NAME.conf) +echo 0 /proc/sys/net/ipv4/conf/$TUN_DEVNAME/send_redirects It looks like that echo would fail since /proc/sys/net/ipv4/conf/tun/send_redirects does not exist. This was indeed the problem in my first patch submission. The new version of the patch in message #15 moved that block after the daemon invocation. Is this line really necessary?? +echo 0 /proc/sys/net/ipv4/conf/all/send_redirects Yes that is required, even if that sounds odd to me too. Thanks for the feedback and your work on OpenVPN. Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
Hi, 2012/2/21 Simon Deziel simon.dez...@gmail.com: Is this line really necessary?? + echo 0 /proc/sys/net/ipv4/conf/all/send_redirects Yes that is required, even if that sounds odd to me too. I usually disable all redirects on all Linux hosts. | # Do not accept ICMP redirects (prevent MITM attacks) | net.ipv4.conf.all.accept_redirects = 0 | # Do not send ICMP redirects (we are not a router) | net.ipv4.conf.all.send_redirects = 0 This is a grave bug to enable all ICMP redirects unconditionally. I would probably understand the need to be enabled *only* on tun/tap devices managed by OpenVPN but for a good technical reason. Care to explain more? Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 10:15 AM, Teodor MICU wrote: Hi, 2012/2/21 Simon Deziel simon.dez...@gmail.com: Is this line really necessary?? +echo 0 /proc/sys/net/ipv4/conf/all/send_redirects Yes that is required, even if that sounds odd to me too. I usually disable all redirects on all Linux hosts. | # Do not accept ICMP redirects (prevent MITM attacks) | net.ipv4.conf.all.accept_redirects = 0 | # Do not send ICMP redirects (we are not a router) | net.ipv4.conf.all.send_redirects = 0 This is a grave bug to enable all ICMP redirects unconditionally. I would probably understand the need to be enabled *only* on tun/tap devices managed by OpenVPN but for a good technical reason. Care to explain more? 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. FWIW, on Ubuntu, net.ipv4.conf.all.accept_redirects = 0 by default; don't know on Debian though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
2012/2/21 Simon Deziel simon.dez...@gmail.com: 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. 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? Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Tue, Feb 21, 2012 at 05:36:16PM +0200, Teodor MICU wrote: 2012/2/21 Simon Deziel simon.dez...@gmail.com: 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. 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? I think I read both conf.all.accept_redirects AND conf.DEV.accept_redirects have to be switched off, didn't try it myself yet. Anyway, what worries me now is that case where dev tun is specified instead of dev tunX, and how to deal with that in the new code proposed. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 10:36 AM, Teodor MICU wrote:
2012/2/21 Simon Deziel simon.dez...@gmail.com:
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 debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
2012/2/21 Alberto Gonzalez Iniesta a...@inittab.org: Anyway, what worries me now is that case where dev tun is specified instead of dev tunX, and how to deal with that in the new code proposed. Is there a way to find the tunX device assigned by ovpn? Also, even if you knew it I think that at the time of the init.d script execution the device does *not* exist and your attempt to disable send_redirects (which should be done via sysctl not via echo 0) will fail. This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Tue, Feb 21, 2012 at 06:41:13PM +0200, Teodor MICU wrote: 2012/2/21 Alberto Gonzalez Iniesta a...@inittab.org: Anyway, what worries me now is that case where dev tun is specified instead of dev tunX, and how to deal with that in the new code proposed. Is there a way to find the tunX device assigned by ovpn? Also, even if you knew it I think that at the time of the init.d script execution the device does *not* exist and your attempt to disable send_redirects (which should be done via sysctl not via echo 0) will fail. Yes, you're right. This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Yep, I guess that's the best way to go. Plus the init.d script also runs on kfreebsd and I'd rather not have Linux specific code on it. THanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 11:41 AM, Teodor MICU wrote: 2012/2/21 Alberto Gonzalez Iniesta a...@inittab.org: Anyway, what worries me now is that case where dev tun is specified instead of dev tunX, and how to deal with that in the new code proposed. Is there a way to find the tunX device assigned by ovpn? In message #25, I proposed to check the alter the settings of the tun device that was created last as based on proc file timestamps. Not sure that's the best idea so I'm open to suggestions. Also, even if you knew it I think that at the time of the init.d script execution the device does *not* exist and your attempt to disable send_redirects The second patch I submitted corrected this behavior by calling the echo after the daemon. (which should be done via sysctl not via echo 0) will fail. sysctl also needs the device to be created : # sysctl -w net.ipv4.conf.tun0.send_redirects=0 error: net.ipv4.conf.tun0.send_redirects is an unknown key Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 11:41 AM, Teodor MICU wrote: This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Upstream (EugeneKay on #openvpn) expressed that they were not inclined to make those changes. They suggest to filter those bogus ICMP redirects at the firewall level. IMHO, avoiding the generation of those bogus ICMP redirects is cleaner and I still think the init script should take care of this. @Alberto, may I ask your opinion on this one ? Thanks, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Tue, Feb 21, 2012 at 01:46:51PM -0500, Simon Deziel wrote: On 12-02-21 11:41 AM, Teodor MICU wrote: This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Upstream (EugeneKay on #openvpn) expressed that they were not inclined to make those changes. They suggest to filter those bogus ICMP redirects at the firewall level. IMHO, avoiding the generation of those bogus ICMP redirects is cleaner and I still think the init script should take care of this. @Alberto, may I ask your opinion on this one ? Hi, I'd like to give this a second thought (kfreebsd compatibility worries me too) How about suggesting (i.e. in README.Debian) inserting that piece of shell you sent in up scripts for those people using tun + subnet? May be including it as /usr/share/openvpn/examples/avoid_redirects.sh so people could just source it in their up script? Thanks both of you for your interest! Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 01:57 PM, Alberto Gonzalez Iniesta wrote: On Tue, Feb 21, 2012 at 01:46:51PM -0500, Simon Deziel wrote: On 12-02-21 11:41 AM, Teodor MICU wrote: This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Upstream (EugeneKay on #openvpn) expressed that they were not inclined to make those changes. They suggest to filter those bogus ICMP redirects at the firewall level. IMHO, avoiding the generation of those bogus ICMP redirects is cleaner and I still think the init script should take care of this. @Alberto, may I ask your opinion on this one ? Hi, I'd like to give this a second thought (kfreebsd compatibility worries me too) I'm also for portability and wouldn't mind using sysctl instead of relying on proc files. I think the following procedure relying on sysctl would provide effectively turn off redirects for dynamically and statically created tun devices : 1) Set net.ipv4.conf.all.send_redirects = 0 2) Save net.ipv4.conf.default.send_redirects value 3) Set net.ipv4.conf.default.send_redirects = 0 4) Call the daemon to create the tun 5) Restore net.ipv4.conf.default.send_redirects initial value Is this better ? How about suggesting (i.e. in README.Debian) inserting that piece of shell you sent in up scripts for those people using tun + subnet? May be including it as /usr/share/openvpn/examples/avoid_redirects.sh so people could just source it in their up script? All my VPNs run with uid != root and are also chroot'ed so an up script is not going to help. Adding it to the documentation would be a good idea if the init script approach is not retained. Thanks both of you for your interest! I appreciate both of your input too, thanks Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On Tue, Feb 21, 2012 at 02:23:19PM -0500, Simon Deziel wrote: On 12-02-21 01:57 PM, Alberto Gonzalez Iniesta wrote: On Tue, Feb 21, 2012 at 01:46:51PM -0500, Simon Deziel wrote: On 12-02-21 11:41 AM, Teodor MICU wrote: This is a hack anyway. How about dealing with this properly with some code in OpenVPN? If I were you I would propose this to upstream developers. Upstream (EugeneKay on #openvpn) expressed that they were not inclined to make those changes. They suggest to filter those bogus ICMP redirects at the firewall level. IMHO, avoiding the generation of those bogus ICMP redirects is cleaner and I still think the init script should take care of this. @Alberto, may I ask your opinion on this one ? Hi, I'd like to give this a second thought (kfreebsd compatibility worries me too) I'm also for portability and wouldn't mind using sysctl instead of relying on proc files. I think the following procedure relying on sysctl would provide effectively turn off redirects for dynamically and statically created tun devices : 1) Set net.ipv4.conf.all.send_redirects = 0 2) Save net.ipv4.conf.default.send_redirects value 3) Set net.ipv4.conf.default.send_redirects = 0 4) Call the daemon to create the tun 5) Restore net.ipv4.conf.default.send_redirects initial value Is this better ? Sounds good :-) Could you try it, please? I don't have a setup with that issue right now. How about suggesting (i.e. in README.Debian) inserting that piece of shell you sent in up scripts for those people using tun + subnet? May be including it as /usr/share/openvpn/examples/avoid_redirects.sh so people could just source it in their up script? All my VPNs run with uid != root and are also chroot'ed so an up script is not going to help. ACK Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
On 12-02-21 02:44 PM, Alberto Gonzalez Iniesta wrote:
On Tue, Feb 21, 2012 at 02:23:19PM -0500, Simon Deziel wrote:
On 12-02-21 01:57 PM, Alberto Gonzalez Iniesta wrote:
On Tue, Feb 21, 2012 at 01:46:51PM -0500, Simon Deziel wrote:
On 12-02-21 11:41 AM, Teodor MICU wrote:
This is a hack anyway. How about dealing with this properly with some
code in OpenVPN? If I were you I would propose this to upstream
developers.
Upstream (EugeneKay on #openvpn) expressed that they were not inclined
to make those changes. They suggest to filter those bogus ICMP redirects
at the firewall level. IMHO, avoiding the generation of those bogus ICMP
redirects is cleaner and I still think the init script should take care
of this.
@Alberto, may I ask your opinion on this one ?
Hi,
I'd like to give this a second thought (kfreebsd compatibility worries
me too)
I'm also for portability and wouldn't mind using sysctl instead of
relying on proc files. I think the following procedure relying on sysctl
would provide effectively turn off redirects for dynamically and
statically created tun devices :
1) Set net.ipv4.conf.all.send_redirects = 0
2) Save net.ipv4.conf.default.send_redirects value
3) Set net.ipv4.conf.default.send_redirects = 0
4) Call the daemon to create the tun
5) Restore net.ipv4.conf.default.send_redirects initial value
Is this better ?
Sounds good :-)
Could you try it, please? I don't have a setup with that issue right now.
This new patch implements the above pseudo code and rely only on sysctl
for kfreebsd compatibility. I tested it with dynamically and statically
named tun devices.
Please let me know if something should be reworked/improved.
Thanks,
Simon
--- openvpn.orig 2011-12-22 09:44:03.049246165 -0500
+++ openvpn 2012-02-21 19:39:38.778032728 -0500
@@ -57,6 +57,22 @@
script_security=--script-security 2
fi
+# tun using the subnet topology confuses the routing code that wrongly
+# emits ICMP redirects for client to client communications
+if grep -q '^[[:space:]]*dev[[:space:]]*tun' $CONFIG_DIR/$NAME.conf \
+ grep -q '^[[:space:]]*topology[[:space:]]*subnet' $CONFIG_DIR/$NAME.conf ; then
+# When using client-to-client, OpenVPN routes the traffic itself without
+# involving the TUN/TAP interface so no ICMP redirects are sent
+if ! grep -q '^[[:space:]]*client-to-client' $CONFIG_DIR/$NAME.conf ; then
+sysctl -w net.ipv4.conf.all.send_redirects=0 /dev/null
+
+# Save the default value for send_redirects before disabling it
+# to make sure the tun device is created with send_redirects disabled
+SAVED_DEFAULT_SEND_REDIRECTS=$(sysctl -n net.ipv4.conf.default.send_redirects)
+sysctl -w net.ipv4.conf.default.send_redirects=0 /dev/null
+fi
+fi
+
STATUS=0
# Check to see if it's already started...
if test -e /var/run/openvpn.$NAME.pid ; then
@@ -66,6 +82,12 @@
$DAEMONARG $STATUSARG --cd $CONFIG_DIR \
--config $CONFIG_DIR/$NAME.conf $script_security /dev/null || STATUS=1
fi
+
+# Set the back the original default value of send_redirects if it was changed
+if [ -n $SAVED_DEFAULT_SEND_REDIRECTS ]; then
+ sysctl -w net.ipv4.conf.default.send_redirects=$SAVED_DEFAULT_SEND_REDIRECTS /dev/null
+fi
+
log_end_msg $STATUS
}
stop_vpn () {
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly, sending ICMP redirects
Tag: patch
Here is an improved patch that only touches the proc files associated
with the tun device after the daemon was launched as the tun can be
dynamically created.
--- openvpn.orig 2012-01-30 11:13:09.993833020 -0500
+++ openvpn 2012-01-30 11:13:22.017832758 -0500
@@ -70,6 +70,19 @@
$DAEMONARG $STATUSARG --cd $CONFIG_DIR \
--config $CONFIG_DIR/$NAME.conf $script_security /dev/null || STATUS=1
fi
+
+# tun using the subnet topology confuses the routing code that wrongly
+# emits ICMP redirects for client to client communications
+TUN_DEVNAME=$(sed -n 's/^[[:space:]]*dev[[:space:]]*\(tun.*\)$/\1/p' $CONFIG_DIR/$NAME.conf)
+if test -n $TUN_DEVNAME grep -q '^[[:space:]]*topology[[:space:]]*subnet' $CONFIG_DIR/$NAME.conf; then
+# When using client-to-client, OpenVPN routes the traffic itself without
+# involving the TUN/TAP interface so no ICMP redirects are sent
+if ! grep -q '^[[:space:]]*client-to-client' $CONFIG_DIR/$NAME.conf ; then
+echo 0 /proc/sys/net/ipv4/conf/all/send_redirects
+echo 0 /proc/sys/net/ipv4/conf/$TUN_DEVNAME/send_redirects
+ fi
+fi
+
log_end_msg $STATUS
}
stop_vpn () {
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly sending ICMP redirects
Package: openvpn Version: 2.2.0-2ubuntu1 Severity: normal When a tun-based VPN is using the subnet topology, the communication between clients can confuse the routing code that will wrongly emit ICMP redirects. This problem is very well described here http://backreference.org/2010/05/02/controlling-client-to-client-connections-in-openvpn/. The same link also provides the workaround (disable ICMP redirect on the TUN device). The orignal bug report was done in Ubuntu's LP and a bzr branch with a fix was also added : https://bugs.launchpad.net/ubuntu/oneiric/+source/openvpn/+bug/907828 -- System Information: Debian Release: wheezy/sid APT prefers oneiric-updates APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 'oneiric-proposed'), (500, 'oneiric') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-15-generic (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openvpn depends on: ii debconf [debconf-2.0] 1.5.40ubuntu1Debian configuration management sy ii libc6 2.13-20ubuntu5 Embedded GNU C Library: Shared lib ii liblzo2-2 2.05-1 data compression library ii libpam0g1.1.3-2ubuntu2.1 Pluggable Authentication Modules l ii libpkcs11-helper1 1.08-1build1 library that simplifies the intera ii libssl1.0.0 1.0.0e-2ubuntu4 SSL shared libraries ii lsb-base4.0-0ubuntu16Linux Standard Base 4.0 init scrip ii net-tools 1.60-23ubuntu3 The NET-3 networking toolkit openvpn recommends no packages. Versions of packages openvpn suggests: ii openssl 1.0.0e-2ubuntu4 Secure Socket Layer (SSL) binary a pn resolvconf none (no description available) -- Configuration Files: /etc/default/openvpn changed [not included] -- debconf information: openvpn/create_tun: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656241: openvpn: tun-based VPNs using the subnet topology are wrongly sending ICMP redirects
Tag: patch The attached patch prevents sending ICMP redirects on tun devices when the subnet topology is used. --- debian/openvpn.init.d 2011-06-09 18:02:14 + +++ debian/openvpn.init.d 2011-12-22 17:29:48 + @@ -61,6 +61,18 @@ script_security=--script-security 2 fi +# the subnet topology (tun only) confuses the routing code that wrongly +# emits ICMP redirects for client to client communications +TUN_DEVNAME=$(sed -n 's/^[[:space:]]*dev[[:space:]]*\(tun.*\)$/\1/p' $CONFIG_DIR/$NAME.conf) +if test -n $TUN_DEVNAME grep -q '^[[:space:]]*topology[[:space:]]*subnet' $CONFIG_DIR/$NAME.conf; then +# When using client-to-client, OpenVPN routes the traffic itself without +# involving the TUN/TAP interface so no ICMP redirects are sent +if ! grep -q '^[[:space:]]*client-to-client' $CONFIG_DIR/$NAME.conf ; then +echo 0 /proc/sys/net/ipv4/conf/all/send_redirects +echo 0 /proc/sys/net/ipv4/conf/$TUN_DEVNAME/send_redirects +fi +fi + STATUS=0 # Check to see if it's already started... if test -e /var/run/openvpn.$NAME.pid ; then
