Federico Heinz wrote:
> * some other people agree that there is a use case, but propose
> different ways of approaching the problem through various
> mechanisms to resolve the interface name to an IP address before
> passing it on to OpenVPN. The disagreement here seems to be in
>
On 14/03/2011, Gert Doering wrote:
> > [...] Multiple openvpn daemons on different interfaces and
> > same port.
> That's one possible use case, but not how I understood Federico.
That's part of my use case, not all.
Please let me summarize what I've read in this discussion:
* some people are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/03/2011, David Sommerseth wrote:
> As Davide Brini already mentioned, I really wonder if this issue is
> due to lack of --multihome in your configuration, combined with
> listen on 0.0.0.0.
Thank you for restating Davide's answer, which I someho
Hi,
On Mon, Mar 14, 2011 at 12:16:20AM +0100, Peter Stuge wrote:
> > - or try to understand why this is needed in the first place :-) - I still
> > don't understand why not binding to anything + --multihome isn't working
>
> Third time: Multiple openvpn daemons on different interfaces and same
Gert Doering wrote:
> On Sun, Mar 13, 2011 at 05:04:21PM +0100, Peter Stuge wrote:
> > Was this for PPP? Sorry then, I completely overlooked that! I'm
> > fortunate to not have to deal with many PPP links now, but I have,
> > and pppd of course /etc/ppp/ip-up and -down where the same info about
> >
Hi,
On Sun, Mar 13, 2011 at 05:04:21PM +0100, Peter Stuge wrote:
> Was this for PPP? Sorry then, I completely overlooked that! I'm
> fortunate to not have to deal with many PPP links now, but I have,
> and pppd of course /etc/ppp/ip-up and -down where the same info about
> (de/re)config is availab
Gert Doering wrote:
> > Changing startup scripts or wrapping openvpn is one way. But I would
> > probably drive everything from the DHCP client instead.
>
> udhcp can notify components if the IP address of a PPP(!) interface
> changes?
>
> "No DHCP involved on PPP links".
Was this for PPP? Sorry
Hi,
On Sun, Mar 13, 2011 at 02:40:00AM +0100, Peter Stuge wrote:
> Changing startup scripts or wrapping openvpn is one way. But I would
> probably drive everything from the DHCP client instead.
>
> As I wrote, udhcpc is very very easy to deal with.
udhcp can notify components if the IP address o
Peter Stuge wrote:
> Your /usr/share/udhcpc/default.script to accomplish this would be:
>
> #!/bin/sh
> test "$1" = bound || exit 0
> sed -i "/^local /s/.*/local $ip/" /etc/openvpn/something/local.conf
> /etc/init.d/openvpn.something restart
>
>
> This covers initial config and reconfig. Zero di
Peter Stuge wrote:
> Changing startup scripts or wrapping openvpn is one way. But I
> would probably drive everything from the DHCP client instead.
>
> As I wrote, udhcpc is very very easy to deal with.
Your /usr/share/udhcpc/default.script to accomplish this would be:
#!/bin/sh
test "$1" = boun
Federico Heinz wrote:
> > > Because I don't know it at configuration time.
> >
> > You said that you already have a solution in place for dealing
> > with interface reconfiguration.
>
> I said I have a solution in place to restart OpenVPN when the
> configuration changes.
I understand. So there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/03/11 22:44, Federico Heinz wrote:
| On 12/03/2011, Peter Stuge wrote:
[...snip...]
|> [...] unless you are prepared to listen on 0.0.0.0, which I would
|> guess already works without special OpenVPN options or code.
|
| Only... it doesn't work
On 13/03/2011, Peter Stuge wrote:
> Federico Heinz wrote:
> > Because I don't know it at configuration time.
> You said that you already have a solution in place for dealing with
> interface reconfiguration.
I said I have a solution in place to restart OpenVPN when the
configuration changes. The s
Federico Heinz wrote:
> On 12/03/2011, Peter Stuge wrote:
> > Federico Heinz wrote:
> > > What I'm trying to solve here is a much simpler (and, in my case,
> > > frequent) use case: I'm starting several instances of OpenVPN,
> > > and I need each of them to listen on specific interfaces, but
> > >
On 12/03/2011, Peter Stuge wrote:
> Federico Heinz wrote:
> > What I'm trying to solve here is a much simpler (and, in my case,
> > frequent) use case: I'm starting several instances of OpenVPN,
> > and I need each of them to listen on specific interfaces, but
> > their dyndns addresses may not be
Federico Heinz wrote:
> What I'm trying to solve here is a much simpler (and, in my case,
> frequent) use case: I'm starting several instances of OpenVPN, and I
> need each of them to listen on specific interfaces, but their dyndns
> addresses may not be up-to date yet, so I can specify neither an
Joe Patterson wrote:
> I'm actually kind of curious what reasons there would be that
> listening to 0.0.0.0 would be undesireable.
..
> if you want to have different configurations bound to different
> interfaces,
Exactly.
> while I could possibly see having one configuration for Internet
> user
On 12/03/2011, Joe Patterson wrote:
> I'm all for adding flexibility, but this really seems like a
> solution to a problem for which there's hardly ever *not* a better
> work-around.
As I just mentioned in an answer to Peter, listening on 0.0.0.0
doesn't work reliably on my setup, please refer to
On 12/03/2011, Peter Stuge wrote:
> There are components in your system which *will* know when your
> address is reconfigured. Please just configure them to reconfigure
> OpenVPN. This would seem to be a good use for the management
> interface in OpenVPN.
I'm not worried abut the IP number *changi
I'm actually kind of curious what reasons there would be that
listening to 0.0.0.0 would be undesireable. For other daemons, I can
see a rationale because of two reasons, one being that you don't trust
the security of the daemon and want to add interface specificity to
your firewall rules for belt
Federico Heinz wrote:
> The reason I looked into this in the first place was that, unlike
> those TCP-based protocols, I couldn't get OpenVPN to work on a
> firewall with two external IP addresses without running two deamons,
> each one bound to one interface only. It is then that I stumbled upon
>
On Sat, 12 Mar 2011 00:35:17 -0300 Federico Heinz wrote:
> The reason I looked into this in the first place was that, unlike
> those TCP-based protocols, I couldn't get OpenVPN to work on a
> firewall with two external IP addresses without running two deamons,
> each one bound to one interface on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/2011, David Sommerseth wrote:
> Sorry that you haven't received any response quickly. Most of us
> here are having full time jobs which is not directly related to
> OpenVPN.
I'm sorry if I sounded like I felt that answers were slow in coming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 16:23, Federico Heinz wrote:
> I'm sorry, folks, I'd like to ask for some clarification.
>
> My patch was NAK'd on implementation issues. I offered alternatives
> to them. I got no answer to them.
>
> Should I bother implementing one of t
I'm sorry, folks, I'd like to ask for some clarification.
My patch was NAK'd on implementation issues. I offered alternatives
to them. I got no answer to them.
Should I bother implementing one of the alternatives, or will the
patch be disregarded nonetheless? If the patch does stand a chance to
b
On 09/03/2011, Markus Kötter wrote:
> David Sommerseth wrote:
> > One is that you do resolve the IP address based on the device
> > name. What if the IP address changes on that device? It would
> > be anticipated by most users that it would then listen to the new
> > IP address. When being done
Hi,
any reason this list does not send a proper reply-to-list?
David Sommerseth wrote:
One is that you do resolve the IP address based on the device name. What if
the IP address changes on that device? It would be anticipated by most users
that it would then listen to the new IP address. Whe
On 09/03/2011, Gert Doering wrote:
> I can understand why this feature is desirable - there are a couple
> of problems with the implementation, though.
> - From a code modularity point of view, socket stuff should not go
>to options.c, but to socket.c
I understand that with "socket stuff"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/2011, David Sommerseth wrote:
> Even though that shell trick isn't so obvious, I would say it
> solves exactly the same thing. It's not as pretty, but your patch
> does not give any extra advantages either.
It provides the only advantage it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/11 01:05, Federico Heinz wrote:
| On 09/03/2011, Alon Bar-Lev wrote:
|> I don't understand why it is needed.
|> You can always start openvpn and override configuration via
|> command-line.
|> So add --local "$(/sbin/ip addr show dev wlan0 | g
Hi,
On Tue, Mar 08, 2011 at 06:52:52PM -0300, Federico Heinz wrote:
> Accept "local if:" option.
I can understand why this feature is desirable - there are a couple of
problems with the implementation, though.
- From a code modularity point of view, socket stuff should not go
to options.c
On 09/03/2011, Alon Bar-Lev wrote:
> I don't understand why it is needed.
> You can always start openvpn and override configuration via
> command-line.
> So add --local "$(/sbin/ip addr show dev wlan0 | grep inet | sed
> 's#.*inet \(.*\)/.*#\1#')" parameter while starting it.
Sure: there's a huge
Hello,
I don't understand why it is needed.
You can always start openvpn and override configuration via command-line.
So add --local "$(/sbin/ip addr show dev wlan0 | grep inet | sed
's#.*inet \(.*\)/.*#\1#')" parameter while starting it.
A more generic approach can be adding $() support into op
Author: Federico Heinz
Accept "local if:" option.
The current 'local' configuration directive allows for two types of
values: IP addresses and DNS hostnames. This is not enough for users
of dynamic DNS services who must restart OpenVPN when their IP
address changes, because their new IP address
34 matches
Mail list logo
