openvpn-devel Mailing List for OpenVPN

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/12 11:24, Gert Doering wrote: > Hi, > > I'm forwarding this "as-is", as I do not have enough understanding of > autoconf to say whether this is necessary, or "the right fix" - but > anyway, I've been told that this is needed to make our configure > behave on MacOS 10.7. > > gert > Applied to the master branch on -stable and -testing trees. commit 3a90edbd194140eef51c245edfcf9afc0ecb2d13 Author: Byron Ellacott <bj...@ap...> Date: Mon Feb 6 19:57:00 2012 +0100 autoconf fixes for building on OSX [DS: a few whitespace fixes was added as well during the merge] Signed-off-by: Byron Ellacott <bj...@ap...> Acked-by: Gilles Espinasse <g....@fr...> Signed-off-by: David Sommerseth <da...@re...> kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8z2ecACgkQDC186MBRfrp2uQCgnwNsEiwhHfgbdi9Bs1ttkNHL oqIAoJB18nrWOeF4izWXMSSG56KxgUST =FiKQ -----END PGP SIGNATURE----- 

Hi, On Thu, Feb 09, 2012 at 10:44:15PM +1300, Michal Ludvig wrote: > >On Thu, Feb 09, 2012 at 03:49:11PM +1300, Michal Ludvig wrote: > >>I'm used to pushing route options to the clients with explicit metrics. > >>That works good for IPv4 with e.g.: > >>push "route 192.168.128.0 255.255.240.0 vpn_gateway 200" > >> > >>However route-ipv6 doesn't accept the 'vpn_gateway' keyword and > >>therefore I can't easily set a metric. I could indeed put the actual > >>server IP in there but that's less flexible, partly because I have this > >>routes section in a separate file included in multiple configs on the > >>same machine. > >What are you trying to achieve? > > I'm trying to set a metric for IPv6 route pushed from the OpenVPN server. > > Long story, if you're asking why, is: we've got multiple OpenVPN > gateways to our network, each in a different location. A VPN user can > connect to any of them, or to more then one, and must have access to the > whole network. Obviously I'm pushing the prefixes local for each > location with a lower metric and the non-local prefixes with a higher > metric. That way, even if a user has a tunnel up to two or more > locations, the traffic to each location is always routed through the > most direct tunnel with the lowest metric. OK, this makes sense, and is a good argument for metric. (And to make this extensible, it would need to understand a gateway parameter, which it currently doesn't). > To make things a little more complicated I have both UDP and TCP > endpoints in each location (TCP is there for users behind HTTP proxies > for example) and most of their configs are shared, therefore I use the > "vpn_gateway" placeholder that gets replaced for the VPN IP of the > actual server, which is different between UDP and TCP on the same > gateway. Without that placeholder I can't share the config with "push > route-ipv6" options between UDP and TCP instances. It won't work anyway right now, because metric isn't handled in IPv6 routing at all - classical case of "other things were more pressing" (and all this stuff is "slightly" system-dependent, so needs lots of testing...). > So that's what I'm trying to achieve. Hope that makes sense :) It does. Thanks for explaining. I'm not promising anything, but it just moved a bit further up on my TODO list... ;-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 02/09/2012 09:20 PM, Gert Doering wrote: > Hi, > > On Thu, Feb 09, 2012 at 03:49:11PM +1300, Michal Ludvig wrote: >> I'm used to pushing route options to the clients with explicit metrics. >> That works good for IPv4 with e.g.: >> push "route 192.168.128.0 255.255.240.0 vpn_gateway 200" >> >> However route-ipv6 doesn't accept the 'vpn_gateway' keyword and >> therefore I can't easily set a metric. I could indeed put the actual >> server IP in there but that's less flexible, partly because I have this >> routes section in a separate file included in multiple configs on the >> same machine. > What are you trying to achieve? I'm trying to set a metric for IPv6 route pushed from the OpenVPN server. Long story, if you're asking why, is: we've got multiple OpenVPN gateways to our network, each in a different location. A VPN user can connect to any of them, or to more then one, and must have access to the whole network. Obviously I'm pushing the prefixes local for each location with a lower metric and the non-local prefixes with a higher metric. That way, even if a user has a tunnel up to two or more locations, the traffic to each location is always routed through the most direct tunnel with the lowest metric. To make things a little more complicated I have both UDP and TCP endpoints in each location (TCP is there for users behind HTTP proxies for example) and most of their configs are shared, therefore I use the "vpn_gateway" placeholder that gets replaced for the VPN IP of the actual server, which is different between UDP and TCP on the same gateway. Without that placeholder I can't share the config with "push route-ipv6" options between UDP and TCP instances. So that's what I'm trying to achieve. Hope that makes sense :) Michal 

