openvpn-devel Mailing List for OpenVPN

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/02/12 16:05, Alon Bar-Lev wrote: > Hello, > > We have a go to rewrite the OpenvPN build system. I started to work at > core product [1]. > > As part of the re-write we split out the TAP-Win32 out of OpenVPN code > base. > > To make things go faster we may try to parallelize the effort. > > Here are the tasks to perform: 1. Create a GIT repository of the > master TAP-Win32 sources with all history, to ease our work, please > use github. 2. Detach the TAP-Win32 build from the OpenVPN build. It > should be a simpler build as it now only use the DDK. 3. Rename the > TAP-Win32 to TAP-Windows as we do not need the legacy "Win32" any > more. 4. Rename the TAP common.h into tap-windows.h. 5. Sync > tap-windows.h symbols per [2], I added prefix and removed the "32", > add another header for version information. 6. Create tap nsis > installation (based on current openvpn nsis), the msi must be silent > installation mode enabled. 7. Within installation, add a group "SDK" > or similar to nsis to install the tap-windows.h as well. 8. Create > build script to build and optionally sign the driver and the msi. 9. > Output of build system would be [at least] (msi, tarball) for (win32, > win64). Why tarball? To enable people to fetch files without hacking > the msi (example: cross compile). > > Anyone interested? Need someone experienced with courage! First of all, yes, we are doing some steps now to clean up the source tree and split out the pieces of the OpenVPN source tree which is not strictly purely OpenVPN. The Windows TUN/TAP driver is a generic driver, which OpenVPN needs. But it's not something other platforms than Windows need (they have their own TUN/TAP drivers) and the TUN/TAP driver is useful for other projects. Alon has stepped up and is willing to help with this job. He has on this mailing list shown knowledge about the autotools tool chain and Windows development. I personally am very much thankful that Alon has said himself willing to look into cleaning up these parts of OpenVPN. And I'm looking forward to start reviewing the changes he is suggesting. However, it might be a potential misunderstanding which I will now attempt to straighten up. The TUN/TAP driver *will not* be moved out of the OpenVPN project itself. It will stay in the OpenVPN project as a separate sub-project in its own git tree. The OpenVPN community which I dare to speak on behalf on now, will be in charge also for the Windows TUN/TAP driver. And Alon is right, the OpenVPN project needs more resources with the right knowledge and/or strong willingness to learn that. That/those person(s) will need to be involved with the OpenVPN community as everyone else. And it is the same expectations of anyone who wants to contribute, that all changes will be sent to the mailing list for review. The mailing list is where we share knowledge and learn each others new things. For more information, see the developer pages in the OpenVPN Community wiki [A]. I will make sure that during the next week the pieces Alon moves out gets into new official git trees. If there are any queries regarding to the OpenVPN project, please contact Samuli Seppänen <sa...@op...> or me (da...@us...) and we will answer as best as we can. Kind regards, David Sommerseth > [1] https://github.com/alonbl/openvpn branch build. [2] > https://github.com/alonbl/openvpn/blob/build/include/tap-windows.h [A] <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9AO1UACgkQDC186MBRfrpfFwCgp4ZXExr/cY3yUxdkJiTMR5XO Nb4AoKvmTAW7xnua6LW1qvnc0SFd0CUi =f74C -----END PGP SIGNATURE----- 

On 02/18/2012 04:53:50 PM, Scott Zeid wrote: > On Feb 18, 2012 9:05 AM, "Alon Bar-Lev" <alo...@gm...> > wrote: > > 9. Output of build system would be [at least] (msi, tarball) for > > (win32, win64). Why tarball? To enable people to fetch files > without > > hacking the msi (example: cross compile). > > It should probably be a zip file since Windows doesn't support > tarballs out > of the box. I'm not a MS guy, but that argument does not carry a whole lot of weight since MS Windows does not support NSIS, or any other sort of installer-crafter, out of the box either; and people should be using an installer to install, not archived binaries in whatever format. It almost makes sense to make it harder for the casual MS user to try to install using the raw binaries. Bikeshed argument flag! In the end, it does not matter. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein 

On Feb 18, 2012 9:05 AM, "Alon Bar-Lev" <alo...@gm...> wrote: > 9. Output of build system would be [at least] (msi, tarball) for > (win32, win64). Why tarball? To enable people to fetch files without > hacking the msi (example: cross compile). It should probably be a zip file since Windows doesn't support tarballs out of the box. 

