Re: [Openvpn-devel] Summary of the IRC meeting (25th Nov 2010)
On Friday 26 November 2010 11:35:31 Samuli Seppänen wrote: > Discussed the "Windows route add command failed" issue: > > <https://community.openvpn.net/openvpn/ticket/68> > > This lead into more high-level discussion about whether failing to add > route(s) should be treated as a fatal OpenVPN error. Agreed that this is > the case if OpenVPN fails to add non-existing routes, but not if OpenVPN > fails when adding routes that already exist (e.g. local routes). Also > agreed that OpenVPN should print a meaningful error message to logs > (e.g. "Admin rights needed") if user lacks privileges to add routes. > This message should also be pushed to the Windows GUI using the > management API "echo" command. I think this should rather be reported in the "state" notification, at least that would be the best place for the GUI to grab it. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] OpenVPN GUI and ntlm Proxy password
Hi Thomas, On Thursday 17 March 2011 06:41:55 Thomas Glanzmann wrote: > Hello Mathias, I fear Mathias is not involved with the OpenVPN GUI since five years or so. There's a project on SourceForge now where I forked the GUI and try to improve it: https://sourceforge.net/projects/openvpn-gui/ > I would like to use you OpenVPN GUI for Windows to authenticate over an > NTLM proxy in Windows and wonder if you're thinking about asking and > supplying the password for NTLM-proxy authentication or planing on doing > so. Maybe you want to check out the latest snapshot and see if it works for you. The GUI uses the OpenVPN management interface for communication and monitoring since a while now. So, there's a fair chance it'll work right away or won't be much work to make it work. =) Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] OpenVPN GUI and ntlm Proxy password
Hi Thomas, On Friday 18 March 2011 14:02:26 Thomas Glanzmann wrote: > > Maybe you want to check out the latest snapshot and see if it works > > for you. The GUI uses the OpenVPN management interface for > > communication and monitoring since a while now. So, there's a fair > > chance it'll work right away or won't be much work to make it work. =) > > It did not work, because it couldn't read or write the file > > Fri Mar 18 13:56:53 2011 Error opening 'HTTP Proxy' auth file: > C:\DOCUME~1\adglth0\LOCALS~1\Temp\openvpn_authfile.: Das System kann die > angegebene Datei nicht finden. (errno=2) > > containing the credentials. But the directory exists. That's a openvpn error message not one of the GUI. Did you see the dot (.) at the end of the filename? How does openvpn know about it? I don't see it mentioned in your configuration. > I also saw a few other things that are confusing: > > - The 'About' button mentions GUI version 1.3 Yes, it's just a snapshot of the current standing in the repository not a new released version. There'll be some time passing until it gets a new version. > - When using 'Intenet Explorer' to determine the proxy, it > doesn't work with proxy pac but doesn't mention it (the > OpenVPN Gui 1.3 did mention that it doesn't work with proxy > pacs). How or where did it mention this? I can't recall removing anything like it. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] OpenVPN GUI and ntlm Proxy password
Hi Thomas. On Friday 18 March 2011 15:43:25 Thomas Glanzmann wrote: > > > Fri Mar 18 13:56:53 2011 Error opening 'HTTP Proxy' auth file: > > > C:\DOCUME~1\adglth0\LOCALS~1\Temp\openvpn_authfile.: Das System kann > > > die angegebene Datei nicht finden. (errno=2) > > > > That's a openvpn error message not one of the GUI. Did you see the dot > > (.) at the end of the filename? How does openvpn know about it? I > > don't see it mentioned in your configuration. > > I thought that the GUI now adds a line to the openvpn command line when > starting the config and writing out the above file, but it doesn't seem > to do that. Am I mistaken? I checked and you are right. I blindly believed the proxy credentials are also queried from the user via the management interface but that's not the case currently. Haven't look too much at the proxy code obviously. =) The GUI could use the auto flag with the --http-proxy option in the future, I'll give it a try next week. The incomplete filename is caused by a too small buffer in the GUI. You must be using a hostname for the proxy and it's somewhere close to 30 characters long, right? I'll add a bug to the tracker for this then. In the meantime, could you please try if it works for you using the proxy IP address. > > How or where did it mention this? I can't recall removing anything like > > it. > > When I install openvpn 2.2 RC from the openvpn community website[1] it > says 'Use Internet Explorer Settings (manually configured)'. Your > version says 'Use Internet Explorer Settings'. Yes, I remember removing this. Thought it had no additional information. Maybe a better solution would be to query the system for the right proxy. Pointers anyone? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Summary of the IRC meeting (30th June 2011)
On Friday 01 July 2011 16:12:52 Samuli Seppänen wrote: > Discussed the domake-win (mingw) and Python-based buildsystems used on > Windows: > > <https://community.openvpn.net/openvpn/wiki/BuildingOnWindows> > > Agreed that the domake-win buildsystem will has some rough edges and it > needs modernization. It was also agreed that it should be maintained > even though official releases are now built with the Python-based > buildsystem. Two primary motivations for this were cross-compiling and > the ability to build OpenVPN on Windows without Visual Studio. Nobody > volunteered to take the role of domake-win maintainer. Have you guys considered autotools for building native WIN32 binaries in cygwin? We use it for building openvpn itself. With a little effort one could even build the driver, sign the binaries and create the installer using make targets. I'm not sure if that would be more convenient for the majority of the people building openvpn for Windows, but it feels more like home to me. =) Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | Amalienbadstraße 41/Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] First Windows installer snapshot now available
On Friday 15 July 2011 01:25:12 Samuli Seppänen wrote: > In my smoketests I had to run it as administrator on Win7 64-bit or > routes would not get created. That said, the included README file seems > to be the same as in the old GUI, so I'm not really sure of what the new > GUI is capable of. > > Heiko: could you shed some light on this? Sorry, it's not yet ready for that. Plans are made, I just haven't gotten around to start coding as I was involved in doing other projects. When the work will be done OpenVPN-GUI will run as any user and be able to establish a tunnel. Hope I get time for it this quarter. I'll keep you posted. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Allow to fill Details tab for exe files
On Monday 08 August 2011 10:17:48 Bertrand Jacquin wrote: > > > Is there a windres equivalent for msvc ? > > There certainly a way to do the same thing using msvc or Python code > > that runs after the build. Does windres simply convert the resource file > > to another format? > > Yes and check the format : > > $ file openvpn-res.o > openvpn-res.o: ACB archive data See http://msdn.microsoft.com/en-us/library/aa381055%28v=VS.85%29.aspx for information on how to invoke the Platform SDK Ressource Compiler. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Windows Auto-Proxy
Hi, On Monday 08 August 2011 01:15:02 Russell Morris wrote: > Has anyone had any luck with the auto-proxy function, in particular with > PAC files? It really doesn't seem to be working for me ... :-(. Are you aware of https://community.openvpn.net/openvpn/ticket/24 ? This is probably what's causing your trouble... and of course the fact that the current impelmentation does not do proxy auto detection. I'll start resolving these issues now as it is something the GUI is relying onto as well. Openvpn should even be able to handle per Dial-up and VPN connection proxy settings if things work out. > Also, does anyone have a proxy server that requires authentication? I > currently use a text file (which does work!), but there are also Windows > functions that should send domain login information automatically. It > would be nice to to that ... :-). I like that idea, but t's probably unrelated to auto-proxy. Could you point me to the APIs. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH 1/2] define IN6_ARE_ADDR_EQUAL macro for WIN32
Windows headers do not define the IN6_ARE_ADDR_EQUAL macro. It needs to be defined locally when building for WIN32 with IPv6 enabled. Signed-off-by: Heiko Hund <heiko.h...@sophos.com> --- win32.h | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/win32.h b/win32.h index d0ecc85..907aaa2 100644 --- a/win32.h +++ b/win32.h @@ -41,6 +41,19 @@ * development environment. */ +#ifdef USE_PF_INET6 + +/* MSVC headers do not define this macro, so do it here */ +#ifndef IN6_ARE_ADDR_EQUAL +#define IN6_ARE_ADDR_EQUAL(a,b) \ +__const uint32_t *) (a))[0] == ((__const uint32_t *) (b))[0]) \ + && (((__const uint32_t *) (a))[1] == ((__const uint32_t *) (b))[1]) \ + && (((__const uint32_t *) (a))[2] == ((__const uint32_t *) (b))[2]) \ + && (((__const uint32_t *) (a))[3] == ((__const uint32_t *) (b))[3])) +#endif + +#endif + void init_win32 (void); void uninit_win32 (void); -- 1.7.5.4
[Openvpn-devel] [PATCH 2/2] don't use struct in6_addr s6_addr32 member anymore
The s6_addr32 member of struct in6_addr is not available when building
for WIN32. To work around this, a local union is defined that allows
accessing 32 bit chunks of the IPv6 address passed to add_in6_addr().
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
socket.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/socket.c b/socket.c
index 6b855c0..887569c 100644
--- a/socket.c
+++ b/socket.c
@@ -2622,13 +2622,6 @@ print_in6_addr (struct in6_addr a6, unsigned int flags,
struct gc_arena *gc)
/* add some offset to an ipv6 address
* (add in steps of 32 bits, taking overflow into next round)
*/
-#ifndef s6_addr32
-# ifdef TARGET_SOLARIS
-# define s6_addr32 _S6_un._S6_u32
-# else
-# define s6_addr32 __u6_addr.__u6_addr32
-# endif
-#endif
#ifndef UINT32_MAX
# define UINT32_MAX (4294967295U)
#endif
@@ -2637,10 +2630,15 @@ struct in6_addr add_in6_addr( struct in6_addr base,
uint32_t add )
int i;
uint32_t h;
+union {
+ uint8_t *addr;
+ uint32_t *addr32;
+} in6 = { .addr = base.s6_addr };
+
for( i=3; i>=0 && add > 0 ; i-- )
{
- h = ntohl( base.s6_addr32[i] );
- base.s6_addr32[i] = htonl( (h+add) & UINT32_MAX );
+ h = ntohl( in6.addr32[i] );
+ in6.addr32[i] = htonl( (h+add) & UINT32_MAX );
/* 32-bit overrun?
* caveat: can't do "h+add > UINT32_MAX" with 32bit math!
*/
--
1.7.5.4
[Openvpn-devel] [PATCH 0/2] fix building for WIN32
Hi, git master currently fails when cross compiling for WIN32 in Debian testing. Two IPv6 related things were introduced in commits 512cda46b0f65f388e24436cd28d44bdc90fe985 and 8335caf929f21b317a0243a12285e1f04361db25 that are incompatible with Windows. IN6_ARE_ADDR_EQUAL and struct in6_addr.s6_addr32 are not available there. While MinGW added both features to ws2tcpip.h, the Microsoft Platform SDK headers do not include them and they are (correctly) missing in the MinGW-w64 headers as well. Following are two patches that try to fix these issues. Heiko Hund (2): define IN6_ARE_ADDR_EQUAL macro for WIN32 don't use struct in6_addr s6_addr32 member anymore socket.c | 16 +++- win32.h | 13 + 2 files changed, 20 insertions(+), 9 deletions(-) Regards Heiko -- 1.7.5.4
Re: [Openvpn-devel] [PATCH 1/2] define IN6_ARE_ADDR_EQUAL macro for WIN32
On Wednesday 10 August 2011 15:47:36 Gisle Vanem wrote: > "Heiko Hund" <heiko.h...@sophos.com> wrote: > > +#ifndef IN6_ARE_ADDR_EQUAL > > +#define IN6_ARE_ADDR_EQUAL(a,b) \ > > +__const uint32_t *) (a))[0] == ((__const uint32_t *) (b))[0]) \ > > + && (((__const uint32_t *) (a))[1] == ((__const uint32_t *) (b))[1]) \ > > + && (((__const uint32_t *) (a))[2] == ((__const uint32_t *) (b))[2]) \ > > + && (((__const uint32_t *) (a))[3] == ((__const uint32_t *) (b))[3])) > > +#endif > > A little more readable: > #define IN6_ARE_ADDR_EQUAL(a, b) \ > (!memcmp ((const void*)(a), (const void*)(b), sizeof (struct > in6_addr))) > > (almost the same as in MingW's ). The version I posted is taken from eglibc 2.13 on Debian testing, by the way. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH 1/2] define IN6_ARE_ADDR_EQUAL macro for WIN32
Windows headers do not define the IN6_ARE_ADDR_EQUAL macro. It needs to be defined locally when building for WIN32 with IPv6 enabled. Signed-off-by: Heiko Hund <heiko.h...@sophos.com> --- win32.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/win32.h b/win32.h index d0ecc85..87d8ecc 100644 --- a/win32.h +++ b/win32.h @@ -41,6 +41,16 @@ * development environment. */ +#ifdef USE_PF_INET6 + +/* MSVC headers do not define this macro, so do it here */ +#ifndef IN6_ARE_ADDR_EQUAL +#define IN6_ARE_ADDR_EQUAL(a,b) \ + (memcmp ((const void*)(a), (const void*)(b), sizeof (struct in6_addr)) == 0) +#endif + +#endif + void init_win32 (void); void uninit_win32 (void); -- 1.7.5.4
[Openvpn-devel] [PATCH] remove legacy code to query IE proxy information
The code in ieproxy.[ch] is not used anywhere in OpenVPN anymore.
So, there's no need to keep it.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
Makefile.am |1 -
ieproxy.c | 146 ---
ieproxy.h | 24 --
proxy.c |5 --
4 files changed, 0 insertions(+), 176 deletions(-)
delete mode 100644 ieproxy.c
delete mode 100644 ieproxy.h
diff --git a/Makefile.am b/Makefile.am
index 32b40bb..266a5af 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -127,7 +127,6 @@ openvpn_SOURCES = \
pool.c pool.h \
proto.c proto.h \
proxy.c proxy.h \
- ieproxy.h ieproxy.c \
ps.c ps.h \
push.c push.h \
pushlist.h \
diff --git a/ieproxy.c b/ieproxy.c
deleted file mode 100644
index 3099870..000
--- a/ieproxy.c
+++ /dev/null
@@ -1,146 +0,0 @@
-/*
- * Copyright (C) 2004 Ewan Bhamrah Harley <c...@ewan.info>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program (see the file COPYING included with this
- * distribution); if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include "syshead.h"
-
-#ifdef WIN32
-
-#include
-#include
-
-LPCTSTR getIeHttpProxyError=NULL;
-
-/* getIeHttpProxy fetches the current IE proxy settings for http */
-
-LPCTSTR getIeHttpProxy()
-{
- DWORD psize=0;
- INTERNET_PROXY_INFO *pinfo;
- LPTSTR proxyString;
- LPTSTR p;
- LPTSTR q;
- unsigned int len;
-
- /* first see how big a buffer we need for the IPO structure */
- InternetQueryOption(NULL, INTERNET_OPTION_PROXY, NULL, );
- if(!psize)
- {
-getIeHttpProxyError="InternetQueryOption failed to return buffer size";
-return(NULL);
- }
-
- /* allocate memory for IPO */
- pinfo = malloc (psize*sizeof(TCHAR));
- if (pinfo == NULL)
- {
-getIeHttpProxyError="malloc failed (1)";
-return(NULL);
- }
-
- /* now run the real query */
- if(!InternetQueryOption(NULL, INTERNET_OPTION_PROXY, (LPVOID) pinfo, ))
- {
-getIeHttpProxyError="InternetQueryOption() failed to find proxy info";
-free(pinfo);
-return(NULL);
- }
-
-
- /* see what sort of result we got */
-
- if(pinfo->dwAccessType == INTERNET_OPEN_TYPE_DIRECT)
- {
-/* No proxy configured */
-free(pinfo);
-return("");
- }
- else if(pinfo->dwAccessType == INTERNET_OPEN_TYPE_PROXY)
- {
-/* we have a proxy - now parse result string */
-/* if result string does NOT contain an '=' sign then */
-/* there is a single proxy for all protocols */
-for (p=(LPTSTR)pinfo->lpszProxy; *p && *p != '='; p++);
-if(!*p)
-{
- /* single proxy */
- /* allocate a new string to return */
- len = 1+strlen(pinfo->lpszProxy);
- proxyString = malloc (len*sizeof(TCHAR));
- if (proxyString == NULL)
- {
-getIeHttpProxyError="malloc failed (2)";
-free(pinfo);
-return(NULL);
- }
- strncpy(proxyString, pinfo->lpszProxy,len);
- proxyString[len]=0;
- free(pinfo);
- return(proxyString);
-}
-else
-{
- /* multiple space seperated proxies defined in the form */
- /* protocol=proxyhost[:port]*/
- /* we want the one marked "http=", if any. */
- p=(LPTSTR)pinfo->lpszProxy;
- while(*p && strncmp(p, "http=", 5))
- {
-for(; *p && *p != ' '; p++);
-if(*p) p++;
- }
- if(*p)
- {
-/* found the proxy */
-p+=5;
-for(q=p; *q && *q != ' '; q++);
-/* allocate a buffer for the proxy information */
-len=1+(q-p);
-proxyString=malloc(len*sizeof(TCHAR));
-if(proxyString==NULL)
-{
- getIeHttpProxyError="malloc failed (3)";
- free(pinfo);
- return(NULL);
-}
-strncpy(proxyString, p, len);
-proxyString[len]=0;
-free(pinfo);
-return(proxyString);
- }
- else
- {
-/* No http proxy in list */
-free(pinfo);
-return("");
- }
-}
- }
- else
- {
-/* InternetQueryOption returned a proxy type we don't know about*/
-getIeHttpProxyError="Unknown Proxy Type";
-
[Openvpn-devel] [PATCH 0/3] better --auto-proxy support for Windows
Hi, the auto-proxy support for Windows was rather sub-optimal. Since Internet Explorer 5 proxy settings were configured with the network or VPN connection, but OpenVPN always queried the settings for the LAN connection. Truely automatic proxy configuration via WPAD and PAC script was not used, either. This patch series tries to change that. Auto proxy detetction is done with WinHTTP which has support for WPAD, PAC and per connection proxy settings. Another thing that is changed is the time at which the auto proxy config takes place in OpenVPN. Instead of doing it once during start-up, potentially changed settings are now fetched once every connect. Heiko Hund (3): add MinGW WinHTTP compatibility layer do automatic proxy detection on Windows right query auto-proxy information when connecting configure.ac | 30 ++ init.c | 23 ++- openvpn.8|9 ++- options.c| 15 ++--- options.h|2 +- proxy.c | 173 +- proxy.h |4 +- win32.c | 108 win32.h | 61 9 files changed, 330 insertions(+), 95 deletions(-) Regards Heiko -- 1.7.5.4
[Openvpn-devel] [PATCH 1/3] add MinGW WinHTTP compatibility layer
MinGW is missing support for winhttp.dll which will be used for automatic
proxy server detection in Windows. Until it becomes available the workaround
performed is to provide wrapper functions and dynamically map the missing
library into the address space, get the function pointer for the actual API
and call it with the arguments provided.
To keep things managable and short in the source code two preprocessor macros
are defined that do most of the work.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
configure.ac | 30
win32.c | 108 ++
win32.h | 61
3 files changed, 199 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index a3789d9..42d46cb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -665,6 +665,36 @@ if test "${WIN32}" = "yes"; then
fi
dnl
+dnl Check if MinGW knows about WinHTTP API
+dnl
+if test "${WIN32}" = "yes"; then
+ AC_MSG_CHECKING([if MinGW knows about WinHTTP])
+ AC_TRY_LINK([
+ #include
+ #include
+ ], [
+ LPWSTR *url;
+ HINTERNET session;
+ WINHTTP_PROXY_INFO proxy_info;
+ WINHTTP_AUTOPROXY_OPTIONS proxy_options;
+ WINHTTP_CURRENT_USER_IE_PROXY_CONFIG ie_proxy_info;
+
+ WinHttpGetDefaultProxyConfiguration (_info);
+ WinHttpGetIEProxyConfigForCurrentUser (_proxy_info);
+ WinHttpDetectAutoProxyConfigUrl (WINHTTP_AUTO_DETECT_TYPE_DHCP |
WINHTTP_AUTO_DETECT_TYPE_DNS_A, url);
+ session = WinHttpOpen (NULL, WINHTTP_ACCESS_TYPE_NO_PROXY,
WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);
+ WinHttpGetProxyForUrl (session, L"http://openvpn.net;, _options,
_info);
+ WinHttpCloseHandle (session);
+ ], [
+ AC_MSG_RESULT([yes])
+ ], [
+ AC_MSG_RESULT([no.])
+ AC_MSG_NOTICE([Enabling WinHTTP compatibility layer.])
+ AC_DEFINE(USE_WINHTTP_COMPAT, 1, [Use the WinHTTP compatibility layer])
+ ])
+fi
+
+dnl
dnl check for LZO library
dnl
diff --git a/win32.c b/win32.c
index cf6cc2d..15743a8 100644
--- a/win32.c
+++ b/win32.c
@@ -1128,4 +1128,112 @@ win_get_tempdir()
}
return tmpdir;
}
+
+
+#ifdef USE_WINHTTP_COMPAT
+
+/*
+ * MinGW is missing support for winhttp.dll which is used for automatic
+ * proxy server detection. Until it becomes available the workaround is
+ * to dynamically map the library into the address space and get the
+ * function pointers for the APIs that are used. The two macros below
+ * do just that.
+ *
+ * PROVIDE_WIN32_LIBRARY provides means to access API functions.
+ * Arguments: LIB - name of the DLL to load
+ *
+ * DEFINE_WIN32_WRAPPER defines a wrapper function around the
+ * original API provoded by the library. The original API can
+ * be accessed within the wrapper as _ (see Arguments).
+ * Arguments: LIB name of the DLL the function is exported in
+ *ERR value to return in case something goes wrong
+ *RET API function's return value type
+ *FUNC exported name of the API function
+ *ARGS declaration of the API function arguments
+ *BODY the wrapper function's body
+ */
+
+#define PROVIDE_WIN32_LIBRARY(LIB)\
+ static HMODULE get_ ## LIB ## _library () \
+ { \
+static HMODULE lib = NULL;\
+ \
+if (lib == NULL) \
+ { \
+ char name[MAX_PATH]; \
+ UINT len = GetSystemDirectory (name, sizeof (name)); \
+ if (len == 0) \
+ return NULL;\
+ \
+ strncpy (name + len, "\\" #LIB ".dll", sizeof (name) - len); \
+ name[sizeof (name) - 1] = '\0'; \
+ \
+ lib = LoadLibrary (name); \
+ } \
+ \
+return lib; \
+ }
+
+#define DEFINE_WIN32_WRAPPER(LIB, ERR, RET, FUNC, ARGS, BODY) \
+ RET FUNC ARGS\
+ {\
+typedef RET (WINAPI *(FUNC ## _fn)) AR
[Openvpn-devel] [PATCH 3/3] query auto-proxy information when connecting
Delaying automatic proxy detection from the time options are parsed
to connection initialization makes sense as proxy information may have
changed since the tunnel was established. Especially if the network
connection or PAC script changed since then. Now, if openvpn receives
an SIGUSR1 it requeries the settings and uses them.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
init.c| 23 +++
options.c |8 ++--
options.h |2 +-
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/init.c b/init.c
index 4a16fba..8219a11 100644
--- a/init.c
+++ b/init.c
@@ -388,15 +388,30 @@ init_proxy_dowork (struct context *c)
#else
const bool did_http = false;
#endif
+ struct auto_proxy_info *auto_proxy_info = NULL;
uninit_proxy_dowork (c);
+ if (c->options.auto_proxy)
+{
+ char *error;
+ char url[128];
+
+ openvpn_snprintf (url, sizeof (url), "%s://%s:%d/",
+ (proto_is_udp (c->options.ce.proto) ? "socks" :
"https"),
+ c->options.ce.remote, c->options.ce.remote_port);
+
+ auto_proxy_info = get_proxy_settings (url, , >c2.gc);
+ if (error)
+ msg (M_WARN, "PROXY: %s", error);
+}
+
#ifdef ENABLE_HTTP_PROXY
- if (c->options.ce.http_proxy_options || c->options.auto_proxy_info)
+ if (c->options.ce.http_proxy_options || auto_proxy_info)
{
/* Possible HTTP proxy user/pass input */
c->c1.http_proxy = http_proxy_new (c->options.ce.http_proxy_options,
-c->options.auto_proxy_info);
+auto_proxy_info);
if (c->c1.http_proxy)
{
did_http = true;
@@ -406,13 +421,13 @@ init_proxy_dowork (struct context *c)
#endif
#ifdef ENABLE_SOCKS
- if (!did_http && (c->options.ce.socks_proxy_server ||
c->options.auto_proxy_info))
+ if (!did_http && (c->options.ce.socks_proxy_server || auto_proxy_info))
{
c->c1.socks_proxy = socks_proxy_new (c->options.ce.socks_proxy_server,
c->options.ce.socks_proxy_port,
c->options.ce.socks_proxy_authfile,
c->options.ce.socks_proxy_retry,
- c->options.auto_proxy_info);
+ auto_proxy_info);
if (c->c1.socks_proxy)
{
c->c1.socks_proxy_owned = true;
diff --git a/options.c b/options.c
index 62c2ac8..c6243cd 100644
--- a/options.c
+++ b/options.c
@@ -2025,7 +2025,7 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
msg (M_USAGE, "--remote MUST be used in TCP Client mode");
#ifdef ENABLE_HTTP_PROXY
- if ((ce->http_proxy_options || options->auto_proxy_info) && ce->proto !=
PROTO_TCPv4_CLIENT)
+ if ((ce->http_proxy_options || options->auto_proxy) && ce->proto !=
PROTO_TCPv4_CLIENT)
msg (M_USAGE, "--http-proxy or --auto-proxy MUST be used in TCP Client
mode (i.e. --proto tcp-client)");
#endif
@@ -4674,12 +4674,8 @@ add_option (struct options *options,
#ifdef GENERAL_PROXY_SUPPORT
else if (streq (p[0], "auto-proxy"))
{
- char *error = NULL;
-
VERIFY_PERMISSION (OPT_P_GENERAL);
- options->auto_proxy_info = get_proxy_settings ("https://openvpn.net;,
, >gc);
- if (error)
- msg (M_WARN, "PROXY: %s", error);
+ options->auto_proxy = true;
}
else if (streq (p[0], "show-proxy-settings"))
{
diff --git a/options.h b/options.h
index 8a51502..47b7ddb 100644
--- a/options.h
+++ b/options.h
@@ -193,7 +193,7 @@ struct options
#endif
#ifdef GENERAL_PROXY_SUPPORT
- struct auto_proxy_info *auto_proxy_info;
+ bool auto_proxy;
#endif
#if HTTP_PROXY_FALLBACK
--
1.7.5.4
[Openvpn-devel] [PATCH 2/3] do automatic proxy detection on Windows right
Automatic proxy detection is now done using WinHTTP and its built
in support for WPAD and PAC. This also means that settings for the
currently active network connection are queried, instead of using
the default one all the time.
If WPAD or a PAC script are not configured or fail, the static Internet
Options proxy settings from the Control Panel are taken into account.
If those are unavailable as well, the default proxy configuration, set
with proxycfg.exe, is used.
Closes ticket #24.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
openvpn.8 |9 ++--
options.c |9 ++--
proxy.c | 173 ++--
proxy.h |4 +-
4 files changed, 110 insertions(+), 85 deletions(-)
diff --git a/openvpn.8 b/openvpn.8
index 7118737..3855e86 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -490,13 +490,14 @@ If the HTTP proxy server requires a password, it will be
queried from
stdin or the management interface. If the underlying OS doesn't support an
API for
returning proxy settings, a direct connection will be attempted.
Currently, only Windows clients support this option via the
-InternetQueryOption API.
+WinHTTP API.
This option exists in OpenVPN 2.1 or higher.
.\"*
.TP
-.B \-\-show-proxy-settings
-Show sensed HTTP or SOCKS proxy settings. Currently, only Windows clients
-support this option.
+.B \-\-show-proxy-settings [url]
+Show sensed HTTP or SOCKS proxy settings. The optional URL parameter is used
+with the PAC script, if there is one detected or configured. Currently, only
+Windows clients support this option.
.\"*
.TP
.B \-\-http-proxy server port [authfile|'auto'|'auto-nct'] [auth-method]
diff --git a/options.c b/options.c
index 77e7c7f..62c2ac8 100644
--- a/options.c
+++ b/options.c
@@ -118,7 +118,7 @@ static const char usage_message[] =
"--connect-retry-max n : Maximum connection attempt retries, default
infinite.\n"
#ifdef GENERAL_PROXY_SUPPORT
"--auto-proxy: Try to sense proxy settings (or lack thereof)
automatically.\n"
- "--show-proxy-settings : Show sensed proxy settings.\n"
+ "--show-proxy-settings [url] : Show sensed proxy settings for url.\n"
#endif
#ifdef ENABLE_HTTP_PROXY
"--http-proxy s p [up] [auth] : Connect to remote host\n"
@@ -4677,17 +4677,18 @@ add_option (struct options *options,
char *error = NULL;
VERIFY_PERMISSION (OPT_P_GENERAL);
- options->auto_proxy_info = get_proxy_settings (, >gc);
+ options->auto_proxy_info = get_proxy_settings ("https://openvpn.net;,
, >gc);
if (error)
msg (M_WARN, "PROXY: %s", error);
}
else if (streq (p[0], "show-proxy-settings"))
{
struct auto_proxy_info *pi;
+ const char *url = p[1] ? p[1] : "https://openvpn.net;;
char *error = NULL;
VERIFY_PERMISSION (OPT_P_GENERAL);
- pi = get_proxy_settings (, >gc);
+ pi = get_proxy_settings (url, , >gc);
if (pi)
{
msg (M_INFO|M_NOPREFIX, "HTTP Server: %s", np(pi->http.server));
@@ -4698,7 +4699,7 @@ add_option (struct options *options,
if (error)
msg (msglevel, "Proxy error: %s", error);
#ifdef WIN32
- show_win_proxy_settings (M_INFO|M_NOPREFIX);
+ show_win_proxy_settings (url, M_INFO|M_NOPREFIX);
#endif
openvpn_exit (OPENVPN_EXIT_STATUS_GOOD); /* exit point */
}
diff --git a/proxy.c b/proxy.c
index b00532c..3403c1a 100644
--- a/proxy.c
+++ b/proxy.c
@@ -924,42 +924,99 @@ static void dummy(void) {}
#ifdef WIN32
-#if 0
-char *
-get_windows_internet_string (const DWORD dwOption, struct gc_arena *gc)
+static char *
+get_windows_proxy_settings (const char *url, struct gc_arena *gc)
{
- DWORD size = 0;
- char *ret = NULL;
+ char *retval = NULL;
+ LPWSTR proxy = NULL;
+ LPWSTR auto_config_url = NULL;
+ BOOL auto_detect = FALSE;
+ WINHTTP_PROXY_INFO proxy_info;
+ WINHTTP_CURRENT_USER_IE_PROXY_CONFIG proxy_config;
+
+ if (WinHttpGetIEProxyConfigForCurrentUser (_config))
+{
+ auto_detect = proxy_config.fAutoDetect;
+ auto_config_url = proxy_config.lpszAutoConfigUrl;
+ proxy = proxy_config.lpszProxy;
+ GlobalFree (proxy_config.lpszProxyBypass);
+}
+ else if (GetLastError () == ERROR_FILE_NOT_FOUND &&
+ WinHttpGetDefaultProxyConfiguration (_info))
+{
+ if (proxy_info.dwAccessType == WINHTTP_ACCESS_TYPE_NAMED_PROXY)
+ {
+ proxy = proxy_info.lpszProxy;
+ GlobalFree (proxy_info.lpszProxyBypass);
+ }
+}
+ else /* failed to get proxy info, try to auto detect it */
+{
+ auto_detect = TRUE;
+}
- /* Initially, get size of return buffer */
- InternetQueryOption (NULL, dwOption, NULL, );
- if (size)
+ if (auto_detect)
{
- /* Now g
Re: [Openvpn-devel] [PATCH 0/3] better --auto-proxy support for Windows
On Wednesday 17 August 2011 15:59:10 Alon Bar-Lev wrote: > Won't it make it harder to configure openvpn as service? I don't see how. Please elaborate. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH 0/3] better --auto-proxy support for Windows
On Wednesday 17 August 2011 16:07:42 Alon Bar-Lev wrote: > How do you configure Internet Explorer proxy detection for local system > account? Or... alternatively you need to create a user for openvpn > service, login, execute IE, set whatever. > Quite difficult for unattended setup. > Well, maybe find places in registry where IE stores the settings... I don't think that's a problem. If no IE proxy configuration can be fetched, the default config set with proxycfg will be used. And besides that there's still the option to manually configure proxy settings in openvpn directly for such setups. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] remove function is_proto_tcp()
The implementation of is_proto_tcp() was invalid since the IPv6 stuff got
merged into master. There's proto_is_tcp() that does the same job right.
Remove is_proto_tcp() and make its only caller use proto_is_tcp() instead.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
options.c |2 +-
socket.h |6 --
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/options.c b/options.c
index 77e7c7f..902cc81 100644
--- a/options.c
+++ b/options.c
@@ -2409,7 +2409,7 @@ options_postprocess_mutate_ce (struct options *o, struct
connection_entry *ce)
ce->local_port = 0;
/* if protocol forcing is enabled, disable all protocols except for the
forced one */
- if (o->proto_force >= 0 && is_proto_tcp(o->proto_force) !=
is_proto_tcp(ce->proto))
+ if (o->proto_force >= 0 && proto_is_tcp(o->proto_force) !=
proto_is_tcp(ce->proto))
ce->flags |= CE_DISABLED;
}
diff --git a/socket.h b/socket.h
index 33da53c..6336f92 100644
--- a/socket.h
+++ b/socket.h
@@ -563,12 +563,6 @@ legal_ipv4_port (int port)
return port > 0 && port < 65536;
}
-static inline int
-is_proto_tcp(const int p)
-{
- return p > 0; /* depends on the definition of PROTO_x */
-}
-
static inline bool
link_socket_proto_connection_oriented (int proto)
{
--
1.7.5.4
[Openvpn-devel] [PATCH] fix warnings in event.c when building for win32-64
When compiling for 64-bit Windows gcc warns about
"cast from pointer to integer of different size"
on two occasions in file event.c, due to invalid casting.
This patch removes the type casts and uses the correct
format specifier instead.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
event.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/event.c b/event.c
index 51b17b3..b6ed673 100644
--- a/event.c
+++ b/event.c
@@ -214,9 +214,9 @@ we_ctl (struct event_set *es, event_t event, unsigned int
rwflags, void *arg)
{
struct we_set *wes = (struct we_set *) es;
- dmsg (D_EVENT_WAIT, "WE_CTL n=%d ev=0x%08x rwflags=0x%04x arg=" ptr_format,
+ dmsg (D_EVENT_WAIT, "WE_CTL n=%d ev=%p rwflags=0x%04x arg=" ptr_format,
wes->n_events,
- (unsigned int)event,
+ event,
rwflags,
(ptr_type)arg);
@@ -344,9 +344,9 @@ we_wait (struct event_set *es, const struct timeval *tv,
struct event_set_return
if (check_debug_level (D_EVENT_WAIT)) {
int i;
for (i = 0; i < wes->n_events; ++i)
- dmsg (D_EVENT_WAIT, "[%d] ev=0x%08x rwflags=0x%04x arg=" ptr_format,
+ dmsg (D_EVENT_WAIT, "[%d] ev=%p rwflags=0x%04x arg=" ptr_format,
i,
- (unsigned int)wes->events[i],
+ wes->events[i],
wes->esr[i].rwflags,
(ptr_type)wes->esr[i].arg);
}
--
1.7.5.4
[Openvpn-devel] [PATCH] add .gitignore to official repository
This .gitignore make the output of git status a lot more readable. It was made from the dynamically generated files that showed after using both build system. Signed-off-by: Samuli Seppänen <sam...@openvpn.ne> Signed-off-by: Heiko Hund <heiko.h...@sophos.com> --- .gitignore | 40 1 files changed, 40 insertions(+), 0 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..3d12f5d --- /dev/null +++ b/.gitignore @@ -0,0 +1,40 @@ +*.[oa] +*.dll +*.exe +*.mak +*.obj +*.pyc +*.so +.deps +Makefile +Makefile.in +aclocal.m4 +autodefs.h +autom4te.cache +config.guess +config.h +config.h.in +config.log +config.status +config.sub +configure +configure.h +depcomp +dist/ +install-sh +install-win32/settings +install-win32/tmp +missing +openvpn +openvpn.8.html +openvpn.exe.manifest +openvpnserv.exe.manifest +openvpn.spec +stamp-h1 +t_client.sh +tap-win32/SOURCES +tap-win32/amd64/ +tap-win32/i386/ +tapinstall/ +vc90.idb +win/version_m4_vars.tmp -- 1.7.5.4
[Openvpn-devel] [PATCH-UPDATE] define IN6_ARE_ADDR_EQUAL macro for WIN32
Windows headers do not define the IN6_ARE_ADDR_EQUAL macro. It needs to be defined locally when building for WIN32. Signed-off-by: Heiko Hund <heiko.h...@sophos.com> Update: remove check for USE_PF_INET6 since commit eb23089183745853fac9414d45a559a478ef51d6 removed the definition of this macro. IPv6 is now always compiled in. --- win32.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/win32.h b/win32.h index 528af6c..5b18e3c 100644 --- a/win32.h +++ b/win32.h @@ -41,6 +41,12 @@ * development environment. */ +/* MSVC headers do not define this macro, so do it here */ +#ifndef IN6_ARE_ADDR_EQUAL +#define IN6_ARE_ADDR_EQUAL(a,b) \ + (memcmp ((const void*)(a), (const void*)(b), sizeof (struct in6_addr)) == 0) +#endif + void init_win32 (void); void uninit_win32 (void); -- 1.7.5.4
[Openvpn-devel] [PATCH] lowercase include header name in syshead.h
Cross compiling for Windows is broken since commit 739fa9881f12e67dc8b9cadc7230e59e7fe42423 added the mixed case header name "NtDDNdis.h" to the file. While this header exists in a MinGW build environment it's lowercase there. Windows doesn't mind the case of a file name, but Linux does. So, lowercasing the filename will make openvpn build in both worlds. Signed-off-by: Heiko Hund <heiko.h...@sophos.com> --- syshead.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/syshead.h b/syshead.h index 87cc369..e208d4c 100644 --- a/syshead.h +++ b/syshead.h @@ -342,7 +342,7 @@ #ifdef WIN32 #include -#include +#include #include /* The following two headers are needed of PF_INET6 */ #include -- 1.7.5.4
[Openvpn-devel] [PATCH] add --mark option to set SO_MARK sockopt
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
init.c|1 +
openvpn.8 |6 ++
options.c | 14 ++
options.h |3 +++
socket.c | 13 +
socket.h |1 +
6 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/init.c b/init.c
index 0530b10..e8c9aab 100644
--- a/init.c
+++ b/init.c
@@ -2640,6 +2640,7 @@ do_init_socket_1 (struct context *c, const int mode)
c->options.mtu_discover_type,
c->options.rcvbuf,
c->options.sndbuf,
+ c->options.mark,
sockflags);
}
diff --git a/openvpn.8 b/openvpn.8
index dc76464..55a9b80 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -1371,6 +1371,12 @@ Set the TCP/UDP socket receive buffer size.
Currently defaults to 65536 bytes.
.\"*
.TP
+.B \-\-mark value
+Mark encrypted packets being sent with value. The mark value can be
+matched in policy routing and packetfilter rules. This option is
+only supported in Linux and does nothing on other operating systems.
+.\"*
+.TP
.B \-\-socket-flags flags...
Apply the given flags to the OpenVPN transport socket.
Currently, only
diff --git a/options.c b/options.c
index a6230de..d410782 100644
--- a/options.c
+++ b/options.c
@@ -280,6 +280,10 @@ static const char usage_message[] =
" or --fragment max value, whichever is lower.\n"
"--sndbuf size : Set the TCP/UDP send buffer size.\n"
"--rcvbuf size : Set the TCP/UDP receive buffer size.\n"
+#ifdef TARGET_LINUX
+ "--mark value: Mark encrypted packets being sent with value. The mark
value\n"
+ " can be matched in policy routing and packetfilter
rules.\n"
+#endif
"--txqueuelen n : Set the tun/tap TX queue length to n (Linux only).\n"
"--mlock : Disable Paging -- ensures key material and tunnel\n"
" data will never be written to disk.\n"
@@ -1473,6 +1477,9 @@ show_settings (const struct options *o)
#endif
SHOW_INT (rcvbuf);
SHOW_INT (sndbuf);
+#ifdef TARGET_LINUX
+ SHOW_INT (mark);
+#endif
SHOW_INT (sockflags);
SHOW_BOOL (fast_io);
@@ -4520,6 +4527,13 @@ add_option (struct options *options,
VERIFY_PERMISSION (OPT_P_SOCKBUF);
options->sndbuf = positive_atoi (p[1]);
}
+ else if (streq (p[0], "mark") && p[1])
+{
+#ifdef TARGET_LINUX
+ VERIFY_PERMISSION (OPT_P_GENERAL);
+ options->mark = atoi(p[1]);
+#endif
+}
else if (streq (p[0], "socket-flags"))
{
int j;
diff --git a/options.h b/options.h
index e723b66..d792872 100644
--- a/options.h
+++ b/options.h
@@ -342,6 +342,9 @@ struct options
int rcvbuf;
int sndbuf;
+ /* mark value */
+ int mark;
+
/* socket flags */
unsigned int sockflags;
diff --git a/socket.c b/socket.c
index 76c760c..a2f9511 100644
--- a/socket.c
+++ b/socket.c
@@ -779,6 +779,15 @@ socket_set_tcp_nodelay (int sd, int state)
#endif
}
+static void
+socket_set_mark (int sd, int mark)
+{
+#ifdef TARGET_LINUX
+ if (mark && setsockopt (sd, SOL_SOCKET, SO_MARK, , sizeof (mark)) != 0)
+msg (M_WARN, "NOTE: setsockopt SO_MARK=%d failed", mark);
+#endif
+}
+
static bool
socket_set_flags (int sd, unsigned int sockflags)
{
@@ -1599,6 +1608,7 @@ link_socket_init_phase1 (struct link_socket *sock,
int mtu_discover_type,
int rcvbuf,
int sndbuf,
+int mark,
unsigned int sockflags)
{
ASSERT (sock);
@@ -1716,6 +1726,9 @@ link_socket_init_phase1 (struct link_socket *sock,
/* set socket buffers based on --sndbuf and --rcvbuf options */
socket_set_buffers (sock->sd, >socket_buffer_sizes);
+ /* set socket to --mark packets with given value */
+ socket_set_mark (sock->sd, mark);
+
resolve_bind_local (sock);
resolve_remote (sock, 1, NULL, NULL);
}
diff --git a/socket.h b/socket.h
index b385fb2..a9a29c5 100644
--- a/socket.h
+++ b/socket.h
@@ -324,6 +324,7 @@ link_socket_init_phase1 (struct link_socket *sock,
int mtu_discover_type,
int rcvbuf,
int sndbuf,
+int mark,
unsigned int sockflags);
void link_socket_init_phase2 (struct link_socket *sock,
--
1.7.4.1
Re: [Openvpn-devel] [PATCH 1/4] WIN32: Check for windres tool
On Sunday 07 August 2011 12:59:14 Bertrand Jacquin wrote: > + AC_CHECK_TOOL(WINDRES, windres) The values should be quoted in square brackets besides that ACK. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH 3/4] Win32: Fill "Details" properties for openvpn.exe
On Sunday 07 August 2011 12:59:16 Bertrand Jacquin wrote: > @@ -161,6 +168,11 @@ dist_noinst_DATA += openvpn.8 > nodist_html_DATA = openvpn.8.html > openvpn.8.html: $(srcdir)/openvpn.8 > $(MAN2HTML) < $(srcdir)/openvpn.8 > openvpn.8.html > + > +comma = , > + > +%.o: %.rc > + $(WINDRES) -D _VERSION_=$(subst .,$(comma),$(VERSION)),0 -i $< -o $@ > else > dist_man_MANS = openvpn.8 > endif This will at least break compilation on master where #define VERSION "2.x-master" _VERSION_ needs needs to be stricly numerical. Maybe we could define a WINDOWS_VERSION a,b,c,0 in version.m4 for this. Or even have separate major, minor and patch version definitions in there that could be used to build the versions in the .rc file itself. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH 1/3] Win32: Add OpenVPN RC file to add fill "Details" exe properties tabs
On Sunday 07 August 2011 13:08:22 Bertrand Jacquin wrote: > +1 VERSIONINFO Could use VS_VERSION_INFO instead of 1 > + FILEVERSION_VERSION_ > + PRODUCTVERSION _VERSION_ See my other mail about the version. > +BLOCK "040904b0" /* en_US, Unicode */ Openvpn itself is not compiled as Unicode binary, so 0409 for ASCII would be more precise. > + VALUE "CompanyName", PACKAGE_NAME "\0" > + VALUE "FileDescription", PACKAGE_NAME "\0" > + VALUE "FileVersion", PACKAGE_VERSION "\0" > + VALUE "InternalName", PACKAGE_TARNAME "\0" > + VALUE "OriginalFilename", PACKAGE_TARNAME ".exe\0" > + VALUE "ProductName", PACKAGE_NAME "\0" > + VALUE "ProductVersion", PACKAGE_VERSION "\0" > + VALUE "LegalCopyright", "(C) 2002-2010 " PACKAGE_NAME " > Technologies, Inc.\0" The \0's are not needed here. > +VALUE "Translation", 0x409, 0x4b0 Same, no Unicode. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] add MinGW WinHTTP compatibility import library
MinGW is missing support for winhttp.dll which will be used for automatic
proxy server detection in Windows. Until it becomes available the workaround
performed is to define the used constants and function prototypes in openvpn
and build a WINHTTP.dll import library in the build process.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
Makefile.am | 15 +
configure.ac | 53 ++
win32.c |2 +
win32.h | 65 +
winhttp32.def |8 +++
winhttp64.def |8 +++
6 files changed, 151 insertions(+), 0 deletions(-)
create mode 100644 winhttp32.def
create mode 100644 winhttp64.def
diff --git a/Makefile.am b/Makefile.am
index 266a5af..b1c0a1b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -74,6 +74,8 @@ dist_noinst_DATA = \
openvpn.spec \
COPYRIGHT.GPL \
PORTS \
+ winhttp32.def \
+ winhttp64.def \
INSTALL-win32.txt \
service-win32/msvc.mak
@@ -163,3 +165,16 @@ openvpn.8.html: $(srcdir)/openvpn.8
else
dist_man_MANS = openvpn.8
endif
+
+if BUILD_WINHTTP_IMPLIB
+openvpn_LDADD = libwinhttp.a
+
+if WIN64
+libwinhttp.a: winhttp64.def
+ $(DLLTOOL) -k -d winhttp64.def -l libwinhttp.a
+else
+libwinhttp.a: winhttp32.def
+ $(DLLTOOL) -k -d winhttp32.def -l libwinhttp.a
+endif
+
+endif
diff --git a/configure.ac b/configure.ac
index a3789d9..7516d68 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,6 +62,22 @@ case "${host}" in
;;
esac
+dnl Check for 64 bit Windows
+WIN64="no"
+if test "${WIN32}" = "yes"; then
+ AC_MSG_CHECKING([if building for 64 bit Windows])
+ case "${host}" in
+*64-*-*)
+ AC_MSG_RESULT([yes])
+ WIN64="yes"
+ ;;
+*)
+ AC_MSG_RESULT([no])
+ ;;
+ esac
+fi
+
+
AC_ARG_ENABLE(lzo,
[ --disable-lzo Disable LZO compression support],
[LZO="$enableval"],
@@ -665,6 +681,42 @@ if test "${WIN32}" = "yes"; then
fi
dnl
+dnl Check if MinGW knows about WinHTTP API
+dnl
+if test "${WIN32}" = "yes"; then
+ AC_MSG_CHECKING([if MinGW knows about WinHTTP])
+ AC_TRY_LINK([
+ #include
+ #include
+ ], [
+ LPWSTR *url;
+ HINTERNET session;
+ WINHTTP_PROXY_INFO proxy_info;
+ WINHTTP_AUTOPROXY_OPTIONS proxy_options;
+ WINHTTP_CURRENT_USER_IE_PROXY_CONFIG ie_proxy_info;
+
+ WinHttpGetDefaultProxyConfiguration (_info);
+ WinHttpGetIEProxyConfigForCurrentUser (_proxy_info);
+ WinHttpDetectAutoProxyConfigUrl (WINHTTP_AUTO_DETECT_TYPE_DHCP |
WINHTTP_AUTO_DETECT_TYPE_DNS_A, url);
+ session = WinHttpOpen (NULL, WINHTTP_ACCESS_TYPE_NO_PROXY,
WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);
+ WinHttpGetProxyForUrl (session, L"http://openvpn.net;, _options,
_info);
+ WinHttpCloseHandle (session);
+ ], [
+ AC_MSG_RESULT([yes])
+ OPENVPN_ADD_LIBS(-lwinhttp)
+ AC_DEFINE([HAVE_WINHTTP], [1], [WinHTTP is available in MinGW])
+ ], [
+ AC_MSG_RESULT([no])
+ AM_CONDITIONAL([BUILD_WINHTTP_IMPLIB], [true])
+ AC_MSG_NOTICE([Compiling own WinHTTP import library.])
+ AC_CHECK_TOOL([DLLTOOL], [dlltool])
+ if test -z "$DLLTOOL"; then
+ AC_MSG_ERROR([Could not find dlltool. Make sure you have binutils for
Windows.])
+ fi
+ ])
+fi
+
+dnl
dnl check for LZO library
dnl
@@ -920,6 +972,7 @@ AC_SUBST(TAP_WIN32_MIN_MINOR)
win32datadir="\${datadir}/${PACKAGE}-win32"
AC_SUBST(win32datadir)
AM_CONDITIONAL(WIN32, test "${WIN32}" = "yes")
+AM_CONDITIONAL(WIN64, test "${WIN64}" = "yes")
# workaround for http://msdn.microsoft.com/en-us/library/aa384252%28v=VS.85%29.aspx
+ */
+#ifdef HAVE_WINHTTP
+
+#include
+
+#else /* HAVE_WINHTTP */
+
+#include
+#include
+
+/* WINHTTP_PROXY_INFO dwAccessType constants */
+/* and WinHttpOpen() access_type */
+#define WINHTTP_ACCESS_TYPE_NO_PROXY 1
+#define WINHTTP_ACCESS_TYPE_NAMED_PROXY 3
+
+/* WinHttpDetectAutoProxyConfigUrl() flags */
+#define WINHTTP_AUTO_DETECT_TYPE_DHCP 1
+#define WINHTTP_AUTO_DETECT_TYPE_DNS_A 2
+
+/* WINHTTP_AUTOPROXY_OPTIONS dwFlags */
+#define WINHTTP_AUTOPROXY_CONFIG_URL 2
+
+/* WinHttpOpen() proxy and bypass values */
+#define WINHTTP_NO_PROXY_NAME0
+#define WINHTTP_NO_PROXY_BYPASS 0
+
+typedef struct {
+ DWORD dwAccessType;
+ LPWSTR lpszProxy;
+ LPWSTR lpszProxyBypass;
+} WINHTTP_PROXY_INFO;
+
+typedef struct {
+ BOOL fAutoDetect;
+ LPWSTR lpszAutoConfigUrl;
+ LPWSTR lpszProxy;
+ LPWSTR lpszProxyBypass;
+} WINHTTP_CURRENT_USER_IE_PROXY_CONFIG;
+
+typedef struct {
+ DWORD dwFlags;
+ DWORD dwAutoDetectFlags;
+ LPCWSTR lpszAutoConfigUrl;
+ LPVOID lpvReserved;
+ DWORD dwReserved;
+ BOOLfAutoLogonIfChallenged;
+
Re: [Openvpn-devel] Summary of the IRC meeting / sprint (8th Sep 2011)
On Friday 09 September 2011 10:21:03 Samuli Seppänen wrote: > Discussed the "Better --auto-proxy support for Windows" patchset: > > <http://thread.gmane.org/gmane.network.openvpn.devel/4927> > > Suggested the following modifications: > > Patch [1/3]: Add MinGW WinHTTP compatibility layer > > - Make use of import libraries: > <http://www.mingw.org/wiki/CreateImportLibraries> See my patch from yesterday. > Patch [2/3]: Do automatic proxy detection on Windows right... > Patch [3/3]: Query auto-proxy information when connecting... > > - Verify that these patches play well with existing functionality: > - PROXY queries from the management interface > - http-proxy-fallback option > - http-proxy-override option Have done the tests now: --http-proxy-override works. The server configured here overrides the one from --auto-proxy. --http-proxy-fallback works as long as no proxy is configured via --http-proxy or --auto-proxy. In that case ">PROXY:NEED_NOW" can be answered with "http-proxy-fallback " via management interface and the fallback proxy entered is used. So, as expected, we're still fine regarding compatibiliy with these options. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Snapshot openvpn-2.x-20110909-master-install.exe fails
On Tuesday 20 September 2011 10:35:33 Krashan Brahmanjara wrote: > > Krashan: how can I reproduce this? Is trying to connect to an OpenVPN > > server enough? > > I installed this package and start openvpnggui only. It doesn't start at > all. The GUI runs openvpn during startup to get version information. That's where the error occurs. ws2_32.dll on Windows XP doesn't have inet_pton and inet_ntop. However, openvpn has its own version of these functions on Windows. I wonder why the linker is looking for it in the dll? I assume it has something to do with the import library on the build system overriding the symbols or maybe it's just that _MSC_VER was not defined. Samuli could you investigate? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Snapshot openvpn-2.x-20110909-master-install.exe fails
On Tuesday 20 September 2011 12:28:30 Heiko Hund wrote: > or maybe it's just that _MSC_VER was not defined Misread the code, it's an #ifndef. Could someone test if replacing the #ifndef _MSC_VER lines in socket.c and win32.h with #if WINVER < 0x0600 leads to a problem when building with MSVC. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Snapshot openvpn-2.x-20110909-master-install.exe fails
On Monday 26 September 2011 14:13:30 Samuli Seppänen wrote: > Ok, did as suggested for socket.c and win32.h and got the following > build failure using MSVC: > > <http://pastebin.com/xZ8J2yrq> ---8<-- c:\users\samuli\openvpn-build\openvpn\win32.h(282) : error C2373: 'inet_ntop' : redefinition; different type modifiers ---8<-- This is hopefully just because MSVC still believes it's building for Vista or later. Does the message disappear if you include syshead.h in win32.h? In there WINVER is already defined to signal building for XP. If that doesn't help, you should also check in if the declaration of inet_ntop is #ifdef'd taking WINVER into account. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Management interface doesn't handle PKCS11 tokens with umlaut characters in the label
Aivo On Friday 14 October 2011 09:34:38 Samuli Seppänen wrote: > > Would it be possible to patch OpenVPN in some way, so that the umlaut > > characters doesn't get stripped in the management interface … or perhaps > > there's some other, more robust way of handling such kind of smart-card > > authentication? > > James, who is responsible for the management interface, can probably fix > this easily. Have you checked with git master. I believe commit 2627335ac2605d0987a68ce97a0a2c4efbe25159 should have fixed most of the non- ASCII charset related problems. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] add check for struct in_pktinfo.ipi_spec_dst
While Windows has struct in_pktinfo it's missing the ipi_spec_dst
member. The current autoconf check needs to be extended to also
check for availablity of ipi_spec_dst for openvpn to compile cleanly.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
configure.ac |6 ++
socket.h |2 +-
syshead.h|2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index a4d68e6..a89c89c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -503,6 +503,12 @@ AC_CHECK_TYPE(
[AC_DEFINE(HAVE_IN_PKTINFO, 1, [struct in_pktinfo needed for IP_PKTINFO
support])],
[],
[#include "syshead.h"])
+AC_CHECK_MEMBER(
+ [struct in_pktinfo.ipi_spec_dst],
+ [AC_DEFINE(HAVE_IPI_SPEC_DST, 1, [struct in_pktinfo.ipi_spec_dst needed
for IP_PKTINFO support])],
+ [],
+ [#include "syshead.h"])
+
AC_CHECK_SIZEOF(unsigned int)
AC_CHECK_SIZEOF(unsigned long)
diff --git a/socket.h b/socket.h
index 4a4f75d..63ef53e 100644
--- a/socket.h
+++ b/socket.h
@@ -586,7 +586,7 @@ addr_defined_ipi (const struct link_socket_actual *lsa)
#if ENABLE_IP_PKTINFO
if (!lsa) return 0;
switch (lsa->dest.addr.sa.sa_family) {
-#ifdef HAVE_IN_PKTINFO
+#if defined(HAVE_IN_PKTINFO) && defined(HAVE_IPI_SPEC_DST)
case AF_INET: return lsa->pi.in4.ipi_spec_dst.s_addr != 0;
#elif defined(IP_RECVDSTADDR)
case AF_INET: return lsa->pi.in4.s_addr != 0;
diff --git a/syshead.h b/syshead.h
index f3c0ac9..200cdb8 100644
--- a/syshead.h
+++ b/syshead.h
@@ -404,7 +404,7 @@
* Does this platform support linux-style IP_PKTINFO
* or bsd-style IP_RECVDSTADDR ?
*/
-#if defined(ENABLE_MULTIHOME) &&
((defined(HAVE_IN_PKTINFO)&(IP_PKTINFO)) || defined(IP_RECVDSTADDR)) &&
defined(HAVE_MSGHDR) && defined(HAVE_CMSGHDR) && defined(HAVE_IOVEC) &&
defined(CMSG_FIRSTHDR) && defined(CMSG_NXTHDR) && defined(HAVE_RECVMSG) &&
defined(HAVE_SENDMSG)
+#if defined(ENABLE_MULTIHOME) &&
((defined(HAVE_IN_PKTINFO)&(HAVE_IPI_SPEC_DST)&(IP_PKTINFO)) ||
defined(IP_RECVDSTADDR)) && defined(HAVE_MSGHDR) && defined(HAVE_CMSGHDR) &&
defined(HAVE_IOVEC) && defined(CMSG_FIRSTHDR) && defined(CMSG_NXTHDR) &&
defined(HAVE_RECVMSG) && defined(HAVE_SENDMSG)
#define ENABLE_IP_PKTINFO 1
#else
#define ENABLE_IP_PKTINFO 0
--
1.7.4.1
Re: [Openvpn-devel] [PATCH 8/8] Fixed a typo when initialising cryptoapi certs
On Monday 31 October 2011 15:29:21 Adriaan de Jong wrote: > Signed-off-by: Adriaan de Jong <dej...@fox-it.com> > --- > ssl_openssl.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/ssl_openssl.c b/ssl_openssl.c > index 391968a..b95944c 100644 > --- a/ssl_openssl.c > +++ b/ssl_openssl.c > @@ -339,7 +339,7 @@ tls_ctx_load_cryptoapi(struct tls_root_ctx *ctx, const > char *cryptoapi_cert) /* Load Certificate and Private Key */ >if (!SSL_CTX_use_CryptoAPI_certificate (ctx->ctx, cryptoapi_cert)) > msg (M_SSLERR, "Cannot load certificate \"%s\" from Microsoft > Certificate Store", -options->cryptoapi_cert); > +cryptoapi_cert); > } > #endif /* WIN32 */ ACK, as this fixes building git master for Windows. -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names
The UTF-8 support that came with commit 2627335 does allow international
usernames and passwords. This patch introduces UTF-8 support for X.509 DNs.
Additionally, instead of using the legacy openssl format, DNs are now
displayed in RFC 2253 format; "/C=ru/L=\xD0\x9C\xD0\xBE\xD1\x81\xD0\xBA\xD0
\xB2\xD0\xB0/O=\xD0\x9A\xD1\x80\xD0\xB5\xD0\xBC\xD0\xBB\xD1\x8C/CN=kreml.ru"
becomes "C=ru, L=Москва, O=Кремль, CN=kreml.ru".
Since the specific character classes for X.509 names are removed, the
"no-name-remapping" configuration option has no use anymore and is removed
as well.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
openvpn.8| 23 +--
options.c| 12 +---
pkcs11_openssl.c |2 +-
sample-scripts/verify-cn |6 +++---
ssl_openssl.c| 36
ssl_openssl.h|1 +
ssl_verify.c | 45 +
ssl_verify_openssl.c |4 ++--
8 files changed, 54 insertions(+), 75 deletions(-)
diff --git a/openvpn.8 b/openvpn.8
index b8594e1..e96c1e4 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -3322,27 +3322,6 @@ the authenticated username as the common name,
rather than the common name from the client cert.
.\"*
.TP
-.B \-\-no-name-remapping
-Allow Common Name, X509 Subject, and username strings to include
-any printable character including space, but excluding control
-characters such as tab, newline, and carriage-return.
-
-By default, OpenVPN will remap
-any character other than alphanumeric, underbar ('_'), dash
-('-'), dot ('.'), and slash ('/') to underbar ('_'). The X509
-Subject string as returned by the
-.B tls_id
-environmental variable, can additionally contain colon (':') or
-equal ('=').
-
-While name remapping is performed for security reasons to reduce
-the possibility of introducing string expansion security vulnerabilities
-in user-defined authentication
-scripts, this option is provided for those cases where it is desirable to
-disable the remapping feature. Don't use this option unless you
-know what you are doing!
-.\"*
-.TP
.B \-\-port-share host port [dir]
When run in TCP server mode, share the OpenVPN port with
another application, such as an HTTPS server. If OpenVPN
@@ -4463,7 +4442,7 @@ When
.B cmd
is executed two arguments are appended, as follows:
-.B cmd certificate_depth X509_NAME_oneline
+.B cmd certificate_depth subject
These arguments are, respectively, the current certificate depth and
the X509 common name (cn) of the peer.
diff --git a/options.c b/options.c
index 0d86cd0..a01ae76 100644
--- a/options.c
+++ b/options.c
@@ -597,7 +597,7 @@ static const char usage_message[] =
" pending TLS connection that has otherwise passed all
other\n"
" tests of certification. cmd should return 0 to allow\n"
" TLS handshake to proceed, or 1 to fail. (cmd is\n"
- " executed as 'cmd certificate_depth X509_NAME_oneline')\n"
+ " executed as 'cmd certificate_depth subject')\n"
"--tls-export-cert [directory] : Get peer cert in PEM format and store it \n"
" in an openvpn temporary file in [directory]. Peer cert is
\n"
" stored before tls-verify script execution and deleted
after.\n"
@@ -2160,9 +2160,6 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
if ((options->ssl_flags & SSLF_AUTH_USER_PASS_OPTIONAL) && !ccnr)
msg (M_USAGE, "--auth-user-pass-optional %s", postfix);
}
-
- if ((options->ssl_flags & SSLF_NO_NAME_REMAPPING) && script_method ==
SM_SYSTEM)
- msg (M_USAGE, "--script-security method='system' cannot be combined
with --no-name-remapping");
}
else
{
@@ -2197,8 +2194,6 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
msg (M_USAGE, "--username-as-common-name requires --mode server");
if (options->ssl_flags & SSLF_AUTH_USER_PASS_OPTIONAL)
msg (M_USAGE, "--auth-user-pass-optional requires --mode server");
- if (options->ssl_flags & SSLF_NO_NAME_REMAPPING)
- msg (M_USAGE, "--no-name-remapping requires --mode server");
if (options->ssl_flags & SSLF_OPT_VERIFY)
msg (M_USAGE, "--opt-verify requires --mode server");
if (options->server_flags & SF_TCP_NODELAY_HELPER)
@@ -5389,11 +5384,6 @@ add_option (struct options *options,
VERIFY_PERMISSION (OPT_P_GENERAL);
options->ssl_flags |= SSLF_AUTH_USER_PA
[Openvpn-devel] [PATCH] Windows UTF-8 input/output
This patch makes openvpn read unicode from the console and convert the input
to UTF-8. And then display UTF-8 output to the console correctly.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
configure.ac |1 +
openvpn.c|4
win32.c |8 +++-
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a4d68e6..169d616 100644
--- a/configure.ac
+++ b/configure.ac
@@ -343,6 +343,7 @@ case "$host" in
OPENVPN_ADD_LIBS(-lcrypt32)
OPENVPN_ADD_LIBS(-liphlpapi)
OPENVPN_ADD_LIBS(-lwinmm)
+ OPENVPN_ADD_LIBS(-lshell32)
;;
*-*-dragonfly*)
AC_DEFINE(TARGET_DRAGONFLY, 1, [Are we running on DragonFlyBSD?])
diff --git a/openvpn.c b/openvpn.c
index 520fda1..611dffa 100644
--- a/openvpn.c
+++ b/openvpn.c
@@ -131,6 +131,10 @@ main (int argc, char *argv[])
return 1;
#endif
+#ifdef TARGET_WIN32
+ SetConsoleOutputCP (CP_UTF8);
+#endif
+
CLEAR (c);
/* signify first time for components which can
diff --git a/win32.c b/win32.c
index cf6cc2d..0f4d11c 100644
--- a/win32.c
+++ b/win32.c
@@ -763,6 +763,7 @@ get_console_input_win32 (const char *prompt, const bool
echo, char *input, const
bool is_console = (GetFileType (in) == FILE_TYPE_CHAR);
DWORD flags_save = 0;
int status = 0;
+ WCHAR *winput;
if (is_console)
{
@@ -777,10 +778,15 @@ get_console_input_win32 (const char *prompt, const bool
echo, char *input, const
is_console = 0;
}
- status = ReadFile (in, input, capacity, , NULL);
+ winput = malloc (capacity * sizeof (WCHAR));
+ if (winput == NULL)
+ return false;
+ status = ReadConsoleW (in, winput, capacity, , NULL);
+ WideCharToMultiByte (CP_UTF8, 0, winput, len, input, capacity, NULL,
NULL);
string_null_terminate (input, (int)len, capacity);
chomp (input);
+ free (winput);
if (!echo)
WriteFile (err, "\r\n", 2, , NULL);
--
1.7.5.4
Re: [Openvpn-devel] [PATCH] Windows UTF-8 input/output
On Wednesday 23 November 2011 14:55:57 Alon Bar-Lev wrote: > OpenVPN output is not always a console. What output are you concerned about? Log file is fine, as much as management interface. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names
On Wednesday 23 November 2011 14:53:06 Alon Bar-Lev wrote: > As this is inserted into environment, what happens if locale is not > unicode enabled? Then the script will receive funny looking strings depending on your locale's code page. However, this is nothing that's being introduced with this patch, as mentioned in the commit message 2627335 already puts UTF-8 user names and passwords into the environment. > I think this may break some configurations. Aren't the environments lacking UTF-8 locales broken with regards to non-ASCII characters anyways? As UTF-8 encoding doesn't change any character < 128 non- ASCII DNs, user names and password will be passed to scripts just like in the good old days. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH] Windows UTF-8 input/output
On Wednesday 23 November 2011 15:43:04 Alon Bar-Lev wrote: > Pipes when run as service. Good one! I'll post an updated patch. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCHv2] Windows UTF-8 input/output
This patch makes openvpn read unicode from the console and convert the input
to UTF-8. And then display UTF-8 output to the console correctly.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
configure.ac |1 +
openvpn.c|4
win32.c | 14 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a4d68e6..169d616 100644
--- a/configure.ac
+++ b/configure.ac
@@ -343,6 +343,7 @@ case "$host" in
OPENVPN_ADD_LIBS(-lcrypt32)
OPENVPN_ADD_LIBS(-liphlpapi)
OPENVPN_ADD_LIBS(-lwinmm)
+ OPENVPN_ADD_LIBS(-lshell32)
;;
*-*-dragonfly*)
AC_DEFINE(TARGET_DRAGONFLY, 1, [Are we running on DragonFlyBSD?])
diff --git a/openvpn.c b/openvpn.c
index 520fda1..611dffa 100644
--- a/openvpn.c
+++ b/openvpn.c
@@ -131,6 +131,10 @@ main (int argc, char *argv[])
return 1;
#endif
+#ifdef TARGET_WIN32
+ SetConsoleOutputCP (CP_UTF8);
+#endif
+
CLEAR (c);
/* signify first time for components which can
diff --git a/win32.c b/win32.c
index cf6cc2d..865d1e3 100644
--- a/win32.c
+++ b/win32.c
@@ -763,6 +763,7 @@ get_console_input_win32 (const char *prompt, const bool
echo, char *input, const
bool is_console = (GetFileType (in) == FILE_TYPE_CHAR);
DWORD flags_save = 0;
int status = 0;
+ WCHAR *winput;
if (is_console)
{
@@ -777,7 +778,18 @@ get_console_input_win32 (const char *prompt, const bool
echo, char *input, const
is_console = 0;
}
- status = ReadFile (in, input, capacity, , NULL);
+ if (is_console)
+{
+ winput = malloc (capacity * sizeof (WCHAR));
+ if (winput == NULL)
+return false;
+
+ status = ReadConsoleW (in, winput, capacity, , NULL);
+ WideCharToMultiByte (CP_UTF8, 0, winput, len, input, capacity, NULL,
NULL);
+ free (winput);
+}
+ else
+status = ReadFile (in, input, capacity, , NULL);
string_null_terminate (input, (int)len, capacity);
chomp (input);
--
1.7.5.4
Re: [Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names
On Wednesday 23 November 2011 17:48:54 Alon Bar-Lev wrote: > Yes, there are many none unicode environments, and I am not sure what > this patch will behave in windows environment as it is SCS-2 not > UTF-8. I agree on the UCS-16 environment in Windows. Will post a patch for that soon, as I'm almost ready with one handling UCS-16 file system related stuff. It'll be just a small addition to that patch. > OpenVPN is also used in embedded systems, such as dd-wrt.com and other. > So I guess I would like to see unicode=true parameter on *NIX use > UTF-8, on Windows use UCS-2. Why would that be useful? Does it make a difference if scripts in a latin-1 environment receive "j\C3\B6rn" or "jörn"? Both forms won't be recognizable without additional effort, while being equally harmless. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Japanese translation
Hi Taro On Friday 25 November 2011 10:02:16 Taro Yamazaki wrote: > Here is the Japanized .rc file. > Please import it to the source repository. Thanks for your contribution, very much appreciated. I've already built a version of the GUI to find out what Japanese will look like. One thing I'd like to ask is if you could send the .rc file again in UTF-8 encoding. I'm having trouble decoding it from SJJS. I'm getting several warnings about unrecognized escape sequences and as I plan to switch to UTF-8 encoded language files anyways, that will probably solve the problem. One thing I noticed is that you changed the dialog font name to "ＭＳ Ｐゴシック". Is "Microsoft Sans Serif" installed on Japanese Windows? Using "ＭＳ Ｐゴシック" on an English Windows XP (with Eastern Asian language support installed) makes the dialogs and controls within appear smaller (check the attached image). Using "Microsoft Sans Serif" still displays the katakana correctly while preserving the original size. So, if that doesn't cause any problems on your side I'll use "Microsoft Sans Serif" instead. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Japanese translation
Hi Taro, On Wednesday 30 November 2011 01:23:06 Taro Yamazaki wrote: > I'm attaching the file as per your request. I uploaded a new snapshot, containing your localization, to sourceforge [1]. Please check if it works as expected. Regards Heiko [1] https://sourceforge.net/projects/openvpn-gui/files/Snapshot%20Binaries/ -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Japanese translation
Hi Taro On Thursday 01 December 2011 11:28:13 Taro Yamazaki wrote: > I checked a new snapshot, and I found the words that needed to be adjusted. > Please use an attached file. Thanks. Committed the change to the repository. It will be contained in the next snapshot. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] handle Windows unicode paths
Openvpn for Windows is not compiled as a Unicode binary and thus cannot
handle paths which contain non-ASCII characters using the argv vector.
Characters that are not present in the system codepage are simply replaced
with a question mark, e.g. if started as 'openvpn --config домой.ovpn'
the file '?.ovpn' is tried to be opened as configuration.
The same applies to paths in config files which need to be UTF-8
encoded if they contain non ASCII characters. The option line
'key лев.pem' will lead to openvpn trying to open 'лев.pem' on a
system with codepage 1252.
This patch makes openvpn read the command line in UCS-2 and convert
it to UTF-8 internally. Windows stores names in the filesystem in UCS-2.
When using a paths openvpn converts it from UTF-8 to UCS-2 and uses the
wide character Windows API function.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
buffer.c |3 +-
crypto.c |6 +-
error.c | 17 +-
manage.c |2 +-
misc.c | 28 +++-
misc.h | 30
options.c| 29 +++-
packet_id.c |6 +-
pf.c |2 +-
plugin.c |3 +-
ps.c |2 +-
ssl_openssl.c| 462 +++---
ssl_verify.c |2 +-
ssl_verify_openssl.c |6 +-
status.c | 48 ++
syshead.h|1 +
win32.c | 60 +--
win32.h |3 +
18 files changed, 350 insertions(+), 360 deletions(-)
diff --git a/buffer.c b/buffer.c
index 2f8e4b8..fd89522 100644
--- a/buffer.c
+++ b/buffer.c
@@ -28,6 +28,7 @@
#include "buffer.h"
#include "error.h"
#include "mtu.h"
+#include "misc.h"
#include "memdbg.h"
@@ -1058,7 +1059,7 @@ buffer_list_advance (struct buffer_list *ol, int n)
struct buffer_list *
buffer_list_file (const char *fn, int max_line_len)
{
- FILE *fp = fopen (fn, "r");
+ FILE *fp = openvpn_fopen (fn, "r");
struct buffer_list *bl = NULL;
if (fp)
diff --git a/crypto.c b/crypto.c
index d17f706..189bd9c 100644
--- a/crypto.c
+++ b/crypto.c
@@ -862,7 +862,7 @@ read_key_file (struct key2 *key2, const char *file, const
unsigned int flags)
#endif
{
in = alloc_buf_gc (2048, );
- fd = open (file, O_RDONLY);
+ fd = openvpn_open (file, O_RDONLY, 0);
if (fd == -1)
msg (M_ERR, "Cannot open file key file '%s'", file);
size = read (fd, in.data, in.capacity);
@@ -1023,7 +1023,7 @@ read_passphrase_hash (const char *passphrase_file,
const int min_passphrase_size = 8;
uint8_t buf[64];
int total_size = 0;
-int fd = open (passphrase_file, O_RDONLY);
+int fd = openvpn_open (passphrase_file, O_RDONLY, 0);
if (fd == -1)
msg (M_ERR, "Cannot open passphrase file: '%s'", passphrase_file);
@@ -1073,7 +1073,7 @@ write_key_file (const int nkeys, const char *filename)
const int bytes_per_line = 16;
/* open key file */
- fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
+ fd = openvpn_open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR |
S_IWUSR);
if (fd == -1)
msg (M_ERR, "Cannot open shared secret file '%s' for write", filename);
diff --git a/error.c b/error.c
index a0de53e..1ed7dd6 100644
--- a/error.c
+++ b/error.c
@@ -464,6 +464,7 @@ redirect_stdout_stderr (const char *file, bool append)
#if defined(WIN32)
if (!std_redir)
{
+ struct gc_arena gc = gc_new ();
HANDLE log_handle;
int log_fd;
@@ -472,13 +473,15 @@ redirect_stdout_stderr (const char *file, bool append)
saAttr.bInheritHandle = TRUE;
saAttr.lpSecurityDescriptor = NULL;
- log_handle = CreateFile (file,
- GENERIC_WRITE,
- FILE_SHARE_READ,
- ,
- append ? OPEN_ALWAYS : CREATE_ALWAYS,
- FILE_ATTRIBUTE_NORMAL,
- NULL);
+ log_handle = CreateFileW (wide_string (file, ),
+GENERIC_WRITE,
+FILE_SHARE_READ,
+,
+append ? OPEN_ALWAYS : CREATE_ALWAYS,
+FILE_ATTRIBUTE_NORMAL,
+NULL);
+
+ gc_free ();
if (log_handle == INVALID_HANDLE_VALUE)
{
diff --git a/manage.c b/manage.c
index ce6fae7..23e32db 100644
--- a/manage.c
+++ b/manage.c
@@ -1423,7 +1423,7 @@ man_record_peer_info (struct management *man)
{
const in_addr_t a = ntohl (addr.sin_addr.s_addr);
const int p = ntohs (addr.sin_port);
- FILE *fp = fopen (man->settings.write_peer_info_file, "w");
+ FILE *fp = openvpn_fopen
[Openvpn-devel] [PATCH] set Windows environment variables as UCS-2
Windows uses 16 bit wide characters to represent Unicode in the
process environment. Convert UTF-8 to UCS-2 and use the wide
character API to set environment variables.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
misc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/misc.c b/misc.c
index ad74357..ddd5fdf 100644
--- a/misc.c
+++ b/misc.c
@@ -1030,8 +1030,8 @@ setenv_str_ex (struct env_set *es,
{
#if defined(WIN32)
{
- /*msg (M_INFO, "SetEnvironmentVariable '%s' '%s'", name_tmp, val_tmp ?
val_tmp : "NULL");*/
- if (!SetEnvironmentVariable (name_tmp, val_tmp))
+if (!SetEnvironmentVariableW (wide_string (name_tmp, ),
+ wide_string (val_tmp, )))
msg (M_WARN | M_ERRNO, "SetEnvironmentVariable failed, name='%s',
value='%s'",
name_tmp,
val_tmp ? val_tmp : "NULL");
--
1.7.5.4
Re: [Openvpn-devel] [PATCH] handle Windows unicode paths
On Wednesday 07 December 2011 17:58:51 Heiko Hund wrote: > This patch makes openvpn read the command line in UCS-2 and convert > it to UTF-8 internally. Windows stores names in the filesystem in UCS-2. > When using a paths openvpn converts it from UTF-8 to UCS-2 and uses the > wide character Windows API function. One thing I left out on purpose for now was handling --capath with a Unicode path. To have that work, openvpn would need to define a custom LOOKUP_METHOD that is Unicode-safe. The one that is currently used is at [1]. The problem here is the _stat call that needs to be _wstat. Please let me know if that's something that should be done or not and I'll provide a patch. Heiko [1] http://cvs.openssl.org/fileview?f=openssl/crypto/x509/by_dir.c=1.32 -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] UTF-8 X.509 distinguished names
The UTF-8 support that came with commit 2627335 does allow international
usernames and passwords. This patch introduces UTF-8 support for X.509 DNs.
Additionally, instead of using the legacy openssl format, DNs are now
displayed in RFC 2253 format; "/C=ru/L=\xD0\x9C\xD0\xBE\xD1\x81\xD0\xBA\xD0
\xB2\xD0\xB0/O=\xD0\x9A\xD1\x80\xD0\xB5\xD0\xBC\xD0\xBB\xD1\x8C/CN=kreml.ru"
becomes "C=ru, L=Москва, O=Кремль, CN=kreml.ru".
Since the specific character classes for X.509 names are removed, the
"no-name-remapping" configuration option has no use anymore and is removed
as well.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
openvpn.8| 23 +--
options.c| 12 +---
pkcs11_openssl.c |2 +-
sample-scripts/verify-cn |6 +++---
ssl_verify.c | 45 +
ssl_verify_openssl.c | 40 ++--
ssl_verify_openssl.h |2 ++
7 files changed, 55 insertions(+), 75 deletions(-)
diff --git a/openvpn.8 b/openvpn.8
index a6d7567..00acd01 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -3322,27 +3322,6 @@ the authenticated username as the common name,
rather than the common name from the client cert.
.\"*
.TP
-.B \-\-no-name-remapping
-Allow Common Name, X509 Subject, and username strings to include
-any printable character including space, but excluding control
-characters such as tab, newline, and carriage-return.
-
-By default, OpenVPN will remap
-any character other than alphanumeric, underbar ('_'), dash
-('-'), dot ('.'), and slash ('/') to underbar ('_'). The X509
-Subject string as returned by the
-.B tls_id
-environmental variable, can additionally contain colon (':') or
-equal ('=').
-
-While name remapping is performed for security reasons to reduce
-the possibility of introducing string expansion security vulnerabilities
-in user-defined authentication
-scripts, this option is provided for those cases where it is desirable to
-disable the remapping feature. Don't use this option unless you
-know what you are doing!
-.\"*
-.TP
.B \-\-port-share host port [dir]
When run in TCP server mode, share the OpenVPN port with
another application, such as an HTTPS server. If OpenVPN
@@ -4463,7 +4442,7 @@ When
.B cmd
is executed two arguments are appended, as follows:
-.B cmd certificate_depth X509_NAME_oneline
+.B cmd certificate_depth subject
These arguments are, respectively, the current certificate depth and
the X509 common name (cn) of the peer.
diff --git a/options.c b/options.c
index cb9738a..6b8ae22 100644
--- a/options.c
+++ b/options.c
@@ -601,7 +601,7 @@ static const char usage_message[] =
" pending TLS connection that has otherwise passed all
other\n"
" tests of certification. cmd should return 0 to allow\n"
" TLS handshake to proceed, or 1 to fail. (cmd is\n"
- " executed as 'cmd certificate_depth X509_NAME_oneline')\n"
+ " executed as 'cmd certificate_depth subject')\n"
"--tls-export-cert [directory] : Get peer cert in PEM format and store it \n"
" in an openvpn temporary file in [directory]. Peer cert is
\n"
" stored before tls-verify script execution and deleted
after.\n"
@@ -2164,9 +2164,6 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
if ((options->ssl_flags & SSLF_AUTH_USER_PASS_OPTIONAL) && !ccnr)
msg (M_USAGE, "--auth-user-pass-optional %s", postfix);
}
-
- if ((options->ssl_flags & SSLF_NO_NAME_REMAPPING) && script_method ==
SM_SYSTEM)
- msg (M_USAGE, "--script-security method='system' cannot be combined
with --no-name-remapping");
}
else
{
@@ -2201,8 +2198,6 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
msg (M_USAGE, "--username-as-common-name requires --mode server");
if (options->ssl_flags & SSLF_AUTH_USER_PASS_OPTIONAL)
msg (M_USAGE, "--auth-user-pass-optional requires --mode server");
- if (options->ssl_flags & SSLF_NO_NAME_REMAPPING)
- msg (M_USAGE, "--no-name-remapping requires --mode server");
if (options->ssl_flags & SSLF_OPT_VERIFY)
msg (M_USAGE, "--opt-verify requires --mode server");
if (options->server_flags & SF_TCP_NODELAY_HELPER)
@@ -5581,11 +5576,6 @@ add_option (struct options *options,
VERIFY_PERMISSION (OPT_P_GENERAL);
options->ssl_flags |= SSLF_AUTH_USER_PASS_OPTIONAL;
}
- else if (streq (p[0], &q
[Openvpn-devel] [PATCH] remove the --auto-proxy option from openvpn
During discussion on FOSDEM 2012 it was decided that proxy auto detection
is best done in the GUI as it's highly platform specific and shouldn't be
handled in openvpn itself for every supported platform in openvpn itself.
This removes --auto-proxy from openvpn.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
init.c| 10 +--
openvpn.8 | 12 ---
options.c | 40 +--
options.h |4 -
proxy.c | 242 +
proxy.h | 27 +---
socks.c | 15 +
socks.h |3 +-
8 files changed, 11 insertions(+), 342 deletions(-)
diff --git a/init.c b/init.c
index 525f441..c60a2e9 100644
--- a/init.c
+++ b/init.c
@@ -492,11 +492,10 @@ init_proxy_dowork (struct context *c)
uninit_proxy_dowork (c);
#ifdef ENABLE_HTTP_PROXY
- if (c->options.ce.http_proxy_options || c->options.auto_proxy_info)
+ if (c->options.ce.http_proxy_options)
{
/* Possible HTTP proxy user/pass input */
- c->c1.http_proxy = http_proxy_new (c->options.ce.http_proxy_options,
-c->options.auto_proxy_info);
+ c->c1.http_proxy = http_proxy_new (c->options.ce.http_proxy_options);
if (c->c1.http_proxy)
{
did_http = true;
@@ -506,13 +505,12 @@ init_proxy_dowork (struct context *c)
#endif
#ifdef ENABLE_SOCKS
- if (!did_http && (c->options.ce.socks_proxy_server ||
c->options.auto_proxy_info))
+ if (!did_http && c->options.ce.socks_proxy_server)
{
c->c1.socks_proxy = socks_proxy_new (c->options.ce.socks_proxy_server,
c->options.ce.socks_proxy_port,
c->options.ce.socks_proxy_authfile,
- c->options.ce.socks_proxy_retry,
- c->options.auto_proxy_info);
+ c->options.ce.socks_proxy_retry);
if (c->c1.socks_proxy)
{
c->c1.socks_proxy_owned = true;
diff --git a/openvpn.8 b/openvpn.8
index 00acd01..26a15e2 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -482,18 +482,6 @@ as the
number of retries of connection attempt (default=infinite).
.\"*
.TP
-.B \-\-auto-proxy
-Try to sense HTTP or SOCKS proxy settings automatically.
-If no settings are present, a direct connection will be attempted.
-If both HTTP and SOCKS settings are present, HTTP will be preferred.
-If the HTTP proxy server requires a password, it will be queried from
-stdin or the management interface. If the underlying OS doesn't support an
API for
-returning proxy settings, a direct connection will be attempted.
-Currently, only Windows clients support this option via the
-InternetQueryOption API.
-This option exists in OpenVPN 2.1 or higher.
-.\"*
-.TP
.B \-\-show-proxy-settings
Show sensed HTTP or SOCKS proxy settings. Currently, only Windows clients
support this option.
diff --git a/options.c b/options.c
index 6b8ae22..6f4b3df 100644
--- a/options.c
+++ b/options.c
@@ -124,10 +124,6 @@ static const char usage_message[] =
"between connection retries (default=%d).\n"
"--connect-timeout n : For --proto tcp-client, connection timeout (in
seconds).\n"
"--connect-retry-max n : Maximum connection attempt retries, default
infinite.\n"
-#ifdef GENERAL_PROXY_SUPPORT
- "--auto-proxy: Try to sense proxy settings (or lack thereof)
automatically.\n"
- "--show-proxy-settings : Show sensed proxy settings.\n"
-#endif
#ifdef ENABLE_HTTP_PROXY
"--http-proxy s p [up] [auth] : Connect to remote host\n"
" through an HTTP proxy at address s and port p.\n"
@@ -2053,8 +2049,8 @@ options_postprocess_verify_ce (const struct options
*options, const struct conne
msg (M_USAGE, "--remote MUST be used in TCP Client mode");
#ifdef ENABLE_HTTP_PROXY
- if ((ce->http_proxy_options || options->auto_proxy_info) && ce->proto !=
PROTO_TCPv4_CLIENT)
-msg (M_USAGE, "--http-proxy or --auto-proxy MUST be used in TCP Client
mode (i.e. --proto tcp-client)");
+ if ((ce->http_proxy_options) && ce->proto != PROTO_TCPv4_CLIENT)
+msg (M_USAGE, "--http-proxy MUST be used in TCP Client mode (i.e. --proto
tcp-client)");
#endif
#if defined(ENABLE_HTTP_PROXY) && defined(ENABLE_SOCKS)
@@ -4890,38 +4886,6 @@ add_option (struct options *options,
options->proto_force = proto_force;
options->force_connection_list = true;
}
-#ifdef GENERAL_PROXY_SUPPORT
- else if (streq (p[0], "auto-proxy"))
-{
- char *error = NULL;
-
- VERIFY_PERMISSION (OPT_P_GENER
[Openvpn-devel] [PATCHv2] handle Windows unicode paths
Openvpn for Windows is not compiled as a Unicode binary and thus cannot
handle paths which contain non-ASCII characters using the argv vector.
Characters that are not present in the system codepage are simply replaced
with a question mark, e.g. if started as 'openvpn --config домой.ovpn'
the file '?.ovpn' is tried to be opened as configuration.
The same applies to paths in config files which need to be UTF-8
encoded if they contain non ASCII characters. The option line
'key лев.pem' will lead to openvpn trying to open 'лев.pem' on a
system with codepage 1252.
This patch makes openvpn read the command line in UCS-2 and convert
it to UTF-8 internally. Windows stores names in the filesystem in UCS-2.
When using a paths openvpn converts it from UTF-8 to UCS-2 and uses the
wide character Windows API function.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
This version of the patch was rebased to current master. It also handles
the access(2) calls introduced in commit 0f2bc0dd by David correctly.
buffer.c |3 +-
crypto.c |6 +-
error.c | 17 +-
manage.c |2 +-
misc.c | 41 -
misc.h | 31
options.c| 37 -
packet_id.c |6 +-
pf.c |2 +-
plugin.c |3 +-
ps.c |2 +-
ssl_openssl.c| 459 +++---
ssl_verify.c |2 +-
ssl_verify_openssl.c |6 +-
status.c | 48 ++
syshead.h|1 +
win32.c | 60 ++--
win32.h |3 +
18 files changed, 367 insertions(+), 362 deletions(-)
diff --git a/buffer.c b/buffer.c
index fca6a90..6800e6e 100644
--- a/buffer.c
+++ b/buffer.c
@@ -28,6 +28,7 @@
#include "buffer.h"
#include "error.h"
#include "mtu.h"
+#include "misc.h"
#include "memdbg.h"
@@ -1073,7 +1074,7 @@ buffer_list_advance (struct buffer_list *ol, int n)
struct buffer_list *
buffer_list_file (const char *fn, int max_line_len)
{
- FILE *fp = fopen (fn, "r");
+ FILE *fp = openvpn_fopen (fn, "r");
struct buffer_list *bl = NULL;
if (fp)
diff --git a/crypto.c b/crypto.c
index e628578..5af92a0 100644
--- a/crypto.c
+++ b/crypto.c
@@ -862,7 +862,7 @@ read_key_file (struct key2 *key2, const char *file, const
unsigned int flags)
#endif
{
in = alloc_buf_gc (2048, );
- fd = open (file, O_RDONLY);
+ fd = openvpn_open (file, O_RDONLY, 0);
if (fd == -1)
msg (M_ERR, "Cannot open file key file '%s'", file);
size = read (fd, in.data, in.capacity);
@@ -1023,7 +1023,7 @@ read_passphrase_hash (const char *passphrase_file,
const int min_passphrase_size = 8;
uint8_t buf[64];
int total_size = 0;
-int fd = open (passphrase_file, O_RDONLY);
+int fd = openvpn_open (passphrase_file, O_RDONLY, 0);
if (fd == -1)
msg (M_ERR, "Cannot open passphrase file: '%s'", passphrase_file);
@@ -1073,7 +1073,7 @@ write_key_file (const int nkeys, const char *filename)
const int bytes_per_line = 16;
/* open key file */
- fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
+ fd = openvpn_open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR |
S_IWUSR);
if (fd == -1)
msg (M_ERR, "Cannot open shared secret file '%s' for write", filename);
diff --git a/error.c b/error.c
index 06b383f..ede33d0 100644
--- a/error.c
+++ b/error.c
@@ -465,6 +465,7 @@ redirect_stdout_stderr (const char *file, bool append)
#if defined(WIN32)
if (!std_redir)
{
+ struct gc_arena gc = gc_new ();
HANDLE log_handle;
int log_fd;
@@ -473,13 +474,15 @@ redirect_stdout_stderr (const char *file, bool append)
saAttr.bInheritHandle = TRUE;
saAttr.lpSecurityDescriptor = NULL;
- log_handle = CreateFile (file,
- GENERIC_WRITE,
- FILE_SHARE_READ,
- ,
- append ? OPEN_ALWAYS : CREATE_ALWAYS,
- FILE_ATTRIBUTE_NORMAL,
- NULL);
+ log_handle = CreateFileW (wide_string (file, ),
+GENERIC_WRITE,
+FILE_SHARE_READ,
+,
+append ? OPEN_ALWAYS : CREATE_ALWAYS,
+FILE_ATTRIBUTE_NORMAL,
+NULL);
+
+ gc_free ();
if (log_handle == INVALID_HANDLE_VALUE)
{
diff --git a/manage.c b/manage.c
index ce6fae7..23e32db 100644
--- a/manage.c
+++ b/manage.c
@@ -1423,7 +1423,7 @@ man_record_peer_info (struct management *man)
{
const in_addr_t a = ntohl (addr.sin_addr.s_addr);
c
[Openvpn-devel] MSVC fixes
Hi, this patch series fixes several issues when building for Windows with the MSVC buildsystem discovered today: [PATCH 1/4] replace check for TARGET_WIN32 with WIN32 [PATCH 2/4] do not use mode_t on Windows [PATCH 3/4] use the underscore version of stat on Windows [PATCH 4/4] make MSVC link against shell32 as well For details check the commit messages of the individual patches. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH 2/4] do not use mode_t on Windows
The MSVC headers do not define mode_t. open() uses an int for
the permissions instead. Fixes building with the MSVC based
buildsystem.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
misc.h |2 +-
win32.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/misc.h b/misc.h
index 8c0bae1..e7a0b55 100644
--- a/misc.h
+++ b/misc.h
@@ -158,7 +158,7 @@ openvpn_fopen (const char *path, const char *mode)
#endif
#ifdef WIN32
-int openvpn_open (const char *path, int flags, mode_t mode);
+int openvpn_open (const char *path, int flags, int mode);
#else
static inline int
openvpn_open (const char *path, int flags, mode_t mode)
diff --git a/win32.c b/win32.c
index 5b38918..a8f4ed9 100644
--- a/win32.c
+++ b/win32.c
@@ -1064,7 +1064,7 @@ openvpn_fopen (const char *path, const char *mode)
}
int
-openvpn_open (const char *path, int flags, mode_t mode)
+openvpn_open (const char *path, int flags, int mode)
{
struct gc_arena gc = gc_new ();
int fd = _wopen (wide_string (path, ), flags, mode);
--
1.7.5.4
[Openvpn-devel] [PATCH 4/4] make MSVC link against shell32 as well
Windows API CommandLineToArgvW(), introduced in Windows unicode path commit 71bbbd76c62630c88441237d72fe5b61f0b45b2a, is defined therein. Signed-off-by: Heiko Hund <heiko.h...@sophos.com> --- win/msvc.mak.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/win/msvc.mak.in b/win/msvc.mak.in index 115e395..191f370 100644 --- a/win/msvc.mak.in +++ b/win/msvc.mak.in @@ -31,7 +31,7 @@ LZO_DYNAMIC = lzo2.lib INCLUDE_DIRS = -I$(OPENSSL)/include -I$(POLARSSL)/include -I$(LZO)/include -I$(PKCS11_HELPER)/include -LIBS = $(OPENSSL_DYNAMIC) $(POLARSSL_DYNAMIC) $(PKCS11_HELPER_DYNAMIC) $(LZO_DYNAMIC) ws2_32.lib crypt32.lib iphlpapi.lib winmm.lib user32.lib gdi32.lib advapi32.lib wininet.lib +LIBS = $(OPENSSL_DYNAMIC) $(POLARSSL_DYNAMIC) $(PKCS11_HELPER_DYNAMIC) $(LZO_DYNAMIC) ws2_32.lib crypt32.lib iphlpapi.lib winmm.lib user32.lib gdi32.lib advapi32.lib wininet.lib shell32.lib LIB_DIRS = -LIBPATH:$(OPENSSL)\lib -LIBPATH:$(POLARSSL)\build\library -LIBPATH:$(PKCS11_HELPER)\lib -LIBPATH:$(LZO)\lib -- 1.7.5.4
[Openvpn-devel] [PATCH 3/4] use the underscore version of stat on Windows
MSVC does not know wstat(). Instead _wstat() must be used here.
Unfortunately _wstat() takes a 'struct _stat'. A type 'stat_t' is
introduced to handle this situation in a portable way.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
misc.h |6 --
pf.c|2 +-
win32.c |4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/misc.h b/misc.h
index e7a0b55..55d494f 100644
--- a/misc.h
+++ b/misc.h
@@ -168,10 +168,12 @@ openvpn_open (const char *path, int flags, mode_t mode)
#endif
#ifdef WIN32
-int openvpn_stat (const char *path, struct stat *buf);
+typedef struct _stat stat_t;
+int openvpn_stat (const char *path, stat_t *buf);
#else
+typedef struct stat stat_t;
static inline int
-openvpn_stat (const char *path, struct stat *buf)
+openvpn_stat (const char *path, stat_t *buf)
{
return stat (path, buf);
}
diff --git a/pf.c b/pf.c
index a0e9fc8..67cd28f 100644
--- a/pf.c
+++ b/pf.c
@@ -498,7 +498,7 @@ pf_check_reload (struct context *c)
&& c->c2.pf.filename
&& event_timeout_trigger (>c2.pf.reload, >c2.timeval, ETT_DEFAULT))
{
- struct stat s;
+ stat_t s;
if (!openvpn_stat (c->c2.pf.filename, ))
{
if (s.st_mtime > c->c2.pf.file_last_mod)
diff --git a/win32.c b/win32.c
index a8f4ed9..4efc8df 100644
--- a/win32.c
+++ b/win32.c
@@ -1073,10 +1073,10 @@ openvpn_open (const char *path, int flags, int mode)
}
int
-openvpn_stat (const char *path, struct stat *buf)
+openvpn_stat (const char *path, stat_t *buf)
{
struct gc_arena gc = gc_new ();
- int res = wstat (wide_string (path, ), buf);
+ int res = _wstat (wide_string (path, ), buf);
gc_free ();
return res;
}
--
1.7.5.4
[Openvpn-devel] [PATCH] move variable declaration to top of function
MSVC chokes on this as it's not according to C89.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
buffer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/buffer.c b/buffer.c
index 6800e6e..391085b 100644
--- a/buffer.c
+++ b/buffer.c
@@ -321,9 +321,9 @@ gc_malloc (size_t size, bool clear, struct gc_arena *a)
#endif
{
void *ret;
+ struct gc_entry *e;
ASSERT (NULL != a);
- struct gc_entry *e;
#ifdef DMALLOC
e = (struct gc_entry *) openvpn_dmalloc (file, line, size + sizeof (struct
gc_entry));
#else
--
1.7.5.4
Re: [Openvpn-devel] [PATCH 2/4] do not use mode_t on Windows
Alon, On Thursday 16 February 2012 18:34:34 Alon Bar-Lev wrote: > Anyway, this is not the correct solution. > Correct solution is to have config-msvc.h and have: > --- > #define mode_t int I don't think that a MSVC specific header will do good. mode_t shouldn't actually be used in mingw either, even if they define it. I stumbled over such glue code a couple of times and the only reason I can come up with why they have it is backwards compatibility with old code. So it's rather a general WIN32 thing. And I absolutely agree that putting all the WIN32 stuff into win32.[ch] would make the code prettier. I just don't feel enough itch to approach this scratching myself. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH 4/4] make MSVC link against shell32 as well
Alon, On Thursday 16 February 2012 18:37:21 Alon Bar-Lev wrote: > On Thu, Feb 16, 2012 at 7:30 PM, Heiko Hund <heiko.h...@sophos.com> wrote: > > Windows API CommandLineToArgvW(), introduced in Windows unicode path > > commit 71bbbd76c62630c88441237d72fe5b61f0b45b2a, is defined therein. > > Usually this should be avoided and get command-line from wmain(). the general idea is to make Unicode things happen without changing the openvpn code too much in a very Windows specific way. Converting UCS-2 to UTF-8 directly where input and output is happening and passing it through the rest of openvpn as char* does that. I don't see any benefit in converting openvpn into a native unicode binary. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows
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 <heiko.h...@sophos.com> --- 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
Re: [Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows
On Monday 20 February 2012 13:44:54 Alon Bar-Lev wrote:
> This X_OK is standard define.
That's true for unixoid systems, but none of the [FWRX]_OK #defines exist in
the MS C runtime headers.
> It exists in mingw as 1.
Yeah, but only for legacy glue code reasons. From io.h:
8<-
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char *__fname, int __mode) {
return _access (__fname, __mode & ~X_OK);
}
#define access(__f,__m) __mingw_access (__f, __m)
8<-
> OpenVPN should not check execute if unsupported by OS, not changing
> standard constants.
> Where exactly is the problem?
Defining them makes code more readable, but without X_OK being 0 on Windows
openvpn crashes. See my commit message again and read the MSDN page about
_access at http://msdn.microsoft.com/en-us/library/1w06ktdy%28v=vs.100%29.aspx
Hence the change for the MSVC buildsystem only. Mingw handles the situation
internally already.
Hope that made it clear.
Heiko
--
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] Better use ip -batch on adding/removing server pushed routes on Linux
On Monday 20 February 2012 16:00:37 Yang Zhe wrote: > It's quite slow to add thousands of routes via execve thousands times. > It's better writing the parameters to a pipe to `ip -batch -` on > linux. I would even go as far as saying that it would make sense to get rid of the forking completely and use rtnetlink directly for this. Has this already been discussed here? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] [PATCH] mask out X_OK when calling WIN32 API _waccess()
This reverts commit 4ebc587e. Instead of defining X_OK 0 for MSVC,
this undefined mode value is now simply masked out close to where
it causes the trouble; in the call to _waccess() as suggested
during the discussion on the development mailing list:
http://thread.gmane.org/gmane.network.openvpn.devel/5452
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
misc.c |2 +-
win/config.h.in |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/misc.c b/misc.c
index a07780f..67345bc 100644
--- a/misc.c
+++ b/misc.c
@@ -629,7 +629,7 @@ openvpn_access (const char *path, int mode)
{
#ifdef WIN32
struct gc_arena gc = gc_new ();
- int ret = _waccess (wide_string (path, ), mode);
+ int ret = _waccess (wide_string (path, ), mode & ~X_OK);
gc_free ();
return ret;
#else
diff --git a/win/config.h.in b/win/config.h.in
index fcb8d6c..b5c31b8 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 0
+#define X_OK 1
#endif
#ifndef F_OK
--
1.7.8.3
Re: [Openvpn-devel] [build] Windows build test
On Wednesday 22 February 2012 00:12:25 Alon Bar-Lev wrote: > BEST METHOD - Compile on Linux > > This is a generic method, it can cross compile OpenVPN using any > toolchain to any environment. > For Windows, make sure you have mingw-w64 toolchain. > We are using nsis so we can also package files at Linux. > > $ cd generic > $ IMAGEROOT=`pwd`/image-win32 CHOST=i686-w64-mingw32 > CBUILD=x86_64-pc-linux-gnu ./build > $ IMAGEROOT=`pwd`/image-win64 CHOST=x86_64-w64-mingw32 > CBUILD=x86_64-pc-linux-gnu ./build I was cross compiling for Windows previously doing something very standard like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What the rationale behind moving away from this way? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [build] Windows build test
On Wednesday 22 February 2012 10:32:23 Alon Bar-Lev wrote: > On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund <heiko.h...@sophos.com> wrote: > > I was cross compiling for Windows previously doing something very > > standard > > like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What > > the rationale behind moving away from this way? > > This is exactly what this build is doing. > Just it also builds the dependencies and package the output. > The most difficult task (usually) is to compile the dependencies. What dependencies do you mean? lzo, openssl and pkcs11-helper? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [RFC][windows] gettimeofday()
On Wednesday 22 February 2012 16:12:24 Alon Bar-Lev wrote: > In windows there is own implementation of gettimeofday(). > In the past there was no gettimeofday(), so we used performance counters, > then James optimize it to reduce CPU consumption. > > Unlike in the past, mingw does provide this function these days. > The question is if it is good enough. Since there's no gettimeofday() in MSVC this will break building with the python build system. Not sure if we're in the process of getting rid of it, which I would welcome, so this is just for additional information. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] openvpn windows gui
Hi Alon On Monday 27 February 2012 14:01:25 Alon Bar-Lev wrote: > I am going to re-write your build system :) Take it easy! =) > It uses autoconf but not automake and looks some rewrite is needed. I did not see the the need for automake in the past. However, now that dist produces a .tar.gz and there's the res/ subdir and the Makefile is quite ugly, plus not all the dependency tracking is in place working, a little automake will be beneficial, so go ahead. Please make sure the snapshot target stays intact and that configure still supports the --with-cyrpto-* arguments for libcrypto (guess you'll go pkg-config here as well). > We should probably write an installer. I'm not sure if it's the best idea to make each and every GUI project out there write it's own installer, when it's mostly a single executable that needs to be replaced to package it with upstream openvpn. The pragmatic way to do it would be to leave the GUI stuff in openvpn itself, but I guess you guys like the idea of bundling installers with other installers, right? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Tuesday 28 February 2012 18:38:57 Alon Bar-Lev wrote: > > Even though, the new communication pipe between the "helper service" and > > openvpn.exe might gain more features with time, which might cover much > > of what the management interface provides today too. But we're _not_ > > trying to kill the management interface. > > There is no need for the helper service. > Nobody care if the openvpn daemon is running in privilege mode. > The problem is the user interaction. > So I would have avoided to invest resources at the daemon side and invest > resources at proper UI. The idea to have the service do the privileged operations instead of just starting openvpn as "Local System" (or whatever) came from the fear of privilege escalation in the scripts that are run by openvpn. So, at least I care that it's not running in privilege mode. Your point is invalid. =P Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Tuesday 28 February 2012 20:34:18 Carsten Krüger wrote: > Add the following lines to client.ovpn > > management localhost 1000 > management-query-passwords > auth-retry interact > management-hold > > and start the service. That's pretty much what the GUI is using at the moment. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Tuesday 28 February 2012 722:09:13 Carsten Krüger wrote: > DS> Heiko can probably give a much better answer, but if I remember right, > DS> the argument was this: Think of a multi-user setup (like a Terminal > DS> Server), the management interface will be accessible for all users on > DS> that server. > > a) Who an earth allows users on a terminal server to create VPN-sessions? > What happens if one of the sessions use redirect gateway? > All users are redirected? That was actually an open question. I don't know if TS manages per session routing tables and haven't tried. However it was only an example and thus didn't have to make any practical sense. =) > I don't think that this is a valid point. The thing is that you need a second communication channel for requesting privileged operations. The management interface won't do, because the GUI (hopefully) runs with an unprivileged token. So the distinction between both is: * mgmt itf for interactive communication with the user * privilege channel for requesting operations that require elevation > Privilege seperation in openvnp deamon is nice, but is a complete > different thing than management interface access. It is, you got it right. > In openvpn case it should be something like this: > openvpnserv.exe running as a service, has no privileges and opens > management interface > openvpnhelpserv.exe running as a service has network operator rights > (no need for local system ...) > > openvpnserv and openvpnhelpserv could communicate via pipe. > > openvpn-management client (could be a perl script) connects to > management interface of openvpnserv.exe to start/stop a tunnel and > supply secrets. You forgot the GUI in this picture. If the service is connected to the management interface the GUI can't connect anymore. It need to to get things done, though. > DS> And how this is implemented, the OpenVPN Service will be started > DS> automatically. The GUI contacts the Service and the service starts the > DS> OpenVPN process with the privileges of the GUI user (IIRC, it was some > DS> neat Windows functions which allows to create processes with privileges > DS> based upon the user credentials of the other side of the named pipe). > > The sounds very bad. > The service shouldn't create processes in the name of the user. Interesting, could you elaborate? > DS> This service should be able to (for now only in theory; it has not been > DS> tested yet) handle more users simultaneously. > > Pretty useless, see above Not users, really. More like session. So you can connect to different server simultaneously. Of course this could be used by two different users at the same time or different impersonations in the same session, while still running ovpn with the credentials of the entity who started openvpn. So the point isn't really that many user can connect, but that the running sessions will be isolated from each other by the service. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 11:05:36 Carsten Krüger wrote: > > [Advertisement] Maybe you want to take a look at UTM9, beta starts > > tomorrow. > Definitely! > > Is Beta available to non customers? Yes, it will be announced at http://astaro.org in the "Beta Versions" section and you can get special licenses for the beta with limited lifetime there. This is getting too off topic now. Actually it's more an abuse of this list. So, please send private mail to me directly if further questions remain. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 11:38:17 Carsten Krüger wrote: > > You forgot the GUI in this picture. If the service is connected to the > > management interface the GUI can't connect anymore. > > ? > If I understand you correctly it works this way: > > openvpnserv.exe spawns openvpn.exe > openvpnhelperserv.exe spawns openvpnhelper.exe It's completely different. =) There will be a new service, I called it interactive service. The GUI/client connects to a named pipe of that service. It passes the working directory, command line options and stdin input for openpvn to the service. The service impersonates the client, creates another named pipe and starts openvpn. Besides the stuff from the GUI it also passes to client end of the created pipe to openvpn. The GUI may now connect the the management interface. If openvpn needs to perform a privileged operation it request it through the named pipe that was passed by the interactive service. There's only a limited and well defined set of privileged operations that are serviced through the pipe. Currently only setting of IPv4 and IPv6 routes, but that will be extended to whatever makes sense e.g. ARP table flush is the next thing that will come. > > Not users, really. More like session. So you can connect to different > > server simultaneously. > > Yeah, that's a point. > But I think it would only need management commands like "connect vpn session > 1" "disconnect vpn session 1", "supply credentials for sessions 1". > Credentials could be more than username/password, for example tls key > or smartcard "connection". Again, the management interface is for user execution level related queries like give me you password, give me your certificate, give me your proxy settings (most of this is not implemented yet), while the privileged channel is for things that the user may not do. This is specifically tailored for the situation on Windows with the GUI. Don't know if it's usable by other system as much, i.e. NetworkManager is the mgmt client and root at the same time, however no ones holding them back to also pass a unix socket to openvpn and set the openvpn routes (etc.) directly instead of performing some sudo wrapper script magic or whatever is currently used. Again, this can be extended to the point where all privileged operation are performed through the unix socket. Binding to the listen socket may be an exception to that if the port is low or can one pass FDs through unix sockets? > > Of course this could be used by two different users at the > > > > same time or different impersonations in the same session, while still > > running ovpn with the credentials of the entity who started openvpn. So > > the point isn't really that many user can connect, but that the running > > sessions will be isolated from each other by the service. > > hmm, I'm unsure if you would win something. > If the network communicating process is compromised (exploited from > internet) than it could get all the credentials via normal interface > from processes that holds them. The network communication process is openvpn and it has the rights as the user that started it. If that user has enough privileges to set it's primary token you have a very unfortunate setup, securitywise. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 12:40:45 Alon Bar-Lev wrote: > 2012/2/29 Heiko Hund <heiko.h...@sophos.com> > This is way too complex solution for a simple problem. > A proper design and discussion should take place before advancing in > this route. And this was a way too simple explanation on why you think it is too complex. Please elaborate on where you see reducible complexity. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 12:54:18 Alon Bar-Lev wrote: > What I wrote is simple. Wrote where? In this thread or C code that tackles the issue? I'm confused. > In order to push a project in coherent direction, a proper design > discussion stage should be done. Yeah, you missed that one obviously. If you want to be part of it you should actually take an active part in the IRC meetings and not complain so much, really. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 12:51:41 Carsten Krüger wrote: > > This is way too complex solution for a simple problem. > > A proper design and discussion should take place before advancing in > > this route. > > ACK Same here, please share your thoughts on how to reduce complexity. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 13:15:16 Alon Bar-Lev wrote: > IRC is synchronous way of communication, it is no suitable for distributed > volunteer team. > Proper discussion of design is done differently, perfecting a design > document and interface specifications. > > If there was such process, it does not mean that all participates at > that time had the skills to evaluate the suggested solution. > > Anyway, if there was a design process, I will appreciate if you can send a > design document, as this is not a small/niche feature, it will effect > the majority of Windows users. Yeah, like the design project phase for the build system revolution. Get a grip, Alon. Things might work this way in a corporation, this isn't one it's an open source project. If you don't like what you see, please speak your mind on how to improve concrete things and stop pulling up discussions into a meta layer. This leads to no solutions but only more discussions about stuff that doesn't get any things done. I hope you got my point. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 13:45:49 Alon Bar-Lev wrote: > I don't understand you attitude, I am not trying to take anything from you, > and I don't think you can find anything in my record that had negative > impact on this (or any other) project. And I do know one or two things in > security and networking. I'm just trying to get a statement from you about the spotted complexity and how it can be reduced, but somehow there's still nothing coming from your direction. > I only recommend the OpenVPN project manager to hold with this solution, > and manage a proper design process, there are people here who can help, if > the process is managed correctly. Alon, there is a process. It's just different from what you imagine it to be. If you're not keen to get on IRC then read the chat log that gets posted here the next day and comment on it. Comment and counter-propose on patches - as you do - and this project will go forward. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
Hi Fabian On Wednesday 29 February 2012 14:07:01 Fabian Knittel wrote: > Let's see whether I understood the design. After initial setup, the > GUI has a connection via the mgmt interface to OpenVPN and OpenVPN has > a connection via the "privilege interface" to the "interactive > service". OpenVPN basically runs in the same context as the GUI, i.e. > without permission to change the network configuration (change routes, > etc.). The "interactive service" runs in a context with permissions to > change the network configuration. Any privileged operations are > requested by OpenVPN via the "privilege interface" and performed by > the "interactive service". (There must be something missing, otherwise > I don't get why you call it "interactive service" ...?) It's interactive in contrast to the other already existing service, that just starts all openvpn connections that it finds at the time the service itself is started. I internally called that service automatic. The GUI and openvpn interact with the interactive service, hence the name. And partially because I couldn't come up with something that made more sense. > Why does the "interactive service" need to start OpenVPN? Why not let > the GUI start OpenVPN and let OpenVPN connect to the "interactive > service"? The key point here is the inheritance of the client end of the named pipe that's being used to request privileged operations. If there would just be a named pipe anyone could connect to, anyone could modify i.e. the routing table. Something MS tries to prevent obviously. > OTOH, if you're going to start OpenVPN as a service anyway, > it probably doesn't really make much of a difference. Although this > could mean that you can keep the GUI-facing side of OpenVPN identical > to what it is now... the "interactive service" would just be an > implementation detail of how openvpn performs its privileged > operations. I got lost at "going to start OpenVPN as a service anyway". Openvpn isn't started as a service, the service starts openvpn. Openvpn is not running with same token the service runs, but the token of the GUI that invoked the service. > Does creating a tun/tap device belong to the operations that need > special privileges under windows? If so, this sounds a lot like an > interface that might also allow splitting off most of the system > specific code ... as in, this could also work on Android, no? No, that example was a spin off to my lengthy and highly fictional NetworkManager story. =) Essentially you're right, though. It could be used as such. Usually I#d say that stuff that can be setup before privileges are dropped should be done at that time. Setting of routes can only be done after privdrop and that's the main use for the new interface. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 15:28:31 Fabian Knittel wrote: > To ensure this in classic Linux this would mean that the OpenVPN > process needs to run as a _different_ user than the GUI user or else > the GUI user could freely manipulate the program using, e.g. ptrace. I > know that similar manipulations are possible in Windows, so can you > protect the service-started OpenVPN-executable from such > manipulations? (And I also assume that _named_ pipes still allow you > to hide the name from some processes of the same user?) (I'm not an > experienced Windows programmer, so please excuse my ignorance...) Me neither, so any guru input is very welcome. Even the not-so-guru one like yours. Much appreciated! The pipe connecting the service and openvpn is limited to one instance, which is created within the service before starting openvpn. So, no other process can just attach this way and send commands even if it's the same user openvpn is running as. There is a way to use DuplicateHandle() to get the client pipe end out of the openvpn process if you have the rights. The GUI user has these rights, but I think there should be a way to take them away from even her via ACLs. Guru input requested on this topic! Starting from Vista there's also a way to run GetNamedPipeClientProcessId() and compare that to the one of the openvpn process before processing messages. Any other ideas to restrict access are very welcome. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] OpenVPN 2.3-alpha1 / GUI
Russell On Wednesday 29 February 2012 17:26:46 Russell Morris wrote: > 1) I know that someone (Heiko?) was looking at auto-proxy a while back. Is > this now working? Is there a way to test it (if it's now working), to see > what it determines for a proxy? During discussion of the Windows --auto-proxy patches at FOSDEM we've decided that the auto-proxy detection shouldn't take place within openvpn as it is very platform specific and there's no apparent need to do it there. We removed the --auto-proxy option from openvpn all together, it wasn't working much anyway and was only supporting Windows. In a future alpha/beta 2.3 release a GUI will be packaged that reacts to openvpn querying for proxy info via management interface. Currently I can't offer much to test, though. Sorry. > 2) I have a Windows GUI of my own (and I don't mean this as a "competition" > to the default OpenVPN GUI, not at all!!!). It's just tweaked for my > personal situation, on and off LAN and wireless, proxy, no proxy, etc. It > uses the management interface completely. In any case, it has some features > that I like, more than anything wondering if there are thoughts of extending > the current GUI to include items like this (as I'd rather use the official > GUI, I'm no SW expert - not even close). In any case, I have attached a few > pictures, in case someone has any ideas about new features for the official > GUI. Could you elaborate on the features you want to see included, please. Obviously you have some nice charts in your GUI. What language did you code this in? I suppose it's not C with plain WIN32 API? Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 18:43:18 Carsten Krüger wrote: > What operation could be in script that is usefull when it's executed > in user context. On Windows you could mount a CIFS share from the corporate LAN to the drive letter a user expects her data at, for example. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Wednesday 29 February 2012 19:18:00 Carsten Krüger wrote: > > If openvpn.exe startet in users context the user can manipulate it in > > ram arbitrarily. > > Example: > http://blog.didierstevens.com/2009/06/25/bpmtk-injecting-vbscript/ > (great blog about process manipulation :-) ) Took a look, neat tool. In the same blog the author mentions that integrity levels, introduced in Vista, can be used to circumvent DLL injection. If that works out, all that is needed is the service increasing the tokens integrity level before starting openvpn and the user will have limited access to the running openvpn process. http://blog.didierstevens.com/2010/09/07/integrity-levels-and-dll-injection/ Of course this makes only sense if the ongoing discussion about whether setting routes via --route config option comes to the conclusion "no". I'll follow up to Fabian about that. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Thursday 01 March 2012 10:40:51 Carsten Krüger wrote: > > If that works out, all that is needed is the service increasing the > > tokens integrity> > > level before starting openvpn and the user will have limited access to the > > running openvpn process. > > a) this didn't work, you can lower the level and but not higher Did you try it? I hope that it doesn't work for a normal user. The service should have sufficient rights to modify it I guess. Again these are only assumptions. If you have practical experience please be more verbose. > b) dll injection is ONE example of how a user can manipulate his own > process. I'm no expert at hacking windows but you can trust me, it > exists 1001 possibilities to do the same. You have no chance to block > them. I file that under FUD until you're more explicit. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Thursday 01 March 2012 11:59:11 Carsten Krüger wrote: > No. If you start a process in users context the user can modify it. > There is nothing you could do against. I'll do some tests next week and post my findings here. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
[Openvpn-devel] GUI size
Samuli, I've received a question about the size of the snapshot binaries in the issue tracker yesterday. https://sourceforge.net/tracker/?func=detail=1327094=3496102_id=248281 Could you compile the GUI yourself and link against the openssl crypto DLL for the next release? The GUI shouldn't be linked statically if there a libeay32.dll lying next to it, really. Thanks Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
On Thursday 01 March 2012 12:11:37 Heiko Hund wrote: > On Thursday 01 March 2012 11:59:11 Carsten Krüger wrote: > > No. If you start a process in users context the user can modify it. > > There is nothing you could do against. > > I'll do some tests next week and post my findings here. Sorry, haven't had much time for tests this week. However, I've done some reading here's the preliminary plans on how to secure openvpn.exe and the named pipe handle. It is false that you cannot set a process' mandatory label to a higher integrity level than the one in the token. Vista introduced the SE_RELABEL_NAME privilege specifically for that purpose. Apparently no default system account comes with the privilege assigned, though. As the "Local System" account on Windows 7 does not have it I wouldn't say it's very practical to go this way as admins would be forced to create a special "OpenVPN Service" account in order to run openvpn. Instead I plan to secure the process (and the probably the pipe handle as well) against malicious operations by not granting the user any sophisticated access to it, i.e. you can only inject code if you can write the process' memory. This will be enforced by the security descriptor assigned to the process by the service at creation time. The service account will own the process object, so that the user cannot sneak his way in by modifying the DACL. Hope I haven't overseen anything. If I did I'll be happy to receive feedback. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
Hi Fabian, On Friday 09 March 2012 16:34:19 Fabian Knittel wrote: > Does your > approach prevent the user from injecting code into the OpenVPN > process? Or does it only prevent the user from directly accessing the > pipe? (IIUC you would need the integrity level approach to prevent the > former so I assume you're describing how the pipe handle will be > protected instead.) It tries to prevent both. While protecting the elevation pipe to the service from arbitrary use is the actual goal it can only be achieved by also protecting the process from modification. In Windows you can clone handles (i.e. the pipe handle) from another process into your process if you have sufficient rights. As Carsten pointed out one could also inject code into the openvpn.exe process and use the pipe in-process in a unintended way. I'm currently uncertain if it's possible to duplicate the pipe handle if access to the process itself is limited down to a minimum. I guess it is. The integrity level thing is actually just a more convenient/automatic way to limit access to processes. Instead of limiting access manually through ACLs Windows will take care that a process with lower integrity level has limited access to one with a higher level by taking away rights of the calling process on a call by call basis during runtime. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
Hi Carsten, On Friday 09 March 2012 17:09:07 Carsten Krüger wrote: > I tried the following (disabled kernel process hacker): > 1. run an instance of notepad as user Carsten (normal windows user, no > admin) 2. entered "testtesttest" > 3. run an instance of process hacker as user Carsten > 4. tried to write to memory -> worked, closed process hacker > 5. run an instance of process hacker as admin and stripped permissions for > user Carsten completly, closed process hacker > 6. run an instance of process hacker as user Carsten > 7. tried to write to memory -> failed as you expected > 8. add full permissions to process for user Carsten -> works !!! This won't work with openvpn.exe started by the service. In your test the process object security descriptor was owned by the user. The owner of an object is always granted write access to the security descriptor of the object, thus you could change the permissions back to whatever you desired. The openvpn.exe process security descriptor will be owned by the user the service is run as, i.e. Local System. That's what I meant by "The service account will own the process object, so that the user cannot sneak his way in by modifying the DACL." Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released
Hi On Monday 12 March 2012 19:01:41 Alon Bar-Lev wrote: > Although I tried to go farther... that what James suggested. > What is the baseline? This what we should agree first... > Should openvpn daemon be run on completely unprivileged account or not. I don't support the idea about running openvpn.exe with elevated privileges. It has been run as the user before and that worked fine until Microsoft limited access to system resources in Vista. The service approach with the elevation pipe solves exactly that problem. Openvpn is very complex, running is under a privileged account is a security risk in my opinion. The elevation pipe offers a very limited and well defined interface to configure needed system resources only and tries hard to allow access for openvpn.exe only. If you compare what the possibilities of an attacker would be if the openvpn.exe process is compromised in both scenarios there's not much room to argue IMO. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [openvpn-gui 0/8] build rewrite
Hi Alon. Thanks for the contributions. I just pushed the changes, some of them modified. See below for comments. > Alon Bar-Lev (8): > cleanup: resolve unused parameter warnings Changed this to use gcc attributes like in other places. > cleanup: dos2unix res/openvpn-gui-res-fi.rc > cleanup: dos2unix res/openvpn-gui-res-jp.rc > cleanup: dos2unix OpenVPN GUI ReadMe.txt Merged into one commit that also converts all source files to \n line endings. > build: rework build Removed use of libtool and the implicit automake rule for .rc files. Instead add a manual rule for the resource object to Makefile.am. Regards Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
Re: [Openvpn-devel] [PATCH] OpenVPN GUI: Corrections to the Danish translation
Hi Kenni On Wednesday 04 April 2012 17:32:40 Kenni Lund wrote: > I created a ticket over at the OpenVPN GUI SourceForge project with a > patch attached - and now I've just noticed the wiki-page about > translations, which indicates that it should have been sent here > instead for visibility. Thanks for the patch. I've forwarded it to the original translator for review. If he doesn't NACK it within the next week or so I'll merge it. If any Danish speaking person here ACKs it it's also good to go of course. Regards Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] [Translation Question] Traditional Chinese
Hi YiWen On Thursday 12 April 2012 02:28:17 Yi-Wen Cheng wrote: > I want to translate openvpn into Traditional Chinese. > Could anybody assist me what should I do to start the work? Great, thank you! I suppose you want to translate the Openvpn GUI for Windows. If so, just fetch the English resource file from the repository at [1], translate the strings in it and make sure you save it UTF-8 encoded. Then send it to this list or open an issue about it at [2]. Please also change the language constants to "LANG_CHINESE | SUBLANG_CHINESE_TRADITIONAL" (this will make a bit more sense after you looked at [1]). Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] [Translation Question] Traditional Chinese
On Thursday 12 April 2012 08:54:12 Heiko Hund wrote: > Great, thank you! I suppose you want to translate the Openvpn GUI for > Windows. If so, just fetch the English resource file from the repository at > [1], translate the strings in it and make sure you save it UTF-8 encoded. > Then send it to this list or open an issue about it at [2]. Please also > change the language constants to "LANG_CHINESE | > SUBLANG_CHINESE_TRADITIONAL" (this will make a bit more sense after you > looked at [1]). Oh yeah, the links… =) [1] http://bit.ly/HyRzAd [2] http://sourceforge.net/tracker/?func=add_id=248281=1327094 Sorry about that. Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] [PATCH] cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest
On Friday 27 April 2012 09:54:15 Samuli Seppänen wrote: > Anyways, I cross-compiled latest "master" with this patch applied and > "bin" and "lib" directories on top of an existing openvpn-2.3-alpha1 > install. The old "bin" directory was renamed to make sure none of it was > used. I then renamed "openvpn.ovpn" to "ääliö.ovpn" and "ta.key" to > "ääliö.key" using Windows Explorer. Then I updated the configuration > file to point to these files using Notepad (and later Wordpad). Notepad saves UTF-8 files with BOM, which is very uncommon. Maybe that was the problem. I ran into that when I was testing my patch. You might want to try using Notepad++ and save it as UTF-8 without BOM. HTH Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] Does OpenVPN Support Unicode Username and Password
Hi, On Wednesday 02 May 2012 10:10:05 Gauri Bhave wrote: > I am customizing the openvpn GUI to support multiple languages. I want to > connect using a non ASCII username, Say a chinese or hindi user name. Is it > possible in Open VPN. actually the GUI at http://sourceforge.net/projects/openvpn-gui/ already supports multiple languages. Basing your translations on that one will save you some time and they will also end up in the upcoming OpenVPN 2.3 installers automatically. So, just grab an existing file from the res/ directory and do your translations based on it. If need further assistance feel free to ask. Regards Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] [Translation Question] Traditional Chinese
Hi Yi-Wen On Monday 14 May 2012 09:37:24 Yi-Wen Cheng wrote: > Could I get the "res_openvpn-gui-res-xx.rc" of simplified chinese? So far nobody has done the translation to Simplyfied Chinese. If you would do it in parallel while translating into Traditional Chinese you'd be some kind of hero! =) > Shall I just translate all Engilsh sentences in English rc file and save to > another rc file? Yes, just grab the English version, save it as openvpn-gui-res-zh-hant.rc (or zh-hans for simplified) and translate it. Make sure to use UTF-8 encoding for the file. When you're done simply post the result here and I will add it to the official repository. Regards Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Re: [Openvpn-devel] [Translation Question] Traditional Chinese
On Thursday 17 May 2012 19:06:06 Yi-Wen Cheng wrote: > I just finished both of files for translating to traditional chinese. Took me a little while, but I just finished integrating it into the GUI. Don't know what .lang file is for, but I suppose it's another project you contribute translation to. The .rc file is now part of the official OpenVPN-GUI. Thanks for your efforts! > Btw,how can I see the new GUI of traditional chinese on my laptop? I released a new snapshot binary. You should be able to download it once it's spread across the Sourceforge download mirrors at http://sf.net/projects/openvpn-gui/files/Snapshot%20Binaries/2012-05-22/ Will you do the translation to Simplified Chinese as well? Is so, please base it on the openvpn-gui-res-zh-hant.rc file in the repository. I made some changes to the one you sent. Thanks again Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
[Openvpn-devel] [PATCH] add option --management-query-proxy
Make openvpn query for proxy information through the
management interface. This allows GUIs to provide (automatically
detected) proxy information on a per connection basis.
This new option supersedes the undocumented --http-proxy-fallback
option and puts the responsibilty for HTTP proxy fallback handling
to the GUI caring for such.
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
doc/management-notes.txt | 31
doc/openvpn.8|6 ++
src/openvpn/init.c | 185 +-
src/openvpn/manage.c | 52 +++--
src/openvpn/manage.h | 17 ++---
src/openvpn/options.c| 112
src/openvpn/options.h| 28 +--
src/openvpn/proxy.c | 15
src/openvpn/proxy.h |3 +
src/openvpn/syshead.h|6 +-
10 files changed, 178 insertions(+), 277 deletions(-)
diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index 785eb88..a07a514 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -719,6 +719,37 @@ use this command:
remote SKIP
+COMMAND -- proxy (OpenVPN 2.3 or higher)
+
+
+Provide proxy server host/port and flags in response to a >PROXY
+notification (client only). Requires that the --management-query-proxy
+directive is used.
+
+ proxy TYPE HOST PORT ["nct"]
+
+The "proxy" command must only be given in response to a >PROXY
+notification. Use the "nct" flag if you only want to allow
+non-cleartext auth with the proxy server. The following >PROXY
+notification indicates that the client config file would ordinarily
+connect to the first --remote configured, vpn.example.com using TCP:
+
+ >PROXY:1,TCP,vpn.example.com
+
+Now, suppose we want to connect to the remote host using the proxy server
+proxy.intranet port 8080 with secure authentication only, if required.
+After receiving the above notification, use this command:
+
+ proxy HTTP proxy.intranet 8080 nct
+
+You can also use the SOCKS keyword to pass a SOCKS server address, like:
+
+ proxy SOCKS fe00::1 1080
+
+To accept connecting to the host and port directly, use this command:
+
+ proxy NONE
+
OUTPUT FORMAT
-
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index a821b5e..56be29e 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -2446,6 +2446,12 @@ for inputs which ordinarily would have been queried from
the
console.
.\"*
.TP
+.B \-\-management-query-proxy
+Query management channel for proxy server information for a specific
+.B \-\-remote
+(client-only).
+.\"*
+.TP
.B \-\-management-query-remote
Allow management interface to override
.B \-\-remote
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index f86fc38..614d081 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -111,102 +111,100 @@ update_options_ce_post (struct options *options)
#endif
}
-#if HTTP_PROXY_FALLBACK
-
+#ifdef ENABLE_MANAGEMENT
static bool
-ce_http_proxy_fallback_defined(const struct context *c)
+management_callback_proxy_cmd (void *arg, const char **p)
{
- const struct connection_list *l = c->options.connection_list;
- if (l && l->current == 0)
-{
- int i;
- for (i = 0; i < l->len; ++i)
- {
- const struct connection_entry *ce = l->array[i];
- if (ce->flags & CE_HTTP_PROXY_FALLBACK)
- return true;
- }
-}
- return false;
-}
+ struct context *c = arg;
+ struct connection_entry *ce = >options.ce;
+ struct gc_arena *gc = >c2.gc;
+ bool ret = false;
-static void
-ce_http_proxy_fallback_start(struct context *c, const char *remote_ip_hint)
-{
- const struct connection_list *l = c->options.connection_list;
- if (l)
-{
- int i;
- for (i = 0; i < l->len; ++i)
- {
- struct connection_entry *ce = l->array[i];
- if (ce->flags & CE_HTTP_PROXY_FALLBACK)
- {
- ce->http_proxy_options = NULL;
- ce->ce_http_proxy_fallback_timestamp = 0;
- if (!remote_ip_hint)
- remote_ip_hint = ce->remote;
- }
- }
+ update_time();
+ if (streq (p[1], "NONE"))
+ret = true;
+ else if (p[2] && p[3])
+{
+ const int port = atoi(p[3]);
+ if (!legal_ipv4_port (port))
+{
+ msg (M_WARN, "Bad proxy port number: %s", p[3]);
+ return false;
+}
+
+ if (streq (p[1], "HTTP"))
+{
+#ifndef ENABLE_HTTP_PROXY
+ msg (M_WARN, "HTTP proxy support is not available");
+#else
+ struct http_proxy_options *ho;
+ if (ce->proto != PROTO_TCPv4 && ce->proto != PROTO_TCPv4_CLIENT &&
+
[Openvpn-devel] [PATCH] remove unused show_connection_list debug function
Signed-off-by: Heiko Hund <heiko.h...@sophos.com>
---
src/openvpn/init.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index f86fc38..81800d3 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -316,30 +316,6 @@ init_connection_list (struct context *c)
}
}
-#if 0 /* fixme -- disable for production */
-static void
-show_connection_list (const struct connection_list *l)
-{
- int i;
- dmsg (M_INFO, "CONNECTION_LIST len=%d current=%d",
- l->len, l->current);
- for (i = 0; i < l->len; ++i)
-{
- dmsg (M_INFO, "[%d] %s:%d proto=%s http_proxy=%d",
- i,
- l->array[i]->remote,
- l->array[i]->remote_port,
- proto2ascii(l->array[i]->proto, true),
- BOOL_CAST(l->array[i]->http_proxy_options));
-}
-}
-#else
-static inline void
-show_connection_list (const struct connection_list *l)
-{
-}
-#endif
-
/*
* Increment to next connection entry
*/
@@ -374,7 +350,6 @@ next_connection_entry (struct context *c)
if (l->current == 0)
newcycle = true;
- show_connection_list(l);
}
ce = l->array[l->current];
--
1.7.9.5
