[Openvpn-devel] [PATCH] Adds support for setting the default IPv6 gateway for routes using the route-ipv6-gateway option
This patch adds support for setting the default IPv6 gateway for routes using the "route-ipv6-gateway” option. Currently if users try to use the "redirect-gateway ipv6” option, or a IPv6 route without a gateway, without using "ifconfig-ipv6" they’ll receive the message "OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options”. However, the "route-ipv6-gateway” option doesn’t actually exist, and it is required for bridged/TAP setups relying on IPv6 auto-configuration for IP assignment. This patch adds the "route-ipv6-gateway” option. The gateway specified must be an IPv6 address, FQDNs are not supported (to match the behaviour of the other IPv6 related options). Currently in production use in Viscosity for macOS and Windows, no reported issues. Signed-off-by: James Bekkema Thanks, James -- James Bekkema SparkLabs Developer https://www.sparklabs.com https://twitter.com/sparklabs supp...@sparklabs.com route-ipv6-gateway.diff Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Restore functionality of route-gateway's dhcp parameter
This patch restores functionality of route-gateway's dhcp parameter, and expands it to support routes using vpn_gateway. OpenVPN supports using a “dhcp” parameter for the "route-gateway” option, which involves intercepting the DHCP reply packet and extracting the gateway to use. However, the current implementation expects to have this information at the time of the initialisation of the route list, which will not happen, and so routes relying on this option are never added. Rather than moving initialisation of the route list until after the route-delay (which can have a negative effect on the resolution of routes using FQDNs), this patch flags routes that require a DHCP gateway, and updates and defines them when a DHCP reply is received. If no reply is received in time, the routes are left undefined. Currently in production use in Viscosity for macOS and Windows, no reported issues. Signed-off-by: James Bekkema Thanks, James -- James Bekkema SparkLabs Developer https://www.sparklabs.com https://twitter.com/sparklabs supp...@sparklabs.com route-gateway-dhcp.diff Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Resolves small IV_GUI_VER typo in the documentation
According to the source code, the environment variable for the GUI version should be IV_GUI_VER, rather than IV_UI_VER. This patch simply fixes this small typo in the docs. Signed-off-by: James Bekkema Thanks, James -- James Bekkema SparkLabs Developer https://www.sparklabs.com https://twitter.com/sparklabs supp...@sparklabs.com doc-iv_ui_ver.diff Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes)
> On 22 Jun 2017, at 7:06 am, David Sommerseth > wrote: > > - What can be done with Cloudflare to fully ensure their caches are > truly purged when we ask for it? As Jonathan noticed, their caches > are tightly connected to the web browser and have a non-deterministic > behaviour across browsers, even on the same computer. Cloudflare’s API supports clearing the cache (as does their web control panel), and this can be done on a file-by-file basis. Based on our experience it only takes around 15-20 seconds for the cache to be cleared on all of Cloudflare's CDN nodes for a file and it can be easily thrown into a release script. https://api.cloudflare.com/#zone-purge-individual-files-by-url-and-cache-tags As for some web browsers, proxy servers, etc. in-between the user and a Cloudflare node, they’re respecting the HTTP cache-control headers which are currently set to cache for 24 hours: curl -I https://swupdate.openvpn.org/community/releases/openvpn-2.4.3.tar.gz Expires: Fri, 23 Jun 2017 00:14:19 GMT Cache-Control: public, max-age=86400 Of course, many proxy servers and web browsers have different approaches to handling caching headers (especially for zipped files), so you will get some differing behaviour. The best approach is to still have an appropriate caching time between nodes and the web server (24 hours is fine) so they don’t need to re-fetch the files too often, but then have a Cloudflare Page Rule to rewrite these with a lower time to clients (we use 4 hours) to limit the impact in the (hopefully rare) event of a file update being needed. https://support.cloudflare.com/hc/en-us/articles/200168306-Is-there-a-tutorial-for-Page-Rules-#cache The final cause of differing behaviour is that each Cloudflare node’s caching time of a file starts when that individual node first gets a request for it. But this can easily be ignored by just using the API to clear the cache of all nodes when needed. > So I suggest we take a few weeks holiday, let this sink in, and then we > can schedule a meeting some time in August where we discuss these > issues. Sorry to throw more noise at the mailing list, but I figured I’d put up some comments as IRC meeting times don’t usually align for those of us in Australia :-) Regards, James -- James Bekkema SparkLabs Developer https://www.sparklabs.com https://twitter.com/sparklabs supp...@sparklabs.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Add Mac OS X keychain support
Hi All, Just to expand on the comments Samuli included below: From a GUI client like Viscosity’s perspective number 1) from Vasily's email is the option we’d take, and ultimately something we were planning on implementing and contributing a patch for down the line anyway (i.e. something similar to the existing --management-external-key option). While this means clients like Viscosity and Tunnelblick will need to implement the interaction with the Keychain directly, this isn’t any different to the existing password Keychain approach both clients have when using --management-query-passwords anyway). I can also see such offloading being utilised on other platforms, and for integration with other security tools as well. However I can understand that there may be some cases where it’s desirable to have headless Keychain support, for example, a sys admin may like to have a headless OpenVPN connection kick in at boot time. Will these users mind if they have to use the file system instead of the Keychain? I believe Tunnelblick supports a headless mode, and Viscosity probably will down the line too: is this sufficient for users wanting Keychain storage, or is direct support a reasonable expectation? I’m afraid I’m not in a position to be able to answer these questions: probably the best users to ask are those using the MacPorts build, along with those deciding on the desired scope of the community OpenVPN project. Ultimately it looks like a lot of effort has gone into the Keychain patch, and if someone is willing to maintain the Keychain integration going forward (Apple does like to deprecate things) I don’t have any objection to it being included in some way (after a code review). While with a GUI like Viscosity may not make direct use of it, it may still be handy to others. Cheers, James -- James Bekkema SparkLabs Developer http://www.sparklabs.com http://www.twitter.com/sparklabs supp...@sparklabs.com > On 6 Jan 2015, at 8:08 pm, Samuli Seppänen wrote: > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >> Hi, >> >> On Fri, Dec 12, 2014 at 19:24 +0100, Arne Schwabe wrote: >>>> On Mon, Dec 08, 2014 at 14:52 +0300, Vasily Kulikov wrote: >>>>> This patch adds support for using certificates stored in the Mac OSX >>>>> Keychain to authenticate with the OpenVPN server. This works with >>>>> certificates stored on the computer as well as certificates on hardware >>>>> tokens that support Apple's tokend interface. The patch is very > similar >>>>> to, and also based on, the Windows Crypto API certificate functionality >>>>> that currently exists in OpenVPN. >> ... >>>>> Signed-off-by: Vasily Kulikov >>>>> -- >>>> Any comments? >> >> Some ideas about keychain implementation out of OpenVPN core. >> >> I see 4 possible alternatives here: >> 1) implement keychain rsa offloading in Tunnelblick >> 2) make my patch use plugin interface >> 3) implement external daemon that communicated with openvpn process via >> management interface >> 4) the same as 3) but make openvpn able to handle more than 1 >> management client >> >> There are problems with all these alternatives: >> (1) is limited to Tunnelblick users and doesn't work for users who start >> openvpn from the terminal or use any other GUI >> (2) implies plugin interface is expanded to handle two new actions: 'user >> certificate request' and 'rsa-sign request' >> (3) implies management interface is expanded to handle 'user certificate >> request'; also it doesn't work with Tunnelblick or any other tool that >> communicates with openvpn via management interface as MI currently >> supports only a single client >> (4) needs 'user certificate request' addition and expanding management >> interface to support more than a single client >> >> So, (1) is a no-go as it works only with Tunnelblick; (3) is a no-go as >> it breaks Tunnelblick and probably someone else. We stay with only two >> interface expantions: plugin interface or management interface. Either >> (a) add 'user certificate request' to plugin interface or (b) add 'user >> certificate request' to management interface and support more than a >> single client. >> >> I'm not sure which way is better. Do you have any plans/objections on >> these interfaces expantion? Maybe I missed some critical limitations of >> the interfaces and they must not be used this way? If no strict >> objections I'd prefer to implement it via plugin interface as my patch >> would need to change only seve
[Openvpn-devel] [PATCH] Fix socket-flag/TCP_NODELAY on Mac OS X
Hi All, OpenVPN 2.3.4 will currently throw a warning of "NOTE: setsockopt TCP_NODELAY=1 failed (No kernel support)” when attempting to use the TCP_NODELAY socket option on Mac OS X/Darwin. Kernel support is there, however the required header file where TCP_NODELAY is defined is not being included. This patch simply alters syshead.h to include on Darwin platforms. --- src/openvpn/syshead.h.orig 2014-05-01 21:12:22.0 +1000 +++ src/openvpn/syshead.h 2014-06-26 17:43:30.0 +1000 @@ -349,6 +349,14 @@ #endif /* TARGET_DRAGONFLY */ +#ifdef TARGET_DARWIN + +#ifdef HAVE_NETINET_TCP_H +#include +#endif + +#endif /* TARGET_DARWIN */ + #ifdef WIN32 #include #include Tested under 10.7 to 10.10dp2. "Socket flags: TCP_NODELAY=1 succeeded” when running with debug enabled. In addition the latest beta version of Viscosity is using a copy of OpenVPN with this patch applied: no issues have been reported from testers thus far. Regards, James -- James Bekkema SparkLabs Developer http://www.sparklabs.com http://www.twitter.com/sparklabs supp...@sparklabs.com