On 02/18/2012 09:05:16 AM, Alon Bar-Lev wrote: > Hello, > > We have a go to rewrite the OpenvPN build system. > 9. Output of build system would be [at least] (msi, tarball) for > (win32, win64). Why tarball? To enable people to fetch files without > hacking the msi (example: cross compile). I'd like to second the motion to produce a MS tarball. People who want only to produce a custom OpenVPN installer, such as the recent thread here regarding packaging OpenVPN in conjunction with an SSL obfuscation proxy, should not also have to go to the trouble to produce OpenVPN binaries. People should instead be able to rely on the OpenVPN project for high-quality prebuilt binaries suitable for repackaging into a customized installer. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein 

The _access and _waccess functions in Windows don't know about X_OK (1). If you pass an uneven mode flag the C runtime's default invalid parameter handler ends execution of openvpn. Signed-off-by: Heiko Hund <hei...@so...> --- win/config.h.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/win/config.h.in b/win/config.h.in index b5c31b8..fcb8d6c 100644 --- a/win/config.h.in +++ b/win/config.h.in @@ -243,7 +243,7 @@ typedef unsigned long in_addr_t; #endif #ifndef X_OK -#define X_OK 1 +#define X_OK 0 #endif #ifndef F_OK -- 1.7.5.4 

Hello, We have a go to rewrite the OpenvPN build system. I started to work at core product [1]. As part of the re-write we split out the TAP-Win32 out of OpenVPN code base. To make things go faster we may try to parallelize the effort. Here are the tasks to perform: 1. Create a GIT repository of the master TAP-Win32 sources with all history, to ease our work, please use github. 2. Detach the TAP-Win32 build from the OpenVPN build. It should be a simpler build as it now only use the DDK. 3. Rename the TAP-Win32 to TAP-Windows as we do not need the legacy "Win32" any more. 4. Rename the TAP common.h into tap-windows.h. 5. Sync tap-windows.h symbols per [2], I added prefix and removed the "32", add another header for version information. 6. Create tap nsis installation (based on current openvpn nsis), the msi must be silent installation mode enabled. 7. Within installation, add a group "SDK" or similar to nsis to install the tap-windows.h as well. 8. Create build script to build and optionally sign the driver and the msi. 9. Output of build system would be [at least] (msi, tarball) for (win32, win64). Why tarball? To enable people to fetch files without hacking the msi (example: cross compile). Anyone interested? Need someone experienced with courage! Alon. [1] https://github.com/alonbl/openvpn branch build. [2] https://github.com/alonbl/openvpn/blob/build/include/tap-windows.h 

