Re: [Openvpn-devel] OpenVPN documentation (man page) review
>> * Move the man page to a better format than the pure man page format. >> Are there some good tools/formats like ascii2man or DocBookXML which >> could help easing the maintenance of our documentation? > Docbook XML for sure is a lot more verbose than asciidoc or roff. > I would tend to avoid Docbook, the toolchains are lacking a bit -- > still :-( although xmlto + fop can yield reasonable PDF results. I'd recommend Texinfo: its man output is not too bad (especially if you write the Texinfo with "man" in your mind), it can be turned into many other formats (including Docbook) and it's not verbose. Stefan
Re: [Openvpn-devel] Fwd: Re: [Openvpn-users] behavior of remote address with more than one A record
> You can test this by making sure the TTL is set low enough on your server > records (say 60 seconds), make sure that your client will do a new DNS > lookup with the proper TTL (you can check this with 'dig'). Then connect > to your server and break the connection after one minute and then > reconnect. In this case, if the DNS server does the job properly, it would > now give your second server - which OpenVPN should use. But this is about load-balancing, whereas the OP's issue is with fail-over. If the TTL is not low enough then the fail-over will not happen (OpenVPN will keep trying to connect to same first host in the list). It seems that for fail-over, OpenVPN should do a single DNS request and then cycle though the list of hosts it received. Stefan
Re: [Openvpn-devel] [PATCH] Added whitespace handling for $KEY_CONFIG variable in easy-rsa/2.0/vars
> There shouldn't be a difference, I did quite a bit of Googling just to > be sure. For example, the Dash shell seems to be used often as > POSIX-compliance reference implementation. From POSIX mandates $() so any posix shell will support it. The issue is with non-POSIX shells, if you do want to support them (e.g. Solaris's /bin/sh). Stefan
Re: [Openvpn-devel] [PATCH] Added whitespace handling for $KEY_CONFIG variable in easy-rsa/2.0/vars
> ACK! That makes sense to me. But it needs to be clearly visible in some > kind of requirements list. If we don't have that, that's probably > something we should have. You could even start your shell scripts with something like: test "x$(pwd)" = "x`pwd`" || (echo "This shell is not good enough"; exit 1) Stefan
[Openvpn-devel] FQDN for routes should expand to all IPs
I've posted a bug report at: http://sourceforge.net/tracker/index.php?func=detail&aid=2872760&group_id=48978&atid=454719 since since I haven't heard any reaction for almost 2 weeks now (although the report includes a patch which works well, at least for me), I'm wondering whether it was the right place. Should I send my patches here instead? Stefan
Re: [Openvpn-devel] FQDN for routes should expand to all IPs
Ping? Stefan >>>>> "Stefan" == Stefan Monnier writes: > I've posted a bug report at: > http://sourceforge.net/tracker/index.php?func=detail&aid=2872760&group_id=48978&atid=454719 > since since I haven't heard any reaction for almost 2 weeks now > (although the report includes a patch which works well, at least for > me), I'm wondering whether it was the right place. Should I send my > patches here instead? > Stefan > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference
Re: [Openvpn-devel] FQDN for routes should expand to all IPs
> This is the right place to submit bug reports. Thanks. > Having said that, your bug report seems more like a feature request since > routing commands/APIs generally do not support DNS A-record expansion > as a standard feature. I understand that it's halfway between feature request and bugreport. The current code does explicitly allow FQDN in route commands and its implementation just happens to choose one (randomly) one IP rather than to select all of them. This basically means that such route commands only work reliably for FQDNs that have only one IP. This is a restriction that iseems to come just from the implementation rather than from a design choice: the FQDN-to-IP mapping is done by reusing the code used elsewhere, but that "elsewhere" is when we want to connect to that FQDN, so in that case selecting all IPs is nonsenscal and we need to choose one (tho we may want to cycle in case of connection failure). So I do think it's a bug, but I understand that it can be considered as a feature to extend route commands to support multiple-IP FQDNs. In either case, I'd love to hear comments about my patch (and even more so to have it be included, since I rely heavily on this feature). > It's an interesting idea though, and one that makes sense, but I haven't > seen any other requests for it. I use it for example to let clients connect to portal.acm.org (which has 2 IPs) via the VPN so as to benefit from the site-wide digital-library access we have. Without this feature, either the redirection works unreliably (half the times, the connection is done via the VPN the other half it's done directly), or I'd have to redirect all traffic (causing a significant load increase on the VPN server, increase of bandwidth use, and general slowdown for the clients), or hard-code the IPs and try and detect when they change. Stefan
Re: [Openvpn-devel] OpenVPN 2.1_rc22 released
> 2009.11.20 -- Version 2.1_rc22
Thanks.
For those like me who need to use routing commands with hostnames mapped
to more than a single IP, here's an updated patch. IIUC the previous
patch should still apply, tho with some offsets.
Stefan
Index: route.c
===
--- route.c (révision 5180)
+++ route.c (copie de travail)
@@ -217,34 +217,39 @@
return false;
}
-static bool
+struct route *
init_route (struct route *r,
+ struct route *last_route,
const struct route_option *ro,
const struct route_special_addr *spec)
{
const in_addr_t default_netmask = ~0;
bool status;
+ int nb = -1;
+ in_addr_t nets[MAX_IPS_PER_HOSTNAME];
+ in_addr_t netmask, gateway;
+ bool metric_defined;
+ int metric;
- r->option = ro;
- r->defined = false;
-
/* network */
if (!is_route_parm_defined (ro->network))
{
goto fail;
}
-
- if (!get_special_addr (spec, ro->network, &r->network, &status))
+
+ if (get_special_addr (spec, ro->network, &nets[0], &status))
+nb = 1;
+ else
{
- r->network = getaddr (
- GETADDR_RESOLVE
- | GETADDR_HOST_ORDER
- | GETADDR_WARN_ON_SIGNAL,
- ro->network,
- 0,
- &status,
- NULL);
+ nb = getaddr_all (GETADDR_RESOLVE
+ | GETADDR_HOST_ORDER
+ | GETADDR_WARN_ON_SIGNAL,
+ nets, MAX_IPS_PER_HOSTNAME,
+ ro->network,
+ 0,
+ NULL);
+ status = (nb >= 0);
}
if (!status)
@@ -254,33 +259,33 @@
if (is_route_parm_defined (ro->netmask))
{
- r->netmask = getaddr (
- GETADDR_HOST_ORDER
- | GETADDR_WARN_ON_SIGNAL,
- ro->netmask,
- 0,
- &status,
- NULL);
+ netmask = getaddr (
+GETADDR_HOST_ORDER
+| GETADDR_WARN_ON_SIGNAL,
+ro->netmask,
+0,
+&status,
+NULL);
if (!status)
goto fail;
}
else
-r->netmask = default_netmask;
+netmask = default_netmask;
/* gateway */
-
+
if (is_route_parm_defined (ro->gateway))
{
- if (!get_special_addr (spec, ro->gateway, &r->gateway, &status))
+ if (!get_special_addr (spec, ro->gateway, &gateway, &status))
{
- r->gateway = getaddr (
- GETADDR_RESOLVE
- | GETADDR_HOST_ORDER
- | GETADDR_WARN_ON_SIGNAL,
- ro->gateway,
- 0,
- &status,
- NULL);
+ gateway = getaddr (
+GETADDR_RESOLVE
+| GETADDR_HOST_ORDER
+| GETADDR_WARN_ON_SIGNAL,
+ro->gateway,
+0,
+&status,
+NULL);
}
if (!status)
goto fail;
@@ -288,7 +293,7 @@
else
{
if (spec->remote_endpoint_defined)
- r->gateway = spec->remote_endpoint;
+ gateway = spec->remote_endpoint;
else
{
msg (M_WARN, PACKAGE_NAME " ROUTE: " PACKAGE_NAME " needs a gateway
parameter for a --route option and no default was specified by either
--route-gateway or --ifconfig options");
@@ -298,35 +303,54 @@
/* metric */
- r->metric_defined = false;
- r->metric = 0;
+ metric_defined = false;
+ metric = 0;
if (is_route_parm_defined (ro->metric))
{
- r->metric = atoi (ro->metric);
- if (r->metric < 0)
+ metric = atoi (ro->metric);
+ if (metric < 0)
{
msg (M_WARN, PACKAGE_NAME " ROUTE: route metric for network %s (%s)
must be >= 0",
ro->network,
ro->metric);
goto fail;
}
- r->metric_defined = true;
+ metric_defined = true;
}
else if (spec->default_metric_defined)
{
- r->metric = spec->default_metric;
- r->metric_defined = true;
+ metric = spec->default_metric;
+ metric_defined = true;
}
- r->defined = true;
+ /* Now fill the corresponding route entries. */
- return true;
+ if (netmask != default_netmask && nb > 1)
+/* If we add individual hosts, then every IP of that host is added,
+ but if we add a whole subnet, then only consider the first IP,
+ presuming that all the IPs are in the same subnet. */
+nb = 1;
+ /* Add a route for each one of t
Re: [Openvpn-devel] OpenVPN project organization
> One the one hand people expect OpenVPN to be rock-solid in both > stability and security. In order to maintain this standard of quality, > there needs to be a rigorous process of patch vetting. On the other > hand, as an open source project, OpenVPN needs to be transparent and > open to contributions from the community. That misses the main issue: you can reject most patches on some stability ground, but then as a contributor I'd like to know how to improve my patch to make it acceptable. E.g. my "fqdn route with fqdn's that map to multiple IPs" patch (which I consider to be a bug-fix rather than a feature addition) has been somewhat discussed but only w.r.t the functionality, not the actual code, so I have no idea what I need to do in order to have it be accepted. This is frustrating. This said, as a maintainer of a Free Software package, I am quite aware that giving responding to all contributions (let alone giving good feedback) can be challenging. Stefan
[Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
[ I've sent this in the past already, but just trying to make sure it
doesn't get lost somewhere. ]
When specifiying an FQDN for the network part of a route, OpenVPN should
setup a route for each IP associated with that FQDN. Currently, it just
chooses one of the IPs at random instead, which leads to inconsistent
and unpredictable behavior since subsequent connections to that FQDN will
sometimes go through the VPN and sometimes not.
The patch below works for me, and I'd welcome any help in bringing it to
a state where it can be included in the mainline code. It was made
against the openvpn-testing/master code.
Stefan
diff --git a/route.c b/route.c
index 24d4bd8..396a20b 100644
--- a/route.c
+++ b/route.c
@@ -217,16 +217,19 @@ is_special_addr (const char *addr_str)
return false;
}
-static bool
+struct route *
init_route (struct route *r,
+ struct route *last_route,
const struct route_option *ro,
const struct route_special_addr *spec)
{
const in_addr_t default_netmask = ~0;
bool status;
-
- r->option = ro;
- r->defined = false;
+ int nb = -1;
+ in_addr_t nets[MAX_IPS_PER_HOSTNAME];
+ in_addr_t netmask, gateway;
+ bool metric_defined;
+ int metric;
/* network */
@@ -234,17 +237,19 @@ init_route (struct route *r,
{
goto fail;
}
-
- if (!get_special_addr (spec, ro->network, &r->network, &status))
+
+ if (get_special_addr (spec, ro->network, &nets[0], &status))
+nb = 1;
+ else
{
- r->network = getaddr (
- GETADDR_RESOLVE
- | GETADDR_HOST_ORDER
- | GETADDR_WARN_ON_SIGNAL,
- ro->network,
- 0,
- &status,
- NULL);
+ nb = getaddr_all (GETADDR_RESOLVE
+ | GETADDR_HOST_ORDER
+ | GETADDR_WARN_ON_SIGNAL,
+ nets, MAX_IPS_PER_HOSTNAME,
+ ro->network,
+ 0,
+ NULL);
+ status = (nb >= 0);
}
if (!status)
@@ -254,33 +259,33 @@ init_route (struct route *r,
if (is_route_parm_defined (ro->netmask))
{
- r->netmask = getaddr (
- GETADDR_HOST_ORDER
- | GETADDR_WARN_ON_SIGNAL,
- ro->netmask,
- 0,
- &status,
- NULL);
+ netmask = getaddr (
+ GETADDR_HOST_ORDER
+ | GETADDR_WARN_ON_SIGNAL,
+ ro->netmask,
+ 0,
+ &status,
+ NULL);
if (!status)
goto fail;
}
else
-r->netmask = default_netmask;
+netmask = default_netmask;
/* gateway */
-
+
if (is_route_parm_defined (ro->gateway))
{
- if (!get_special_addr (spec, ro->gateway, &r->gateway, &status))
+ if (!get_special_addr (spec, ro->gateway, &gateway, &status))
{
- r->gateway = getaddr (
-GETADDR_RESOLVE
-| GETADDR_HOST_ORDER
-| GETADDR_WARN_ON_SIGNAL,
-ro->gateway,
-0,
-&status,
-NULL);
+ gateway = getaddr (
+ GETADDR_RESOLVE
+ | GETADDR_HOST_ORDER
+ | GETADDR_WARN_ON_SIGNAL,
+ ro->gateway,
+ 0,
+ &status,
+ NULL);
}
if (!status)
goto fail;
@@ -288,7 +293,7 @@ init_route (struct route *r,
else
{
if (spec->remote_endpoint_defined)
- r->gateway = spec->remote_endpoint;
+ gateway = spec->remote_endpoint;
else
{
msg (M_WARN, PACKAGE_NAME " ROUTE: " PACKAGE_NAME " needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options");
@@ -298,35 +303,54 @@ init_route (struct route *r,
/* metric */
- r->metric_defined = false;
- r->metric = 0;
+ metric_defined = false;
+ metric = 0;
if (is_route_parm_defined (ro->metric))
{
- r->metric = atoi (ro->metric);
- if (r->metric < 0)
+ metric = atoi (ro->metric);
+ if (metric < 0)
{
msg (M_WARN, PACKAGE_NAME " ROUTE: route metric for network %s (%s) must be >= 0",
ro->network,
ro->metric);
goto fail;
}
- r->metric_defined = true;
+ metric_defined = true;
}
else if (spec->default_metric_defined)
{
- r->metric = spec->default_metric;
- r->metric_defined = true;
+ metric = spec->default_metric;
+ metric_defined = true;
}
- r->defined = true;
+ /* Now fill the corresponding route entries. */
- return true;
+ if (netmask != default_netmask && nb > 1)
+/* If we add individual hosts, then every IP of that host is added,
+ but if we add a whole subnet, then only consider the first IP,
+ presuming that all the IPs are in the same subnet. */
+nb = 1;
+
+ /* Add a route for each one of the IPs found. */
+ while (nb > 0 && r < last_route)
+{
+ nb--;
+ r->option = ro;
+ r->network = nets[nb];
+ r->netmask = netmask;
+ r->gateway = gateway;
+ r->metric_defined = metric_defined;
+ r->metric = metric;
+ r->defined = true;
+ r++;
+}
+
+ return r;
fail:
msg (M_WARN, PACKAGE_NAME " ROUTE: failed to parse/resolve route for host/network: %s",
ro->network);
- r->defined = false;
- return false;
+ retu
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
> Thanks a lot for you patch! In general, it very looks good. Can you > elaborate a little bit on how you have tested this patch? I've been using it on my client machines for the last few months. This is not a very extensive test, obviously: they're all configured identically and so they all lookup the same FQDNs received from the same VPN server. > Have you checked it for memory leaks? (e.g. using valgrind) No, my patch does not use dynamic memory allocation, so memory leaks seem unlikely (tho I don't know enough of the functions I call to be 100% sure). > What happens if no FQDNs are found? I have not touched this part of the code, AFAIK, so the behavior should be the same as before (not sure what it is). Stefan
Re: [Openvpn-devel] [IPv6 support] - usage of gethostbyname() in getaddr()
> When reviewing the patch "FQDN for routes should expand to all IPs" > today, I spotted that there is a function called getaddr() (renamed to > getaddr_all() in the mentioned patch). This function again makes use of > the old gethostbyname() function. This is not compatible with IPv6 > addresses. I'm glad other people replied in this thread: I know next to nothing about those functions (which is why my patch just uses as much as possible the pre-existing code and didn't move from gethostbyname to something else). Stefan "Not a network programmer by a long shot, just a user who needed a specific feature"
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
> You are right in regards to dynamic memory allocation. You're using > static array allocation, defined by MAX_IPS_PER_HOSTNAME. This value is > set to 100. Where did you take this number from? IMHO, that sounds to > be fairly high. Actually, I don't use static allocation but stack allocation. The value of 100 comes straight out of nowhere. Basically I though "hmm, I've never seen more than about 10 IPs for a given FQDN, so 100 should cover most cases". This is based on the premise that 400bytes of stack space is pretty much negligible on the one hand, and that more than 100 IPs is so unlikely that dynamic allocation is not worth the trouble. > Correct! Thanks for the nitpick! Stack memory is anyway precious, on > some systems more than others depending on how stack allocation is done. What's the smallest system on which OpenVPN is expected to work? My OpenVPN server has 32MB of RAM (a linksys home router), and I assumed it was on the lower scale already. A system where 1KB of stack space is significant would have to be a lot smaller. > As I said initially, in the current situation this might not be the > case. But this part of OpenVPN will most likely see a change in the > future. Not forked nor threaded applications scales very badly on > today's multi core systems. So this comment was really meant as a > hands-up of a potential issue in the future. Depending on the style of threading, I could imagine 1KB of stack space per thread to become more significant, indeed. I'll let others decide whether it's likely to be a real problem or not. > Reasonable argument. On the other hand, a hackerish approach it might > be considered to use a global variable in this case. This setting > should only be read only, not changed and is a global setting. Even > though, I'm not a big fan of global variables, I'm willing to consider > it in this setting. If it's a config var, it could indeed just be a global var, so I don't think it would be very complex. But that's really not something the user should have to configure. >> Reading through this, my suggestion would be "go for a reasonable but >> lower value", something like "20". Still arbitrary, but brings down the >> (transient!) memory used to 80 bytes, which is hard to beat with any sort >> of dynamic allocation scheme. > Good point! But that's only valid as long as openvpn stays single > threaded. On the other hand, this might be good enough for now. A normal function's activation frame can already be within the same order of magnitude, so worrying about 80bytes sounds pretty extreme to me (as a compiler guy). OTOH I don't know if 20 entries is enough (it's plenty for my use case, tho, so I'd be fine with this choice). Stefan
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c
>> I'm fine with whichever path you choose. But just bear in mind, some >> systems might not have IPv6 support - which breaks portability ... > On the unixish side, there is no system which has tun/tap today but > does not have IPv6. What about embedded systems using uclibc compiled "without ipv6 support"? Or is that some different kind of "support" that wouldn't affect your code? Stefan
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs (second round)
> - From the following review discussion, a few other things needs to be > changed and I hope you are willing to look into adopting your patch to > those guidelines. This is also to follow the standards [1] we try to > introduce as well. Sure, I'd like to get this in the main OpenVPN code, so I'll do what it takes. > So, to give a summary to what needs to be done: > * This feature should be #ifdef'ed, so that it can be disabled for those > not wanting this feature. AFAIK this is a bug-fix rather than a feature (the current behavior for FQDNs mapping to multiple IPs is pretty difficult to justify), so I wonder why it requires such #ifdef'ing. > * MAX_IPS_PER_HOSTNAME should be set via ./configure. I'd probably > recommend that if this value is 0 the feature is not enabled (covers the > first point automatically and simplifies ./configure) If f.ex. only > - --enable-resolve-all-ips (probably need a better targeted name) is given > without a number, the default should be 20. I'll do that. I do wonder: IIUC setting this to 1 might result in reproducing the current (buggy) behavior, so would #ifdef'ing still be necessary? > * Implement this patch on top of the frp branch, I'm not sure what you mean by the "frp" branch. Is tht a new branch in the Git repository? > and make sure you add the possibility to disable the randomisation > of resolving. Of course, as before I'll just try and keep the "old" code and/or behavior. > Would you be willing to do this job? When these things are covered, I > believe the patch has reached a state where it is suitable for inclusion. OK, I'll let you know when it's ready for review, Stefan
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs (second round)
> I was doing some considerations back and forth here before starting this > second round. The issue is that it changes the behaviour quite a lot > from what might be expected from earlier versions (if you're used to the > former behaviour). I'm at a loss when it comes to try and imagine someone who's used to the current behavior and bothered by the new behavior. Really. How can the current behavior ever be preferable? Why would someone ever prefer that a route would be randomly chosen to either go through the VPN or not. I haven't heard any such someone raise her voice, and neither have I heard anyone come up with a scenario where such a someone could exist. If someone could give at least some vaguely plausible scenario, that'd help. > And it introduces some new code paths, including a new function > (getaddr_all). So I would prefer to consider this, at least for now, > as a feature change rather than a bug fix. OK, so it's a question of code, not of behavior. That does make sense. >>> * MAX_IPS_PER_HOSTNAME should be set via ./configure. I'd probably >>> recommend that if this value is 0 the feature is not enabled (covers the >>> first point automatically and simplifies ./configure) If f.ex. only >>> - --enable-resolve-all-ips (probably need a better targeted name) is given >>> without a number, the default should be 20. >> >> I'll do that. I do wonder: IIUC setting this to 1 might result in >> reproducing the current (buggy) behavior, so would #ifdef'ing still >> be necessary? > I prefer that having it set to 0 gives the old code path. The value of > one can be used to have the same behaviour as 0, but with your new code > path. That also makes sense then, yes. >>> * Implement this patch on top of the frp branch, >> I'm not sure what you mean by the "frp" branch. Is tht a new branch in >> the Git repository? > Yes, it's the feature removal branch. The reason for this is that the > removal of the randomisation is found in this branch. And here you'll > only find those changes, so a conflict with other fea I see, that's fine. IIUC, this will cause a conflict when merging with some of the IPv6 code. We'll cross this bridge when we get there. Stefan
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs (second round)
>> If someone could give at least some vaguely plausible scenario, >> that'd help. > Maybe there's more than one tunnel and there's some stupid > load balancing going on using a hosts file? (Along with > deleting all non-vpn routes.) [ Setting aside the fact that using OpenVPN's broken handling of multi-FQDN to implement this is far from the only option. ] I'm not even sure *how* this could work: how would you ensure that the different tunnels happen to (together) route all IPs rather than all chosing the same IP (for example)? Stefan
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
> because i really believe in open source software I've decided to check > all sorts of configurations to check problems with tcp tunneling. This makes it sound like OpenVPN's performance is lower than some comparable non-Free software. Have you actually compared OpenVPN's performance to some other TCP-tunnel solution? That would be instructive since it may point to ways to improve the TCP support. I know in general OpenVPN discourages the use of TCP tunnels and for good reasons, but the support for TCP tunnels is also one of the strengths of OpenVPN, making it usable even with the most uncooperative firewalls. Stefan
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
> That's a very good suggestion! I just tried this with OpenVPN-ALS > (adito), and while the average performance is slightly lower (java > vs. compiled code?), the throughput inconsistency is not there, rather > it's only the case with OpenVPN! IIUC OpenVPN-ALS is not comparable in that it works in a completely different way which means it can't tunnel just any IP packets. So, it doesn't suffer from "TCP-over-TCP" problems. Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
> In either case we'd be looking at an openvpn configuration > directive (or 2) that takes a command to run once > the link comes up (and down). If that was in place then > any of A, B, C, or D, or your choice of using an ifup/ifdown > script would all work. BTW, there are generic tools to run/stop dhcp clients (and other configuration steps) when the interface goes up/down. I've used ifplugd for it, but IIUC there are others. I think if the user just starts the dhcp client on an interface independently from the moment the interface goes up (or down), this is simply a misconfiguration. > Given that. Why not just use -up and --down to do what's > needed? Avoid changing the code and write documentation. Sounds about right, Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
>> I think if the user just starts the dhcp client on an interface >> independently from the moment the interface goes up (or down), this >> is simply a misconfiguration. > I'm not sure I understand. Are you saying that manually starting > a dhcp client means that the system is mis-configured because > it's not configured to do the right thing automatically? No, I mean if the dhcp client is started for example in the boot scripts. Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
> bring the interfaces up > start dhcp client (if not triggered directly from the interfaces) > start openvpn That is a misconfiguration in my book. The only correct configuration is when the dhcp client is triggered from the interface. After all, openvpn may take half an hour to get the connection and it may lose the connection at some point and reconnect to another openvpn server (via round-robin DNS, for example) which might require a reconfiguration on the dhcp side. Of course, the correct result can be obtained in various ways: - let openvpn run scripts to start&stop the dhcp client. - use ifplugd (assuming it works with openvpn, which I haven't checked). - use a dhcp client which internally does what ifplugd does (don't know which ones that would be). Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
> My understanding of dhcp is that the client is supposed to > automatically reconfigure on lease expiration Yes. > or whenever the link goes up and down. Not necessarily, and that's the problem. > I suppose it's possible that there are dhcp clients > that exit when the link goes down and must be restarted > but I don't know of any. No, but many don't do anything when the link goes down or when the link comes back up. They only do something when the lease needs to be refreshed. That's why we have things like ifplugd. Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
> Implementing a DHCP client within OpenVPN tends to make this a more > self-contained problem. I don't think OpenVPN should get into the DHCP business. Especially because this is not a problem specific to OpenVPN: the same problem of refreshing DHCP info happens with ethernet and with wifi when you disconnect and reconnect. Various solutions to this problem already exist: a tool (e.g. ifplugd) can monitor the interface's status, or OpenVPN can be instructed (via its script hooks) to run commands upon (re|dis)connection. These existing solutions are better because they profit from the general infrastructure and will hence blend in much better. E.g. they will automatically adopt the global DHCP customizations. Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
>>> Implementing a DHCP client within OpenVPN tends to make this a more >>> self-contained problem. >> I don't think OpenVPN should get into the DHCP business. >> Especially because this is not a problem specific to OpenVPN: the same >> problem of refreshing DHCP info happens with ethernet and with wifi when >> you disconnect and reconnect. > I agree to your points, from a theoretical point of view. But from a > practical point of view, I'm not sure how possible it is to find a more > generic solution which can be used on all *nix based setups. There is maybe no such generic solution, but every system will have such a tool, for the reason stated: it's a general problem not specific to OpenVPN. > I'm running Fedora 12, and ifplugd is available but not installed. I > presume that's because NetworkManager is taking care of everything with > networking. In fact, I know that if I manually start dhclient on an > extra device with NetworkManager, I often experience that NetworkManager > reclaims control of that device, and it looses its IP address. In this > case, I'd say that OpenVPN should integrate against NetworkManager > instead. But that's not sustainable either. NetworkManager is indeed an alternative to ifplugd. If NetworkManager doesn't know how to do-the-right-thing in this case, then we should try and fix *that*, rather than implement DHCP in OpenVPN. > In my point of view, it's more important to find a solution which will > be easy to maintain in the OpenVPN code and which doesn't give a > headache to the package maintainers or system admins needing to > configure OpenVPN. The least headaches for the distribution maintainers is when each tool sticks to its particular functionality so you don't get spurious conflicts (e.g. both OpenVPN and some DHCP client trying to configure the interface), and you don't get inconsistency where different configurations are needed for the same problem depending on which device happens to be used. Stefan
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
>> Let's not add more complexity to openvpn itself, I'd be much happier if > You just don't understand. > The complexity *WILL* be in OpenVPN, if we decide to support > "route-gateway dhcp" for non-Windows platforms. I'm not sure what "route-gateway dhcp" does, so maybe that's part of the reason why we disagree. I thought the discussion was about how to make DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems like GNU/Linux. On those systems, the only thing you need to do is to make sure that things like ifplugd correctly receive the info about when the tunnel goes up and down. > a) figuring out how to properly run the system's DHCP client [which might >not even be installed] for *this* version of Linux or FreeBSD or >OpenBSD or NetBSD or Solaris or MacOS in the right way That's not something OpenVPN should worry about. It's the distribution's job to do that. > This might be the other big misunderstanding here. As of today, if you > want to use "ifplugd + dhcp + ..." on a TAP interface, just do so - OpenVPN > won't stand in your way. This is not the issue at hand - the issue is > that OpenVPN wants to be friendly to the users, and give them an option > to do DHCP-on-TAP without(!) having to fiddle with their local network > setup. I find the effort would be better spent on working with other people trying to make sure that ifplugd/NetworkManager/distributions/... make this setup as troublefree as possible. E.g. make sure that ifplugd works well with tap devices (e.g. that it tries to handle them by default) and that NetworkManager can easily use OpenVPN and correctly (re)starts dhcp clients for the corresponding tap devices. Stefan
Re: [Openvpn-devel] openvpn and dll hijacking?
> Having apps that can't be tricked into downloading random DLLs from > strange websites would certainly be a good thing ;-) Upgrade to a sane system, like GNU/Linux and all your apps will be fixed in one fell swoop, Stefan
Re: [Openvpn-devel] openvpn and dll hijacking?
>> > Having apps that can't be tricked into downloading random DLLs from >> > strange websites would certainly be a good thing ;-) >> Upgrade to a sane system, like GNU/Linux and all your apps will be fixed >> in one fell swoop, > "if they were built with a sane rpath". AFAIK, that's usually the case under most GNU/Linux distributions. > Which is the whole point of the advisory: if you build applications wrongly, > they will become vulnerable. Yes, but those risks with rpath and friends have been known for a very long time under unixy systems and have been taken fairly seriously, so it's rather rare to find a vulnerable package in my experience (e.g. I have never seen current-directory in the rpath). Stefan
