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 whe
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 creat
Hi,
2012/2/21 Simon Deziel :
>> 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 atta
On 12-02-21 10:15 AM, Teodor MICU wrote:
> Hi,
>
> 2012/2/21 Simon Deziel :
>>> 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 hos
2012/2/21 Simon Deziel :
> 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
On Tue, Feb 21, 2012 at 05:36:16PM +0200, Teodor MICU wrote:
> 2012/2/21 Simon Deziel :
> > 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
On 12-02-21 10:36 AM, Teodor MICU wrote:
> 2012/2/21 Simon Deziel :
>> 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. Ev
2012/2/21 Alberto Gonzalez Iniesta :
> 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
On Tue, Feb 21, 2012 at 06:41:13PM +0200, Teodor MICU wrote:
> 2012/2/21 Alberto Gonzalez Iniesta :
> > 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 devic
On 12-02-21 11:41 AM, Teodor MICU wrote:
> 2012/2/21 Alberto Gonzalez Iniesta :
>> 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
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 sugges
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 upst
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 wit
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 i
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
2012/2/22 Simon Deziel :
> 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
On 12-02-22 08:38 AM, Teodor MICU wrote:
> 2012/2/22 Simon Deziel :
>> 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/im
2012/2/22 Simon Deziel :
> 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 w
On 12-02-23 10:53 AM, Teodor MICU wrote:
> 2012/2/22 Simon Deziel :
>> 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 ori
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 :
> >> 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
2012/2/23 Simon Deziel :
> 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 mayb
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/control
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
+
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 @@
$
25 matches
Mail list logo