Hi David, David Sommerseth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/02/12 16:56, Jan Just Keijser wrote: > >> Hi Paul, >> >> Paul Bakker wrote: >> >>> On 8-2-2012 15:53, Jan Just Keijser wrote: >>> >>>> Hi Paul, >>>> >>>> >>>> I can't find why the client would use 'eth0' for the 'tun0' >>>> network - perhaps if you rerun with 'verb 7' and check for GDG >>>> messages you will get a clue what openvpn is deciding... As a >>>> workaround, try adding the second config route-gateway >>>> 10.100.0.10 redirect-gateway def1 >>>> >>>> this should tell openvpn that the default GW is 10.100.0.10. >>>> >>> ========================================= Wed Feb 8 16:14:22 2012 >>> us=437713 GDG: route[1] 0.0.0.0/0.0.0.0/172.31.0.1 m=0 Wed Feb 8 >>> 16:14:22 2012 us=437752 GDG: route[2] >>> 10.100.0.0/255.255.255.0/0.0.0.0 m=0 Wed Feb 8 16:14:22 2012 >>> us=437786 GDG: route[3] 169.254.0.0/255.255.0.0/0.0.0.0 m=1000 Wed >>> Feb 8 16:14:22 2012 us=437817 GDG: route[4] >>> 172.31.0.0/255.255.255.0/0.0.0.0 m=1 Wed Feb 8 16:14:22 2012 >>> us=437849 GDG: route[5] 192.168.1.18/255.255.255.255/172.31.0.1 m=0 >>> Wed Feb 8 16:14:22 2012 us=437909 GDG: best=172.31.0.1[1] lm=0 Wed >>> Feb 8 16:14:22 2012 us=438044 GDG: route[1] >>> 0.0.0.0/0.0.0.0/172.31.0.1 m=0 Wed Feb 8 16:14:22 2012 us=438078 >>> GDG: route[2] 10.100.0.0/255.255.255.0/0.0.0.0 m=0 Wed Feb 8 >>> 16:14:22 2012 us=438110 GDG: route[3] >>> 169.254.0.0/255.255.0.0/0.0.0.0 m=1000 Wed Feb 8 16:14:22 2012 >>> us=438140 GDG: route[4] 172.31.0.0/255.255.255.0/0.0.0.0 m=1 Wed Feb >>> 8 16:14:22 2012 us=438171 GDG: route[5] >>> 192.168.1.18/255.255.255.255/172.31.0.1 m=0 Wed Feb 8 16:14:22 2012 >>> us=438216 GDG: best=172.31.0.1[1] lm=0 Wed Feb 8 16:14:22 2012 >>> us=438254 ROUTE default_gateway=172.31.0.1 Wed Feb 8 16:14:22 2012 >>> us=439676 TUN/TAP device tun1 opened Wed Feb 8 16:14:22 2012 >>> us=439749 TUN/TAP TX queue length set to 100 Wed Feb 8 16:14:22 >>> 2012 us=439815 do_ifconfig, tt->ipv6=0, >>> tt->did_ifconfig_ipv6_setup=0 Wed Feb 8 16:14:22 2012 us=439928 >>> /sbin/ifconfig tun1 172.30.1.2 netmask 255.255.255.0 mtu 1500 >>> broadcast 172.30.1.255 Wed Feb 8 16:14:22 2012 us=445345 >>> /sbin/route add -net 10.100.0.10 netmask 255.255.255.255 gw >>> 172.31.0.1 Wed Feb 8 16:14:22 2012 us=447721 /sbin/route add -net >>> 0.0.0.0 netmask 128.0.0.0 gw 172.30.1.1 Wed Feb 8 16:14:22 2012 >>> us=449931 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw >>> 172.30.1.1 ========================================= >>> >>> So indeed it seems to think the default gateway should be >>> 172.31.0.1, which is correct.. While for adding a static route for >>> an ip (10.100.0.10) in this case, it is making the wrong choice. It >>> can deduce that route[2] would be used (which has interface tun0) >>> instead of the default route.. So this is a bug in OpenVPN handling >>> the redirect-gateway def1 command and adding the static route.. >>> >>> Adding the redirect gateway solves the problem, but is not viable in >>> my setup, so I'm going for a manual add at this point in time. If >>> this ever gets fixed in OpenVPN i'll move back to the >>> redirect-gateway. >>> >>> >> this indeed looks like a (minor) bug: - the second layer openvpn >> server is reachable via _A_ local network (10.100.0.0/24) - you've >> requested 'redirect-gateway' - for safety reasons openvpn then adds a >> direct route to the VPN server via the original gateway (10.100.0.10 >> via 172.31.0.1) >> >> a workaround is to add 'redirect-gateway def1' to the inner layer VPN >> as well. >> > > Just to be sure we're not trying to fix something which might be fixed. > Which version of OpenVPN are you testing this on? The later master > branch or a 2.2 release? > > The reason for asking is that I know James Yonan did some additions to > the routing code lately, also solving some --redirect-gateway issues. > I'm far from convinced it's really related. But it's close enough to > check out. > > <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8fc83a2d6cfa44032f38e13fc2f7dbc096f584d9> > > I'll check the sources later today... what Paul is seeing is triggered by the fact that in this particular case you do NOT want the /32 route to the VPN server via the original default gateway. It might be worthwhile to add this as an option to OpenVPN. A scenario like this does not apply only to the double tunnel scenario, but also the following: - client has 2 network interfaces, eth0 and eth1 - eth0 is connected to the default GW, e.g. 172.31.0.1 - eth1 is connected to another LAN, 10.100.0.0/24 - the OpenVPN server is on this other LAN, 10.100.0.10 if the client connects and wants to redirect the GW, an extra route is added 10.100.0.10/32 *via the original GW* : this route overrules the LAN route '10.100.0.0/24 via eth1' Perhaps it's possible to determine via which interface openvpn is talking to the server - we could then decided whether to add the /32 route or not. A user-override option would also be useful in this case. cheers, JJK 