I totally agree on not ACKing the patch and your solution description ;-) I tried to start a discussion on IRC about the preferred solution before sending this patch, but that didn't get very far. Op 17 februari 2012 22:58 heeft Gert Doering <ge...@gr...> het volgende geschreven: > Hi, > > On Fri, Feb 17, 2012 at 10:04:50PM +0100, Frank de Brabander wrote: >> This causes compiler warnings when using Clang instead of default GCC. > > I'm not particularily interested in source code fixes "just to silence > a compiler warning" - but Clang is right, of course, that this variable > cannot ever be negative, and thus it should be cleaned up :-) > > I'm not ACKing this patch anyway, because I think the issue is bigger - I > want to look at the IPv4 code paths and see whether the IPv4 "netbits" > structure element can ever be negative - and if yes, figure out whether > this should be possible for IPv6, and if not, convert the IPv4 netbits > to "unsigned int" as well, and get rid of the if() statement there as > well. > > Thanks for reporting this.  I'll look into it. > > 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... 

 Hello Jun! I have spent the last couple of days preparing a bundled installer for the Tor Obfuscation Proxy combined with OpenVPN. The installer currently works on 32-bit and 64-bit Windows. It simply installs obfsproxy in SOCKS proxy mode and sets it up as a Windows service, so it starts at boot. The goal is to make this an automatic install for both clients and servers. To convert an existing OpenVPN profile to use the obfsproxy, you simply change the destination port of your remote line to point at the obfuscated server port instead of the regular OpenVPN server port: BEFORE: remote my.server.com 443 AFTER: remote my.server.com 80 (assuming obfsproxy server is listening on 80) Then, you just set OpenVPN to use a socks proxy by adding these lines to you config file: socks-proxy-retry socks-proxy 127.0.0.1 1050 After this, when you initiate the OpenVPN connection, it will use obfsproxy as a SOCKS proxy. Just remember to connect to the obfsproxy port on the server, not the OpenVPN port, in your client config and it works great! A couple of important notes: 1) I have only tested this with TCP mode. I don't expect UDP to work through Socks proxy, but haven't yet tried it. 2) Once, obfsproxy died on me and I had to go to Control Panel->Administrative Tools->Services and restart the obfsproxy service. This seems to be a one-time crash, though. The Windows Installer is available here: http://awgh.org/files/obfsvpn-installer-0_0_1.exe You can build it yourself by checking out the project on bitbucket here: https://bitbucket.org/awgh/obfsproxy-windows-installer I am also working on init scripts and packages for Linux distros, which can be used for both the client side and server side of an obfsproxy connection. So far, I just have CentOS RPMs and init scripts, which are available in this project: https://bitbucket.org/awgh/obfsproxy-rpm-build I am planning on adding some additional features to the installer bundle, to allow the configuration of shared secrets and the importation of existing config files. Please feel free to either email me with bugs/feature requests or to use the issue tracking on bitbucket! Hope this will be useful to some of you. Best Regards, - Ben > -------- Original Message -------- > Subject: Re: [Openvpn-devel] Obfuscation for Iran SSL blocking > Date: Thu, 16 Feb 2012 15:01:45 +0200 > From: Samuli Seppänen< sa...@op...> > Organization: OpenVPN Technologies, Inc > To: Jun Matsushita< ju...@gm...> > CC: David Sommerseth< ope...@to...>, > " ope...@li..." > < ope...@li...> > > > > > Hi Jun, > > I would try David's obfsproxy + OpenVPN suggestion first and reconsider > if that fails. > If we would add obfuscation into OpenVPN itself, we'd soon be in the > same cat and mouse game as Tor, with the exception we don't have the > same amount of developer interest to follow it through. So, I think > keeping the obfuscation functionality would be challenging in the long > run. > > * Unknown Key > * 0xA036E792(L) > > 

 Hello Jun! I have spent the last couple of days preparing a bundled installer for the Tor Obfuscation Proxy combined with OpenVPN. The installer currently works on 32-bit and 64-bit Windows. It simply installs obfsproxy in SOCKS proxy mode and sets it up as a Windows service, so it starts at boot. The goal is to make this an automatic install for both clients and servers. To convert an existing OpenVPN profile to use the obfsproxy, you simply change the destination port of your remote line to point at the obfuscated server port instead of the regular OpenVPN server port: BEFORE: remote my.server.com 443 AFTER: remote my.server.com 80 (assuming obfsproxy server is listening on 80) Then, you just set OpenVPN to use a socks proxy by adding these lines to you config file: socks-proxy-retry socks-proxy 127.0.0.1 1050 After this, when you initiate the OpenVPN connection, it will use obfsproxy as a SOCKS proxy. Just remember to connect to the obfsproxy port on the server, not the OpenVPN port, in your client config and it works great! A couple of important notes: 1) I have only tested this with TCP mode. I don't expect UDP to work through Socks proxy, but haven't yet tried it. 2) Once, obfsproxy died on me and I had to go to Control Panel->Administrative Tools->Services and restart the obfsproxy service. This seems to be a one-time crash, though. The Windows Installer is available here: http://awgh.org/files/obfsvpn-installer-0_0_1.exe You can build it yourself by checking out the project on bitbucket here: https://bitbucket.org/awgh/obfsproxy-windows-installer I am also working on init scripts and packages for Linux distros, which can be used for both the client side and server side of an obfsproxy connection. So far, I just have CentOS RPMs and init scripts, which are available in this project: https://bitbucket.org/awgh/obfsproxy-rpm-build I am planning on adding some additional features to the installer bundle, to allow the configuration of shared secrets and the importation of existing config files. Please feel free to either email me with bugs/feature requests or to use the issue tracking on bitbucket! Hope this will be useful to some of you. Best Regards, - Ben > -------- Original Message -------- > Subject: Re: [Openvpn-devel] Obfuscation for Iran SSL blocking > Date: Thu, 16 Feb 2012 15:01:45 +0200 > From: Samuli Seppänen< sa...@op...> > Organization: OpenVPN Technologies, Inc > To: Jun Matsushita< ju...@gm...> > CC: David Sommerseth< ope...@to...>, > " ope...@li..." > < ope...@li...> > > > > > Hi Jun, > > I would try David's obfsproxy + OpenVPN suggestion first and reconsider > if that fails. > If we would add obfuscation into OpenVPN itself, we'd soon be in the > same cat and mouse game as Tor, with the exception we don't have the > same amount of developer interest to follow it through. So, I think > keeping the obfuscation functionality would be challenging in the long > run. > > * Unknown Key > * 0xA036E792(L) > >