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
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)
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
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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?
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
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)
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
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
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
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 @@
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
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
+#
25 matches
Mail list logo
