[Openvpn-devel] TAP driver & NDIS 6.3

[Jan Just Keijser]

yo list,

did anybody see this post on the forum

 https://forums.openvpn.net/topic12455.html

"Current windows TAP driver 9.9.2 uses NDIS API version 5.0. This is 
fine for desktop Windows including Windows 8, but the driver sources 
cannot be recompiled for Windows RT. Windows RT requires NDIS drivers to 
use NDIS API version 6.30, and MS completely removed support for older 
NDIS API."


?

cheers,

JJK

[Openvpn-devel] forum topic12703: cross compile problem with crypto-library=polarssl

[Jan Just Keijser]

hi *, particularly Adriaan,

can someone take a look at
 https://forums.openvpn.net/topic12703.html
subject: cross compile problem with crypto-library=polarssl

thx,

JJK

Re: [Openvpn-devel] [PATCH] Add auto value to pkcs11-id parameter

[Jan Just Keijser]

Chris J Arges wrote:

This patch allows one to specify --pkcs11-id auto to automatically
select the first certificate on a pkcs11 device. This simplifies
scripts and usage in environments where clients may only use a single
certificate for connecting to a VPN.
Based on a patch by Oliver Dumschat-Hötte.

  
some security-minded (paranoid?) folks will say that you should never 
automatically select a certificate/key pair (which is what a normal user 
would want, of course).  This patch does seem like a useful addition, 
and it actually restores some functionality found in earlier versions of 
OpenVPN, IIRC.  Perhaps more warnings should be added about this being a 
(minor) security risk.


A man page snippet for this is missing from the patch, but that can be 
done if the patch is ACKed by others.

I'm not authoratitive on ACKing patches, but as far as I am concerned: ACK

JJK