Hi, On Thu, Feb 09, 2012 at 03:49:11PM +1300, Michal Ludvig wrote: > I'm used to pushing route options to the clients with explicit metrics. > That works good for IPv4 with e.g.: > push "route 192.168.128.0 255.255.240.0 vpn_gateway 200" > > However route-ipv6 doesn't accept the 'vpn_gateway' keyword and > therefore I can't easily set a metric. I could indeed put the actual > server IP in there but that's less flexible, partly because I have this > routes section in a separate file included in multiple configs on the > same machine. What are you trying to achieve? > Can we have 'route-ipv6' accepting the same keywords as 'route' for > consistency? Please :) Someone needs to do the work. It's somewhere on my TODO list, but I haven't seen a strong need yet, so other bits have been done earlier. > BTW ideally, for even more consistency, modify 'route' (v4) to also > accept "net/prefix" as well as the old-fashioned "net netmask". OpenVPN > is one of the last programs where I still have to use netmasks instead > of the more convenient prefixes. That'd be truly awesome :) (but not as > important as the vpn_gateway support for route-ipv6 of course). Someone would need to implement that, in a backwards-compatible fashion. I'm not, as I don't work on legacy IP support anymore. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi guys I'm used to pushing route options to the clients with explicit metrics. That works good for IPv4 with e.g.: push "route 192.168.128.0 255.255.240.0 vpn_gateway 200" However route-ipv6 doesn't accept the 'vpn_gateway' keyword and therefore I can't easily set a metric. I could indeed put the actual server IP in there but that's less flexible, partly because I have this routes section in a separate file included in multiple configs on the same machine. Can we have 'route-ipv6' accepting the same keywords as 'route' for consistency? Please :) BTW ideally, for even more consistency, modify 'route' (v4) to also accept "net/prefix" as well as the old-fashioned "net netmask". OpenVPN is one of the last programs where I still have to use netmasks instead of the more convenient prefixes. That'd be truly awesome :) (but not as important as the vpn_gateway support for route-ipv6 of course). Thanks! Michal