Reported-by: Oliver Dumschat-Hötte 
Signed-off-by: Chris J Arges 
---
 src/openvpn/pkcs11.c |   41 +
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/pkcs11.c b/src/openvpn/pkcs11.c
index 3a15ef6..11d5e8f 100644
--- a/src/openvpn/pkcs11.c
+++ b/src/openvpn/pkcs11.c
@@ -669,14 +669,39 @@ tls_ctx_use_pkcs11 (
}
}
else {
-   if (
-   (rv = pkcs11h_certificate_deserializeCertificateId (
-   _id,
-   pkcs11_id
-   )) != CKR_OK
-   ) {
-   msg (M_WARN, "PKCS#11: Cannot deserialize id %ld-'%s'", 
rv, pkcs11h_getMessage (rv));
-   goto cleanup;
+   if ( strcmp(pkcs11_id, "auto") == 0 ) {
+   char *pkcs11_id_read = NULL;
+   char *base64 = NULL;
+   if ( !pkcs11_management_id_get(
+  0,
+  _id_read,
+  
+  )
+   ) {
+   msg (M_WARN, "PKCS#11: pkcs11_management_id_get 0 
failed");
+   goto cleanup;
+   }
+   if (
+   (rv = 
pkcs11h_certificate_deserializeCertificateId (
+   _id,
+   pkcs11_id_read
+   )) != CKR_OK
+   ) {
+   msg (M_WARN, "PKCS#11: Cannot deserialize auto id 
%ld-'%s'", rv,
+pkcs11h_getMessage (rv));
+   goto cleanup;
+   }
+   } else {
+   if (
+   (rv = 
pkcs11h_certificate_deserializeCertificateId (
+   _id,
+   pkcs11_id
+   )) != CKR_OK
+   ) {
+   msg (M_WARN, "PKCS#11: Cannot deserialize id 
%ld-'%s'", rv,
+pkcs11h_getMessage (rv));
+   goto cleanup;
+   }
}
}
 
  

Re: [Openvpn-devel] option --crl-verify PATH dir

[Jan Just Keijser]

Adriaan de Jong wrote:

-Original Message-
From: David Sommerseth [mailto:openvpn.l...@topphemmelig.net]
Sent: zondag 3 februari 2013 15:52
To: Jan Just Keijser
Cc: openvpn-devel@lists.sourceforge.net
Subject: Re: [Openvpn-devel] option --crl-verify PATH dir

On 03/02/13 12:02, Jan Just Keijser wrote:


hi,

what is the second option to '--crl-verify' supposed to do? in
options.c it sets a flag SSLF_CRL_VERIFY_DIR which then triggers the
function 'verify_check_crl_dir'. However, this function does not seem
to do anything
  

Quickly looked at the code ... with the 'dir' flag (which sets
SSLF_CRL_VERIFY_DIR), it's no longer a typical CRL file validation.  If
you create (touch) a file in the defined directory with the file name
matching a particular client's serial number; the connection will be
denied.




Confirmed, with the footnote that this is a weird way of going about things. 


I would like to suggest deprecating this option from 2.4 (or 2.3.1?) onwards, 
and forcing people to either:

 - Create an actual CRL file. This is not difficult. In general, people using 
OpenVPN should be managing their own CA in the OpenVPN world.
 - Failing that, create a custom script to do this.

I'm always open for discussion, but imho this should not be core functionality 
in OpenVPN.
  


I agree that CA cert and CRL management should not be part of the "core" 
functionality of OpenVPN.
In one of my setups I've got a --ca-path containing 108 different CA 
certs, with 108 CRLs for each of them - concatenating those 108 CRLs 
into one big CRL.pem file every day would be a major nuisance...
OpenSSL has very nice support (--ca-path) for a directory containing a 
set of CA certs and their corresponding CRLs; AFAIK PolarSSL does not 
have this option - so perhaps there is some usefulness to this option 
after all?



share and enjoy,

JJK

Re: [Openvpn-devel] [PATCH 1/7] refine assertion to allow other modes than CBC

[Jan Just Keijser]

Arne Schwabe wrote:

Am 16.08.12 10:38, schrieb Heiko Hund:
  

cipher_ctx_final() only returns an outlen in CBC mode. If CFB or OFB
are used the assertion outlen == iv_len is always false.

There's no CBC mode defined for the GOST 28147-89 block cipher. Hence
this patch is needed for it to work. It's needed for other ciphers like
BF-CFB as well, though.

Signed-off-by: Heiko Hund 
---
 src/openvpn/crypto.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index ac2eecd..2f67e5e 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -153,7 +153,7 @@ openvpn_encrypt (struct buffer *buf, struct buffer work,
  /* Flush the encryption buffer */
  ASSERT(cipher_ctx_final(ctx->cipher, BPTR () + outlen, ));
  work.len += outlen;
- ASSERT (outlen == iv_size);
+ ASSERT (mode != OPENVPN_MODE_CBC || outlen == iv_size);
 
 	  /* prepend the IV to the ciphertext */

  if (opt->flags & CO_USE_IV)



I have a user of my app that also tripped over this asssert line:

  
hhh - removing the assert is nice, but do the other ciphers actually 
*WORK* after that? does the test

 openvpn --test-crypto
pass after that? I remember commenting out the assert for a few elliptic 
curve ciphers, but openvpn was still not able to encrypt/decrypt  
traffic successfully.



JJK

[Openvpn-devel] man page patch for missing options

[Jan Just Keijser]

hi all,

attached is a man page patch to include the options that were made 
connection-entry specific (by a patch of mine, which is included in 2.3.0).


see you in a bit,

JJK

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 2ed5201..829bbd2 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -346,20 +346,27 @@ block:
.B connect-retry,
.B connect-retry-max,
.B connect-timeout,
+.B explicit-exit-notify,
.B float,
+.B fragment,
.B http-proxy,
.B http-proxy-option,
.B http-proxy-retry,
.B http-proxy-timeout,
+.B link-mtu,
.B local,
.B lport,
+.B mssfix,
+.B mtu-disc,
.B nobind,
.B port,
.B proto,
.B remote,
.B rport,
-.B socks-proxy, and
-.B socks-proxy-retry.
+.B socks-proxy,
+.B socks-proxy-retry,
+.B tun-mtu and
+.B tun-mtu-extra.

A defaulting mechanism exists for specifying options to apply to
all

Re: [Openvpn-devel] Summary of the IRC meeting (29th Nov 2012)

[Jan Just Keijser]

Hi all,

Samuli Seppänen wrote:

Hi,

Here's the summary of the previous IRC meeting.


  
it's great to hear that the openvpn community is getting together again 
at FOSDEM 2013 !
One small practial remark , however:  the train schedule between 
Amsterdam en Brussels is about to change; the train andj and I took last 
year no longer runs in 2013; instead you have to make a reservation for 
a new *faster* train , the Fyra. If somebody is interested in taking 
this route (Amsterdam/Schiphol -> Brussels)  then contact me for details.



And it's great to hear that an iOS client is forthcoming - people have 
been pestering me about that for ages!


cheers,

JJK



COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
Date: Thursday 29th Nov 2012
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting will be announced in advance, but will probably be on the same
weekday and at the same time. Your local meeting time is easy to check
from services such as



or with

$ date -u


SUMMARY

cron2, dazo, ecrist, krzee, jamesyonan, mattock, novaflash, plaisthos,
raidz and swg0101 participated in this meeting.

--

Started the meeting with short round of introductions. Some were not
formally introduced, but are included here. On the community side:

- cron2: The OpenVPN IPv6+BSD+Solaris developer, buildbot farmer (Germany)
- dazo:  master of plugins and git, does patch management, cleanups and
lots of other good work (Norway)
- d12fk: develops the new openvpn-gui for Windows (Germany)
- ecrist: takes care of forums, easy-rsa maintenance, #openvpn channel,
etc. (Unites States)
- krzee: takes care of the forums and IRC with ecrist; a mystical figure
(somewhere in the Caribbean)
- plaisthos: did the Android port; in charge of overhauling the socket.c
code (Germany)

On the company side:

- jamesyonan: Father of OpenVPN (United States/Colorado)
- mattock: Community manager, server administrator, does OSS releases,
testing, etc. (Finland)
- novaflash: Support technician (Netherlands)
- raidz: Support engineer, network engineer, and janitor (United
States/California)
- swg0101: Support and development (United States)

A few non-participants were also mentioned:

- andj: Added polarssl support to openvpn and is maintaining that part
(Netherlands)
- juanjo: The other IPv6 guy who we seldom see (from where?)

---

Jamesyonan gave a short introduction of the new C++ codebase:

- about 30K lines of C++ code
- an object-oriented rethinking of openvpn from the ground up
- design similar to original OpenVPN 3.0:

- is very modular in the sense that SSL/crypto libraries, transport
protocols, etc. can be modularized
- fairly prototypical/incomplete at this stage; only the client-side has
been implemented
- has been tested against Access Server (based on OpenVPN 2.1.x) and
OpenVPN 2.3* servers
- is 100% protocol compatible with 2.x branches
- has most 2.x's options
- is being used in the OpenVPN tech android client and the upcoming iOS
client
- may (at some point) supplant the 2.x branch, but that'll probably take
at least 1-2 years

Some more technical tidbits:

- core leverages on Boost Asio as it's async i/o layer
- C++ is really ready for prime time in system programming / networking
space
- C++ 2003 that's used seems to work very well on different compilers
- C++ static polymorphism (templates) is great for network programming
where we have small objects that have polymorphic properties, such as
IPv4 vs IPv6 addresses

---

Discussed open sourcing the C++ codebase:

According to jamesyonan, the plan is to release this probably under GPL
within the next couple months, but the company needs the ability to
relicense the C++ core because of (Apple) app store issues. It was
agreed that having OpenVPN on that platform is a must. To accomplish
this, relicensing the codebase is necessary. The consensus was that this
can be done in a way that's acceptable to all parties, without resorting
to the classic "copyright handover" scheme, which was not ok for everyone.

The alternative would be to release the C++ codebase under a permissive
license (e.g. BSD), but that would allow companies such as Apple or
Microsoft to "steal" it. This was not seen as a good option, either.

---

Discussed the role of OpenVPN 2.3 within the company:

The company is planning to migrate the Access Server to OpenVPN 2.3*.
Before the meeting mattock had already managed to get the Access Server
running with OpenVPN-2.3-rc1 in a few hours, with only few minor
modifications. Tests run by raidz during the meeting revealed no further
issues. More details will follow later.

---

Discussed having a joint company/community meeting in FOSDEM
(https://fosdem.org/2013). Most of the present developers seem to be
coming, but nobody has dared book the flights or hotel yet.

---

Re: [Openvpn-devel] RFC - Usage of --script-security with the 'system' flag

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

Hi all,

I've been reviewing a bug reported to the v2.3 code base.  We're in the 
beta phase currently, and this is a bug I'd like to get fixed before 
we're moving on further.  The bug is related to the use of the 'system' 
flag in --script-security.




The use of the 'system' flag has been deprecated for a long time.  And 
it is really a potential security issue to use it, due to shell 
expansions which might happen.  The preferred (and default way) is to 
use execve(), which is far safer and does not do the shell expansions 
while executing the script or binary.


  
on Linux the difference is not that big, however watch out for Windows 
servers - with the old (system) like functionality it was possible to 
specify e.g. a VBS script directly. With the 'exec' style you need to 
specify the vbscript.exe, the full path to the script etc etc. There's 
even an example about this in the book you're reviewed for me ;)
If at all possible I'd leave in the 'system' like functionality , as it 
is very valuable for debugging scripts. We can add warnings about it 
being deprecated and the fact that there's the risk of memory leaks , 
but I do see value in this feature.


JM2CW,

JJK


The fix I'm currently considering is to remove support for the system() 
call completely.  This support was introduced in 2.1_rc9 (Nov 17, 2008).


Does anyone depend on --script-security where the 'system' flag is 
required?  If you need this feature, can you please elaborate why this 
support is needed and why you cannot use the preferred default with 
execve?


The main differences between execve() and system() calls are:

system() loads a shell before executing the script or binary, which
also provides all system environment variables defined by
/etc/profile etc.  On top of that, all the OpenVPN configured
environment variables are added.

execve() will load and execute the script or binary directly, which
will only provide the environment variables provided by OpenVPN by
default.  Example:

   -
   #!/bin/bash

   printenv
   -

Using this with '--script-security 2' will dump this out:

   -
   dev_type=tap
   ifconfig_local=192.168.100.1
   proto_1=udp
   tun_mtu=1500
   ifconfig_netmask=255.255.255.0
   script_type=up
   verb=4
   local_port_1=10443
   dev=tap0
   remote_port_1=10443
   PWD=/home/test/openvpn
   daemon=0
   ifconfig_broadcast=192.168.100.255
   SHLVL=1
   script_context=init
   daemon_start_time=1350465187
   daemon_pid=19045
   daemon_log_redirect=0
   link_mtu=1573
   -

If you need system variables as well with execve, you can either modify
the #!/bin/bash line to add --login, or you can source /etc/profile in
your script.

If you modify the --script-security to look like
'--script-security 2 system', printenv will dump a rather massive list
with environment variables.



* Technical details regarding a possible fix:

The reason this is hard to fix, is that it will require a massive work 
to avoid memory leaks.  An first example:


   
 char *envvar = malloc(100);

 snprintf(envvar, 30, "TESTVAL=abc");
 putenv(envvar); /* NOTE: We only do putenv() here */
 system("/bin/sh");  /* echo $TESTVAL returns 'abc' */

 snprintf(envvar, 30, "TESTVAL=123456");  /* A simple change */
 system("/bin/sh");  /* echo $TESTVAL returns '123456' */

 free(e);
 system("/bin/sh");  /* echo $TESTVAL is not set */
   

The current implementation will clean up the environment variables too 
early when using 'system'.  When using 'execve', OpenVPN provides a the 
environment variables via a completely different mechanism which cleans 
up the memory properly at the right time.


The result is that with 'system', we're seeing assertion issues as it 
is now.  Trying to fix this, leads easily to other fun memory 
corruption issues.  And fixing this requires a more massive amount of 
adding proper gc_arena garbage collection higher up in the call paths.  
This is needed to let the system() call have all the environment 
variables set by OpenVPN untouched while running and first clean them 
up afterwards.


Considering that using system() is less safer than execve(), I would 
prefer to remove support for system(); instead of passing around a lot 
more gc_arena pointers to get the memory management correct for 
system() to function properly.


My first hackish attempt (without cleaning it up) gives this change stat:

 $ git diff --stat
 src/openvpn/misc.c |   65 
++---
 src/openvpn/misc.h |6 --
 src/openvpn/platform.c |6 +++---
 src/openvpn/platform.h |2 +-
 4 

Re: [Openvpn-devel] Ability to send variable data from client to server

[Jan Just Keijser]

Hi Gert,

Gert Doering wrote:

Hi,

On Mon, Oct 01, 2012 at 06:58:28AM +, f7n4ahb...@snkmail.com wrote:
  
I believe there is ongoing development to allow a variable to be set in the client config which can be used by the client-connect or route-up scripts on the server. Specifically I need to add a custom route for each client depending on a value set in their config file. 


Can anyone point me to a thread where this is being tracked or the person to 
whom this feature has been assigned as I would like to assist in development if 
possible.



I'm not aware of such a development going on (doesn't mean nobody is 
working on it, but it wasn't discussed recently on #openvpn-devel or this

list)

Can't you use the client's common-name or username for that?  That's what 
everybody else seems to be doing...


  
I'm the one who forwarded him to this mailing list; the "work" I'm 
referring to is the ENABLE_PUSH_PEER_INFO stuff which is present in 
openvpn 2.2+ but which does not seem to be complete. I was and am hoping 
that one of the developers (perhaps James Y?) can comment on the status.


cheers,

JJK

Re: [Openvpn-devel] openvpn-gui disconnect

[Jan Just Keijser]

Hi Nelson,

Nelson Teixeira wrote:

Hello,

Sorry by writting directly to devel list, but I'm not being able to 
solve this problem I'm in and thought maybe you would be so kind to 
take a look. Thanks in advance :)


I'm having trouble in finding how to end openvpn programmatically in 
windows. If I run openvpn in command line, I can end it graciously 
with F4. What I want to do is to make my python program (or batch 
file/executable program, can be in C/C++) do the same thing: end it 
gracioulsy, allow for openvpn to do it's cleanup tasks.
Yet the only thing available to stop the process is taskkill /F /PID 
 that ends it immediately without allowing openvpn to do 
it's  cleanup tasks. If I don't use /F switch, it just ignores the 
command. I tried  also with /T (Tree Kill). No luck.
I also tried to get openvpn pid and send it a signal using this python 
code (it's python but it's easily understandable by anyone:


the "proper" way to do this is to use the management interface; the 
openvpn-gui code does just that (file openvpn.c):


725 /* Construct command line */
726 _sntprintf_0(cmdline, _T("openvpn "
727 "--config \"%s\" %s --service %s 0 --log%s \"%s\" "
728 "--management 127.0.0.10 %hd stdin --auth-retry interact "
729 "--management-hold --management-query-passwords --tls-exit"),


you can then use the same management interface to properly shut down 
openvpn again.


HTH,

JJK

[Openvpn-devel] [Fwd: Re: [OpenVPN Community] #97: OpenVPN produces DCHP NAK bomb on Win 7 64bit]

[Jan Just Keijser]

did one of the tap-win32 developers see this:

Seems to be a bug in the TAP driver. It's happening after you try to
refresh the DHCP lease 3 times (after resume from hibernation, Windows
tries to acquire a DHCP lease too).
I think the reason for this is a programming error in dhcp.c in function
ProcessDHCP:


  // Is this a bad DHCPREQUEST?
  if (msg_type == DHCPREQUEST && dhcp->ciaddr != p_Adapter->m_dhcp_addr)
++p_Adapter->m_dhcp_bad_requests;


should be:

  if (dhcp->ciaddr && msg_type == DHCPREQUEST && dhcp->ciaddr !=
p_Adapter->m_dhcp_addr)
++p_Adapter->m_dhcp_bad_requests;

as the win32 DHCP client always requests with all fields set to 0, so this
increases the error counter even though it isn't a bad request and as
BAD_DHCPREQUEST_NAK_THRESHOLD is 3, it fails after the third renew
attempt.


?

share and enjoy,

JJK



--- Begin Message ---
#97: OpenVPN produces DCHP NAK bomb on Win 7 64bit
--+-
 Reporter:  janjust   |Owner:   
 Type:  Bug / Defect  |   Status:  closed   
 Priority:  major |Milestone:  release 2.2.2
Component:  Networking|  Version:  2.1.4
 Severity:  Not set (if unsure, select this one)  |   Resolution:  fixed
 Keywords:  win7 tap-win32 dhcpnak|  
--+-

Comment(by ert):

 Seems to be a bug in the TAP driver. It's happening after you try to
 refresh the DHCP lease 3 times (after resume from hibernation, Windows
 tries to acquire a DHCP lease too).
 I think the reason for this is a programming error in dhcp.c in function
 ProcessDHCP:


   // Is this a bad DHCPREQUEST?
   if (msg_type == DHCPREQUEST && dhcp->ciaddr != p_Adapter->m_dhcp_addr)
 ++p_Adapter->m_dhcp_bad_requests;


 should be:

   if (dhcp->ciaddr && msg_type == DHCPREQUEST && dhcp->ciaddr !=
 p_Adapter->m_dhcp_addr)
 ++p_Adapter->m_dhcp_bad_requests;

 as the win32 DHCP client always requests with all fields set to 0, so this
 increases the error counter even though it isn't a bad request and as
 BAD_DHCPREQUEST_NAK_THRESHOLD is 3, it fails after the third renew
 attempt.
 Could someone please fix this in the TAP driver and provide a signed copy?
 We need the driver for production use...

 Regards.

-- 
Ticket URL: 
OpenVPN Community 
OpenVPN is a layer 2/3 SSL VPN
--- End Message ---

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Jan Just Keijser]

Hi,

Samuli Seppänen wrote:

Hello,

I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/

The API of Android 4.0 requires that openvpn runs as completely
unprivileged process. There all opening of tun, adding of routes,
ifconfig etc. has to be done by another process.

This patch implements an API to allow pushing routes, dns, tun over the
management interface (unix socket). Also on Android 4.0 the connection
for the control has to be protect via an API call from the Java GUI.
 
Basically I am using the needok feature of the management protocol to

push all relevant information to the GUI or to request information. I
have not split the patch into multiple small patches because it should
be first discussed if this is right architectural way.


Arne


Hi Arne,

This is very neat, thanks! I wish I had an Android phone to test with
this...

  
FYI: actually, you can run android 4 on your PC (Linux/Win/Mac) quite 
nicely - simply download the android SDK.  Performance is actually 
pretty good!


cheers,

JJK

Re: [Openvpn-devel] openvpn question

[Jan Just Keijser]

Hi Raj,

Raj Kumar wrote:


Hi all,

I am new to openvpn. I am using openvpn on my  linux machine.

I have a basic question about openvpn. 


How openvpn process the incoming packets ?

Is it processing incoming packets one by one, means receive one packet 
from the kernel, decrypt it and send it back to the kernel then next 
packet ?

or
whenever a packet comes, openvpn receives  and queues it while doing 
decryption of already received packet ?


 
openvpn processes the incoming packets one by one , both from the VPN 
side (the encrypted packets) , and the packets coming in via the tun/tap 
interface. This is one of the main reasons why openvpn speeds top off at 
around ~ 300 Mbps.


HTH,

JJK

Re: [Openvpn-devel] openssl ouch

[Jan Just Keijser]

Jan Just Keijser wrote:

ouch:
 http://www.openssl.org/news/secadv_20120419.txt

we need to investigate whether and how openvpn is affected.


did somebody end up writing an 'authoritative' answer to the question if 
and how openvpn is affected by this bug?


cheers,

JJK

Re: [Openvpn-devel] [PATCH] Signed-off-by: Jan Just Keijser <janj...@nikhef.nl>

[Jan Just Keijser]

Hi Adriaan,

Adriaan de Jong wrote:



+void
+tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, const char


*curve_name


+)
+{
+#ifdef USE_SSL_EC
+  if (curve_name != NULL)
+  {
+int nid;
+EC_KEY   *ecdh  = NULL;
+
+nid = OBJ_sn2nid(curve_name);
+
+if (nid == 0)
+  msg(M_SSLERR, "unknown curve name (%s)", curve_name);
+else
+{
+  ecdh = EC_KEY_new_by_curve_name(nid);
+  if (ecdh == NULL)
+msg (M_SSLERR, "Unable to create curve (%s)", curve_name);
+  else
+  {
+const char *sname;
+
+if (!SSL_CTX_set_tmp_ecdh(ctx->ctx, ecdh))
+  msg (M_SSLERR, "SSL_CTX_set_tmp_ecdh: cannot add curve");
+



What is happening here exactly? Is the same key being reused for
  

every


connection, or is it magically regenerated by OpenSSL on every
  

connection?

  

the function SSL_CTX_set_tmp_ecdh is very similar to SSL_CTX_set_tmp
(for DH keys).
It adds the curve to the SSL CTX (ConTeXt); this CTX is used only when
negotiating the TLS channel - NOT the data channel. It is updated by
the OpenSSL TLS code automagically.



Thanks, I realise this is just about the control channel. Still: for a server setup, multiple control channels are set up (one for each connection). 


What I'm reading here, but that could be a mistake is the following:

1. Determine Curve NID
2. Generate a new DH key based on the curve NID (ecdh = 
EC_KEY_new_by_curve_name(nid);)
3. For the global context, set that key as the one be used. 

Now, if that is correct, the same key is reused across multiple connections for a server setup. 


Again, note that my assumptions here might be incorrect, especially in step 2. 
Unfortunately, I can't find decent documentation for the OpenSSL functions.

  



What I'm mostly concerned with is the control channel setup. As I understand 
it, there's two steps involved that can use elliptic curve crypto:

1. Authentication using ECDSA/RSA/DSA/whatever
2. Anonymous DH/ECDH negotiation to get a session key

What I'm wondering is, if you use ECDSA, how is the curve for ECDSA set? As I understand it, this patch only sets the ECDH curve and key, not the 



  

The main reason for adding this patch is to allow the use of
certificates which are generated with ECDH keys and which are signed
with a SHA2 family hash; without this patch , this is not allowed.




That's what my question boils down to: isn't ECDSA, not ECDH the 
certificate-based part of the algorithm? ECDH is anonymous, isn't it?

  

Finally one more comment: to be accepted into the main branch, this
needs manpage and command line documentation.


  

very true... but that applies to more patches ;)




Unfortunately true...

I hope that clarifies my concerns a little. Unfortunately, I haven't found a 
good authoritative source for the functionality of SSL_CTX_set_tmp_ecdh. If it 
works in a similar manner to SSL_CTX_set_tmp_rsa, then you would need to use 
SSL_CTX_set_tmp_ecdh_callback instead to generate a new key for every control 
channel (see the ssl_openssl.c code for an example of that).
  

Your questions are all very valid.
The documentation on these functions is indeed atrocious ...  from what 
I understood  the SSL_CTX_set_tmp_ecdh function is very similar to the 
SSL_CTX_set_tmp_dh function; there's also a 'set_tmp_dh_callback' 
function which is not used very often, as the DH params are static for a 
single server.
If you read the openssl code , file ssl/s3_lib.c and look for 
SSL_CTRL_SET_TMP_ECDH then you'll find that the s3_lib.c code does treat 
the calls pretty much the same - this leads me to believe that the 
SSL_CTX_set_tmp_ecdh_callback function does NOT need to be used. To make 
sure I will post a question to the openssl developers on this.


The main reason for adding this function to the openvpn server instance 
is to ensure that enough 'ECDH entropy' , for lack of a better word, is 
available so that SHA2 message signing is possible.  Again, this is my 
understanding of things, but I'm about as blind as you are when it comes 
to understanding this part of the OpenSSL code base.



HTH,

JJK

Re: [Openvpn-devel] [PATCH] Signed-off-by: Jan Just Keijser <janj...@nikhef.nl>

[Jan Just Keijser]

Hi Adriaan,

Adriaan de Jong wrote:

Hi Janjust,

I've finally had the time to take a look at this patch with a colleague
who is more familiar with the subject at hand :).

Hope this helps. Please see my comments inline.

Adriaan

On 02/07/2012 04:13 PM, Jan Just Keijser wrote:
  

Added support for Elliptic curves (ECDSA) + SHA2 family signed
certificates.
---
 init.c |7 
 options.c  |   15 ++
 options.h  |6 
 ssl.c  |3 ++
 ssl_backend.h  |   10 ++
 ssl_openssl.c  |   84 
 ssl_polarssl.c |9 ++
 7 files changed, 134 insertions(+), 0 deletions(-)

diff --git a/init.c b/init.c
index 525f441..51b0d64 100644
--- a/init.c
+++ b/init.c
@@ -895,6 +895,9 @@ print_openssl_info (const struct options *options)
   if (options->show_ciphers || options->show_digests || options->show_engines
 #ifdef USE_SSL
   || options->show_tls_ciphers
+#ifdef USE_SSL_EC
+|| options->show_curves
+#endif
 #endif
 )
 {
@@ -907,6 +910,10 @@ print_openssl_info (const struct options *options)
 #ifdef USE_SSL
   if (options->show_tls_ciphers)
show_available_tls_ciphers ();
+#ifdef USE_SSL_EC
+  if (options->show_curves)
+show_available_curves ();
+#endif
 #endif
   return true;
 }
diff --git a/options.c b/options.c
index 6b8ae22..ce23dbc 100644
--- a/options.c
+++ b/options.c
@@ -836,6 +836,9 @@ init_options (struct options *o, const bool init_gc)
 #ifdef ENABLE_X509ALTUSERNAME
   o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
 #endif
+#ifdef USE_SSL_EC
+  o->curve_name = NULL;
+#endif
 #endif /* USE_SSL */
 #endif /* USE_CRYPTO */
 #ifdef ENABLE_PKCS11
@@ -6368,6 +6371,18 @@ add_option (struct options *options,
   VERIFY_PERMISSION (OPT_P_GENERAL);
   options->show_tls_ciphers = true;
 }
+#ifdef USE_SSL_EC
+  else if (streq (p[0], "show-curves"))
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->show_curves = true;
+}
+  else if (streq (p[0], "ecdh") && p[1])
+{
+  VERIFY_PERMISSION (OPT_P_CRYPTO);
+  options->curve_name= p[1];
+}
+#endif
   else if (streq (p[0], "tls-server"))
 {
   VERIFY_PERMISSION (OPT_P_GENERAL);
diff --git a/options.h b/options.h
index 831d4f6..81e0757 100644
--- a/options.h
+++ b/options.h
@@ -200,6 +200,9 @@ struct options
   bool show_engines;
 #ifdef USE_SSL
   bool show_tls_ciphers;
+#ifdef USE_SSL_EC
+  bool show_curves;
+#endif
 #endif
   bool genkey;
 #endif
@@ -533,6 +536,9 @@ struct options
   const char *priv_key_file;
   const char *pkcs12_file;
   const char *cipher_list;
+#ifdef USE_SSL_EC
+  const char *curve_name;
+#endif
   const char *tls_verify;
   const char *tls_export_cert;
   const char *tls_remote;
diff --git a/ssl.c b/ssl.c
index c26756e..54efe2f 100644
--- a/ssl.c
+++ b/ssl.c
@@ -308,6 +308,9 @@ init_ssl (const struct options *options, struct 
tls_root_ctx *new_ctx)
 {
   tls_ctx_server_new(new_ctx);
   tls_ctx_load_dh_params(new_ctx, options->dh_file, 
options->dh_file_inline);
+#ifdef USE_SSL_EC
+  tls_ctx_load_ecdh_params(new_ctx, options->curve_name);
+#endif
 }
   else /* if client */
 {
diff --git a/ssl_backend.h b/ssl_backend.h
index 243c9e3..ebf9f36 100644
--- a/ssl_backend.h
+++ b/ssl_backend.h
@@ -145,6 +145,16 @@ void tls_ctx_load_dh_params(struct tls_root_ctx *ctx, 
const char *dh_file
 );
 
 /**

+ * Load Elliptic Curve Parameters, and load them into the library-specific
+ * TLS context.
+ *
+ * @param ctx  TLS context to use
+ * @param curve_name   The name of the elliptic curve to load.
+ */
+void tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const char *curve_name
+);
+
+/**
  * Load PKCS #12 file for key, cert and (optionally) CA certs, and add to
  * library-specific TLS context.
  *
diff --git a/ssl_openssl.c b/ssl_openssl.c
index b95944c..912dd8f 100644
--- a/ssl_openssl.c
+++ b/ssl_openssl.c
@@ -50,6 +50,9 @@
 #include 
 #include 
 #include 
+#ifdef USE_SSL_EC
+#include 
+#endif
 
 /*

  * Allocate space in SSL objects in which to store a struct tls_session
@@ -238,6 +241,46 @@ tls_ctx_load_dh_params (struct tls_root_ctx *ctx, const 
char *dh_file
   DH_free (dh);
 }
 
+void

+tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, const char *curve_name
+)
+{
+#ifdef USE_SSL_EC
+  if (curve_name != NULL)
+  {
+int nid;
+EC_KEY   *ecdh  = NULL;
+  
+nid = OBJ_sn2nid(curve_name);
+  
+if (nid == 0)

+  msg(M_SSLERR, "unknown curve name (%s)", curve_name);
+else
+{
+  ecdh = EC_KEY_new_by_curve_name(nid);
+  if (ecdh == NULL)
+msg (M_SSLERR, "Unable to create curve (%s)", curve_name);
+  else
+  {
+const char *sname;
+  
+if (!SSL_CTX_set_tmp_ecdh(ctx->ctx, ecdh))

+  msg (M_SSLERR, "SS

Re: [Openvpn-devel] [DISCUSS] much more complicated gcc invocations now

[Jan Just Keijser]

Alon Bar-Lev wrote:

On Wed, Mar 28, 2012 at 11:12 AM, Jan Just Keijser <janj...@nikhef.nl> wrote:
  

Hi,


Gert Doering wrote:

Hi,

On Mon, Mar 26, 2012 at 07:51:01PM +0200, Alon Bar-Lev wrote:


The benefit is to divide the code into libraries and core which is
easier to maintain and reuse.


I'm not sure I understand what's so hard about "compile stuff, use
'ar' to pack into libopenvpn.a" that stuff needs more convolutions.

We're not building a shared library - which I agree is major pains unless
handled by libtool.  But static libraries are easy on about everything
(except Windows, can't speak about that).



actually, most of the problems I've seen with libtool have to deal with
shared libraries - I would NOT trust libtool to be able to build shared
libraries the way I want it to, esp when shared libs use other shared libs.
don't know if libtool 2.x solves the issues found in 1.5

Anyway, new automake does support silent rules, try the following[1]
patch and see if it makes you happier.


This is missing the point: I think what automake/autoconf is doing now
is much too complicated.  I *like* to see what it's doing, and hiding
complexity by just not showing it is a step into the wrong direction.



I fully agree with Gert here; if we can avoid libtool then I'd really like
to do so - it only adds an extra layer that (IMHO) is not needed; what was
wrong with the "old" method?



I tried to explain during this thread, do you have a specific question?
Anyway, we also found that it is not libtool that cause the long
command, but rather old gcc which probably did not handle the deletion
of dependency file correctly so automake/libtool compensate that.

  
ah OK, I normally don't care about dependencies because I build openvpn 
only once. why did automake decide to add these rules , whilst it didn't 
do so in the past?


and no, apart from the above I don't have a specific question, but I 
also don't like it when things are added to a (build) system that I 
don't see an immediate use for. For what it's worth, I'm very happy that 
the build system wasn't rewritten using 'cmake' - if that happens I'm 
forking the source code immediately :)


cheers,

JJK

Re: [Openvpn-devel] [DISCUSS] much more complicated gcc invocations now

[Jan Just Keijser]

Hi,

Gert Doering wrote:

Hi,

On Mon, Mar 26, 2012 at 07:51:01PM +0200, Alon Bar-Lev wrote:
  

The benefit is to divide the code into libraries and core which is
easier to maintain and reuse.



I'm not sure I understand what's so hard about "compile stuff, use
'ar' to pack into libopenvpn.a" that stuff needs more convolutions.

We're not building a shared library - which I agree is major pains unless
handled by libtool.  But static libraries are easy on about everything
(except Windows, can't speak about that).

  
actually, most of the problems I've seen with libtool have to deal with 
shared libraries - I would NOT trust libtool to be able to build shared 
libraries the way I want it to, esp when shared libs use other shared 
libs. don't know if libtool 2.x solves the issues found in 1.5

Anyway, new automake does support silent rules, try the following[1]
patch and see if it makes you happier.



This is missing the point: I think what automake/autoconf is doing now
is much too complicated.  I *like* to see what it's doing, and hiding
complexity by just not showing it is a step into the wrong direction.

  
I fully agree with Gert here; if we can avoid libtool then I'd really 
like to do so - it only adds an extra layer that (IMHO) is not needed; 
what was wrong with the "old" method?


JM2CW,

JJK

Re: [Openvpn-devel] two tls-auth questions

[Jan Just Keijser]

Mr Dash Four wrote:
Is there a way to generate a symmetric ta.key without using "openvpn 
--genkey --secret ta.key"?   
  
yep, just use any freeform key that has enough entropy. For example, 
this ta.key file is good enough


]# cat mykey
garble warble we need lots of entropy

So, in theory, I could use, for example, openssl to generate any key, 
encode it in pem format and use that as raw material (i.e. a sequence of 
printable characters), is that correct?


  

It is NOT possible to use the direction parameter for this


You mean the digit which goes after tls-auth - i.e. 0 or 1?

  

yep
Is it possible to embed the contents of the above file in my openvpn 
config file in a similar fashion as it is done with the  
tag for example? If so, what tag should I use for this?
  
  

in theory you co do this using

tls-auth [inline]





but this seems to work only for --genkey keys ; so it's either a 
freeform key or an inline , not both. I think you actually may have 
found a (minor) bug.

What is the meaning of "inline"? If I use  how do I 
specify the digit (0 or 1)?


  

the first statement
 tls-auth [inline]
tells openvpn to look for an inline version of the tls-auth file; this 
inline version is contained in the blob.

you can use
 tls-auth [inline] 0|1
to specify a direction ,  but as I said, that works only for 'openvpn 
--genkey' generated keys.


HTH,

JJK

Re: [Openvpn-devel] two tls-auth questions

[Jan Just Keijser]

Mr Dash Four wrote:
Is there a way to generate a symmetric ta.key without using "openvpn --genkey --secret ta.key"? 
  
yep, just use any freeform key that has enough entropy. For example, 
this ta.key file is good enough


]# cat mykey
garble warble we need lots of entropy

when openvpn starts you'll see something

Control Channel Authentication: using '/etc/openvpn/cookbook/mykey' as a 
free-form passphrase file


It is NOT possible to use the direction parameter for this


Is it possible to embed the contents of the above file in my openvpn config file in a 
similar fashion as it is done with the  tag for example? If so, what 
tag should I use for this?
  


in theory you co do this using

tls-auth [inline]





but this seems to work only for --genkey keys ; so it's either a 
freeform key or an inline , not both. I think you actually may have 
found a (minor) bug.


cheers,

JJK

Re: [Openvpn-devel] openvpn windows gui

[Jan Just Keijser]

Samuli Seppänen wrote:

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 



Right :). The primary benefit I see in having separate installers for
the OpenVPN-GUI, TAP-driver and easy-rsa is the possibility of
installing and upgrading each component separately more easily. It might
even be possible (=have not checked) to have the "OpenVPN Windows
installer bundle" fetch the latest dependency installers from predefined
URLs prior to installation and fallback to included ones if that fails.
Not sure if we want do that, but it's an option.

  
e, it would be nice to keep/have a "single click install" option - 
one of the nice features of the current OpenVPN installer is that you 
get everything in one download. Also, it will ensure that there is at 
least one set of components that works together.


JM2CW,

JJK

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Jan Just Keijser]

Hi Alon,

Alon Bar-Lev wrote:

Hello all,

There is an abnormality in the openvpn sources I want to resolve.

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.

There is also a note:
/* on WIN32, gettimeofday is faster than time(NULL) */

I am not sure about any of these, can you please try to run the
benchmark and report back the results?
It must be compiled using mingw, either at cygwin or at linux.

  

First:
$ i686-pc-mingw32-gcc -o timebench.exe timebench.c

In a virtual WinXP SP3 env on my 2.50 GHz Intel T9300:

c:\users\janjust>timebench.exe
time(): 18
gettimeofday(): 47
openvpn_gettimeofday(): 16



share and enjoy,

JJK

Re: [Openvpn-devel] [RFC] openssl minimum supported version

[Jan Just Keijser]

Alon Bar-Lev wrote:
> Hello,
>
> OpenVPN supports minimum openssl version of 0.9.6, while this version
> is unsupported by upstream and probably a security risk.
>
> What would be a suitable minimum version to support?
>
> I think that 0.9.8 is the one.
>   

EL5 and most SuSE distro's still use 0.9.8 , so I think that is probably
the right minimum version.

JJK

Re: [Openvpn-devel] Config question

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/02/12 16:56, Jan Just Keijser wrote:
  

Hi Paul,

Paul Bakker wrote:


On 8-2-2012 15:53, Jan Just Keijser wrote:
  

Hi Paul,


I can't find why the client would use 'eth0' for the 'tun0'
network - perhaps if you rerun with 'verb 7' and check for GDG
messages you will get a clue what openvpn is deciding... As a
workaround, try adding the second config route-gateway
10.100.0.10 redirect-gateway def1

this should tell openvpn that the default GW is 10.100.0.10.


= Wed Feb  8 16:14:22 2012
us=437713 GDG: route[1] 0.0.0.0/0.0.0.0/172.31.0.1 m=0 Wed Feb  8
16:14:22 2012 us=437752 GDG: route[2] 
10.100.0.0/255.255.255.0/0.0.0.0 m=0 Wed Feb  8 16:14:22 2012

us=437786 GDG: route[3] 169.254.0.0/255.255.0.0/0.0.0.0 m=1000 Wed
Feb  8 16:14:22 2012 us=437817 GDG: route[4] 
172.31.0.0/255.255.255.0/0.0.0.0 m=1 Wed Feb  8 16:14:22 2012
us=437849 GDG: route[5] 192.168.1.18/255.255.255.255/172.31.0.1 m=0 
Wed Feb  8 16:14:22 2012 us=437909 GDG: best=172.31.0.1[1] lm=0 Wed
Feb  8 16:14:22 2012 us=438044 GDG: route[1] 
0.0.0.0/0.0.0.0/172.31.0.1 m=0 Wed Feb  8 16:14:22 2012 us=438078

GDG: route[2] 10.100.0.0/255.255.255.0/0.0.0.0 m=0 Wed Feb  8
16:14:22 2012 us=438110 GDG: route[3] 
169.254.0.0/255.255.0.0/0.0.0.0 m=1000 Wed Feb  8 16:14:22 2012

us=438140 GDG: route[4] 172.31.0.0/255.255.255.0/0.0.0.0 m=1 Wed Feb
8 16:14:22 2012 us=438171 GDG: route[5] 
192.168.1.18/255.255.255.255/172.31.0.1 m=0 Wed Feb  8 16:14:22 2012

us=438216 GDG: best=172.31.0.1[1] lm=0 Wed Feb  8 16:14:22 2012
us=438254 ROUTE default_gateway=172.31.0.1 Wed Feb  8 16:14:22 2012
us=439676 TUN/TAP device tun1 opened Wed Feb  8 16:14:22 2012
us=439749 TUN/TAP TX queue length set to 100 Wed Feb  8 16:14:22
2012 us=439815 do_ifconfig, tt->ipv6=0, 
tt->did_ifconfig_ipv6_setup=0 Wed Feb  8 16:14:22 2012 us=439928

/sbin/ifconfig tun1 172.30.1.2 netmask 255.255.255.0 mtu 1500
broadcast 172.30.1.255 Wed Feb  8 16:14:22 2012 us=445345
/sbin/route add -net 10.100.0.10 netmask 255.255.255.255 gw
172.31.0.1 Wed Feb  8 16:14:22 2012 us=447721 /sbin/route add -net
0.0.0.0 netmask 128.0.0.0 gw 172.30.1.1 Wed Feb  8 16:14:22 2012
us=449931 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw
172.30.1.1 =

So indeed it seems to think the default gateway should be
172.31.0.1, which is correct.. While for adding a static route for
an ip (10.100.0.10) in this case, it is making the wrong choice. It
can deduce that route[2] would be used (which has interface tun0)
instead of the default route.. So this is a bug in OpenVPN handling
the redirect-gateway def1 command and adding the static route..

Adding the redirect gateway solves the problem, but is not viable in
my setup, so I'm going for a manual add at this point in time. If
this ever gets fixed in OpenVPN i'll move back to the
redirect-gateway.

  

this indeed looks like a (minor) bug: - the second layer openvpn
server is reachable via _A_ local network (10.100.0.0/24) - you've
requested 'redirect-gateway' - for safety reasons openvpn then adds a
direct route to the VPN server via the original gateway (10.100.0.10
via 172.31.0.1)

a workaround is to add 'redirect-gateway def1' to the inner layer VPN
as well.



Just to be sure we're not trying to fix something which might be fixed.
Which version of OpenVPN are you testing this on?  The later master
branch or a 2.2 release?

The reason for asking is that I know James Yonan did some additions to
the routing code lately, also solving some --redirect-gateway issues.
I'm far from convinced it's really related.  But it's close enough to
check out.

<http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8fc83a2d6cfa44032f38e13fc2f7dbc096f584d9>

  


I'll check the sources later today... what Paul is seeing is triggered 
by the fact that in this particular case you do NOT want the /32 route 
to the VPN server via the original default gateway. It might be 
worthwhile to add this as an option to OpenVPN. A scenario like this 
does not apply only to the double tunnel scenario, but also the following:


- client has 2 network interfaces, eth0 and eth1
- eth0 is connected to the default GW, e.g. 172.31.0.1
- eth1 is connected to another LAN, 10.100.0.0/24
- the OpenVPN server is on this other LAN, 10.100.0.10

if the client connects and wants to redirect the GW, an extra route is 
added 10.100.0.10/32 *via the original GW* : this route overrules the 
LAN route '10.100.0.0/24 via eth1'


Perhaps it's possible to determine via which interface openvpn is 
talking to the server - we could then decided whether to add the /32 
route or not. A user-override option would also be useful in this case.


cheers,

JJK

Re: [Openvpn-devel] [PATCH] Signed-off-by: Jan Just Keijser <janj...@nikhef.nl>

[Jan Just Keijser]

Alon Bar-Lev wrote:
> This is nice!
>
> Some questions:
>
> 1. Why not enable this automatically if openssl is sufficient version?
> There is no point in not using this if available.
>
some distro's (notably RedHat) disable EC support by default; so it's
not possible to check the OpenSSL version number. There is a '#define
OPENSSL_NO_EC'  that could be used, so the configure.ac script should
check for that. As other SSL implementations might use a different
#define to state that ECs are supported (or are NOT supported), I figure
the decision whether to support ECs should be made by the configure.ac
script, not by the openvpn code itself.
> 2. I would have liked to see this in negotiation as well, so server
> will use EC if supported by the client and fallback if not... This way
> migration path can take place.
>
The client won't even enter the negotiation phase without this patch: if
the client and server are configured to use ECDSA+SHA512 certs and the
'ecdh' parameters are NOT set on the server then the initial TLS
handshake fails.

cheers,

JJK



> On Tue, Feb 7, 2012 at 5:13 PM, Jan Just Keijser <janj...@nikhef.nl
> <mailto:janj...@nikhef.nl>> wrote:
>
> Added support for Elliptic curves (ECDSA) + SHA2 family signed
> certificates.
> ---
>  init.c |7 
>  options.c  |   15 ++
>  options.h  |6 
>  ssl.c  |3 ++
>  ssl_backend.h  |   10 ++
>  ssl_openssl.c  |   84
> 
>  ssl_polarssl.c |9 ++
>  7 files changed, 134 insertions(+), 0 deletions(-)
>
> diff --git a/init.c b/init.c
> index 525f441..51b0d64 100644
> --- a/init.c
> +++ b/init.c
> @@ -895,6 +895,9 @@ print_openssl_info (const struct options *options)
>   if (options->show_ciphers || options->show_digests ||
> options->show_engines
>  #ifdef USE_SSL
>   || options->show_tls_ciphers
> +#ifdef USE_SSL_EC
> +|| options->show_curves
> +#endif
>  #endif
> )
> {
> @@ -907,6 +910,10 @@ print_openssl_info (const struct options
> *options)
>  #ifdef USE_SSL
>   if (options->show_tls_ciphers)
>show_available_tls_ciphers ();
> +#ifdef USE_SSL_EC
> +  if (options->show_curves)
> +show_available_curves ();
> +#endif
>  #endif
>   return true;
> }
> diff --git a/options.c b/options.c
> index 6b8ae22..ce23dbc 100644
> --- a/options.c
> +++ b/options.c
> @@ -836,6 +836,9 @@ init_options (struct options *o, const bool
> init_gc)
>  #ifdef ENABLE_X509ALTUSERNAME
>   o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
>  #endif
> +#ifdef USE_SSL_EC
> +  o->curve_name = NULL;
> +#endif
>  #endif /* USE_SSL */
>  #endif /* USE_CRYPTO */
>  #ifdef ENABLE_PKCS11
> @@ -6368,6 +6371,18 @@ add_option (struct options *options,
>   VERIFY_PERMISSION (OPT_P_GENERAL);
>   options->show_tls_ciphers = true;
> }
> +#ifdef USE_SSL_EC
> +  else if (streq (p[0], "show-curves"))
> +{
> +  VERIFY_PERMISSION (OPT_P_GENERAL);
> +  options->show_curves = true;
> +}
> +  else if (streq (p[0], "ecdh") && p[1])
> +{
> +  VERIFY_PERMISSION (OPT_P_CRYPTO);
> +  options->curve_name= p[1];
> +}
> +#endif
>   else if (streq (p[0], "tls-server"))
> {
>   VERIFY_PERMISSION (OPT_P_GENERAL);
> diff --git a/options.h b/options.h
> index 831d4f6..81e0757 100644
> --- a/options.h
> +++ b/options.h
> @@ -200,6 +200,9 @@ struct options
>   bool show_engines;
>  #ifdef USE_SSL
>   bool show_tls_ciphers;
> +#ifdef USE_SSL_EC
> +  bool show_curves;
> +#endif
>  #endif
>   bool genkey;
>  #endif
> @@ -533,6 +536,9 @@ struct options
>   const char *priv_key_file;
>   const char *pkcs12_file;
>   const char *cipher_list;
> +#ifdef USE_SSL_EC
> +  const char *curve_name;
> +#endif
>   const char *tls_verify;
>   const char *tls_export_cert;
>   const char *tls_remote;
> diff --git a/ssl.c b/ssl.c
> index c26756e..54efe2f 100644
> --- a/ssl.c
> +++ b/ssl.c
> @@ -308,6 +308,9 @@ init_ssl (const struct options *options,
> struct tls_root_ctx *new_ctx)
> {
>   tls_ctx_server_new(new_ctx);
>   tls_ctx_load_dh_params(new_ctx, options-

Re: [Openvpn-devel] [PATCH] Made some options connection-entry specific

[Jan Just Keijser]

sorry about the noise, folks; this was my second git patch attempt :)

cheers,

JJK


Jan Just Keijser wrote:
> Made some options connection-entry specific:
>  fragment  
>  mssfix
>  tun-mtu
>  tun-mtu-extra
>  link-mtu  
>  mtu_discover_type
>  explicit-exit-notification
> in order to support stuff like
> 
>   remote host
>   proto udp
>   fragment  
>   explicit-exit-notification 3
> 
>  
>   remote host 
>   proto tcp
> 
>
> Signed-off-by: Jan Just Keijser <janj...@nikhef.nl>
> ---
>  forward.c |2 +-
>  init.c|   38 ++-
>  occ.c |2 +-
>  options.c |  125 
> +++--
>  options.h |   36 +-
>  sig.c |6 +-
>  6 files changed, 107 insertions(+), 102 deletions(-)
>
> diff --git a/forward.c b/forward.c
> index dfef4ef..96c6b9a 100644
> --- a/forward.c
> +++ b/forward.c
> @@ -1005,7 +1005,7 @@ process_incoming_tun (struct context *c)
>  void
>  process_ipv4_header (struct context *c, unsigned int flags, struct buffer 
> *buf)
>  {
> -  if (!c->options.mssfix)
> +  if (!c->options.ce.mssfix)
>  flags &= ~PIPV4_MSSFIX;
>  #if PASSTOS_CAPABILITY
>if (!c->options.passtos)
> diff --git a/init.c b/init.c
> index 51b0d64..8f42120 100644
> --- a/init.c
> +++ b/init.c
> @@ -1786,10 +1786,10 @@ do_deferred_options (struct context *c, const 
> unsigned int found)
>  #ifdef ENABLE_OCC
>if (found & OPT_P_EXPLICIT_NOTIFY)
>  {
> -  if (!proto_is_udp(c->options.ce.proto) && 
> c->options.explicit_exit_notification)
> +  if (!proto_is_udp(c->options.ce.proto) && 
> c->options.ce.explicit_exit_notification)
>   {
> msg (D_PUSH, "OPTIONS IMPORT: --explicit-exit-notify can only be used 
> with --proto udp");
> -   c->options.explicit_exit_notification = 0;
> +   c->options.ce.explicit_exit_notification = 0;
>   }
>else
>   msg (D_PUSH, "OPTIONS IMPORT: explicit notify parm(s) modified");
> @@ -1962,10 +1962,10 @@ frame_finalize_options (struct context *c, const 
> struct options *o)
>  }
>
>frame_finalize (>c2.frame,
> -   o->link_mtu_defined,
> -   o->link_mtu,
> -   o->tun_mtu_defined,
> -   o->tun_mtu);
> +   o->ce.link_mtu_defined,
> +   o->ce.link_mtu,
> +   o->ce.tun_mtu_defined,
> +   o->ce.tun_mtu);
>  }
>  
>  /*
> @@ -2411,8 +2411,8 @@ do_init_frame (struct context *c)
>/*
> * Adjust frame size based on the --tun-mtu-extra parameter.
> */
> -  if (c->options.tun_mtu_extra_defined)
> -tun_adjust_frame_parameters (>c2.frame, c->options.tun_mtu_extra);
> +  if (c->options.ce.tun_mtu_extra_defined)
> +tun_adjust_frame_parameters (>c2.frame, c->options.ce.tun_mtu_extra);
>  
>/*
> * Adjust frame size based on link socket parameters.
> @@ -2441,13 +2441,13 @@ do_init_frame (struct context *c)
>/*
> * MTU advisories
> */
> -  if (c->options.fragment && c->options.mtu_test)
> +  if (c->options.ce.fragment && c->options.mtu_test)
>  msg (M_WARN,
>"WARNING: using --fragment and --mtu-test together may produce an 
> inaccurate MTU test result");
>  #endif
>  
>  #ifdef ENABLE_FRAGMENT
> -  if ((c->options.mssfix || c->options.fragment)
> +  if ((c->options.ce.mssfix || c->options.ce.fragment)
>&& TUN_MTU_SIZE (>c2.frame_fragment) != ETHERNET_MTU)
>  msg (M_WARN,
>"WARNING: normally if you use --mssfix and/or --fragment, you should 
> also set --tun-mtu %d (currently it is %d)",
> @@ -2619,9 +2619,9 @@ do_init_buffers (struct context *c)
>  static void
>  do_init_fragment (struct context *c)
>  {
> -  ASSERT (c->options.fragment);
> +  ASSERT (c->options.ce.fragment);
>frame_set_mtu_dynamic (>c2.frame_fragment,
> -  c->options.fragment, SET_MTU_UPPER_BOUND);
> +  c->options.ce.fragment, SET_MTU_UPPER_BOUND);
>fragment_frame_init (c->c2.fragment, >c2.frame_fragment);
>  }
>  #endif
> @@ -2632,10 +2632,10 @@ do_init_fragment (struct context *c)
>  static void
>  do_init_mssfix (struct context *c)
>  {
> -  if (c->options.mssfix)
> +  if (c->options.ce.mssfix)
>  {
>frame_set_mtu_dynamic (>c2.frame,
> -  c->options.mssfix, SET_MTU_UPPER_BOUND);
> +  c->options.ce.ms

[Openvpn-devel] [PATCH] Made some options connection-entry specific

[Jan Just Keijser]

Made some options connection-entry specific:
 fragment  
 mssfix
 tun-mtu
 tun-mtu-extra
 link-mtu  
 mtu_discover_type
 explicit-exit-notification
in order to support stuff like

  remote host
  proto udp
  fragment  
  explicit-exit-notification 3

 
  remote host 
  proto tcp


Signed-off-by: Jan Just Keijser <janj...@nikhef.nl>
---
 forward.c |2 +-
 init.c|   38 ++-
 occ.c |2 +-
 options.c |  125 +++--
 options.h |   36 +-
 sig.c |6 +-
 6 files changed, 107 insertions(+), 102 deletions(-)

diff --git a/forward.c b/forward.c
index dfef4ef..96c6b9a 100644
--- a/forward.c
+++ b/forward.c
@@ -1005,7 +1005,7 @@ process_incoming_tun (struct context *c)
 void
 process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf)
 {
-  if (!c->options.mssfix)
+  if (!c->options.ce.mssfix)
 flags &= ~PIPV4_MSSFIX;
 #if PASSTOS_CAPABILITY
   if (!c->options.passtos)
diff --git a/init.c b/init.c
index 51b0d64..8f42120 100644
--- a/init.c
+++ b/init.c
@@ -1786,10 +1786,10 @@ do_deferred_options (struct context *c, const unsigned 
int found)
 #ifdef ENABLE_OCC
   if (found & OPT_P_EXPLICIT_NOTIFY)
 {
-  if (!proto_is_udp(c->options.ce.proto) && 
c->options.explicit_exit_notification)
+  if (!proto_is_udp(c->options.ce.proto) && 
c->options.ce.explicit_exit_notification)
{
  msg (D_PUSH, "OPTIONS IMPORT: --explicit-exit-notify can only be used 
with --proto udp");
- c->options.explicit_exit_notification = 0;
+ c->options.ce.explicit_exit_notification = 0;
}
   else
msg (D_PUSH, "OPTIONS IMPORT: explicit notify parm(s) modified");
@@ -1962,10 +1962,10 @@ frame_finalize_options (struct context *c, const struct 
options *o)
 }

   frame_finalize (>c2.frame,
- o->link_mtu_defined,
- o->link_mtu,
- o->tun_mtu_defined,
- o->tun_mtu);
+ o->ce.link_mtu_defined,
+ o->ce.link_mtu,
+ o->ce.tun_mtu_defined,
+ o->ce.tun_mtu);
 }

 /*
@@ -2411,8 +2411,8 @@ do_init_frame (struct context *c)
   /*
* Adjust frame size based on the --tun-mtu-extra parameter.
*/
-  if (c->options.tun_mtu_extra_defined)
-tun_adjust_frame_parameters (>c2.frame, c->options.tun_mtu_extra);
+  if (c->options.ce.tun_mtu_extra_defined)
+tun_adjust_frame_parameters (>c2.frame, c->options.ce.tun_mtu_extra);

   /*
* Adjust frame size based on link socket parameters.
@@ -2441,13 +2441,13 @@ do_init_frame (struct context *c)
   /*
* MTU advisories
*/
-  if (c->options.fragment && c->options.mtu_test)
+  if (c->options.ce.fragment && c->options.mtu_test)
 msg (M_WARN,
 "WARNING: using --fragment and --mtu-test together may produce an 
inaccurate MTU test result");
 #endif

 #ifdef ENABLE_FRAGMENT
-  if ((c->options.mssfix || c->options.fragment)
+  if ((c->options.ce.mssfix || c->options.ce.fragment)
   && TUN_MTU_SIZE (>c2.frame_fragment) != ETHERNET_MTU)
 msg (M_WARN,
 "WARNING: normally if you use --mssfix and/or --fragment, you should 
also set --tun-mtu %d (currently it is %d)",
@@ -2619,9 +2619,9 @@ do_init_buffers (struct context *c)
 static void
 do_init_fragment (struct context *c)
 {
-  ASSERT (c->options.fragment);
+  ASSERT (c->options.ce.fragment);
   frame_set_mtu_dynamic (>c2.frame_fragment,
-c->options.fragment, SET_MTU_UPPER_BOUND);
+c->options.ce.fragment, SET_MTU_UPPER_BOUND);
   fragment_frame_init (c->c2.fragment, >c2.frame_fragment);
 }
 #endif
@@ -2632,10 +2632,10 @@ do_init_fragment (struct context *c)
 static void
 do_init_mssfix (struct context *c)
 {
-  if (c->options.mssfix)
+  if (c->options.ce.mssfix)
 {
   frame_set_mtu_dynamic (>c2.frame,
-c->options.mssfix, SET_MTU_UPPER_BOUND);
+c->options.ce.mssfix, SET_MTU_UPPER_BOUND);
 }
 }

@@ -2691,7 +2691,7 @@ do_init_socket_1 (struct context *c, const int mode)
   c->options.ce.connect_retry_seconds,
   c->options.ce.connect_timeout,
   c->options.ce.connect_retry_max,
-  c->options.mtu_discover_type,
+  c->options.ce.mtu_discover_type,
   c->options.rcvbuf,
   c->options.sndbuf,
   c->options.mark,
@@ -3406,7 +3408,7 @@ init_instance (struct context *c, const struct env_set 
*env, const unsigned int

 #ifdef ENABLE_FRAGMENT
   /* initialize internal fragmentation ob

[Openvpn-devel] Elliptic curve patch

[Jan Just Keijser]

hi all,

attached is my elliptic curve patch, to add support for using ECDSA 
curves in combination with SHA256/SHA512 signed certificates; currently 
you can do either ECDSA with SHA1-signed certificates, or no ECDSA but 
SHA256/SHA512 signed certs . The error message seen is

 SSL3_CLIENT_GET_HELLO:no shared cipher
This patch overcomes this.

With the patch you should see for the control channel:
  Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-SHA

Two new parameters are added to OpenVPN
 --show-curves
to list the available elliptic curves, and
 --ecdh 
to select a curve name.

TODO: this code is currently only enabled using '#ifdef USE_SSL_EC' ; 
I've manually added a line

 #define USE_SSL_EC 1
to config.h after a './configure' step. I'm not familiar enough with 
autoconf and friends to turn it into an .ac script:
- you need OpenSSL 1.0+ WITH EC support enabled (RedHat , for example, 
disables it by default)

- PolarSSL does not support it (yet).

It would be great if somebody can help me sort the autoconf thing out.

The patch was tested on Fedora 14 64bit using a git cloned repo , but 
without the latest buffer.c patch.



cheers,

JJK

diff -Naur openvpn.git/init.c openvpn.git-ecdsa/init.c
--- openvpn.git/init.c  2012-02-06 11:21:16.393339212 +0100
+++ openvpn.git-ecdsa/init.c2012-02-06 10:53:25.936655131 +0100
@@ -895,6 +895,9 @@
   if (options->show_ciphers || options->show_digests || options->show_engines
 #ifdef USE_SSL
   || options->show_tls_ciphers
+#ifdef USE_SSL_EC
+|| options->show_curves
+#endif
 #endif
 )
 {
@@ -907,6 +910,10 @@
 #ifdef USE_SSL
   if (options->show_tls_ciphers)
show_available_tls_ciphers ();
+#ifdef USE_SSL_EC
+  if (options->show_curves)
+show_available_curves ();
+#endif
 #endif
   return true;
 }
diff -Naur openvpn.git/options.c openvpn.git-ecdsa/options.c
--- openvpn.git/options.c   2012-02-06 11:21:16.401340746 +0100
+++ openvpn.git-ecdsa/options.c 2012-02-06 10:51:02.289625514 +0100
@@ -836,6 +836,9 @@
 #ifdef ENABLE_X509ALTUSERNAME
   o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
 #endif
+#ifdef USE_SSL_EC
+  o->curve_name = NULL;
+#endif
 #endif /* USE_SSL */
 #endif /* USE_CRYPTO */
 #ifdef ENABLE_PKCS11
@@ -6368,6 +6371,18 @@
   VERIFY_PERMISSION (OPT_P_GENERAL);
   options->show_tls_ciphers = true;
 }
+#ifdef USE_SSL_EC
+  else if (streq (p[0], "show-curves"))
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->show_curves = true;
+}
+  else if (streq (p[0], "ecdh") && p[1])
+{
+  VERIFY_PERMISSION (OPT_P_CRYPTO);
+  options->curve_name= p[1];
+}
+#endif
   else if (streq (p[0], "tls-server"))
 {
   VERIFY_PERMISSION (OPT_P_GENERAL);
diff -Naur openvpn.git/options.h openvpn.git-ecdsa/options.h
--- openvpn.git/options.h   2012-02-06 11:21:16.401340746 +0100
+++ openvpn.git-ecdsa/options.h 2012-02-06 10:51:11.030222937 +0100
@@ -200,6 +200,9 @@
   bool show_engines;
 #ifdef USE_SSL
   bool show_tls_ciphers;
+#ifdef USE_SSL_EC
+  bool show_curves;
+#endif
 #endif
   bool genkey;
 #endif
@@ -533,6 +536,9 @@
   const char *priv_key_file;
   const char *pkcs12_file;
   const char *cipher_list;
+#ifdef USE_SSL_EC
+  const char *curve_name;
+#endif
   const char *tls_verify;
   const char *tls_export_cert;
   const char *tls_remote;
diff -Naur openvpn.git/ssl.c openvpn.git-ecdsa/ssl.c
--- openvpn.git/ssl.c   2012-02-06 11:21:16.410342470 +0100
+++ openvpn.git-ecdsa/ssl.c 2012-02-06 10:51:20.431949238 +0100
@@ -308,6 +308,9 @@
 {
   tls_ctx_server_new(new_ctx);
   tls_ctx_load_dh_params(new_ctx, options->dh_file, 
options->dh_file_inline);
+#ifdef USE_SSL_EC
+  tls_ctx_load_ecdh_params(new_ctx, options->curve_name);
+#endif
 }
   else /* if client */
 {
diff -Naur openvpn.git/ssl_backend.h openvpn.git-ecdsa/ssl_backend.h
--- openvpn.git/ssl_backend.h   2012-02-06 11:21:16.410342470 +0100
+++ openvpn.git-ecdsa/ssl_backend.h 2012-02-06 10:39:19.840445199 +0100
@@ -145,6 +145,16 @@
 );

 /**
+ * Load Elliptic Curve Parameters, and load them into the library-specific
+ * TLS context.
+ *
+ * @param ctx  TLS context to use
+ * @param curve_name   The name of the elliptic curve to load.
+ */
+void tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const char *curve_name
+);
+
+/**
  * Load PKCS #12 file for key, cert and (optionally) CA certs, and add to
  * library-specific TLS context.
  *
diff -Naur openvpn.git/ssl_openssl.c openvpn.git-ecdsa/ssl_openssl.c
--- openvpn.git/ssl_openssl.c   2012-02-06 11:21:16.410342470 +0100
+++ openvpn.git-ecdsa/ssl_openssl.c 2012-02-06 10:51:39.447464796 +0100
@@ -50,6 +50,9 @@
 #include 
 #include 
 #include 
+#ifdef USE_SSL_EC
+#include 
+#endif

 /*
  * Allocate space in SSL objects in which to store a struct tls_session
@@ -238,6 +241,46 @@
   DH_free (dh);
 }

+void
+tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, 

Re: [Openvpn-devel] Summary of the IRC meeting (19th Jan 2012)

[Jan Just Keijser]

Hi all,


Samuli Seppänen wrote:

Hi,

Here's the summary of the previous IRC meeting / sprint.

  
I've been offline for a while but am slowly getting back online ; as for 
the chatlog attachment: Gert did ask me about bug #97 (dhcpnak storm) ; 
I have not been able to reproduce the DHCP NAK storm with the openvpn 
2.2.2. tap-win32 adapter , so I'm inclined to consider this bug solved. 
I hope someone else can also verify this (i.e. install 2.2.1, produce 
the DHCP NAK storm, then upgrade to 2.2.2. etc).


cheers,

JJK

PS I'm intending to go to FOSDEM on sunday; which room will you guys 
meet in?




---

COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
Date: Thursday 19th Jan 2012
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting will be announced in advance, but will probably be on the same
weekday and at the same time. Your local meeting time is easy to check
from services such as



or with

$ date -u


SUMMARY

cron2, dazo, ecrist and mattock participated in this meeting.

--

Discussed Bruessels/FOSDEM hackfests. Agreed that arranging them on
Sat-Sun (4.-5. Feb) makes most sense for all. The goal is to complete
three related mini-projects:

1) The "squash/close as many bugs as possible"
2) Complete all tasks holding back 2.3 alpha and make the release
3) Review d12fk's Windows patches that got stuck to the patch queue

All of these should be doable within the given timeframe.

--

Discussed vBulletin's OpenVPN theme. According to raidz, the theme
should be ready next Monday.

---

Full chatlog as an attachment
  

Re: [Openvpn-devel] OpenVPN 2.2.2 released

[Jan Just Keijser]

Hi mattock,

Samuli Seppänen wrote:

The OpenVPN community project team is proud to release OpenVPN 2.2.2. It
can be downloaded from here:



Changes include:

- Pkcs11 support built into the Windows version
- Fixed a bug in the Windows TAP-driver

  

this tap-driver bug seems to fix the DHCP NAK storm on Win7 !
I ran OpenVPN 2.2.0 with the tap-win32 9.8 driver, and checked that I 
could trigger the DHCP NAK storm quite easily (just reconnect a couple 
of times)
I then upgraded to 2.2.2 + tap-win32 9.9 and since then I have not seen 
the DHCP NAK storm (in wireshark).


http://www.youtube.com/my_speed performance also seems improved:
- raw link : 14000+ kbps
- vpn link: between 3000 and 1 kbps

(I remember it was worse before).

Excellent findings by Gert - I can't believe nobody caught the missing 
'break' statement sooner; I went through the entire tapdrvr.c source 
code to see if I could find any other missing 'breaks' but it seems OK.


cheers,

JJK


Full list of changes is attached to this email and is also available here:



For generic help use these support channels:

- Official documentation:

- Wiki: 
- Forums: 
- User mailing list: 
- User IRC channel: #openvpn at irc.freenode.net

Please report bugs and ask development questions here:

- Bug tracker and Wiki: 
- Developer mailing list: 
- Developer IRC channel: #openvpn-devel at irc.freenode.net

Note that we've recently switched to using a different Git repository:

  

Re: [Openvpn-devel] Topics for today's meeting

[Jan Just Keijser]

Alon Bar-Lev wrote:
> I hate CMake, it is way too complex, these guys re-invented the wheel
> with no decent reuse of any methodology / language that existed
> before.
>   
I agree with Alon here :

+1 autoconf
-9 CMake

esp troubleshooting a non-working CMake setup is a nightmare.

JJK
> If we take SCons as another example, it took python and used it to do
> build... So if you are python developer most probably you know how to
> SCons.
> Also, look the huge backlog of bugs of CMake, it is amazing!
>
> Common to both CMake and SCons is the ability to work with Microsoft
> toolchain to produce binaries. This is a great advantage over the
> autotools. However, these tools are inferior when it comes to
> autotools (provided you know what you are doing) in *NIX, embedded and
> cross compile.
>
> To build using CMake or SCCons you need these tools on *TARGET*
> machine, these tools has LONG LIST of dependencies. To build using
> autotools you need POSIX utils (sh, sed, ls, rm, ...) and POSIX make
> and that's it!
>
> I don't mind if for Windows CMake/SCons will be maintain in addition,
> keep autotools usage for windows cross compile and *NIX build using
> autotools.
>
> Alon.
>
> On Thu, Nov 24, 2011 at 11:25 AM, Adriaan de Jong  wrote:
>   
>> Just to put in my 2cents on the build options: there is a tool that supports 
>> all of those environments (gmake, cygwin, mingw, nmake, visual studio, 
>> eclipse, ), and that's CMake. It's widely used, and has a pretty good 
>> track record. It can also support automated test environments and packaging.
>>
>> It has one major disadvantage: the current build system would need to be 
>> converted from an autoconf-based to a new CMake-based system, together with 
>> all of the knowledge contained within it. Further, there is less knowledge 
>> of CMake than autoconf within the OpenVPN community.
>>
>> Disclaimer: I'm not trying to start a holy war here, I know every system has 
>> its own advantages and drawbacks. I just want to get the option on the table 
>> :). I've had some positive experience with CMake, through PolarSSL and some 
>> projects at work. I'll try to make it to the meeting this evening for the 
>> discussion.
>>
>> Kind Regards,
>>
>> Adriaan
>>
>> 
>>> -Original Message-
>>> From: Samuli Seppänen [mailto:sam...@openvpn.net]
>>> Sent: donderdag 24 november 2011 9:48
>>> To: openvpn-devel@lists.sourceforge.net
>>> Subject: [Openvpn-devel] Topics for today's meeting
>>>
>>> Hi,
>>>
>>> We're having an IRC meeting today, starting at 18:00 UTC on #openvpn-
>>> de...@irc.freenode.net. Current topic list is here:
>>>
>>> 
>>>
>>> If you have any other things you'd like to bring up, respond to this
>>> mail, send me mail privately or add them to the list yourself.
>>>
>>> In case you can't attend the meeting, please feel free to make comments
>>> on the topics by responding to this email or to the summary email sent
>>> after the meeting.
>>>
>>> NOTE: It's required to use a registered Freenode IRC nickname to join
>>> #openvpn-devel - look here for details:
>>>
>>>   

Re: [Openvpn-devel] [PATCH 3/3] Changed default algorithm for PolarSSL to AES-128, as BF is not supported

[Jan Just Keijser]

I'd NACK this patch : the default behaviour of OpenVPN should be
independent of the SSL implementation.

JJK

Adriaan de Jong wrote:
> Signed-off-by: Adriaan de Jong 
> ---
>  options.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/options.c b/options.c
> index 39e7a57..d917072 100644
> --- a/options.c
> +++ b/options.c
> @@ -810,7 +810,12 @@ init_options (struct options *o, const bool init_gc)
>o->server_poll_timeout = 0;
>  #endif
>  #ifdef USE_CRYPTO
> +#ifdef USE_OPENSSL
>o->ciphername = "BF-CBC";
> +#endif
> +#ifdef USE_POLARSSL
> +  o->ciphername = "AES-128-CBC";
> +#endif
>o->ciphername_defined = true;
>o->authname = "SHA1";
>o->authname_defined = true;
>   

Re: [Openvpn-devel] Fatal Error on XP

[Jan Just Keijser]

Hi,

the log line
"VERIFY ERROR: depth=1, error=self signed certificate in certificate 
chain: 
/C=US/ST=NewYork/L=minerals/O=certify.com/OU=R_D/CN=certify/emailAddress=cert...@server1.com"


shows that the client does not trust the server certificate, or the CA 
certificate that signed the server certificate; verify that you have 
loaded the right 'ca.crt' file in the client. You can print information 
about certificates using

 openssl x509 -text -noout -in ca.crt
or
 openssl x509 -subject -issuer -noout -in ca.crt

HTH,

JJK

Richard Francis wrote:


Hi, anyone can help? Greatly appreciative of your expertise.

 


Fri Oct 07 14:41:38 2011 us=958000 Current Parameter Settings:

Fri Oct 07 14:41:38 2011 us=958000 config = 'VPN.ovpn'

Fri Oct 07 14:41:38 2011 us=958000 mode = 0

Fri Oct 07 14:41:38 2011 us=958000 show_ciphers = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 show_digests = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 show_engines = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 genkey = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 key_pass_file = '[UNDEF]'

Fri Oct 07 14:41:38 2011 us=958000 show_tls_ciphers = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 Connection profiles [default]:

Fri Oct 07 14:41:38 2011 us=958000 proto = tcp-client

Fri Oct 07 14:41:38 2011 us=958000 local = '[UNDEF]'

Fri Oct 07 14:41:38 2011 us=958000 local_port = 0

Fri Oct 07 14:41:38 2011 us=958000 remote = 'vpn.certify.com'

Fri Oct 07 14:41:38 2011 us=958000 remote_port = 443

Fri Oct 07 14:41:38 2011 us=958000 remote_float = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 bind_defined = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 bind_local = DISABLED

Fri Oct 07 14:41:38 2011 us=958000 connect_retry_seconds = 5

Fri Oct 07 14:41:38 2011 us=958000 connect_timeout = 10

Fri Oct 07 14:41:38 2011 us=958000 NOTE: --mute triggered...

Fri Oct 07 14:41:38 2011 us=958000 252 variation(s) on previous 20 
message(s) suppressed by --mute


Fri Oct 07 14:41:38 2011 us=958000 OpenVPN 2.1.3 i686-pc-mingw32 [SSL] 
[LZO2] [PKCS11] built on Aug 20 2010


Fri Oct 07 14:41:38 2011 us=978000 WARNING: No server certificate 
verification method has been enabled. See 
http://openvpn.net/howto.html#mitm for more info.


Fri Oct 07 14:41:38 2011 us=978000 NOTE: OpenVPN 2.1 requires 
'--script-security 2' or higher to call user-defined scripts or 
executables


Fri Oct 07 14:41:39 2011 us=508000 LZO compression initialized

Fri Oct 07 14:41:39 2011 us=528000 Control Channel MTU parms [ L:1576 
D:140 EF:40 EB:0 ET:0 EL:0 ]


Fri Oct 07 14:41:39 2011 us=538000 Socket Buffers: R=[8192->8192] 
S=[8192->8192]


Fri Oct 07 14:41:39 2011 us=819000 Data Channel MTU parms [ L:1576 
D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]


Fri Oct 07 14:41:39 2011 us=819000 Local Options String: 'V4,dev-type 
tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher 
BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'


Fri Oct 07 14:41:39 2011 us=819000 Expected Remote Options String: 
'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto 
TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 
2,tls-server'


Fri Oct 07 14:41:39 2011 us=819000 Local Options hash (VER=V4): '31fdf004'

Fri Oct 07 14:41:39 2011 us=819000 Expected Remote Options hash 
(VER=V4): '3e6d1056'


Fri Oct 07 14:41:39 2011 us=819000 Attempting to establish TCP 
connection with 1.1.1.1:443


Fri Oct 07 14:41:39 2011 us=909000 TCP connection established with 
1.1.1.1:443


Fri Oct 07 14:41:39 2011 us=909000 TCPv4_CLIENT link local: [undef]

Fri Oct 07 14:41:39 2011 us=909000 TCPv4_CLIENT link remote: 1.1.1.1:443

Fri Oct 07 14:41:39 2011 us=979000 TLS: Initial packet from 
1.1.1.1:443, sid=48fe7a7z 189d19pc


Fri Oct 07 14:41:41 2011 us=401000 VERIFY ERROR: depth=1, error=self 
signed certificate in certificate chain: 
/C=US/ST=NewYork/L=minerals/O=certify.com/OU=R_D/CN=certify/emailAddress=cert...@server1.com


Fri Oct 07 14:41:41 2011 us=401000 TLS_ERROR: BIO read 
tls_read_plaintext error: error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed


Fri Oct 07 14:41:41 2011 us=401000 TLS Error: TLS object -> incoming 
plaintext read error


Fri Oct 07 14:41:41 2011 us=401000 TLS Error: TLS handshake failed

Fri Oct 07 14:41:41 2011 us=401000 Fatal TLS error 
(check_tls_errors_co), restarting


Fri Oct 07 14:41:41 2011 us=401000 TCP/UDP: Closing socket

Fri Oct 07 14:41:41 2011 us=411000 SIGUSR1[soft,tls-error] received, 
process restarting


Fri Oct 07 14:41:41 2011 us=411000 Restart pause, 5 second(s)

 

 


Richard Francis

http://www.pelicancomputers.us

1.847.256.0639

 




--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and 

Re: [Openvpn-devel] Summary of the IRC meeting (7th July 2011)

[Jan Just Keijser]

dazo wrote:


dazo 12:16:09
we need to catch up on janjust on that one ... I think he dropped the ball due 
to holiday season or so ... I think it's been quite quiet from him lately (esp. 
here on IRC) 


yep - I'm on holidays right now and I have not had the time to look into 
this further ;  I still want to build my own tap-win32 driver to see if 
I can get some more info on what is causing the DHCPNAK bomb. I hope to 
be able to get to that in august.


cheers,

JJK


Samuli Seppänen wrote:

Hi,

Here's the summary of the previous community meeting.

---

COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
Date: Thursday, 7th July 2011
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting will be announced in advance, but will be on the same
weekday and at the same time. Your local meeting time is easy to check
from services such as



or with

$ date -u


SUMMARY

andj, dazo, ecrist, jamesyonan and mattock were present in this
meeting.

--

Discussed issues of building OpenVPN from the "tmp/winbuildfix" branch
in openvpn-testing.git. Noticed that there was a simple typo that
triggered the only remaining error in win32.h. Mattock will fix this and
provide a patch.

--

Discussed the "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch:



Decided to take this up with jjo and cron2, as they're responsible for
the IPv6 code in OpenVPN.

--

Discussed "Bug: extended x509-username-field broken in git" patch:



Andj had provided a fix to the same issue earlier than Markus, so it was
decided to implement andj's version.

--

Discussed andj's doxygen patchset:



Jamesyonan gave this patchset his ACK, provided that it does not change
any functionality. Dazo will verify that and then merge the patches to Git.

--

Discussed the possibility of arranging "sprints" where large patchsets
(such as andj's) would be reviewed, fixed and ACKed in one go. The
patches would still be first published on the mailinglist and would not
be merged into Git until a summary of each sprint session was sent to
the mailinglist for review. This would allow input even from those who
were unable to attend the actual sprint.

Smaller patchsets and single patches would still be handled through the
mailinglist. If they stayed there for too long (1-2 weeks) without any
comments, they could be handled in a sprint, too. Also, whenever
possible, a poll (e.g. Doodle) would be arranged prior to sprint, so
that as many developers as possible could attend.

The Gerrit tool was mentioned, too, as a tool we could potentially use
to ease the patch review process:



--

Decided to arrange the next meeting next Thursday, but 1 hour earlier
that usual (17:00 UTC). The meeting would also include a sprint.

---

Full chatlog as an attachment

  



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.

http://p.sf.net/sfu/splunk-d2d-c2


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add new openssl.cnf to easy-rsa/Windows

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/06/11 11:36, Jan Just Keijser wrote:
  

NACK on this patch - the openssl.cnf file should be (almost) the same as
the one used in easy-rsa/2.0
that way the certificates are generated in the same manner (*with*
EKU=ServerAuth)




Okay, I'll revert commit 663860ad04dd4190fddbee63e724d3fdceafd937 (master)
and 6989cbde616a00380acf3a390959987765a5325b (release/2.2) immediately.

Samuli, can you please look closer into this?  I did a more careful diff
from 2.0/openssl.cnf and Windows/openssl.cnf ... and it seems quite
different.  Can we please unite them?

JJK: Do you know which differences are needed between Windows and non-Windows?

  
I just checked that the openssl.cnf file shipped with the windows 
version of  openvpn 2.1.4 is identical to the easy-rsa/2.0 version - is 
there any reason not to do the same for openvpn 2.2?


cheers,

JJK

Re: [Openvpn-devel] [PATCH] Add new openssl.cnf to easy-rsa/Windows

[Jan Just Keijser]

NACK on this patch - the openssl.cnf file should be (almost) the same as 
the one used in easy-rsa/2.0
that way the certificates are generated in the same manner (*with* 
EKU=ServerAuth)


JJK

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/06/11 09:49, sam...@openvpn.net wrote:
  

From: Samuli Seppänen 

This is required for patch "Fix a build-ca issue on Windows" to work
---
 easy-rsa/Windows/openssl.cnf |  350 ++
 1 files changed, 350 insertions(+), 0 deletions(-)
 create mode 100644 easy-rsa/Windows/openssl.cnf



ACK.  Applied to master and release/2.2

I see that 'extendedKeyUsage=serverAuth' is not set. I am not 100% sure if
that is needed or not, or just "nice to have".  This was mentioned in Trac
ticket #125 [1]. So I'm accepting the openssl.cnf patch as it is now, and
we can rather fix this attribute later on if it is not enough.

commit 663860ad04dd4190fddbee63e724d3fdceafd937 (master)
commit 6989cbde616a00380acf3a390959987765a5325b (release/2.2)
Author: Samuli Seppänen 
Date:   Mon Jun 20 10:49:41 2011 +0300

Add new openssl.cnf to easy-rsa/Windows

This is required for patch "Fix a build-ca issue on Windows" to work

Signed-off-by: Samuli Seppänen 
Acked-by: David Sommerseth 


Kind regards,

David Sommerseth


[1] 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/EnsACgkQDC186MBRfroPsQCfT6am6MJsmzhaNtWEOWfs0PFp
KyMAn1M3ljU1cf6BWgL/8rraB0IBrh4O
=VmQ8
-END PGP SIGNATURE-

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
  

Re: [Openvpn-devel] Summary of the IRC meeting (9th June 2011)

[Jan Just Keijser]

Hi *,


> Discussed the possibility of arranging a "real" face-to-face meeting
> between the company and community people, for example in New York. Costs
> are an issue, but this might happen eventually.
JM2CW: I think this would be a *very* good thing , for both the openvpn
community developers as well as for the people working for 'openvpn
inc'.  Let me know if I can help.

cheers,

JJK



Samuli Seppänen wrote:
> Hi,
>
> Here's the summary of the previous community meeting.
>
> ---
>
> COMMUNITY MEETING
>
> Place: #openvpn-devel on irc.freenode.net
> Date: Thursday, 9th June 2011
> Time: 18:00 UTC
>
> Planned meeting topics for this meeting were on this page:
>
> 
>
> Next meeting will be announced in advance, but will be on the same
> weekday and at the same time. Your local meeting time is easy to check
> from services such as
>
> 
>
> or with
>
> $ date -u
>
>
> SUMMARY
>
> cron2, dazo, ecrist and mattock were present in this meeting.
>
> --
>
> Discussed branching out beta/2.3. There are a few patches that are
> required first:
>
> * PolarSSL and Doxygen patches from andj
> * Visual Studio 2008 build fixes now in "winbuildtmp" branch
> * Cron2 needs to make "tap" work with "push route-ipv6"
> * https://community.openvpn.net/openvpn/ticket/128 (if reproducible)
> * https://community.openvpn.net/openvpn/ticket/140
> * https://community.openvpn.net/openvpn/ticket/125
> * Some open tickets from 2.2.0
>
> --
>
> Discussed 2.2.0 release. Will try to get it out in two weeks. There's at
> least a few patches missing:
>
> * James segfault fix from SVN (left out from 2.2.0)
> * https://community.openvpn.net/openvpn/ticket/125
>
> --
>
> Discussed the possibility of placing non-invasive ads to OpenVPN Windows
> installers, e.g. links to commercials product in Start menu or to the
> README file. Idea met with lukewarm response, because the community has
> effectively ran the project for the last ~18 months. The fact that
> OpenVPN (OSS) is hard to find from all commercial content in openvpn.net
> also raised critique.
>
> For the above reasons agreed that splitting openvpn.net (commercial
> site) and openvpn.org (community site) would make sense. Both sites
> would be linked together tightly. Agreed that having a joint community /
> company meeting focusing on this issue makes sense. At least Samuli,
> Francis and James would need to attend (from the company) along with
> most active  community members.
>
> Also agreed that the company needs to mentally "let openvpn go" and
> focus on working with the project and build products on top of it
> like everyone else. If a fork ever happened, getting distributors (*NIX
> distros) and later users to migrate to it should not pose a big problem.
> OpenOffice.org/LibreOffice is a good analogy: most/all major *NIX
> distros migrated to LibreOffice in their first post-fork release.
>
> --
>
> Discussed the possibility of arranging a "real" face-to-face meeting
> between the company and community people, for example in New York. Costs
> are an issue, but this might happen eventually.
>
> --
>
> Discussed the problem with Access Server's OpenVPN version, which is
> effectively a fork (based on 2,1 release). This means AS is atm lacking
> features which OpenVPN has. This divergence has already caused some
> nasty merge conflicts.
>
> --
>
> Discussed Russell's questions posted to the mailinglist:
>
> 
>
> Management interface does come up before connection, but it's only used
> for passing the username and password to OpenVPN daemon.
>
> Adding more granular exit codes to OpenVPN would be possible, but it
> would not be trivial without a (needed) overhaul of err.[ch].
>
> ---
>
> Full chatlog as an attachment
>
>   
> 
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> 
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make '--comp-lzo no' the default behaviour if LZO is enabled

[Jan Just Keijser]

Hi *,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/05/11 13:10, David Sommerseth wrote:
  

This makes 'comp-lzo' pushable without requiring clients to have
--comp-lzo defined in the client configs.  To make 'comp-lzo' not
pushable on the client, a new 'disabled' argument have been added.

Trac-ticket: 128
Signed-off-by: David Sommerseth 
---
 openvpn.8 |   12 ++--
 options.c |   10 +++---
 2 files changed, 13 insertions(+), 9 deletions(-)




As announced on the developers meeting yesterday (Samuli will paste the
summary with the discussion), I'm withdrawing this patch in the current form.

The reason is that the OpenVPN wire protocol changes slightly when using
'--comp-lzo no' versus not having --comp-lzo in the config file.  This
change will cause server/client incompatibilities.

Alon proposed another approach with white/blacklist of pushed options which
should be processed.  And this approach do make a lot of sense, and we
should implement this as well.  But this will be a bigger change.

However, I'm looking at a different approach right now isolated to
- --comp-lzo, where OpenVPN can detect incompatible --comp-lzo settings and
rather provide a better error and stop OpenVPN.  This I consider better
than to try to reconnect indefinitely when critical config options on
client and server is incompatible.

- From a quick brain storm, for --comp-lzo, the only compatible/valid
combinations are:

   Client  Server
   (no --comp-lzo) (no --comp-lzo)
   --comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
   --comp-lzo yes (*)  --comp-lzo yes
   --comp-lzo no  (*)  --comp-lzo no

(*) In these combinations, comp-lzo should be pushable which can change the
client setting.  If client does not have comp-lzo in its config, it should
disconnect from the server if the server pushes --comp-lzo settings, as the
wire protocol from the server will be different from what the client expects.

  

please remember the reason for this patch: bug
 https://community.openvpn.net/openvpn/ticket/128

if there is a 'comp-lzo' mismatch and the server pushes out 'push 
"comp-lzo yes"' then upon reconnecting it works all of a sudden - this 
inconsistency needs to be addressed one way or the other.
If we don't want to change the 'comp-lzo' behaviour then at the very 
least this "reconnect-makes-it-work" feature/bug should be fixed in a 
different manner.


JM2CW,

JJK

Re: [Openvpn-devel] [Openvpn-users] behavior of remote address with more than one A record

[Jan Just Keijser]

Hi William,

William Cooley wrote:


On 5/12/2011 1:46 PM, Jan Just Keijser wrote:

William Cooley wrote:
I'd like to have a remote address setting that has two A records. 
The client should randomly try to connect to one of the addresses 
and if it fails it should either try the other IP address or do a 
randomize operation on the IP selection again.
In previous versions of openvpn if you specified a domain that 
resolved to two or more IP addresses you'd get a long line like
/RESOLVE: NOTE: vpndomain.com resolves to 2 addresses, choosing one 
by random/

and I believe it performed as I described above.
However it looks like with openvpn 2.1.4 and newer you simply get
/RESOLVE: NOTE: vpndomain.com resolves to 2 addresses/
and if it fails to connect to the first IP address it never tries 
the other address and simply indefinitely tries to connect to the 
same address.


Was there some type of change in the code that was not mentioned in 
the changelog? Does any one have more information on this? Is there 
a setting that can restore this behavior?



it's mentioned in the changelog:

* Implemented multi-address DNS expansion on the network field of route
 commands.

 When only a single IP address is desired from a multi-address DNS
 expansion, use the first address rather than a random selection.


but it seems this had the unintentional side-effect , namely what you 
describe.

this is either a bug or it should have been documented better.

cheers,

JJK


Yes I say this but I assumed it only applied to the route command.
The man pages for both 2.1 and 2.2 still say
If *host* is a DNS name which resolves to multiple IP addresses, one 
will be randomly chosen, providing a sort of basic load-balancing and 
failover capability.

So can this be called a bug?

I'm not sure, that's why I copied in openvpn-devel - either it's changed 
behaviour, which needs to be mentioned in the changelog and manual page, 
or it's a bug, in which case it needs to be fixed. Personally I'd say 
it's a bug.


cheers,

JJK

Re: [Openvpn-devel] Fwd: OpenVPN netsh.exe patch

[Jan Just Keijser]

Hi,

Gert Doering wrote:
> Hi,
>
> On Tue, May 10, 2011 at 03:31:56PM +0200, Jan Just Keijser wrote:
>   
>> Seth Mos wrote:
>> 
>>> Here is the tun.c patch for correction of the netsh.exe commands.
>>>
>>> I've confirmed that the patch works on Windows XP SP2 and Windows 7.
>>>
>>> Patch!
>>> http://iserv.nl/files/pfsense/0001-Change-the-netsh.exe-command-from-add-to-set-.-Th.patch
>>>   
>> please explain the rationale behind this patch: is something wrong when
>> using 'ipv6 add address' ? 
>> 
>
> Without "store=active", address assignment is "sticky" and will even
> survive reboots - thus making the next tunnel setup fail, because the
> address is already there.  On WinXP, that was not needed, but Win7 seems
> to have changed the default.
>
>   
but then why not use
  add address <> store=active
? why switch to "set address" ? what's the difference?

JJK

Re: [Openvpn-devel] Fwd: OpenVPN netsh.exe patch

[Jan Just Keijser]

Hi Seth,

Seth Mos wrote:
> Here is the tun.c patch for correction of the netsh.exe commands.
>
>
>
> I've confirmed that the patch works on Windows XP SP2 and Windows 7.
>
> Patch!
> http://iserv.nl/files/pfsense/0001-Change-the-netsh.exe-command-from-add-to-set-.-Th.patch
>
>   

please explain the rationale behind this patch: is something wrong when
using 'ipv6 add address' ? why is the patch applied only for IPv6
addresses?

thx,

JJK

Re: [Openvpn-devel] OpenVPN 2.2.0 released

[Jan Just Keijser]

Hi,

I just would like to thank dazo, mattock and all the other developers 
and contributors who have put so much time into creating this release  - 
great job guys!


JJK


David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/11 20:48, Samuli Seppänen wrote:
|
| Note that we've recently switched to using a different Git repository:
|
| 

Just to follow up this one a little bit with more details.

For me personally, the 2.2 release is a remarkable release for the OpenVPN
community.  This is probably the release with the most visible patches from
the community.  If I've counted correctly, there are 23 different patch
authors in addition to the work of James Yonan.  Over 100 patches have been
contributed and have been implemented.  So I want to thank all of you who have
contributed with fixes, new features, documentation and other improvements.

To mark that we now are officially using git as the official source
repository, all releases and the approved patches will now go into the new
openvpn.git tree, as announced.  This tree will also have release branches,
one for each major release, like 2.1, 2.2 and the coming 2.3.  All major and
minor releases (2.1.x, 2.2.x, etc) are in addition tagged.

For more information about the code repositories, please have a look at our 
wiki:



We have for about a year used the openvpn-testing.git tree.  The future of
this tree will be discussed in the near future.  Right now, this tree will be
available.  The master branch in this tree and in the openvpn.git tree will be
kept in sync, and all approved feature branches will be merged into allmerged
together with the master branch when they are considered stable enough.  Right
now, it is not much new things in the allmerged branch, as the last
outstanding and approved feature branches was the IPv6 branches.

As you now understand, the OpenVPN 2.3 will have IPv6 as one of the more
important features.  Both feat_ipv6_transport (connecting/listening to IPv6
addresses between OpenVPN client and server) and feat_ipv6_payload
(transporting IPv6 traffic inside the tunnel) have been available in the
allmerged branch for about a year, so it is considered safe and stable enough
to be merged into the master branch.  So everyone who wants to begin to look
at what OpenVPN 2.3 really will bring, grab the a master branch.


So to summarise it quickly:  openvpn.git is the main git repository, where all
that has been released and will be released in the coming OpenVPN releases can
be found.  The openvpn-testing.git repository contains now experimental code
which needs a lot of testing and possibly much more development.  And the
master branch in both trees will stay in sync.  What is in found the master
branch will make it into a coming release.

Again thanks to all support and contributions.  They are indeed very much
appreciated!
  

Re: [Openvpn-devel] [Openvpn-users] OpenVPN memory usage

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/04/11 17:25, Jan Just Keijser wrote:
  

Hi *,

copying in the openvpn-devel list as they might be interested in this memory 
usage analysis as well

Ralf Hildebrandt wrote:


* Ralf Hildebrandt <ralf.hildebra...@charite.de>:
  

* Fredrik Kers <fredrik.k...@gmail.com>:


I measure the memory usage by checking the VmRSS (Resident Set Size) in
/proc/[pid]/status before and after the clients connect (about 1000 of
them).
  

So it's the same method (because that's what top and htop do).



I'm using a 64 bit system, maybe that will cause OpenVPN to consume
more memory per client then your setup
  

Yes, that could be. It's 32Bit here.

pmap -d pid_of_openvpn 


is showing:

# pmap -d 1607
1607:   /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --syslog 
ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf
Address   Kbytes Mode  Offset   DeviceMapping
08048000 500 r-x--  068:5 openvpn
080c5000   4 rwx-- 0007d000 068:5 openvpn
080c6000  24 rwx--  000:0   [ anon ]
* 08b51000   41396 rwx--  000:0   [ anon ]
b727 132 rwx--  000:0   [ anon ]
...
bfef8000 132 rw---  000:0   [ stack ]
mapped: 46240Kwriteable/private: 42304Kshared: 0K

The line starting with * shows the biggest chunk of memory in use.

  

I'm running openvpn 2.1.4 on a 64bit system (CentSO 5.5 with openssl 0.9.8e). 
when the first client connects the openvpn server
gets "hit" by ~ 600 Kb (as seen using pmap). The size of the 'hit' most likely 
depends on the encryption cipher used.

I recompiled openvpn using
  ./configure --with-mem-check=valgrind
and then ran the server again using
  valgrind --tool=massif .../openvpn

this results in a nice memory report which you can view using
  ms_print massif.out.22218

turns out that most memory is allocated by the openssl libraries : CRYPTO_malloc
the memory trace is too large to show here, but there's tons of stuff in that 
'ms_print' output.
Note that compression was NOT used in this example, apparently the openssl libs 
call deflateInit internally?

Timestep 49 is when the client connects: you see the memory usage jump from 
327,520 bytes to 934,688.


  ntime(i) total(B)   useful-heap(B) extra-heap(B)stacks(B)

 48 36,072,833  327,520  276,10251,4180
 49 36,341,762  934,688  883,12651,5620
94.48% (883,126B) (heap allocation functions) malloc/new/new[], --alloc-fns, 
etc.



Again, thanks a lot for wonderful reports.  It is easy to shoot OpenSSL
here.  But I'm not going to do that just yet.  There are some work in
progress of modularising the SSL layer in OpenVPN (if patches are cleaned
up in time and get a decent review, we might have this in OpenVPN 2.3
already).  This work will also add support for PolarSSL.

When we see those patches, it might be easier to see if there's something
which can be improved in OpenVPN or if it is something which is completely
into the hands of OpenSSL.  So running this test with the PolarSSL module
instead will be very interesting.

I generally think that the crypto context needs to stay in memory for some
time, especially in UDP mode, to avoid re-negotiating of the connections in
case of connectivity issues between client and server.  But when the
session is defined as closed by the OpenVPN server, this memory pool should
be released.  For TCP mode, the session is closed (afair) when the client
explicitly closes the connection.  In UDP mode it's a timeout, unless
- --explicit-exit is used.  This freeing of context memory needs to be
verified in the code.
  
for the record: I did not mean to "shoot OpenSSL"  here; I use OpenSSL a 
lot for my regular work and I know how difficult it is to get it to 
behave correctly when it comes to memory usage.
The reason I started digging was that I added a very dumb 'printf' 
statement every time gc_alloc or ALLOC_OBJ was called (in openvpn 
buffer.c) ; I then grabbed the output after a client connected and added 
up all the mallocs : this did not even add up to 75 KB (and I'm probably 
double counting too). So then I went on a hunt to find out what _IS_ 
causing the 600 KB hit, which led to the ms_print report.


I'm not too worried about a 600 KB per client hit for an OpenVPN server 
- it means a 1,000 clients will eat up less than 1 GB of RAM . Unless 
you're running on tiny hardware (dd-wrt etc) this should not be an 
issue, but I would not recommend to connect a 1,000 clients to a single 
dd-wrt box anyway.


It will b

Re: [Openvpn-devel] [Openvpn-users] OpenVPN memory usage

[Jan Just Keijser]

Hi *,

copying in the openvpn-devel list as they might be interested in this memory 
usage analysis as well

Ralf Hildebrandt wrote:
> * Ralf Hildebrandt :
>> * Fredrik Kers :
>>> I measure the memory usage by checking the VmRSS (Resident Set Size) in
>>> /proc/[pid]/status before and after the clients connect (about 1000 of
>>> them).
>> So it's the same method (because that's what top and htop do).
>>
>>> I'm using a 64 bit system, maybe that will cause OpenVPN to consume
>>> more memory per client then your setup
>> Yes, that could be. It's 32Bit here.
> 
> pmap -d pid_of_openvpn 
> 
> is showing:
> 
> # pmap -d 1607
> 1607:   /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --syslog 
> ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf
> Address   Kbytes Mode  Offset   DeviceMapping
> 08048000 500 r-x--  068:5 openvpn
> 080c5000   4 rwx-- 0007d000 068:5 openvpn
> 080c6000  24 rwx--  000:0   [ anon ]
> * 08b51000   41396 rwx--  000:0   [ anon ]
> b727 132 rwx--  000:0   [ anon ]
> ...
> bfef8000 132 rw---  000:0   [ stack ]
> mapped: 46240Kwriteable/private: 42304Kshared: 0K
> 
> The line starting with * shows the biggest chunk of memory in use.
> 

I'm running openvpn 2.1.4 on a 64bit system (CentSO 5.5 with openssl 0.9.8e). 
when the first client connects the openvpn server
gets "hit" by ~ 600 Kb (as seen using pmap). The size of the 'hit' most likely 
depends on the encryption cipher used.

I recompiled openvpn using
  ./configure --with-mem-check=valgrind
and then ran the server again using
  valgrind --tool=massif .../openvpn

this results in a nice memory report which you can view using
  ms_print massif.out.22218

turns out that most memory is allocated by the openssl libraries : CRYPTO_malloc
the memory trace is too large to show here, but there's tons of stuff in that 
'ms_print' output.
Note that compression was NOT used in this example, apparently the openssl libs 
call deflateInit internally?

Timestep 49 is when the client connects: you see the memory usage jump from 
327,520 bytes to 934,688.


  ntime(i) total(B)   useful-heap(B) extra-heap(B)stacks(B)

 48 36,072,833  327,520  276,10251,4180
 49 36,341,762  934,688  883,12651,5620
94.48% (883,126B) (heap allocation functions) malloc/new/new[], --alloc-fns, 
etc.
->82.41% (770,295B) 0x3858CDAD90: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
| ->62.91% (588,016B) 0x3858CBFF34: ??? (in /lib64/libcrypto.so.0.9.8e)
| | ->14.02% (131,072B) 0x38578064B3: deflateInit2_ (in 
/usr/lib64/libz.so.1.2.3)
| | | ->14.02% (131,072B) 0x3857806622: deflateInit_ (in 
/usr/lib64/libz.so.1.2.3)
| | |   ->14.02% (131,072B) 0x3858CBFECA: ??? (in /lib64/libcrypto.so.0.9.8e)
| | | ->14.02% (131,072B) 0x3858CBFA96: COMP_CTX_new (in 
/lib64/libcrypto.so.0.9.8e)
| | |   ->07.01% (65,536B) 0x385E025CDF: tls1_change_cipher_state (in 
/lib64/libssl.so.0.9.8e)
| | |   | ->07.01% (65,536B) 0x385E020492: ssl3_do_change_cipher_spec (in 
/lib64/libssl.so.0.9.8e)
| | |   |   ->07.01% (65,536B) 0x385E021952: ssl3_read_bytes (in 
/lib64/libssl.so.0.9.8e)
| | |   | ->07.01% (65,536B) 0x385E0222AE: ssl3_get_message (in 
/lib64/libssl.so.0.9.8e)
| | |   |   ->07.01% (65,536B) 0x385E022B1B: ssl3_get_finished (in 
/lib64/libssl.so.0.9.8e)
| | |   | ->07.01% (65,536B) 0x385E01A740: ssl3_accept (in 
/lib64/libssl.so.0.9.8e)
| | |   |   ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in 
/lib64/libssl.so.0.9.8e)
| | |   | ->07.01% (65,536B) 0x385E01E55F: ??? (in 
/lib64/libssl.so.0.9.8e)
| | |   |   ->07.01% (65,536B) 0x385E038F3F: ??? (in 
/lib64/libssl.so.0.9.8e)
| | |   | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in 
/lib64/libcrypto.so.0.9.8e)
| | |   |   ->07.01% (65,536B) 0x46F7A3: bio_read 
(ssl.c:2058)
| | |   | ->07.01% (65,536B) 0x46FA8F: 
key_state_read_plaintext (ssl.c:2148)
| | |   |   ->07.01% (65,536B) 0x474859: tls_process 
(ssl.c:4075)
| | |   | ->07.01% (65,536B) 0x475420: 
tls_multi_process (ssl.c:4303)
| | |   |   ->07.01% (65,536B) 0x411B4C: 
check_tls_dowork (forward.c:93)
| | |   | ->07.01% (65,536B) 0x41571F: 
check_tls (forward-inline.h:41)
| | |   |   ->07.01% (65,536B) 0x415663: 
pre_select (forward.c:1304)
| | |   | ->07.01% (65,536B) 

Re: [Openvpn-devel] [PATCH] Fix the --client-cert-not-required feature

[Jan Just Keijser]

With this explanation, I'm ACKing the patch.


JJK

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31/03/11 09:57, Jan Just Keijser wrote:
  

Hi David,

David Sommerseth wrote:


Commit 2e8337de248ef0b5b48cbb2964da0d5c3f28b15b introduced a new
feature for using other SSL certificate fields for authentication
than then CN field.

This commit introduced a bug, which made the verify_callback()
function getting called even if --client-cert-not-required was
enabled in the config.

The reason for this was that an 'else' statement was lacking a
couple of curly braces.  The offending commit in reality moved
the setup the verify_callback() function out of the 'else'
statement.

Report-URL: https://community.openvpn.net/openvpn/ticket/108
Report-URL: https://forums.openvpn.net/topic7751.html
Signed-off-by: David Sommerseth <dav...@redhat.com>
---
 ssl.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/ssl.c b/ssl.c
index ed10714..6d9a9fd 100644
--- a/ssl.c
+++ b/ssl.c
@@ -1874,13 +1874,15 @@ init_ssl (const struct options *options)
 }
   else
 #endif
+{
 #ifdef ENABLE_X509ALTUSERNAME
-  x509_username_field = (char *) options->x509_username_field;
+  x509_username_field = (char *) options->x509_username_field;
 #else
-  x509_username_field = X509_USERNAME_FIELD_DEFAULT;
+  x509_username_field = X509_USERNAME_FIELD_DEFAULT;
 #endif
-  SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
-   verify_callback);
+  SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
+  verify_callback);
+}

   /* Connection information callback */
   SSL_CTX_set_info_callback (ctx, info_callback);

  

weird, but with your patch I get a completely different error:

Thu Mar 31 09:55:01 2011 us=368010 194.171.96.28:44859 Could not create
temporary file 'openvpn_acf_ab60cdb4d9d6bdf5d3c7812ea9710705.tmp':
Permission denied
Thu Mar 31 09:55:01 2011 us=368145 194.171.96.28:44859 Exiting


if I run it with '--tmp-dir /tmp' it works again - looks like this patch
triggers another bug?



Actually, it's not another bug, it's an expected behavioural change.  In
OpenVPN 2.1 and earlier there is a function which is called quite often
when plug-in's or the script hooks are used, which generates a unique
filename and passes this filesname to the plug-in or script.  This function
was called create_temp_filename().  Plug-ins or script could then create
this file if it wanted to pass some information back to OpenVPN.

This might be a security issue, where it is, theoretically at least,
possible to intercept OpenVPN and put configuration statements which would
then be processed by the OpenVPN server.

To solve this the create_temp_filename() function has been replaced by
create_temp_file(), which creates a temp file which is read/writeable only
by the OpenVPN user before the plug-in/script is called.  The
plug-in/script only needs to open this file and write to it to pass
information back.  The OpenVPN server evaluates the file and deletes it
when the plug-in/script is done.

The reality is that when you use --plugin or some of the script hooks, you
now need to have a writeable directory anyway.  Earlier this was only
needed if the plug-in/script did create the file.  So it's not really a
bug, but it reveals this behaviour more easily now.

For those concerned about performance, it is possible to put this --tmp-dir
on a tmpfs or RAM disk mounted directory.  It's also been discussed briefly
if we should default to /tmp, %TMPDIR%, or similar standard paths for
- --tmp-dir.  I think we need to do that.

The man page has been updated to cover this change.  But it could probably
be mentioned as well in the --client-connect and --plugin sections too.

For OpenVPN 2.3, a new plug-in API is comming.  I'm considering to extend
that so that the plug-in can create this file and provide the filename back
to OpenVPN.  This sounds easy, but I have not looked at possible security
considerations here yet.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2UO1wACgkQDC186MBRfrqGOACgmtxxYU2riZxQPJS/GXx9Ah6O
f5UAnjqD1uhwUwFqMOnDv1jGPM43ZMnx
=bEod
-END PGP SIGNATURE-
  

Re: [Openvpn-devel] [PATCH] Fix the --client-cert-not-required feature

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

Commit 2e8337de248ef0b5b48cbb2964da0d5c3f28b15b introduced a new
feature for using other SSL certificate fields for authentication
than then CN field.

This commit introduced a bug, which made the verify_callback()
function getting called even if --client-cert-not-required was
enabled in the config.

The reason for this was that an 'else' statement was lacking a
couple of curly braces.  The offending commit in reality moved
the setup the verify_callback() function out of the 'else'
statement.

Report-URL: https://community.openvpn.net/openvpn/ticket/108
Report-URL: https://forums.openvpn.net/topic7751.html
Signed-off-by: David Sommerseth 
---
 ssl.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/ssl.c b/ssl.c
index ed10714..6d9a9fd 100644
--- a/ssl.c
+++ b/ssl.c
@@ -1874,13 +1874,15 @@ init_ssl (const struct options *options)
 }
   else
 #endif
+{
 #ifdef ENABLE_X509ALTUSERNAME
-  x509_username_field = (char *) options->x509_username_field;
+  x509_username_field = (char *) options->x509_username_field;
 #else
-  x509_username_field = X509_USERNAME_FIELD_DEFAULT;
+  x509_username_field = X509_USERNAME_FIELD_DEFAULT;
 #endif
-  SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
-   verify_callback);
+  SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
+  verify_callback);
+}
 
   /* Connection information callback */

   SSL_CTX_set_info_callback (ctx, info_callback);
  

weird, but with your patch I get a completely different error:

Thu Mar 31 09:55:01 2011 us=368010 194.171.96.28:44859 Could not create 
temporary file 'openvpn_acf_ab60cdb4d9d6bdf5d3c7812ea9710705.tmp': 
Permission denied

Thu Mar 31 09:55:01 2011 us=368145 194.171.96.28:44859 Exiting


if I run it with '--tmp-dir /tmp' it works again - looks like this patch 
triggers another bug?


cheers,

JJK

Re: [Openvpn-devel] sctp in openvpn

[Jan Just Keijser]

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/02/11 12:25, Gert Doering wrote:
| Hi,
|
| On Sat, Feb 26, 2011 at 11:19:19AM +, Olivier Van Acker wrote:
|>> The code parts in question inside OpenVPN (socket.c) are somewhat
|>> complicated due to lots of existing options and lots of existing
|>> operating systems being supported, so this will not be a trivial
|>> task.
|>
|> Would it be a good idea to limit the scope of this project by concentrating
|> on one OS first? I was thinking FreeBSD first since that contains the
|> reference implementation of SCTP.
|
| Well, you'd certainly start with one OS, but in the long run, you'd want
| the mainstream OSes (Linux and Windows) as well...

I second this.  SCTP is really interesting for OpenVPN in my perspective, but
we should rather quickly after having "something which works" support other
OSes as well.  When we reach that point, merging SCTP support into 'allmerged'
for broader testing gets interesting.  If Linux gets support quickly, I'm able
to test this out pretty soonish in a limited prod environment.

Some practical details.  General info about the development process can be
found here:
, including
git repositories.

For the git branch to look at, JJO's IPv6 transport patches is called
feat_ipv6_transport.  *But* as soon as we manage to get the OpenVPN 2.2
release out the door (I'm hope I'll be able to finalise the beta2.2 branch
today for the RC release), we're going to merge stuff, including JJO's branch
and Gert's feat_ipv6_payload branches officially and get started with the
OpenVPN 2.3 cycle.  So what I'm saying, please base your stuff on JJO's branch
now, but be sure your changes can be merged against the feat_ipv6_payload
branch too.  As I'm the one going to do the merges, I'm going to be noisy if
it doesn't go smooth ;-)

And just let me state that, if someone got time to do a real overhaul of
socket.c, that would really be beneficial.  That source file is confusing at
best to read.  However, we do have some source documentation patches is the
wild somewhere, waiting to go in soonish too - which I'd like to see go into
the 2.3 cycle.  So - there's a little coordination needed to be done here with
such an overhaul too.

  
there seems to be a freely available SCTP implementation for Windows 
XP/Vista/7:

 http://www.bluestop.org/SctpDrv/

Sources for an older version of this driver are available, but I am not 
sure under what conditions/license is released.


As for adding SCTP support: if I read the 'socat' sources it should be 
dead-easy: just open the socket using the protocol IPP_SCTP4 and that's 
about it.
The real question is whether we'd want to support some of the niftier 
features that SCTP has to offer (e.g. opening multiple channels via a 
single connections).


cheers,

JJK

Re: [Openvpn-devel] OpenVPN 2.2-rc Windows installer ready

[Jan Just Keijser]

hi Samuli,

Samuli Seppänen wrote:

Hi all,

The (hopefully) final preview of the OpenVPN 2.2-rc installer for
Windows is available here:



The main reason for this preview installer is our use of the new,
relatively untested Python-based buildsystem which uses VS 2008 tools.
Note that the new buildsystem is not replacing the old autotools-based
one. This installer and the included binaries have been tested on the
following platforms:

- Windows XP 32-bit
- Windows XP 64-bit
- Windows 7 64-bit

The plan is to get James to sign the installer during today's IRC
meeting (#openvpn-devel at irc.freenode.net) at 18:00 UTC. If you want
help make sure that 2.2-rc is a solid release, please test the installer
and let us know if there are any issues - or if it works perfectly.

  
just FYI: this installers runs on Windows 2000 (grin), if  you choose to 
not install the TAP-Win32 driver. the executables work, but OpenVPN 
refuses to start as the tap-win32 driver needs to be version 9.7 and I 
only have 9.6 - is this new version *really* necessary? what is new in it?


Tomorrow I will test it on a Windows XP VM (which I don't have here 
right now) and on Win7 64bit.


cheers,

JJK

Re: [Openvpn-devel] Help testing OpenVPN 2.2-rc Windows installer?

[Jan Just Keijser]

hi  Samuli,

Samuli Seppänen wrote:

Hi Samuli,

Samuli Seppänen wrote:
  


Hi,

As some of you may be aware, I've been working on the new Python-based
OpenVPN Windows buildsystem; now the first fully functional OpenVPN
installer is ready:



However, I've only done very limited testing. On Windows 7 64-bit
platform the following seems to work:

- installing and uninstalling all userspace components
- installing and uninstalling the (64-bit) TAP driver
- running OpenVPN as service
- running OpenVPN using the OpenVPN-GUI

I've only noticed two small issues on the Win7 64-bit platform:

- uninstall does not remove the OpenVPN start menu entries properly
(remove manually using right click -> delete)
- "View README" at the end of install does not work

Note that the installer itself is not signed, even though the TAP
drivers are. This will be fixed in the final 2.2-rc release.

Now, I'd need help in verifying that both the installer and the included
executables work properly on all supported 32 and 64-bit Windows
platforms (XP and later). If you can, please test the installer on some
_non-critical system_ and report back, whether everything works properly
or not. Once all installer bugs are squashed, I'll make the
openvpn-2.2-rc release. After that I'll clean up my buildsystem patches,
send them here for review and then update the Windows building Wiki page:

  

  
just tried it on a 32bit Windows XP SP3 machine. Installation went OK, 
the README works but the format of the README file itself does not 
display properly in Notepad (CR/LF problem?).
  
The bad news is that the binaries don't work. All binaries refuse to 
start (openvpn.exe, openssl.exe, openvpn-gui.exe). The command-line 
tools fail with 'Cannot execute the specified program'. The OpenVPN GUI 
fails with an error 0xC0150002.
  


Interesting, given that OpenVPN was built on WinXP. This may have
something to do with the (external) manifest files or DLL versions. I'll
setup another WinXP VM to test the installer, fix these issues and then
upload a second preview.
  
did some testing: turns out that the new executables depend on the 
Visual Studio 2008 runtime (msvcr90.dll). The manifest files point to 
these MSVCR files but I did not install them in my VM (nor do I think I 
should have to install them).
After installing the Visual Studio 2008 RT the openvpn.exe command at 
least *runs* .
If I remove the manifest files it no longer works - personally I think 
this is kinda ugly ...


cheers,

JJK

Re: [Openvpn-devel] Help testing OpenVPN 2.2-rc Windows installer?

[Jan Just Keijser]

Hi Samuli,

Samuli Seppänen wrote:

Hi,

As some of you may be aware, I've been working on the new Python-based
OpenVPN Windows buildsystem; now the first fully functional OpenVPN
installer is ready:



However, I've only done very limited testing. On Windows 7 64-bit
platform the following seems to work:

- installing and uninstalling all userspace components
- installing and uninstalling the (64-bit) TAP driver
- running OpenVPN as service
- running OpenVPN using the OpenVPN-GUI

I've only noticed two small issues on the Win7 64-bit platform:

- uninstall does not remove the OpenVPN start menu entries properly
(remove manually using right click -> delete)
- "View README" at the end of install does not work

Note that the installer itself is not signed, even though the TAP
drivers are. This will be fixed in the final 2.2-rc release.

Now, I'd need help in verifying that both the installer and the included
executables work properly on all supported 32 and 64-bit Windows
platforms (XP and later). If you can, please test the installer on some
_non-critical system_ and report back, whether everything works properly
or not. Once all installer bugs are squashed, I'll make the
openvpn-2.2-rc release. After that I'll clean up my buildsystem patches,
send them here for review and then update the Windows building Wiki page:

  
just tried it on a 32bit Windows XP SP3 machine. Installation went OK, 
the README works but the format of the README file itself does not 
display properly in Notepad (CR/LF problem?).


The bad news is that the binaries don't work. All binaries refuse to 
start (openvpn.exe, openssl.exe, openvpn-gui.exe). The command-line 
tools fail with 'Cannot execute the specified program'. The OpenVPN GUI 
fails with an error 0xC0150002.


I have not tested whether the TAP-Win32 driver works.

share and enjoy,

JJK

Re: [Openvpn-devel] OpenVPN documentation (man page) review

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi folks!

This is a little cry for help from us playing with the OpenVPN code.

We have a quite good man page today with a lot of information.  But
maintaining it and to make sure it is up-to-date with all the features
OpenVPN supports is often not high up on the priority list.  In
addition, the current format (one single file, in pure man page format)
is getting harder and harder to maintain as well.

So, we're hoping some people with some English skills is interested to
help out improving this situation.  What we immediately would like to
see is something along these lines:

* Move the man page to a better format than the pure man page format.
  Are there some good tools/formats like ascii2man or DocBookXML which
  could help easing the maintenance of our documentation?

* Split up the documentation into more focused sections, like
  - main openvpn page (kind of like openvpn.8 today)
  Gives an executive overview over OpenVPN, features and references
  to the other documentation pages.  A bonus would be if it easily
  can produce other formats in addition, like HTML, PS/PDF, ePub.

  - openvpn common options
  Gives information about the common options openvpn has, which is
  useful on both server and client instances.  F.ex. --keepalive,
  --tls-auth, --cert, --key, --ca, etc

  - openvpn server options
  Describes only the options which are relevant for openvpn servers

  - openvpn client options
  Describes only options useful for openvpn clients

  - openvpn plug-ins
  Describes the different script plug-in hooks and environment
  variables available to scripts and plug-ins written in C

* Review the contents of all the documentation, check their accuracy
  - Make sure no options are not available in OpenVPN 2.2 or later
  - Make sure no options are missing in the documentation, which is
available in the source code  (options.c is a good reference)

* Review and check if all external references
  - Make sure all references to external sources, like web-sites, are
still available, valid and relevant in the document context
  - Find other external resources which are worth including.

(These points are not carved into stone, but is more like a guideline of
what needs to be considered)

This task should hopefully not require too much in-depth development
knowledge.  It should be user-focused, so that we avoid using terms and
details which is not so easy to understand.  What I'm saying is that
this documentation can be more useful and readable if users are involved
in this process.

If someone are willing to step up and take a lead, that would be great!
 Further, discussions and reviews of the document changes should
probably happen on the openvpn-users mailing list.  That way, it might
be easier for users to review the documentation and provide feedback.

We don't want this to just be a solo-project from someone in our OpenVPN
community, so we hope more people can help out and contribute, also if
you don't consider yourself a developer.
  
I'd be willing to contribute but I don't see myself leading this effort 
right now (due to other obligations).
As for the document format: if we want users to contribute then we 
should not opt for a too-difficult format that users would have to learn 
before being able to contribute. Docbook and/or texinfo are nice for 
Linux users but you'd scare away most Windows/Mac users.

What about plain simple OpenDoc (odf) ?

cheers,

JJK

Re: [Openvpn-devel] [Openvpn-users] Using EasyRSA intermediate CA with OpenVPN - warning with certificate revocation list: "CRL crl.pem is from a different issuer than the issuer of certificate ..."

[Jan Just Keijser]

Hi Erich,

(copying in the openvpn-devel list as this might be considered a minor bug)

Erich Titl wrote:

Hi JJK

at 11.01.2011 15:45, Jan Just Keijser wrote:
  

Hi,



...

  
  
  
the "CRL crl.pem is from a different issuer" warning is actually an 
error: when OpenVPN goes through a stacked CRL list it prints out this 
message. This should be raised as a (minor) bug.
The message is harmless however, as clients with revoked certs are 
denied access (as I have tested myself).


the only way to get rid of this warning is to switch to
  capath 
mode, where the capath directory contains your CA certs and CRL certs as 
.0 and .r0 files.

You can generate the .0 and .r0 files using
  cp ca.crtcadir/`openssl x509 -hash -noout -in ca.crt`.0
  cp crl.pem cadir/`openssl x509 -hash -noout -in ca.crt`.r0



Now this raises a number of questions

1) is the file name suffix responsible for the warning to go away
2) is the hash based filename responsible 
3) is the fact that both files reside in the cadir directory responsible

If all 3 then what should be achieved with this condition stacking

  
actually, it's all 3. OpenSSL has two ways of using certificates and 
CRLs; the first method, which is used most often, is to supply a single 
certificate file and single CRL file. The cert file and CRL file may be 
"stacked" , that is , more than one CA can be specified, related or not, 
and also more than one CRL file, related or not. The OpenVPN code 
processes the CA and CRL file and prints out the warning mentioned when 
it finds a CRL that does not belong to a particular cert. This warning 
is to prevent people from loading the wrong CRL alongside a particular 
ca.crt file. When the wrong file is loaded it is simply ignored by 
OpenSSL. It would be nicer to match each CRL against *a* certificate in 
the stacked ca.crt file, but this makes the verification algorithm a bit 
more complex.

With two certs and CRLs are stacked the warning is printed twice:
- first when CRL_1 is matched against CA_CERT_2
- second when CRL_2 is matched against CA_CERT_1

The second method for using certs and CRLs is to use a 'capath' method 
where all certs and CRLs are put in a single directory using a special 
naming scheme (the 'openssl x509 -hash' thingie). When validating a 
client certificate OpenSSL (and thus, OpenVPN) will go through each of 
the .0 files in the 'capath' directory to find a matching CA cert. It 
then looks at the corresponding .r0 file (the CRL) to check whether the 
certificate has been revoked. Due to the way OpenVPN is coded the CRL 
warning is NOT printed in this case.



cheers,

JJK

Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?

[Jan Just Keijser]

Hi Henno,

Henno Täht wrote:

FWIW, I posted this issue to Microsoft's forum:
http://social.answers.microsoft.com/Forums/en-US/xpnetwork/thread/82388e04-1791-43a0-a678-de8475bce537

Everyone who like this to be answered can mark that article to up the 
"X persons needs an answer" thing.



I think I finally figured it out (I ran into this issue myself this 
morning so I started hacking ;-)) :


if I set "Non-Admin Access" to "Not allowed" in the TAP-Win32 Adapter V9 
Advanced properties page and reboot the box then I can access the shares 
on my WinXP box using

 smbclient -L -p 445 \\192.168.200.2
(where 192.168.200.2 is the VPN IP).

Of course, the problem with not allowing this is that non-Admin users 
can no longer start a VPN connection. You'd need to run

 runas /env /profile user:AdminUser "openvpn ..."
to get around this.

Can somebody verify this? It sounds like a nice one for the FAQ.

share and enjoy,

JJK



2010/6/26 Gert Doering <g...@greenie.muc.de <mailto:g...@greenie.muc.de>>

Hi,

On Wed, Jun 23, 2010 at 10:50:45PM +0300, Henno Täht wrote:
> On Wed, Jun 23, 2010 at 22:48, Gert Doering <g...@greenie.muc.de
<mailto:g...@greenie.muc.de>> wrote:
> > On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:
> > > assigns a 169.254 address. If this works for you as well
then maybe the
> > > tap-win32 developers can dive deeper into this and find out
why windows
> > > treats the 'always connected' adapter differently from an
'application
> > > controlled' adapter .
> >
> > I'd assume that windows services are not "bound" to "dynamic"
interfaces...
>
> By dynamic interface you mean an interface which has  "Obtain IP
address
> automatically" set?

No, I was thinking about interfaces that sort of "are not always
there".

But that was a misconception, the TAP interface *is* always there
- what's
application controlled is whether it's "connected to an ethernet
cable"
(virtual, of course) all the time, or only if openvpn tells it so.

But in that my idea doesn't really make sense - it's as if windows
wouldn't
start windows sharing if the ethernet cable is not plugged in at
boot time.

gert

--
USENET is *not* the non-clickable part of WWW!
 
//www.muc.de/~gert/ <http://www.muc.de/%7Egert/>
Gert Doering - Munich, Germany
g...@greenie.muc.de <mailto:g...@greenie.muc.de>
fax: +49-89-35655025  
 g...@net.informatik.tu-muenchen.de

<mailto:g...@net.informatik.tu-muenchen.de>

Re: [Openvpn-devel] Summary of the IRC meeting (9th Dec 2010)

[Jan Just Keijser]

Hi Adriaan,

Adriaan de Jong wrote:
  

-Original Message-
From: Jan Just Keijser [mailto:janj...@nikhef.nl]
Hi Samuli, David, list,

What some people get confused about is a stacked certificate vs a
certificate chain: OpenVPN only supports stacked CA certificates,
meaning that any of the certs present in the stacked file are
considered
trusted.
What some people want is a certificate chain, like some websites use:
the website has a server certificate signed by a sub-CA which in turn
is
signed by Verisign. The webserver sends the entire chain (server cert +
sub-CA cert + verisign cert) to the client for verification. That way
the client only needs the Verisign cert to trust a particular website
(the Verisign CA cert is installed in most browser by default). OpenVPN
does not support this at the moment. It would require changing
  SSL_CTX_use_certificate()
to
  SSL_CTX_use_certificate_chain()
to ensure that the entire certificate chain is sent to the remote end
(client or server).



I think SSL_CTX_use_certificate_chain_file() is actually used when loading the 
certificate from a separate cert file. It's just slightly confusing due to the 
fact that it is loaded twice:

- SSL_CTX_use_certificate_file is used here:
http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=ssl.c;h=a1268ac2a9291dc1512fa28e3ab4efc65085c952;hb=HEAD#l1639

- SSL_CTX_use_certificate_chain_file is used here:
  
http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=ssl.c;h=a1268ac2a9291dc1512fa28e3ab4efc65085c952;hb=HEAD#l1738

I'm not entirely sure whether I'm right, and why things are done this way. Does 
anyone know the reasoning behind this?

  


ah mea culpa - I did not read the rest of the init_ssl function. It does 
seem a bit odd though:


this happens first (2.1.3 code base):
1623   if (!SSL_CTX_use_certificate_file (ctx, 
options->cert_file, SSL_FILETYPE_PEM))
1624 msg (M_SSLERR, "Cannot load certificate file %s", 
options->cert_file);

1625   using_cert_file = true;

so we load the cert and we set 'using_cert_file = true' . Then later:
1721   /* Enable the use of certificate chains */
1722   if (using_cert_file)
1723 {
1724   if (!SSL_CTX_use_certificate_chain_file (ctx, 
options->cert_file))
1725 msg (M_SSLERR, "Cannot load certificate chain file %s 
(SSL_use_certificate_chain_file)", options->cert_file);

1726 }

so the certificate is loaded again but now using _use_certificate_chain 
! It does suggest that you can use certificate chains , however.


I just tested a setup where the client cert is a concatenation of the 
client cert + intermediate CA. The client sends these certs to a server 
which only trusts the "root" CA (i.e. the one that signed the 
intermediate CA to begin with) but I cannot connect. It seems the 
'verify_callback' function does not work with certificate chains (yet) : 
only the top level cert is inspected.


to be continued...

cheers,

JJK

Re: [Openvpn-devel] script-security 1

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/10 15:53, Jan Just Keijser wrote:
  

hi all,

the openvpn 2.1 man page on script-security reads:

--script-security level [method]
This directive offers policy-level control over OpenVPN's usage of 
external programs and scripts. Lower level values are more restrictive, 
higher values are more permissive. Settings for level:


0 -- Strictly no calling of external programs.
1 -- (Default) Only call built-in executables such as ifconfig, ip, 
route, or netsh.

2 -- Allow calling of built-in executables and user-defined scripts.
3 -- Allow passwords to be passed to scripts via environmental 
variables (potentially unsafe).


but if I try something like
 openvpn --config  --script-security 1 --up "/sbin/ip addr 
show eth0"

I still get

Thu Dec  2 15:52:51 2010 /sbin/ip addr show eth0 tun0 1500 1541 
192.168.200.1 255.255.255.0 init
Thu Dec  2 15:52:51 2010 openvpn_execve: external program may not be 
called unless '--script-security 2' or higher is enabled.  Use 
'--script-security 3 system' for backward compatibility with 2.1_rc8 and 
earlier.  See --help text or man page for detailed info.

Thu Dec  2 15:52:51 2010 script failed: external program fork failed
Thu Dec  2 15:52:51 2010 Exiting

what _IS_ the list of built-in executables? I cannot find it in the 
source code either.



My understanding of it is executables which are executed by the C code,
like the programs mentioned.  That further means that no external script
hooks may be used, like --up, --down, --route-up, etc, etc.

You need --script-security 2 to enable the script hooks, which will
enable the execve() code path for these hooks.  And if
'--script-security 2 system' is set, it will use system() instead of
execve() to execute the scripts.

If --script-security 0 is used, the execve() calls will be completely
blocked.

For Linux, I believe the list of "built-ins" are ip, ifconfig, netstat
and route.  I'm not sure about the Windows side.

  

thanks for the clarification! and indeed, when running
 openvpn --config  --script-security 0
openvpn even refuses to start (on Linux) as it is not capable of 
assigning an IP address to the tun/tap interface...
I guess the only platform on which '--script-security 0' can do 
something useful is Windows, as the IPAPI calls are "internal", that is, 
they do not require an execve() to initialize things like adapters and 
routes.


h, come to think of it: wouldn't this be a nice feature on Linux/Mac 
OS too, i.e. bring up the tun/tap interface programmatically instead of 
using an external binary? I am not sure how portable it would be though.


cheers,

JJK

PS yes this will go into "the book" ;-)

[Openvpn-devel] OpenVPN (cook)book

[Jan Just Keijser]

Hi all,

I just wanted to let you know that the OpenVPN 2 Cookbook , which I've 
been working on for the past 6 months or so, is due for publication in 
early 2011. A pre-release (RAW) version of the book can already be found 
here:

 https://www.packtpub.com/openvpn-2-cookbook/book

cheers,

JJK

[Openvpn-devel] VERY weird interaction between openvpn and opensc-pkcs11

[Jan Just Keijser]

hi all,

I just spent almost a day debugging a very weird interaction between 
OpenVPN 2.1 and opensc-pkcs11 :


Hardware:
a Feitian ePass smartcard with an Omnikey CardMan 3121 card reader

Software:
openvpn 2.1.3
opensc 0.12.0 (not officially released yet)
pkcs11-helper 1.07
linux 2.6.34 64bit kernel (fc13)

Here's what happens:

openvpn starts up, queries me for the PKCS11 prompt, connection is 
established alright.
When I look at the log file (with 'verb 99') I see that the pkcs11 
function __pkcs11h_forkFixup is called several times, with a different 
pid=%d value every time. This is bad, as it causes opensc-pkcs11 to 
reload the card every time (it calls C_Finalize then C_Initialize). This 
operation is very expensive.
During key renegotiation it gets even worse, as openvpn prompts me for 
the PIN again and connectivity is lost until I enter the PIN.


Now here's the weirdest part:

the __pkcs11h_forkFixup function is called after the invocation of an 
external program (e.g. /sbin/ip link , /sbin/ip/addr add etc). If I use

 script-security 2 system
the openvpn_execve function uses 'system()' calls to start these 
programs and the problem goes away !


So it seems that openvpn's openvpn_execve fork+waitpid function causes 
the program pid to change every time, triggering the reset of the pkcs11 
interface !


What shall we do about this?

cheers,

JJK / Jan Just Keijser

Re: [Openvpn-devel] Problem with client reconnect when using username-as-common-name and username is blank

[Jan Just Keijser]

Hi Carlos,

this looks like a repeat of something reported on March 1st :

in multi.c the function multi_client_connect_setenv contains

1410   /* setenv incoming cert common name for script */
1411   setenv_str (mi->context.c2.es, "common_name", tls_common_name 
(mi->context.c2.tls_multi, true));


this is missing from the corresponding multi_client_disconnect_setenv 
function


Unfortunately the openvpn-devel folks were unable to reproduce this 
error and hence no patch was not included. Can you try adding these two 
lines to "multi_client_disconnect_setenv" , rebuild openvpn and see if 
the problem goes away?


HTH,

JJK

Carlos Soto wrote:

I have been having a very strange behavior with openvpn and I have finally
found the source. I do not know if it is a bug or not so I will explain it
and let the experts decide.

I am using OpenVPN 2.1.3 in several openwrt routers connected with ADSL with
dynamic IPs. Every once in a client reconnects (normally because there is a
change in the IP). As I do not use the cn-duplicate, when the client
reconnects, it first calls the client-disconnect script and then the client
connect. See log:

Thu Nov  4 07:55:16 2010 XX.148.40.117:42335 [javier] Peer Connection
Initiated with XX.148.40.117:42335
Thu Nov 04 07:55:16 2010 XX.148.40.117:45483 openvpn_scripts:
(CN=javier/cn=javier) start client-disconnect
Thu Nov  4 07:55:16 2010 javier/XX.148.40.117:42335 TCP/UDP: Closing socket
Thu Nov  4 07:55:16 2010 MULTI: new connection by client 'javier' will cause
previous active sessions by this client to be dropped.  Remember to use the
--duplicate-cn option if you want multiple clients using the same
certificate or username to concurrently connect.
Thu Nov 04 07:55:16 2010 XX.148.40.117:42335 openvpn_scripts:
(CN=javier/cn=javier) start client-connect

openvpn_scripts are the log entries from my custom scripts that setup the
iptables and routes. This is all the expected behavior.

The problem comes when I activate the username-as-common-name option. When
the client reconnects, the client-disconnect script does not get called and
only the client connect script gets called. The username is always blank for
this particular connection and CN. After the reconnection is done, there is
a timeout of the first connection because of the ping-restart option and the
client-disconnect script gets called. Here is the log

Thu Nov  4 08:24:29 2010 XX.148.40.117:39056 TLS: Initial packet from
XX.148.40.117:39056, sid=2b306f61 c6c30e51
Thu Nov  4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=1,
/C=ES/ST=MAD/L=Madrid/O=CS/CN=CS_CA/emailAddress=xx@xxx
Thu Nov  4 08:24:33 2010 XX.148.40.117:39056 VERIFY OK: depth=0,
/C=ES/ST=MAD/L=Madrid/O=CS/CN=javier/emailAddress=xx@xxx
Thu Nov 04 08:24:34 2010 XX.148.40.117:39056 openvpn_scripts:
(CN=javier/cn=javier) start user-pass-verify
Thu Nov  4 08:24:34 2010 XX.148.40.117:39056 TLS: Username/Password
authentication succeeded for username '' [CN SET]
Thu Nov  4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Cipher
'BF-CBC' initialized with 128 bit key
Thu Nov  4 08:24:34 2010 XX.148.40.117:39056 Data Channel Encrypt: Using 160
bit message hash 'SHA1' for HMAC authentication
Thu Nov  4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Cipher
'BF-CBC' initialized with 128 bit key
Thu Nov  4 08:24:34 2010 XX.148.40.117:39056 Data Channel Decrypt: Using 160
bit message hash 'SHA1' for HMAC authentication
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 Control Channel: TLSv1, cipher
TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 [] Peer Connection Initiated
with XX.148.40.117:39056
Thu Nov 04 08:24:35 2010 XX.148.40.117:39056 openvpn_scripts: (CN=javier)
start client-connect
route: SIOCADDRT: File exists
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 OPTIONS IMPORT: reading client
specific options from: /tmp//openvpn_cc_9448a5143bd3e6786d2b8060da752fe5.tmp
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.1.16.18 ->
XX.148.40.117:39056
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 MULTI: primary virtual IP for
XX.148.40.117:39056: 10.1.16.18
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 MULTI: internal route
10.2.0.0/16 -> XX.148.40.117:39056
Thu Nov  4 08:24:35 2010 XX.148.40.117:39056 MULTI: Learn: 10.2.0.0/16 ->
XX.148.40.117:39056
Thu Nov  4 08:24:37 2010 XX.148.40.117:39056 PUSH: Received control message:
'PUSH_REQUEST'
Thu Nov  4 08:24:37 2010 XX.148.40.117:39056 SENT CONTROL [UNDEF]:
'PUSH_REPLY,route 10.1.16.1,topology net30,ping 10,ping-restart 60,route
10.1.0.0 255.255.0.0,ifconfig 10.1.16.18 10.1.16.17' (status=1)
Thu Nov  4 08:24:45 2010 MULTI: Learn: 10.2.0.2 -> XX.148.40.117:39056
Thu Nov  4 08:24:57 2010 XX.148.40.117:46554 [UNDEF] Inactivity timeout
(--ping-restart), restarting
Thu Nov  4 08:24:57 2010 XX.148.40.117:46554 SIGUSR1[soft,ping-restart]
received, client-instance restarting
Thu Nov 04 08:24:57 2010 XX.148.40.117:46554 openvpn_scripts: (CN=javier)
start 

Re: [Openvpn-devel] [Openvpn-users] Variable-Expansion withon *.ovpn files?

[Jan Just Keijser]

Ralf Hildebrandt wrote:

* Jan Just Keijser <janj...@nikhef.nl>:

  

Does openvpn handle Variable-Expansion within its config files?
e.g.pkcs12 %HOMEPATH%\\client.p12
  


  
not that I am aware of and not that I can find in the OpenVPN sources ; 
the word 'getenv' appears nowhere in the sources, suggesting that 
OpenVPN does not look at any environment variables.



OK. It was just an idea, since it would enable users to keep their
certificate in their "own" directories.


  
I like the idea and I think it's fairly trivial to implement. Let's 
enter it as a feature request ...


cheers,

JJK

Re: [Openvpn-devel] Enhancements.

[Jan Just Keijser]

Gert Doering wrote:

Hi,

On Fri, Sep 24, 2010 at 12:01:08PM +0200, Jan Just Keijser wrote:
  

3385 #ifdef ENABLE_PUSH_PEER_INFO


[..]
  
just toyed with it for about an hour or so and I can't get it to work - 
I even ran

  openvpn --cipher none --auth none
to see if I could see the IV_ and UV_ variables fly over the wire and I 
don't even see that.



Are you sure it has been compiled in?  The code block is #ifdef'ed...

(Yes, this sounds like a dumb question, but sometimes we overlook the
obvious)
  


OK, just toyed with it a little bit more:

- yes the code is compiled in (there's a #define in syshead.h)
- yes the IV_ lines are sent over the wire if you specify --push-peer-info
- but no the server never does anything with it  (in key_method_2_read 
the buffer is emptied out after reading the username and password; the 
IV_/UV_ part comes after that)


so it definitely looks like a "work in progress" ...


cheers,

JJK



smime.p7s
Description: S/MIME Cryptographic Signature

[Openvpn-devel] openvpn 2.2 --x509-username-field

[Jan Just Keijser]

hi all,

I was just playing with the new 2.2 option
 --x509-username-field 
why is the field "uppercased" ? There are quite a few X509 fields that 
are case sensitive:

 emailAddress
 name
 dnQualifier
etc (all from /usr/include/openssl/objects.h)

It should also be noted that only the objects listed in the objects.h 
file can be added to the subject string  - simply doing something like

 /NAME=blah
will not be grokked by openssl.

cheers,

JJK





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Openvpn-devel] With route-noexec openvpn still adds routes automatically

[Jan Just Keijser]

Ansis Atteka wrote:

Hello,

I have OpenVPN configuration where I want to add all routes from up.sh 
and down.sh scripts manually. My setup also has route-noexec option in 
config file, so according to man pages I would expect that OpenVPN 
should not add any routes on its own:


/   --route-noexec
  Don't add or remove routes automatically.  Instead  
pass  routes

  to --route-up script using environmental variables.
/
But it turns out that with topology P2P it still adds a route when 
setting up TUN with ifconfig command for pointopoint mode.



My questions are:
1. Is it by design that OpenVPN still adds routes automatically with 
topology p2p and route-noexec set? I guess that openvpn has limited 
visibility over what ifconfig command does, so maybe this is the reason...
2. Should one use topology Subnet instead of P2P in such cases, to get 
pure control over what routes are being added?




alternatively you could use
 ifconfig-noexec
and write a script which brings up the tun interface for you - in that 
case you're solely responsible for bringing up the interface in the 
right manner and for adding or not adding any routes.


HTH,

JJK

Re: [Openvpn-devel] openvpn, NTLM and McAfee Web Gateway

[Jan Just Keijser]

openvpn wrote:

dear all,

a few days ago I deployed an ovpn solution in a medium sized company. 
One of the two ends of the vpn network is passing through a proxy with 
NTLM authentication. ovpn has problems to recognize the authentication 
because immediately after sending the message type 1, the proxy sends 
no response, so I had to modify the source code by replacing the 
current message with a similar but different one.


in particular this one:

TlRMTVNTUAABAgIAAA==


become:

TlRMTVNTUAABB4IIogAFASgKDw==


A detail of the work is available at:

http://www.morzello.com/?p=350 (in Italian).

I was wondering if you could have a function that supports this type 
of proxy (such as McAfee Web Gateway).


I applied your "patch" and I still cannot get it to work for my 
httpd+mod_ntlm (NTLMv1 only) installation. The NTLM handshake that 
OpenVPN does is broken. Without the patch Wireshark tells me the first 
NTLMSPP message is invalid

 http://www.nikhef.nl/~janjust/openvpn/openvpn-ntlm-error1.png
If I change the phase_1 NTLM message to the above I get one step further 
but then it breaks at the next packet:

 http://www.nikhef.nl/~janjust/openvpn/openvpn-ntlm-error2.png
It seems the Windows domain and username are not stored properly inside 
the request. The same httpd+mod_ntlm installation works flawlessly using 
Internet Explorer 7: in that case the domain and user name are encoded 
just fine.


What am I doing wrong?

cheers,

JJK

Re: [Openvpn-devel] [Openvpn-users] TAP installation Problem (2.1.3) on Windows 2000

[Jan Just Keijser]

Hi Gert (and David),

Gert Doering wrote:

Hi,

On Thu, Oct 07, 2010 at 05:47:40PM +0200, Gert Doering wrote:
  

On Thu, Oct 07, 2010 at 05:28:13PM +0200, Jan Just Keijser wrote:


WHy is that?


it's a (minor) mistake in how openvpn 2.1.3 is packaged:
  
This is not a mistake (as in "oops, we didn't know"), but was unavoidable 
since the latest WDK is needed to properly support signed drivers for 
Win7, and that version does not support Win2k anymore.


OTOH, there *should* be a Windows 2000 install.exe, but right now 
I cannot find it on the download page either - James did build it,
with the old WDK/DDK, but somewhere in the release process it must 
have fallen through the cracks.



David found it:

http://secure.openvpn.net/win/openvpn-2.1.3-install.exe (XP to 7)
http://secure.openvpn.net/win/openvpn-2.1.3-install-win2k.exe   (w2k)

  


thanks for sorting this out so quickly! I did not know that version 
still existed (and I'm an old-fashioned wk2 user ;-))


cheers,

JJK

Re: [Openvpn-devel] [Openvpn-users] TAP installation Problem (2.1.3) on Windows 2000

[Jan Just Keijser]

Ralf Hildebrandt wrote:
During installation, no TAP32 adapter is being installed and the 
addtap.bat returns an error:


d:\program files\openvpn\bin\tapinstall.exe is not a valid Win32 application.

WHy is that?

  

it's a (minor) mistake in how openvpn 2.1.3 is packaged:

openvpn 2.1.1 comes with tapinstall.exe v6.0.6001.18000, named 'Windows 
Codename Longhorn DDK driver'
openvpn 2.1.3 comes with tapinstall.exe v6.1.7600.16385, named 'Windows 
Win 7 DDK provider'


Apparently this later version of tapinstall.exe is not recognized as a 
valid win32 application, most likely because Microsoft stopped 
supporting Windows 2000 some time ago. Note that OpenVPN 2.2 will also 
no longer include Windows 2000 support, as was discussed somewhere late 
august.


The nice fix would be to include the older version of tapinstall.exe in 
an update of the windows installer package. A quick hack is to 
copy over the tapinstall.exe from the 2.1.1 installer and then run 
'tapinstall' again (from the OpenVPN menu option in the 'Start' menu)



HTH,

JJK

Re: [Openvpn-devel] HTTP/1.1 Host header

[Jan Just Keijser]

Lars Hupel wrote:

I'm not sure if I understand the question ; openvpn already has the
option to use http/1.1 headers using
 --http-proxy-option VERSION 1.1
which should send HTTP/1.1 type messages - doesn't that work?



The problem is that (at least Apache) rejects these requests because the
Host header is missing, so I get "Bad Request" responses.

Additionally, without Host header it's impossible to use Apache's
VirtualHost facility.

Regards
Lars

  
ah right, now I see... hmmm 'Host: ...' headers should not be required 
by a web server and with apache's Virtual Hosts you can override this using


   
   DocumentRoot /www/default1234
   ...
   

   
   DocumentRoot /www/default80
   ...
   

etc but this seems like an easy patch. Perhaps someone else on the -devel list 
can comment on why it was not accepted...

cheers,

JJK

Re: [Openvpn-devel] HTTP/1.1 Host header

[Jan Just Keijser]

Lars Hupel wrote:

Hi,

as the subject states, I would like that OpenVPN sends an appropriate
Host header, because my server configuration relies on Apache's
VirtualHosts. Because OpenVPN doesn't send this header, I patched it
myself. Recently, I found the discussion on openvpn-devel from 10/2008
(subject was "enhance compatibility with HTTP/1.1 proxies", from Frank
Behrens) about a very similar patch. However, I was not able to extract
from that discussion why the patch was rejected (or simply ignored?).
Are there any objections to accept the patch?

  
I'm not sure if I understand the question ; openvpn already has the 
option to use http/1.1 headers using

 --http-proxy-option VERSION 1.1
which should send HTTP/1.1 type messages - doesn't that work?

HTH,

JJK

Re: [Openvpn-devel] Enhancements.

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/10 09:15, Jan Just Keijser wrote:
  

Yo all,


[...snip...]
  

I was just browsing through the 2.1.3 source tree and found this in ssl.c:

3379 static bool
3380 push_peer_info(struct buffer *buf, struct tls_session *session)
3381 {
3382   struct gc_arena gc = gc_new ();
3383   bool ret = false;
3384
3385 #ifdef ENABLE_PUSH_PEER_INFO
3386   if (session->opt->push_peer_info) /* write peer info */
3387 {
3388   struct env_set *es = session->opt->es;
3389   struct env_item *e;
3390   struct buffer out = alloc_buf_gc (512*3, );
3391
3392   /* push version */
3393   buf_printf (, "IV_VER=%s\n", PACKAGE_VERSION);
3394
3395   /* push platform */
3396 #if defined(TARGET_LINUX)
3397   buf_printf (, "IV_PLAT=linux\n");
3398 #elif defined(TARGET_SOLARIS)


this gets called if --push-peer-info is specified . This seems to be new
for 2.1.3 - has anyone tested it?



Good catch ... this is the commit which introduces it.  (SVN r5668)
You're right, this is in 2.1.2/2.1.3

commit aaf72974672e4f2af2053247b63ef6f06bdc80c0
Author: James Yonan <ja...@openvpn.net>
Date:   Tue Jun 1 07:12:27 2010 +

Implemented a key/value auth channel from client to server.

Version 2.1.1i


git-svn-id:
http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@5668
e7ae566f-a301-0410-adde-c780ea21d3b5



  And according to our normal procedure, this is of course not
  documented in the man page.


Thanks, JJK for catching this!  I don't think many have tested it -
except James.  So if you wouldn't mind testing it out and maybe shed
some knowledge about it, that would be great!
  
just toyed with it for about an hour or so and I can't get it to work - 
I even ran

 openvpn --cipher none --auth none
to see if I could see the IV_ and UV_ variables fly over the wire and I 
don't even see that.


Looks like this is still under development, but it is a nice starting 
point for implementing this enhancement (I'd go for a full negotiation 
step).


share and enjoy,

JJK

Re: [Openvpn-devel] Enhancements.

[Jan Just Keijser]

Yo all,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/09/10 13:37, Gert Doering wrote:
  

Hi,

On Tue, Sep 14, 2010 at 11:10:28AM +0200, Jan Just Keijser wrote:


 if (buf_string_match_head_str (, "AUTH_FAILED"))
   receive_auth_failed (c, );
 else if (buf_string_match_head_str (, "PUSH_"))
   incoming_push_message (c, );
 else if (buf_string_match_head_str (, "RESTART"))
   server_pushed_restart (c, );
 else
   msg (D_PUSH_ERRORS, "WARNING: Received unknown control 
   message: %s",

BSTR ());

is the control message stage early enough? that means authentication has 
been completed, and the client_connect script has been run (or am I 
mistaken? 
  

I'm not absolutely sure at what time these messages can be sent.  But
most likely you're right, you want this before running client-connect.

Someone around who fully understands the session flow...?




Taken completely from memory, the PUSH_REQ phase comes in _after_ the
authentication process.  But, I also believe it comes after
OPENVPN_PLUGIN_CLIENT_CONNECT phase, as that plug-in hook can push
config settings to the client dynamically.  And of the
OPENVPN_PLUGIN_CLIENT_CONNECT hook sends a rejection, the connection is
dropped.

Unless somebody else chimes in before I've been able to double check it,
I'll do some more checks here.


  

I was just browsing through the 2.1.3 source tree and found this in ssl.c:

3379 static bool
3380 push_peer_info(struct buffer *buf, struct tls_session *session)
3381 {
3382   struct gc_arena gc = gc_new ();
3383   bool ret = false;
3384
3385 #ifdef ENABLE_PUSH_PEER_INFO
3386   if (session->opt->push_peer_info) /* write peer info */
3387 {
3388   struct env_set *es = session->opt->es;
3389   struct env_item *e;
3390   struct buffer out = alloc_buf_gc (512*3, );
3391
3392   /* push version */
3393   buf_printf (, "IV_VER=%s\n", PACKAGE_VERSION);
3394
3395   /* push platform */
3396 #if defined(TARGET_LINUX)
3397   buf_printf (, "IV_PLAT=linux\n");
3398 #elif defined(TARGET_SOLARIS)


this gets called if --push-peer-info is specified . This seems to be new 
for 2.1.3 - has anyone tested it?


cheers,

JJK

Re: [Openvpn-devel] proper "logout" support for the server?

[Jan Just Keijser]

Jason Haar wrote:

 Hi there

Minor feature request. When a user ends their openvpn client session,
shouldn't it be possible to send one last command to the server - a
"logout" command? That way the server can clean up the session much
faster than waiting for a keepalive timeout cycle...

(the problem I see is that we make extensive use of "--up"/etc scripts
and a user can sometimes do several "up->down->up" in a row - which
leads to "flapping" checks. If the server was told the client was
leaving, this would reduce these issues).

  

it's already available:
 --explicit-exit-notify
this is needed only for UDP based connections, as the server will know 
when a TCP connection has ended.


HTH,

JJK

[Openvpn-devel] comp-lzo & push "comp-lzo"

[Jan Just Keijser]

hi all,

just noticed something odd with openvpn 2.1 (.1 & .3):

in the server config I specify
 comp-lzo
 push "comp-lzo"

if the client config has does NOT have a line
 comp-lzo
then this "push" is not picked up by the client. If the client has a line
 comp-lzo no
(or 'yes' or 'adaptive' ) then the pushed value DOES get picked up by 
the client.


Seems like an initialization error in init.c: it only initializes the 
LZO libs if a parameter was specified:


3179 #ifdef USE_LZO
3180   /* initialize LZO compression library. */
3181   if ((options->lzo & LZO_SELECTED) && (c->mode == CM_P2P || child))
3182 lzo_compress_init (>c2.lzo_compwork, options->lzo);
3183 #endif

(lzo_compress_init sets a flag which causes the macro lzo_defined() to 
return true).
When the PUSH message is received from the server it does contain the 
'comp-lzo' statement but it is not processed by init.c:


1580 #ifdef USE_LZO
1581   if (found & OPT_P_COMP)
1582 {
1583   if (lzo_defined (>c2.lzo_compwork))
1584 {
1585   msg (D_PUSH, "OPTIONS IMPORT: LZO parms modified");
1586   lzo_modify_flags (>c2.lzo_compwork, c->options.lzo);
1587 }
1588 }
1589 #endif

so if you want the client to automagically pick up the right 'comp-lzo' 
setting from the server, specify

 comp-lzo no
in the client config - that way , the server can always overrule it 
using the appropriate 'push' directive.


cheers,

JJK

Re: [Openvpn-devel] Enhancements.

[Jan Just Keijser]

Hi,

Gert Doering wrote:

Hi,

On Tue, Sep 14, 2010 at 09:58:19AM +1200, Jason Haar wrote:
  

 On 09/14/2010 08:52 AM, Brad Dameron wrote:


Also can there be reporting added for the server side to show what
version the client is connecting with?
  

I agree. I have previously asked for client version and OS to be
"pushed" during the initial phase so that the server can be decisions
based on it. 



As far as I understand the code (check_incoming_control_channel_dowork()
in forward.c) this should be doable without breaking compatibility to
older servers - new control messages can be added, and a server that
does not understand them will just log a warning:

...
  if (buf_string_match_head_str (, "AUTH_FAILED"))
receive_auth_failed (c, );
  else if (buf_string_match_head_str (, "PUSH_"))
incoming_push_message (c, );
  else if (buf_string_match_head_str (, "RESTART"))
server_pushed_restart (c, );
  else
msg (D_PUSH_ERRORS, "WARNING: Received unknown control message: %s",
 BSTR ());


  
is the control message stage early enough? that means authentication has 
been completed, and the client_connect script has been run (or am I 
mistaken? please correct me if I am wrong). I could foresee that an 
administrator wants to specify a different client_connect script 
depending on the client version, or that an administrator wants to not 
even allow access by older clients (e.g. at the tls-verify level)


JM2CW,

JJK

So...

 - someone needs to specify the control message

 - someone needs to implement sending it on the client side

 - someone needs to think about the planned-usage on the server side
   (present at management interface? put into environment for scripts/
   plugins?  if yes, structured environment variables or just one big
   "lump" with whatever the client puts in there?)

 - someone needs to implement parsing the control message on the server
   side and distribute the resulting information to server-side config
   structures and to plugins/scripts

 - someone else needs to review and ACK.


I'm fairly busy with the IPv6 stuff (and with earning a living), so I won't
implement this, but I'm happy to help with it - bounce ideas around, 
discuss in #openvpn-devel on irc.freenode.net, etc.


gert
  



  

[Openvpn-devel] shaper broken in openvpn 2.1.1 linux clients?

[Jan Just Keijser]

hi all,

is the option
 shaper 10
broken in openvpn 2.1.1 on linux? If I add this option to a client 
config I get very erratic behaviour when running iperf:

- performance is absolute crap
- after iperf has finished the link remain active doing something but is 
not responding; after about 20 seconds I can ping the remote end again.


Same host, same client, different openvpn version (2.0.9) and I get 
exactly the behaviour that I expected ie

 shaper 10
gives me 100 KB/s upload speed using iperf.

thanks for any input,

JJK

Re: [Openvpn-devel] My results of OpenVPN Benchmarking

[Jan Just Keijser]

Hi Ansis,

Ansis Atteka wrote:

Hi Jan,

2. The reason for tun0 TX packets being dropped seems more like a Tun 
queue thing. I would guess that OpenVPN does not poll frequently 
enough for incoming packets from TUN device. I am wondering if anyone 
else was able to connect with >1000 clients to a single VPN server



try increasing the txqueuelen:
 --txqueuelen 1000

(default is 100)

HTH,

JJK


4. lsof shows mostly sockets to the clients (almost all are in 
Established state).


Ansis




On Tue, Aug 31, 2010 at 3:16 AM, Jan Just Keijser <janj...@nikhef.nl 
<mailto:janj...@nikhef.nl>> wrote:


Hi Ansis,

very interesting results, it's been on my TODO list to do some
extensive benchmarking for some time, especially in a 1 Gbps and
10 Gbps network environment. See some comments below


Ansis Atteka wrote:

Hello

I have done some benchmarking of OpenVPN and wanted to share
my numbers and also ask some questions. Here is a table that
shows how OpenVPN scales. I ran up to 4 instances of OpenVPN
servers simulatenously with different ciphers:


 ICMP test (MiByes/s)

*Cipher\OpenVPNs instances*

   


*1*

   


*2*

   


*3*

   


*4*

*BF-CBC*

   


35

   


65

   


84

   


96

*AES-128-CBC*

   


45

   


80

   


94

   


96(lower CPU)

*AES-256-CBC*

   


40

   


76

   


96

   


96(low CPU)


Total of 800 tunnels were established in each test. Each
tunnel was utilized with following ping command: "ping -I tunX
-s 800 -i 0.003 ". Lower CPU indicates that CPU
usage was lower than in other tests.

Deployment was as follows:

1. Server (Intel Xeon E5530 6GB of RAM with two 1GBit NICs;
Ubuntu 10.04) connected directly with two clients (without a
switch, so that total throughput could be 2Gbits)

2. Client1 (Q6600) runs half of the OpenVPN client instances

3. Client2 (Intel Xeon E5530) runs the other half of OpenVPN
instances.


Questions:

1. Why single OpenVPN server instance never consumes more than
85% of a CPU core in the System Monitor? Is this related to
ep_pool() call that has a minimum wait interval and OpenVPN
does not do anything at that time?
2. During the ping test on the server I observed that incoming
traffic (ping requests) pushed out outgoing traffic (ping
responses). The incoming and outgoing traffic should be equal,
but this does not hold true in a load test. Any explanation
why that happened? Maybe because ICMP is unreliable protocol
and datagrams(responses) were dropped?

this depends on your openvpn setup ; was compression enabled (it
is by default) ? what kind of encryption was used? was
'keep-alive' used at all (this adds extra traffic) ?


3. Have anyone tried to run OpenVPN on a newer CPU that has
AES-NI instruction set (e.g. Xeon E56XX series)? I would like
to know what would be the bandwidth benefit when AES is chosen
as the data Tunnel Cipher?

openvpn is based on openssl; if openssl supports the AES-NI
instructions then openvpn can use it as well. I've downloaded a
patch for openssl 1.0.0 to support the AES-NI instruction set
(engine 'aesni' ) and tried on a machine which supports these
instructions but found no speed up at all ('openssl speed was
actually SLOWER). The guy who wrote the patch still has to get
back to me on that ...


4. During a OpenVPN 1200 client bomb test I observed that
OpenVPN stalled with 100% CPU. In the openvpn log I saw that
there are too many opened files (output of "ls /proc/PID/fd |
wc -l" showed that there were 1027 opened files). The bad
thing is that killing all those 1200 clients did not help the
OpenVPN server to recover and it remained in stall state. It
looks like a bug for me.

sounds like it ; what does 'lsof' report? what files were opened
and never closed?



Are there any tools which are already developed and would help
in benchmarking multiple OpenVPN clients/servers?

nothing that I know of - if you find any, please let me know :)

cheers,

JJK

Re: [Openvpn-devel] Netmask OpenVPN Server

[Jan Just Keijser]

Hi Eike,

Eike Lohmann wrote:

We are working with static assignments and if the 2 networks are side by
side I can recompile the code and define a larger mask.
Is this also working if I have 2 networks far away from each other (10.x
and 192.168.x), with defining a 'all your base belong to us' netmask in
the code e.g. 0.0.0.0 :)

We don't have client-2-client and didn't use the ifconfig-pool.


  
if you're not using ifconfig-pool then you can do this without 
recompiling anything; use a 'learn-addr' script or 'client-connect' 
script to assign addresses and do NOT use the 'server' statement (see my 
previous posting).


cheers,

JJK


Am 01.09.2010 10:22, schrieb Gert Doering:
  

Well, this really depends on what you want to do with it.  If you want
to do static assignments (ifconfig-push in ccd/ or via radius-plugin),
this can be done today.  If you want the ifconfig-pool to span two 
different networks, this can not be done today - there can only be one 
pool, and it must be contiguous.
  

Re: [Openvpn-devel] Netmask OpenVPN Server

[Jan Just Keijser]

Gert Doering wrote:

Hi,

On Tue, Aug 31, 2010 at 12:35:03PM +0200, Eike Lohmann wrote:
  

In the past only /16 networks were possibel per openvpn instance.
Is it now possibel to define larger networks or define 2x /16 networks 
on one openvpn instance?



I assume that you're talking about this error message:

  --server directive netmask allows for too many host addresses (subnet must be 
%s or higher)

right?  If yes, it should work to change 


#define IFCONFIG_POOL_MIN_NETBITS16

in pool.h to "14" (etc) and recompile - every extra bit will double
memory consumption [for the pool handling, of I remember right], so 
use with care.


(You really have more than 16000 users on a single OpenVPN instance? 
Wow, I'm impressed!)
  
alternatively, if you have fewer than 16000 users but want to have a 
very large network anyways then don't use 'server 10.192.0.0 
255.240.0.0' but try something like


ifconfig 10.192.0.1 10.192.0.2
ifconfig-pool 10.192.100.100 10.192.100.192
route 10.192.0.0 255.240.0.0
push "route 10.192.0.1"  # if client-to-client is not used
push "route 10.192.0.0 255.240.0.0"  # this is used for client-to-client

this sets up the network 10.192.0.0/12 but allocates a much smaller pool 
for the clients inside this network.



HTH,

JJK

Re: [Openvpn-devel] My results of OpenVPN Benchmarking

[Jan Just Keijser]

Hi Ansis,

very interesting results, it's been on my TODO list to do some extensive 
benchmarking for some time, especially in a 1 Gbps and 10 Gbps network 
environment. See some comments below


Ansis Atteka wrote:

Hello

I have done some benchmarking of OpenVPN and wanted to share my 
numbers and also ask some questions. Here is a table that shows how 
OpenVPN scales. I ran up to 4 instances of OpenVPN servers 
simulatenously with different ciphers:



  ICMP test (MiByes/s)

*Cipher\OpenVPNs instances*



*1*



*2*



*3*



*4*

*BF-CBC*



35



65



84



96

*AES-128-CBC*



45



80



94



96(lower CPU)

*AES-256-CBC*



40



76



96



96(low CPU)


Total of 800 tunnels were established in each test. Each tunnel was 
utilized with following ping command: "ping -I tunX -s 800 -i 0.003 
". Lower CPU indicates that CPU usage was lower than in 
other tests.


Deployment was as follows:

1. Server (Intel Xeon E5530 6GB of RAM with two 1GBit NICs; Ubuntu 
10.04) connected directly with two clients (without a switch, so that 
total throughput could be 2Gbits)


2. Client1 (Q6600) runs half of the OpenVPN client instances

3. Client2 (Intel Xeon E5530) runs the other half of OpenVPN instances.


Questions:

1. Why single OpenVPN server instance never consumes more than 85% of 
a CPU core in the System Monitor? Is this related to ep_pool() call 
that has a minimum wait interval and OpenVPN does not do anything at 
that time?
2. During the ping test on the server I observed that incoming traffic 
(ping requests) pushed out outgoing traffic (ping responses). The 
incoming and outgoing traffic should be equal, but this does not hold 
true in a load test. Any explanation why that happened? Maybe because 
ICMP is unreliable protocol and datagrams(responses) were dropped?
this depends on your openvpn setup ; was compression enabled (it is by 
default) ? what kind of encryption was used? was 'keep-alive' used at 
all (this adds extra traffic) ?


3. Have anyone tried to run OpenVPN on a newer CPU that has AES-NI 
instruction set (e.g. Xeon E56XX series)? I would like to know what 
would be the bandwidth benefit when AES is chosen as the data Tunnel 
Cipher?
openvpn is based on openssl; if openssl supports the AES-NI instructions 
then openvpn can use it as well. I've downloaded a patch for openssl 
1.0.0 to support the AES-NI instruction set (engine 'aesni' ) and tried 
on a machine which supports these instructions but found no speed up at 
all ('openssl speed was actually SLOWER). The guy who wrote the patch 
still has to get back to me on that ...


4. During a OpenVPN 1200 client bomb test I observed that OpenVPN 
stalled with 100% CPU. In the openvpn log I saw that there are too 
many opened files (output of "ls /proc/PID/fd | wc -l" showed that 
there were 1027 opened files). The bad thing is that killing all those 
1200 clients did not help the OpenVPN server to recover and it 
remained in stall state. It looks like a bug for me.


sounds like it ; what does 'lsof' report? what files were opened and 
never closed?



Are there any tools which are already developed and would help in 
benchmarking multiple OpenVPN clients/servers?

nothing that I know of - if you find any, please let me know :)

cheers,

JJK

Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS

[Jan Just Keijser]

Hi Martin,

the '0' and '1' are direction parameters for the ta.key file. I actually 
made a mistake when I posted

 ta.key 0
for both client and server - that will never work. Either omit the 
parameter or use 0 on the server and 1 on the client.


For the error that you are seeing the ta.key file is irrelevant, 
however. You can verify this by removing the 'tls-auth' line. You should 
still get the exact same error.


Can you increase the verbosity on the server when connecting? It's the

VERIFY ERROR: depth=0, error=unsupported certificate purpose: 
/C=NL/O=Test/CN=glaurung/emailAddress=janj...@x.nl

error which is troubling: it could be that Gentoo did something to the 
openssl libs to cause this. Also, what happens if you type


openssl x509 -text -noout -in client.crt

and look for the X509v3 extensions? The certificate purposes should be 
listed. If I do this with the client.crt file I sent you I get


   X509v3 extensions:
   X509v3 Basic Constraints:
   CA:FALSE
   Netscape Comment:
   Easy-RSA Generated Certificate
   X509v3 Subject Key Identifier:
   96:58:6A:E5:E0:D5:70:3C:A5:4D:67:08:40:33:45:E6:E4:44:79:EF
   X509v3 Authority Key Identifier:

keyid:E2:52:EE:0F:91:54:A4:7A:FB:2E:45:A8:9A:13:16:EE:FA:20:21:F8
   DirName:/C=NL/O=Test/CN=Test CA/xxx
   serial:DF:DD:C7:62:11:B9:F9:58

   X509v3 Extended Key Usage:
   TLS Web Client Authentication
   X509v3 Key Usage:
   Digital Signature

does the gentoo openssl command report something different?

HTH,

JJK

Martin Mokrejs wrote:

Hi,
  I am re-sending my answer from June 22 to this thread: 
http://thread.gmane.org/gmane.network.openvpn.devel/3703
It must have somehow fallen deeply in your email boxes. ;-) The text below show 
that the two certificates Jan
Just Keijser generated the days before could not be used on my Gentoo box. 
Clearly, the problem is with Gentoo
install/my binaries and has nothing to do with the key and certificate creation.
Thanks,
Martin

--
Hi everybody,
  so I tested the keys which Jan generated and did reproduce the problem again
on my Gentoo Linux build. It is related to the fact that I had on client:

tls-auth /home/janjust/rsa-test/ta.key 1

while on the server

tls-auth /home/janjust/rsa-test/ta.key 0 


Jun 22 23:24:18 vrapenec openvpn[21646]: OpenVPN 2.1.0 i686-pc-linux-gnu [SSL] 
[LZO2] [EPOLL] built on May 17 2010
Jun 22 23:24:18 vrapenec openvpn[21646]: NOTE: OpenVPN 2.1 requires 
'--script-security 2' or higher to call user-defined scripts or executables
Jun 22 23:24:18 vrapenec openvpn[21646]: Control Channel Authentication: using 
'keys/ta.key' as a OpenVPN static key file
Jun 22 23:24:18 vrapenec openvpn[21646]: Outgoing Control Channel 
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:24:18 vrapenec openvpn[21646]: Incoming Control Channel 
Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jun 22 23:24:18 vrapenec openvpn[21646]: LZO compression initialized
Jun 22 23:24:18 vrapenec openvpn[21646]: Control Channel MTU parms [ L:1542 
D:166 EF:66 EB:0 ET:0 EL:0 ]
Jun 22 23:24:18 vrapenec openvpn[21646]: Data Channel MTU parms [ L:1542 D:1450 
EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Jun 22 23:24:18 vrapenec openvpn[21646]: Local Options hash (VER=V4): '504e774e'
Jun 22 23:24:18 vrapenec openvpn[21646]: Expected Remote Options hash (VER=V4): 
'14168603'
Jun 22 23:24:18 vrapenec openvpn[21647]: NOTE: UID/GID downgrade will be 
delayed because of --client, --pull, or --up-delay
Jun 22 23:24:18 vrapenec openvpn[21647]: Socket Buffers: R=[108544->131072] 
S=[108544->131072]
Jun 22 23:24:18 vrapenec openvpn[21647]: UDPv4 link local: [undef]
Jun 22 23:24:18 vrapenec openvpn[21647]: UDPv4 link remote: XXX.XXX.XXX.XXX:1194
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS: Initial packet from 
XXX.XXX.XXX.XXX:1194, sid=2f11657e e78d6a4f
Jun 22 23:24:18 vrapenec openvpn[21647]: VERIFY ERROR: depth=0, 
error=unsupported certificate purpose: 
/C=NL/O=Test/CN=glaurung/emailAddress=janj...@x.nl
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS_ERROR: BIO read tls_read_plaintext 
error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate 
verify failed
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS Error: TLS object -> incoming 
plaintext read error
Jun 22 23:24:18 vrapenec openvpn[21647]: TLS Error: TLS handshake failed
Jun 22 23:24:18 vrapenec openvpn[21647]: TCP/UDP: Closing socket
Jun 22 23:24:18 vrapenec openvpn[21647]: SIGUSR1[soft,tls-error] received, 
process restarting
Jun 22 23:24:18 vrapenec openvpn[21647]: Restart pause, 2 second(s)
Jun 22 23:24:20 vrapenec openvpn[21647]: NOTE: OpenVPN 2.1 requires 
'--script-security 2' or higher to call user-defined scripts or executables
Jun 22 23:24:20 vrapenec openvpn[21647]: Re-using SSL/TLS context
Jun 22 23:24:20 vrapenec openvpn[21647]: LZO co

Re: [Openvpn-devel] [Openvpn-users] Problem with installation on Windows7 (64bit)

[Jan Just Keijser]

Hi Ralf,

Ralf Hildebrandt wrote:

After installation of openvpn-2.1.1, I was able to start openvpn-gui as
NORMAL user (not admin). No problems there.

But in order to actually *use* openvpn, I have to start openvpn-gui via
"run as admin". When I would do that, openvpn gui would report:

CreateProcess failed, exe='C:\Program Files\OpenVPN\bin\openvpn.exe'
cmdline='openvpn --version' dir='c:\Program Files\OpenVPN\bin'

Alas, this path does indeed not exist, since OpenVPN installed itself
into:

C:\Program Files (x86)\OpenVPN
not
C:\Program Files\OpenVPN

so I deinstalled everything and during reinstallation I overrode the
default installation path to:

C:\Program Files\OpenVPN

and after that it would work, even when run as admin. 


What's wrong here? Why does it choose C:\Program Files (x86)\OpenVPN
during installation but expects C:\Program Files\OpenVPN during runtime?

  

see for example

http://www.sevenforums.com/general-discussion/30857-installing-program-files-x86.html

openvpn is a 32bit program using a 64bit driver; the windows 7 installer 
decides to place openvpn in the 32bit folder unless you override this.
I guess the proper solution is to build a 64bit version of openvpn for 
windows Vista/7/2003 64bit
(I'm including the -devel list to see if anybody has any comments about 
that :))


cheers,

JJK

Re: [Openvpn-devel] [Openvpn-users] OpenVPN server listening both on udp and tcp?

[Jan Just Keijser]

Hi Henno,

Henno Täht wrote:

Hello!

2010/7/2 David Sommerseth >


On 02/07/10 19:38, Henno Täht wrote:
> Hello!
>
> Can anyone experienced and helpful scribble a little guide how
to have
> the same OpenVPN server listening both on 1194 UDP (reason: fast,
> preferable) and 443 TCP (reason: always works, fallback)?

That is not possible.  OpenVPN can only listen to TCP or UDP, not
both.
 To do this, you will need two independent OpenVPN configurations and
run two separate OpenVPN daemons

Having that said, this is a common question and a feature which is
under
evaluation for the next generation OpenVPN.


Great news!

A client config file should also support this. Something like this:
remote 198.51.100.15:1194  proto udp wait 10
remote 203.0.113.234:443  proto tcp  wait 1
remote 192.168.0.1:8080->203.0.113.234:443  
proto tcp wait 1


Explanation:
First try direct connection to udp port 1194, wait 10 seconds (should 
be enough to survive OpenVPN server restarts after config change).
If that fails (timeout of 10 seconds is past and no answer), try 
another ip with tcp 443 and wait 1 second for reply (443 tcp is 
usually left open for https).
If that too fails, assume that the user is again visiting NSA-like 
institution but which luckily has a local proxy (which allows only for 
tcp port 80 and 443 connections for that matter).


This is just some thoughts of me how OpenVPN should treat the --remote 
option in the future. 
I'm hoping that someone picks this up to start a discussion.
the client side already supports this (with a drawback): if you read the 
openvpn 2.1 manual page , section 'connection profiles' you'll see



 remote host:1194
 proto udp



 remote host:443
 proto tcp



 remote host:443
 proto tcp
 http-proxy host:port


etc. The drawback is that  you can no longer tweak some settings , such 
as fragment/tcp timeouts etc. This is an open bug which hopefully will 
be addressed in openvpn 2.2 ; the redesign of openvpn to allow multiple 
listeners on the server side is further off.


HTH,

JJK

Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?

[Jan Just Keijser]

Gert Doering wrote:

Hi,

On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:
  
assigns a 169.254 address. If this works for you as well then maybe the 
tap-win32 developers can dive deeper into this and find out why windows 
treats the 'always connected' adapter differently from an 'application 
controlled' adapter .



I'd assume that windows services are not "bound" to "dynamic" interfaces...

  
They're not , as far as I know. 
However,
- the SMBoverIP service binds to 0.0.0.0:445 yet it refuses access from 
IPs other than the 'always connected' ones
- as Henno found out,  disabling and then enabling the "windows file 
sharing" protocol on the TAP-win32 adapter after the connection has been 
established fixes the problem ; I don't know if it is possible to do 
this using some 'netsh' magic, however

- the same thing works on windows 2000, no modifications
- on windows XP and higher it *does* work for PPTP/L2TP+IPsec VPNs


JJK

Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?

[Jan Just Keijser]

Hi Henno,

Henno Täht wrote:

Is it possible to share files from Windows XP using port 445 over
OpenVPN tunnel?

Everything works within the LAN but from the other side of OpenVPN
connection I'm getting "No network provider accepted the given network
path." error while trying to access XP's shares.

Sniffing shows this:
(zeus is the machine trying to access XP's shares)

TimeSourceDestination ProtoInfo
1.718123zeusxpTCP  3285 > 445 [SYN]
Seq=0 Win=64240 Len=0 MSS=1460
1.830665xp  zeus  TCP  445 > 3285 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0
2.189052zeusxpTCP  3285 > 445 [SYN]
Seq=0 Win=64240 Len=0 MSS=1460
2.219486xp  zeus  TCP  445 > 3285 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0
2.735585zeusxpTCP  3285 > 445 [SYN]
Seq=0 Win=64240 Len=0 MSS=1460
2.766907xp  zeus  TCP  445 > 3285 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0

So XP is refusing port 445 connections from OpenVPN adapter. Firewall
is off (otherwise no packet would be sent back).

While NetBIOS over TCP/IP works (port 139), it has been disabled on
zeus and as I understand DirectSMB (microsoft-ds or port 445) should
be more efficient.
  

you're actually not the first person to report this issue...

I can reproduce the behaviour on Windows XP but not on Windows 2000 , 
using the exact same openvpn version and installation configuration.


similar to what you are seeing , I can see in wireshark is that any 
access over port 445 to \\>\ is dropped immediately by windows 
XP, yet on windows 2000 this works flawlessly.


The only thing I can think of is that Windows XP explicitly forbids 
access to port 445 as a countersecurity measure unless it's coming from 
an "official" network card.
It seems like OpenVPN is working as it should, it's just that Windows XP 
(and Vista/7?) does not regard the tap-win32 adapter as an official 
network card and hence does not allow access.


Your best bet is to continue using netbios-over-tcpip for the time being 
(I always disable port 445 anyways) until a Windows kernel guru can tell 
us just what the heck is happening here (where would this be logged? my 
XP firewall is turned off


Maybe someone on the -devel list (CC'ed) knows more about the 
interaction between the tap-win32 adapter and the rest of the windows os?


cheers,

JJK

Re: [Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS

[Jan Just Keijser]

Hi,

Martin Mokrejs wrote:

Hi,

David Sommerseth wrote:
  

On 08/06/10 18:24, Martin Mokrejs wrote:


Hi,
  I had a look into the original bug report I sent and the summary is this:
at some version openvpn implemented a more strict check for certificate
values and if teh cjeck fails one yields "unsupported certificate purpose"
message.
  
  I figured out that few more allowed values have to be included in the

certificate so that openVPN does not complain anymore. Basically, the patch
synchronizes the current openVPN behavior with the easy-rsa/ tools.
  
  Is it clearer now? I attached to the bugreport at Gentoo an older version

of the patch to hopefully help you better with understanding what I tried.
What I believe should happen that somebody documents better what requirements
are for the server/client certifices in openVPN. The patch(es) show what
fields you should describe in docs and some version of the patch be committed
over easy-rsa/openssl.cf as well (or loosen the checks back in openVPN sources).
Martin
  

Ahoj Martin,

Thanks a lot for your patch and your investigations!  That is very much
appreciated!

Your issues was discussed in the last developers meeting (Thu June 3rd)
and it is not clear to us why you experiences this problem.  I believe
Jan Just Keiser told that he had quite recently tested out easy-rsa-2.0
and he had no issues at all.

I am also running a OpenVPN server on a Gentoo box, even though on this
box I'm using TinyCA, so it is not directly comparable.  Anyhow, the
X509v3 extensions are not that far away from what I do see easy-rsa-2.0
should normally set:

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME, Object Signing

I do see however that you are having mentioned Netscape Cert Type in
your bug report.

Could this be related to some trickery patches Gentoo does to OpenVPN or
OpenSSL?  Or that it is related to the OpenSSL version?



I have no idea what is patched on Gentoo and why, but I found lots of those
"unsupported certificate purpose" reports through Google, with very few real
answers. I don't believe it is Gentoo specific.


On the client:
I use net-misc/openvpn-2.1.0-r1, I see there are two patches applying to
my systems (no IPv6 patch):
epatch "${FILESDIR}/${PN}-2.1_rc13-peercred.patch"
epatch "${FILESDIR}/${PN}-2.1_rc20-pkcs11.patch"
I use dev-libs/openssl-0.9.8n.

On the server:
net-misc/openvpn-2.1.0-r1
dev-libs/openssl-0.9.8n


  

Would you mind sharing your configuration files and information about
the OpenSSL version you are using?



The client and server configs are attached.


  

here's what I just did:

- downloaded openssl 0.9.8n
- ran
 ./config shared
 make
on it
- reconfigured openvpn 2.1.1 to make use of this version of openssl
- ran
 ./configure ...
 make clean
 make
on it

- set up a new CA + server cert + client server using umodified easy-rsa 
2.0 scripts from the openvpn distro

- set up client and server config files pretty much like the ones attached

Result: Both server and client start without problems. I can even add
 remote-cert-tls client
to the server config and the thing still starts. In other words: I 
cannot reproduce the bug.


When I took a closer look at the original Ubuntu bug report it suggests 
that the original server cert was not built correctly:


May 17 14:33:20 vrapenec openvpn[21477]: ++ Certificate has key usage  0080,
expects 00a0
May 17 14:33:20 vrapenec openvpn[21477]: ++ Certificate has key usage  0080,
expects 0088
May 17 14:33:20 vrapenec openvpn[21477]: VERIFY KU ERROR

the key usage found (0080) is for a *client* certificate, not a server certificate. 
The server certificate should eku '00a0' set, as the log file later on in the bug report

shows.

Martin, can you
- use the stock easy-rsa scripts (i.e. not the ones from ubuntu)
- create a new CA and client server and server cert (build-ca, build-key 
, build-key-server)

- rerun your test

If this still fails then Ubuntu may have added a patch that broke something.

cheers,

JJK





Hi,

We discussed your bug report in last week's public IRC meeting:



In a nutshell, we had difficulties understanding what is required to
reproduce this bug. Unfortunately the discussion logs were lost so I
can't be any more specific. Would you like help us understand this issue
by chatting with our devs on #openvpn-de...@irc.freenode.net? Or
alternatively by sending mail to openvpn-devel mailinglist:



All the best,

-- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Martin Mokrejs wrote:


Hi,
  I think the easy-rsa/openssl.cnf file should be modified so thet client
CERTs would match current openVPN expectations. Please see my bug report
at 

Re: [Openvpn-devel] [PATCH-fixed] revocation

[Jan Just Keijser]

Davide Brini wrote:

On Thursday 22 April 2010, Davide Brini wrote:
  

(moving to -devel as this is obviously pertains there more than -users)



Sorry, too quick! I posted an incomplete version of the patch. The attached 
one should be better.


The only doubt I have is about error handling; in this case, if the allocation 
of the BIO fails, an error message is logged and nothing is done. Is this the 
right thing to do?


  
I don't know if a FATAL error is such a good thing - not being able to 
set an env var does not warrant a server crash , I'd say.

Also, you're not freeing the BIO as far as I can tell.

apart from that: nice patch !

cheers,

JJK

Re: [Openvpn-devel] man page patch

[Jan Just Keijser]

Hi,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/04/10 19:48, Jan Just Keijser wrote:
  

man page patch to fix (based on the git page).

- explicit-exit-notify text is misleading : parameter [n] is the number 
of attempts not the number of retries


- I would make a statement that a section starting with 'so I would make 
a statement' does not belong in a man page



--- new-openvpn.82010-04-16 19:16:08.427860657 +0200
+++ jjk-openvpn.82010-04-16 19:46:01.374609848 +0200
@@ -3308,8 +3308,8 @@
 option will tell the server to immediately close its client instance object
 rather than waiting for a timeout.  The
 .B n
-parameter (default=1) controls the maximum number of retries that the 
client

-will attempt to resend the exit notification message.
+parameter (default=1) controls the maximum number of attempts that the 
client

+will make to send the exit notification message.



ACK

  

 .\"*
 .SS Data Channel Encryption Options:
 These options are meaningful for both Static & TLS-negotiated key modes
@@ -3591,7 +3591,7 @@
 OpenVPN adds to the IPSec model by limiting the window size in time as 
well as

 sequence space.
 
-OpenVPN also adds TCP transport as an option (not offered by IPSec) in 
which
+OpenVPN also adds TCP transport as an option (not offered by plain 
IPSec) in which



Does some IPSec implementations support TCP transport?  I thought that
IPSec was OSI layer 3 (network) traffic, while TCP starts on OSI layer 4
(transport).

  
at least Cisco support IPSec-over-TCP , similarly to IPSec-over-UDP (aka 
NAT traversal)



 case OpenVPN can adopt a very strict attitude towards message deletion and
 reordering:  Don't allow it.  Since TCP guarantees reliability, any packet
 loss or reordering event can be assumed to be an attack.
@@ -3601,11 +3601,6 @@
 message deletion or reordering attack which falls within the normal
 operational parameters of IP networks.
 
-So I would make the statement that one should never tunnel a non-IP 
protocol
-or UDP application protocol over UDP, if the protocol might be 
vulnerable to a
-message deletion or reordering attack that falls within the normal 
operating
-parameters of what is to be expected from the physical IP layer.  The 
problem

-is easily fixed by simply using TCP as the VPN transport layer.




Even though I do agree with you that a "personal message" should not be
in a man page, I also do see the importance of the message given here.
But it can be understood as controversial for some, as it is formulated
in a biased way.  If the message given is false, it should be removed as
well.  But I'd rather see this whole paragraph being rephrased, reworked
and become a bit more unbiased towards the TCP/UDP discussion.

Now it can be understood that TCP is the best security solution - but
that's when you only read this little paragraph.  Changing from TCP to
UDP also got it's fair share of advantages and disadvantages as well,
which should be covered somehow in the man page.


  
to me the last paragraph seems like a rehash of the previous one, with 
wording like "I would make a statement bla bla" . I don't know who wrote 
the original paragraph but at the very least the wording should be 
changed such that

- it is no longer a personal message
- it adds value to the paragraph above.
I tried rewriting the Personal Message paragraph myself but ended up 
with something almost identical to the paragraph right above it.




Could we please split these three changes into three different patches,
as they cover three different parts of the man page and tracking their
changes separately is cleaner when people try to figure out what was
discussed and which conclusions was made.
  

no problem; I'll send another man page patch.

cheers,

JJK

Re: [Openvpn-devel] DNS problems with openvpn 2.1 on Windows

[Jan Just Keijser]

Heiko Hund wrote:


Hi,

On Tuesday 06 April 2010 22:36:31 Johan Ymerson wrote:
> I have tested on 3 PC's with Windows XP, all 3 show the same 
problem, at

> almost 100% of my connection attempts. OpenVPN 2.0.9 does not have this
> issue (ie. reverting back to 2.0.9 on the same machines with the same
> config never show the problem).

We also tried 2.0.9 but were able to reproduce the bug with it as 
well, so it

has nothing to do with the openvpn driver version involved. I came to the
conclusion that it's rather some kind of race condition in the Windows 
XP DNS

resolver. At least I haven't seen this problem on Vista or 7 personally.
 
> Is this problem known, and is someone working on it?

> I can of course help debugging this, but I don't have the development
> environment needed to compile the Windows binaries.

Not much to debug anyway. The DNS servers get passed correctly via 
DHCP and

Windows actually takes notice of them as they show up in `ipconfig /all`.
Problem is that XP resolver somehow forgets to reprioritize the DNS 
servers
list after an DHCP update sometimes and sticks with the old preferred 
name

server until the scheduled reprioritization. At least that's my personal
conclusion. And it would explain why a /renew fixes it.

We've contacted Microsoft tech support about this issue. If anything 
like a
fix comes out of that I'll post an update here. If not we'll have to 
consider
a workaround of some kind, but let's wait with that discussion until 
we're

sure it's not fixable the right way.


isn't
 ipconfig /flushdns
or
 net stop dnscache
 net start dnscache
enough? This might be related to
http://support.microsoft.com/kb/311218

I've recommended to people on the -users list to use an 'up' script with
 net stop dnscache
 net start dnscache
this has worked in 99% of the cases.

cheers,

JJK

Re: [Openvpn-devel] Auto-Proxy

[Jan Just Keijser]

open...@rkmorris.us wrote:


Hi,

 

I have been using two different config files to connect to my OpenVPN 
server - as I am sometimes behind a proxy server, and sometimes not. 
So to fix this I tried using auto-proxy ... but it didn't work (in the 
proxy case) ... :-(.


 


I am running the client on Windows - so it should work, no?

 



note to the developers: all error codes when using the 
InternetQueryOption API are lost ... also read

 http://support.microsoft.com/kb/226473
Openvpn 2.1 uses the "old" IE4 API .

cheers,

JJK

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

[Jan Just Keijser]

Peter Stuge wrote:

Jan Just Keijser wrote:
  
FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1 
are *by definition* not encapsulated (according to my CCNA guide ;-))



802.1Q != CCNA..

Look at the spec, Table 9-2 on page 86. (100 in PDF)

VID Use
  0 "no VLAN identifier is present in the frame"
  1 "The default PVID value used for classifying frames on ingress ..
 The PVID value of a Port can be changed by management."
FFF "Reserved for implementation use."


  
be careful here (from table 9.2; I actually have an older copy of the 
802.1Q spec):


The null VLAN ID. Indicates that the tag header contains only priority
information; no VLAN identifier is present in the frame. This VID value 
shall not
be configured as a PVID or a member of a VID Set, or configured in any 
Filtering

Database entry, or used in any Management operation.

so it *does* have priority info in it and it is *not* the same as no 
VLAN identifier ...



cheers,

JJK

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

[Jan Just Keijser]

Fabian Knittel wrote:

Peter Stuge schrieb:
  

Fabian Knittel wrote:


+  if (ntohs (vlanhdr.tpid) != OPENVPN_ETH_P_8021Q)
+{
+  /* Drop untagged frames */
+  goto err;
+}
  

It would be nice to be able to use VID 0 to mean untagged packets.



Hm, nice idea.  I'll implement it in my next round of patches.
  
FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1 
are *by definition* not encapsulated (according to my CCNA guide ;-))

VID 0 means "priority frames"
Perhaps we need to make sure that VID 1 means untagged ...

For more details, see http://www.javvin.com/protocolVLAN.html

cheers,

JJK

Re: [Openvpn-devel] [Fwd: Re: Clarifications to "OpenVPN will not connect through certain HTTP proxies" bug report]

[Jan Just Keijser]

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/03/10 14:57, Samuli Seppänen wrote:
  

I somehow managed to miss the attached response earlier today. So the
proxy server error was encountered on T-mobile t-zones web proxy only.
Should we close the bug report or make further inquiries?



This was reported November 2007.  I can't recall having seen too much
fuzz about this issue during the time I've been active on the mailing
lists.  I believe this is a really minor issue.  With only a confirmed
issue with T-Mobile t-zones proxy over 2 years ago, I feel we this issue
is rather limited.

I would suggest closing it.  It can be re-opened if this turns out to be
a needed requirement for OpenVPN.  After all, OpenVPN follows the RFC,
that is the most important thing.  We should avoid adding support for
non-standards unless the it is so widespread that it really is
exceptionally needed.


  

ACK - let's make this a 'wontfix' .

cheers,

JJK

Re: [Openvpn-devel] Summary of the IRC meeting (18th Mar 2010)

[Jan Just Keijser]

Hi Samuli,

(I'd prefer to be referred to as JJK in minutes ;-) )

see comments below

Samuli Seppänen wrote:

Hi,

Here's the summary of the previous community meeting.

---

COMMUNITY MEETING

Place: #openvpn-discussion on irc.freenode.net
Date: Thursday, 18th March 2010
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting next week, same place, same time. Your local meeting time
is easy to check from services such as




SUMMARY

Discussed an issue that came up earlier in the mailinglists:

 

Agreed that allowing two clients to connect with the same certificate
without "duplicate-cn" being set (as in "first one to connect wins")
would be harmful and hence unimplementable.

Discussed a potential bug with global config file defaults (e.g. nobind)
not propagating to  blocks. Agreed that this bug is almost
certainly invalid and was triggered by misconfiguration. However, Jan
will check if the OpenVPN man-page requires clarifications in this area.

Discussed Linux TUN/TAP performance and Jan's EPOLL modification
designed to improve it:

 

Agreed that switching from POLL to EPOLL does not improve overall
performance enough to justify the change. Also agreed that no action
should be taken for now, as the TUN/TAP performance is good enough.
  

I did some more tests on the gigabit lan:
- openvpn 1.6.0 (yes the old one) performs worse than 2.1.1
- openvpn 2.1.1 in client-server mode also performs worse than in 
point-to-point mode, again with compression and encryption fully turned 
off...


Let's just leave it here , if somebody else has suggestions just let me know



Discussed this SF.net bug report which was found to be fixed in SVN r3128:



Discussed potential problems with disfunctional proxy servers:



RFC2817 clearly states that proxies need to use this syntax:

 CONNECT host:port/

  

that is not entirely correct:

5.2 Requesting a Tunnel with CONNECT

  A CONNECT method requests that a proxy establish a tunnel connection
  on its behalf. The Request-URI portion of the Request-Line is always
  an 'authority' as defined by URI Generic Syntax [2], which is to say
  the host name and port number destination of the requested connection
  separated by a colon:

 CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80

  Other HTTP mechanisms can be used normally with the CONNECT method --
  except end-to-end protocol Upgrade requests, of course, since the
  tunnel must be established first.


the "other HTTP mechanisms" seems to be implemented by some (reverse?) 
proxy servers ; there are numerous hits in google if you look closely. 
Still don't know how relevant they are, however



However, according to the bug report some proxy servers require invalid
syntax:

 CONNECT http://host:port/

Samuli will try to contact the original bug reporter and will do some
additional research. If no widely used proxy servers require this
invalid syntax, this bug report will be closed as wontfix.

  

the

Discussed a potential bug where CN gets mixed up with certificate name
occasionally after disconnecting. This messes up iptables rulesets and
status files:

http://article.gmane.org/gmane.network.openvpn.user/29181

Agreed that this may indeed be a bug. Decided to do more research:

- check what happens if disconnect happens before connection has reached
  ACTIVE state
- check if this occurs when session is renegotiated (each hour)


  
I tested it but could not reproduce it using openvpn 2.1.1 ; I forgot to 
mention last night that the user was *also* using a 
auth-user-pass-verify script . I duplicated his setup but could not 
reproduce the problem. However, I had already suggested this fix to him:


diff -Nru multi.c multi.c.patched
--- multi.c 2009-10-24 21:17:29.0 -0200
+++ multi.c.patched 2010-03-02 14:57:12.0 -0300
@@ -447,6 +447,9 @@
multi_client_disconnect_setenv (struct multi_context *m,
struct multi_instance *mi)
{
+  /* setenv incoming cert common name for script */
+  setenv_str (mi->context.c2.es, "common_name", 
tls_common_name(mi->context.c2.tls_multi, true));
+
  /* setenv client real IP address */
  setenv_trusted (mi->context.c2.es, get_link_socket_info (>context));

and he says the problem is now fixed ! Hmmm I never like it when 
something is fixed when I don't understand *why* it is fixed...



have a good weekend,

JJK

Re: [Openvpn-devel] Windows, OpenVPN-GUI, disconnect

[Jan Just Keijser]

Hi Gert,

Gert Doering wrote:

Hi,

can one of you tell me what happens "under the hood" if I click the
"disconnect" button of the openvpn-gui under Windows XP?

Why am I asking?  I managed to get my windows build environment working
well enough that I can now build a complete installer package with the
IPv6 patches, and with the adapted tun/tap driver - but it breaks in
funny ways.

 - Installation works fine
 - running the openvpn-gui (precompiled) works fine
 - (client) connection to a TUN server works fine
   [initiated by pressing the "connect..." button of the GUI in the 
windowsstatus bar]

 - IPv4 and IPv6 connectivity works

 - pressing the "disconnection" button of the GUI doesn't seem to do 
   anything.  Well, the status window says "disconnecting..." and the
   button is greyed out - but no update in the log file or the status 
   window, no nothing.


I assume that "something is miscompiled" or "a newer version of mingw
has some surprising side effects" - but to know where to start looking,
it would be helpful to understand what signalling is used 


  openvpn-gui --> openvpn.exe

to signal disconnect.

(Since I didn't touch any of the signal handling stuff, I'm fairly sure
that it wasn't one of my changes, but I still want to have a working
Windows bundle to get people to test it)
  

took me a while to figure this one out:
the openvpn gui codes sets an 'exit event' (using a win32 API call 
CreateEvent) before starting the actual openvpn process; when the user 
chooses 'disconnect' this 'exit event' is triggered, which causes the 
process to be terminated (using the appropriate win32 signal).


The question now becomes: what does openvpn do when it receives a 
terminate signal? actually, is there a signal being sent to the server 
to say "client X is disconnecting" ?


cheers,

JJK

Re: [Openvpn-devel] Linux tun/tap performance issues

[Jan Just Keijser]

Hi David,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/03/10 16:29, Jan Just Keijser wrote:
  

More tests, this time with 'oprofile' : here's a recap:
- nothing changed on the server side:
openvpn --ifconfig 10.222.0.1 10.222.0.2 --dev tun --secret secret.key
--cipher none

- upgraded to kernel 2.6.32.9-70.fc12.x86_64 on my laptop
- selinux is disabled
- installed the debuginfo rpms to get a 'vmlinux'
- configure the oprofile deamon using
opcontrol
--vmlinux=/usr/lib/debug/lib/modules/2.6.32.9-70.fc12.x86_64/vmlinux
- now start it, reset the statistics, start openvpn
 opcontrol --start
 opcontrol --reset
 ./openvpn --ifconfig 10.222.0.2 10.222.0.1 --dev tun --secret
secret.key --remote kudde.nikhef.nl --cipher none
- download a file using 'nc' (this maxes out my 100 Mbps LAN at roughly
11 MB/s)
- get the statistics
 opcontrol --dump
 opreport -l > stats



Thanks a lot!  This is way cool!  It just strikes me that you probably
should play with ftrace instead of oprofile.  It's better and got a
lower overhead than oprofile, afaik.

<http://lwn.net/Articles/322666/>

(btw. with an ftrace enabled kernel, it's even available on embedded
devices. You only need 'mount', 'echo' and 'cat' to interact with ftrace
... even though Steven Rostedt is working on a GUI for ftrace, called
kernelshark)

With such new kernel, there's also the perf tool.

<http://perf.wiki.kernel.org/index.php/Main_Page>

In both of these tools you have something called callgraph, iirc.  And
with that you see which function is calling which function and the
amount of time each step used.

I'll ask some people who's been involved in both ftrace and perf for
some better pointers!
  

your wish is my command ;-) :

actually, 'perf' is a lot easier to use then opcontrol/opreport.  I ran

 perf record -g -f -- ./openvpn ..
 perf report --call-graph > perf.data-20100316

At
 http://www.nikhef.nl/~janjust/openvpn/perf.callgraph-20100316.gz
you will find the callgraph for a 512 MB file copy ; the rest is 
identical to the previous tests.


share and enjoy,

JJK / Jan Just Keijser

Re: [Openvpn-devel] Linux tun/tap performance issues

[Jan Just Keijser]

342  0.2969  (no location information)   libc-2.11.1.so   poll
1336  0.2956  dev.c:2285  vmlinux  
netif_receive_skb
1334  0.2952  softirq.c:142   vmlinux  
_local_bh_enable_ip
1324  0.2929  csum-partial_64.c:134   vmlinux  
csum_partial
1321  0.2923  forward.c:1325  openvpn  
io_wait_dowork
1283  0.2839  entry_64.S:1009 vmlinux  
reschedule_interrupt
1273  0.2817  process_64.c:380vmlinux  
__switch_to
1248  0.2761  avc.c:790   vmlinux  
avc_has_perm_noaudit



Observations:
- note that openvpn itself does not even make the top 15. It's lower in
the list, however:
11896 0.3580  openvpn  openvpn  
io_wait_dowork
10842 0.3263  openvpn  openvpn  po_wait
9608  0.2892  openvpn  openvpn  
openvpn_decrypt
9449  0.2844  openvpn  openvpn  main
9250  0.2784  openvpn  openvpn  pre_select
9191  0.2766  openvpn  openvpn  
process_incoming_link
7027  0.2115  openvpn  openvpn  po_ctl
4148  0.1248  openvpn  openvpn  
packet_id_add
4090  0.1231  openvpn  openvpn  mss_fixup
4022  0.1210  openvpn  openvpn  process_io
[...]
- why do I see 'po_ctl' and the likes? is this the old
openvpn-does-not-properly-use-EPOLL bug again?

I also ran a similar test using a Centos5 client (kernel
2.6.18-164.6.1.el5) over a Gbps LAN : here you can see some limitations
of the tun driver or openvpn itself:
- raw UDP gives me ~ 110 MB/s  (maxing out the Gbps LAN)
- raw TCP/IP gives me ~ 60 MB/s (could use some tweaking but is not so
bad, actually)
- openvpn over UDP maxes out at somewhere between 32 - 40 MB/s
- openvpn over TCP maxes out at ~ 16 MB/s

So either I'm misreading oprofile or it's *not* the tun driver that is
causing bottlenecks.


If anybody else has more experience with 'oprofile' then please let me
know how I can rerun these tests more effectively.


share and enjoy,

JJK / Jan Just Keijser

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Jan Just Keijser]

Stefan Monnier wrote:

Implementing a DHCP client within OpenVPN tends to make this a more
self-contained problem.



I don't think OpenVPN should get into the DHCP business.
Especially because this is not a problem specific to OpenVPN: the same
problem of refreshing DHCP info happens with ethernet and with wifi when
you disconnect and reconnect.

Various solutions to this problem already exist: a tool (e.g. ifplugd)
can monitor the interface's status, or OpenVPN can be instructed (via
its script hooks) to run commands upon (re|dis)connection.

These existing solutions are better because they profit from the general
infrastructure and will hence blend in much better.  E.g. they will
automatically adopt the global DHCP customizations.

  

I tend to agree with Stefan here:

it would be useful if the package builder or system engineer has more 
control over how a tun or tap device is configured but why re-invent the 
wheel ? I'd more than happy if the /sbin/ip command (as determined by 
./configure) became scriptable so that a package maintainer can 
determine which script/program to use to bring the interface up and 
down. I do most of my work on RedHat based systems so I'd replace 
/sbin/ifup with a script which writes out

/etc/sysconfig/networking-scripts/ifup-tap
and then simply call
/sbin/ifup tap0
or something like that... On Ubuntu the package maintainer can choose to 
write his or her favourite /etc/network script, etc etc. Adding your own 
DHCP code is more than likely only going to interfere with system 
package which are already in place (NetworkManager, ifplugd, etc etc).


Let's not add more complexity to openvpn itself, I'd be much happier if 
the complexity is separated as much as possible (heck, why am I even 
stuck using a tun or tap adapter? It'd be nice/fun to be able to use a 
ppp adapter as well, provided that I provide the right interface between 
what openvpn expects and what ppp expects)


JM2CW,

JJK / Jan Just Keijser

Re: [Openvpn-devel] Linux tun/tap performance issues

[Jan Just Keijser]

Hi all,

just ran a very silly test, all with openvpn 2.1.1, on my laptop running 
FC12 (2.6.31.12-174.2.22.fc12.x86_64) ,  Intel(R) Core(TM)2 Duo CPU 
T9300 @ 2.50GHz, connected to a 100 Mbps LAN


server side:  
 openvpn --ifconfig 10.222.0.1 10.222.0.2 --dev tun --secret secret.key 
--cipher none

client side:
 time ./openvpn --ifconfig 10.222.0.2 10.222.0.1 --dev tun --secret 
secret.key --remote kudde.nikhef.nl --cipher none


and then use 'nc' to pipe a 100 MB file from server to client :

nc'ing it once:
user0m2.150s
sys 0m3.972s

nc'ing it twice:
user0m4.128s
sys 0m8.012s

Now with some encryption:

server side:  
 openvpn --ifconfig 10.222.0.1 10.222.0.2 --dev tun --secret secret.key

client side:
 time ./openvpn --ifconfig 10.222.0.2 10.222.0.1 --dev tun --secret 
secret.key --remote kudde.nikhef.nl


nc'ing it once:
user0m5.010s
sys 0m4.385s

nc'ing it twice:
user0m9.922s
sys 0m8.536s

Transfer speeds are about 10 Mb/s in all cases, i.e. the LAN is maxed out.

So yes , quite some time is spent in 'sys' but I don't think it is too 
much ... my guess is that with older CPUs the amount of time spent in 
the kernel vs the time spent in user space was different, i.e. older 
CPUs had more trouble with the encryption/decryption, hence you'd see a 
larger difference between user vs sys.



cheers,

JJK / Jan Just Keijser



David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/03/10 15:47, James Yonan wrote:
  
I believe this has been discussed before, but I noticed recently that a 
Linux-based OpenVPN client (Linux 2.6.24, OpenVPN 2.1.1) spends a lot 
more CPU time in kernel space than in user space.  This is surprising, 
given the fact that all of the CPU-intensive cryptographic operations 
are being done in user space.


Using the 'time' utility on the OpenVPN client, while a wget of a 50MB 
file was done over the VPN, I found that 80% of the CPU time was taken 
by the kernel, and 20% by user space (I should add that the Linux client 
was running as a VM on VMWare Fusion).


I'm wondering if anyone with kernel background has any insights on this. 
  Are there performance bottlenecks in the tun/tap driver?



I'm not a hardcore kernel developer, but I'm interested in the to

James, would you mind trying to run a test on the 2.6.33 kernel?  That's
the newest stable kernel available, just to see if your observations are
visible there as well, and if they are better or worse.

And when you say earlier kernels did not use so much time in kernel
space, which kernels did you compare against?  It would be interesting
to look through the changelog from the "good" kernel version to 2.6.24,
to see what was changed in tun.c.

In this case, it would be easier to try to nail down where such a
behavioural change happened.  And after all, 2.6.24 was released about 2
years ago (Jan 24 14:58:37 2008) ... and the drivers/net/tun.c has been
changed 72 times, as far as I can see.  It's a big job going on getting
rid of the BKL (big kernel lock, blocking all apps while kernel is doing
something) ... so it's difficult to say now just what could have been
the reason for what you observe.

James, if you have a "test script" with configuration files, I can setup
a test environment and run some tests and also enable ftrace [1], which
could also pin-point more where the kernel spends its time doing things.

  

Re: [Openvpn-devel] Erratic TCP Throughput

[Jan Just Keijser]

open...@rkmorris.us wrote:


Hi,

 

This is more my bet, because my question wasn't very clear ... I 
require a proxy server during "normal" operation, but for this data 
throughput test I had no proxy server, rather a "direct" connection.


 

without config files it's impossible to tell - is compression disabled 
during testing? otherwise iperf numbers don't make a lot of sense...


cheers,

JJK