Re: [Openvpn-devel] Building the TAP drivers from source and then signing them (possible?)

[James Yonan]

Jon Onstott wrote:

Hello,

I am compiling OpenVPN and the TAP driver from source and would like the 
TAP driver to be signed so that it installs correctly on Vista (and 
doesn't pop-up warning dialog boxes).  I noticed that the configure 
scripts attempt to do that if "signtool" is defined.  Is there any way 
that I could sign the TAP driver?


I think for most people, signing drivers themselves would be more pain 
than it's worth.  You have to get a special certificate from Verisign 
that costs ~$450/year.  You have to get the full WDK toolchain from 
Microsoft.


I have thought about using the prebuilt TAP driver (from 
openvpn.net/prebuilt/ ) but the prebuilt 
binaries lag behind the current version and I need the TAP driver to be 
the most recent one possible.


The TAP driver in http://openvpn.net/prebuilt/ is based on rc22 which is 
identical to the driver that was just released with 1.2.0.


James

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[James Yonan]

Karl O. Pinc wrote:

On 12/10/2009 04:39:57 AM, Samuli Seppänen wrote:

David Sommerseth ha scritto:



I believe James have received several patches in the past from

people on
the mailing list - or directly. 



They will either include patches into their own source

trees, or

kick them back to be reworked or cancelled completely.

Patches which are accepted will then be sent to James for a final

review

and inclusion.  If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was

rejected
and how to make it more acceptable for inclusion.  If James can 

take
the

time to bring this discussion on the mailing list directly himself

in

these cases, that would bring the needed transparency.  Further, it
should hopefully not happen too often, as James' "inner circle"

should

already have made sure it is suitable for inclusion.


Via public discussion.  Who wants to submit a patch when it
just disappears without comment.  Public discussion has been
sorely lacking in the past.


 Even

patches

these people write themselves should be posted to the openvpn-devel

list

(or other another more suitable one).  That way, more eyes can pay
attention and raise awareness if something seems to be wrong or

needs to

be discussed.


Absolutely.  Public discussion of all submitted patches is essential.

When you can commit to public discussion of submitted patches
then I'll re-send at least one.  (Something very minor.)

Another topic which is needed to be included is documentation.  

This

would be to organise the documentation and make sure all features

are

documented, review documentation to make sure it works as expected

etc,
etc.  This part do not necessarily require any coding skills at 

all.


However, it _could_ be a requirement that all patches be submitted
with documentation.  If not, I can't see how you'd want to
include any functional changes without also having documentation
so somebody else would have to be gotten to document the patch.
This is obviously up to whomever reviews the patches.



What I do see as much more urgent is actually a better distributed
VCS/RCS.  I believe SVN is used now - but I don't recall where I

found

the URL for it (and I have lost now, I believe).  There's also a

rather

outdated CVS tree on sourceforge.net.  This needs to be cleaned up,

and

a publicly available source tree must be made available.



David Sommerseth



The SVN repository URL's are here:

http://www.openvpn.net/index.php/open-source/documentation/
miscellaneous/subversion-repository.html

I checked the logs and last update in 2.1 branch was from 2009-11-20,
so
it's probably 100% up-to-date. I agree with you for the most part.
Beaker sounds interesting, as I guess OpenVPN probably lends itself
well
to automated testing. 


Are you saying that there has been no development on OpenVPN since
2009-11-20, approximately 20 days ago?  That seems a long time
for James to have done no work on the code or documentation.

A public revision control repository means that the public gets
to see all the changes as they are committed.  It does not mean
that we get to see the code only at arbitrary release points.

There are 2 reasons for this.  The first is trust and transparency.
We want to see where the code is going as it gets there so
we can make our plans.  The second is to assist the people who
review submitted patches.  Submitted patches should, by
strong preference, be against the very latest version
of the code.  This keeps merge conflicts, and related bugs,
to a minimum and makes the job of reviewing patches much
easier.

If you don't have a public version of the latest development
code you can't be said to be running an open project.

FWIW using a good (rather than merely adequate) revision control
system makes it much easier to keep the very latest code
on-line and still perform regression tests, keep separate
code branches for feature development, and so forth.

What's the real policy regards the SVN repository and
what are the concerns that have driven this policy?


I wanted to respond to some of the points brought up, as they are good 
points.


First of all, the patch policy: fundamentally, we have to balance two 
conflicting goals:


One the one hand people expect OpenVPN to be rock-solid in both 
stability and security.  In order to maintain this standard of quality, 
there needs to be a rigorous process of patch vetting.  On the other 
hand, as an open source project, OpenVPN needs to be transparent and 
open to contributions from the community.


It can be a challenge to balance these goals.  And certainly in the 
lead-up to the release of 2.1 there was a long period of time that we 
had to lean strongly towards (1) to ensure that 2.1 final would be solid.


I think it's great that Samuli Seppänen has come forward to serve as the 
OpenVPN Community Manager -- one of our key goals here is to create a 
community structure around the patch 

[Openvpn-devel] Building the TAP drivers from source and then signing them (possible?)

[Jon Onstott]

Hello,

I am compiling OpenVPN and the TAP driver from source and would like the TAP
driver to be signed so that it installs correctly on Vista (and doesn't
pop-up warning dialog boxes).  I noticed that the configure scripts attempt
to do that if "signtool" is defined.  Is there any way that I could sign the
TAP driver?

I have thought about using the prebuilt TAP driver (from
openvpn.net/prebuilt/) but the prebuilt binaries lag behind the current
version and I need the TAP driver to be the most recent one possible.

Thanks!
-Jon

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Onstott
Software / Web / Database Engineer
Email: jononst...@gmail.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openvpn-devel] Patch for plugin/auth-pam.c

[David Sommerseth]

On 11/12/09 18:51, Daniel Johnson wrote:
> Daniel Johnson wrote on 2008-12-12:
>> When I began testing OpenVPN v2.1_rc9 I was having trouble
>> authenticating to the MS Active Directory through auth-pam and Samba.
>> I used the following line in my configs (without the linebreak of
>> course):
> 
>> plugin /opt/openvpn/openvpn-auth-pam.so
>> "openvpn login OURDOMAIN+USERNAME password PASSWORD"
> 
>> Finally I turned on more verbose logging and found that the plugin
>> did not recognize "USERNAME" as something to replace, because it
>> expected the string to be surrounded by whitespace.  I wrote the
>> following patch to correct this.  I hope you find it useful,
> 
>> http://thor.chguernsey.com/temp/auth-pam.patch  (2kb)
>> http://thor.chguernsey.com/temp/auth-pam.patch.sig
>> MD5: 6560cbdfe24b3469dcb551d8963efdfa *auth-pam.patch
> 
>> Daniel Johnson
>> progman2...@usa.net
> 
> I've seen no replies to this, and the patch did not make it into
> v2.1.0.  The patch cleanly applies to v2.1.0, is there any interest
> in merging this functionality?
> 

I just decided to do a quick review, I don't believe this has made it
into openvpn-2.1.0.  But from what I see, I have one concern in regards
to a potential memory leak.

The pam_server() function receives a "message" which puts the
information into a "static" memory area which is using struct user_pass.
 This is fine.  Then it calls pam_auth() with a pointer to this memory
region.

The pam_auth() function calls my_conv(), and if this function gets a
match on USERNAME or PASSWORD value in the block around line 562, it
calls searchandreplace() which does a strdup().  This is dynamically
allocated with strdup() and saved into return_value.  But!  In line 569,
you have this line:

  aresp[i].resp = strdup (return_value);

I presume that the aresp[] struct is freed somehow, I have not dug into
that now.  But you have here a double strdup() situation if you get a
match on USERNAME or PASSWORD.  It's almost like saying:

char *ptr = strdup (strdup ("string"));
free(ptr);

This code will give you a memory leak.

Please confirm if my assumptions are correct.  I would probably suggest
to move the strdup() on line 569 and skip using the return_value at all.
 Just use aresp[i].resp directly.


kind regards,

David Sommerseth

[Openvpn-devel] Client blocks

[Yevgeny Kosarzhevsky]

Greetings,

I've setup the client to use two connection blocks, but wasn't able to
provide certain options in it.

I have one  block in udp mode and the other one in tcp. I'd
like to customize udp-specific options, like fragment, mssfix,
replay-window, tun-mtu. If I put it in udp connection block, then I get 
error:


Options error: option 'fragment' cannot be used in this context

Otherwise, if I put them globally, I get:

Options error: --fragment can only be used with --proto udp

I think some other options which I haven't tested should be moved to
 blocks, like comp-lzo, no-replay, no-iv, cipher, auth and
may be some more, so one configuration file may be able to connect to
different server configurations.

Am I missing something and workaround exists already?

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.1.0 released

[David Balazic]

James Yonan wrote:
> 
> I'm happy to announce the release of OpenVPN 2.1.0.  This release is 
> basically 2.1_rc22 + some last-minute trivial fixes to 
> documentation and plugin sample code.  Enjoy!

Does this mean patches are now accepted?

In other words: What is next? What is the plan?

Regards,
David

Re: [Openvpn-devel] OpenVPN 2.1.0 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/12/09 10:17, James Yonan wrote:
> I'm happy to announce the release of OpenVPN 2.1.0.  This release is 
> basically 2.1_rc22 + some last-minute trivial fixes to documentation and 
> plugin sample code.  Enjoy!
> 
> James

I have updated the patch for providing certificate SHA1
digest/fingerprint via the environment table for plug-ins.  This is
needed for the eurephia project I'm working on.

The patch is basically identical to the 2.1_rc22 patch.

The patch is available for download here:


A pre-patched OpenVPN 2.1.0 release can be downloaded here:


The openvpn source tree with and without this patch can be fetched here:


The git tree can be browsed via:



kind regards,

David Sommerseth

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

iEYEARECAAYFAksiUOEACgkQDC186MBRfro8FQCgrF0besE8cipvATt8lNQp7NST
tF8AoJ4x1uwqFq+OqqQgvf6EDlMzi6c3
=cuX9
-END PGP SIGNATURE-

Re: [Openvpn-devel] OpenVPN 2.1.0 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/12/09 10:17, James Yonan wrote:
> I'm happy to announce the release of OpenVPN 2.1.0.  This release is 
> basically 2.1_rc22 + some last-minute trivial fixes to documentation and 
> plugin sample code.  Enjoy!

This is indeed good news!  Thank you very much for your hard work!
Today, it's only pure joy! :)

However, I just checked the differences between 2.1_rc22 and the final
2.1.0.  And I do see that there are some unexpected files here ...

tap-win32/filt.py
tap-win32/tmp/
tap-win32/tmp/hexdump.h
tap-win32/tmp/types.h
tap-win32/tmp/error.c
tap-win32/tmp/error.h
tap-win32/tmp/instance.c
tap-win32/tmp/tapdrvr.c
tap-win32/tmp/macinfo.c
tap-win32/tmp/constants.h
tap-win32/tmp/endian.h
tap-win32/tmp/prototypes.h
tap-win32/tmp/dhcp.h
tap-win32/tmp/dhcp.c
tap-win32/tmp/lock.h
tap-win32/tmp/proto.h
tap-win32/tmp/hexdump.c
tap-win32/tmp/macinfo.h
tap-win32/tmp/common.h
tap-win32/tmp/mem.c

I believe these files are just leftovers after making the license a pure
GPLv2 license.  Is this a correct assumption?

Btw!  Good move on the license!


kind regards,

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

iEYEARECAAYFAksiF70ACgkQDC186MBRfrqEjACeLYEA2zw+tIC8biANywvDtgcj
A6oAn2u+LveoFX9+FihPuwBTkj1kbIyG
=F0iV
-END PGP SIGNATURE-

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

Davide,

Try adding the "nobind" directive to your client config file.  I think 
this will solve the problem.


James

Davide Brini wrote:

On Thursday 12 November 2009, David Sommerseth wrote:


On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf

On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


Sorry to jump in here, but I've run into a weird behavior when using multihome 
in all versions, up to rc15 (I haven't tried later versions, but I guess that 
it would be the same thing since I don't see anything related to this in the 
changelog). I'm using Gentoo on both the client and the server.


In short, it seems that, despite having "multihome" enabled, the server still 
sends replies back to the client out the "wrong" interface, but only under 
certain (not clearly defined) conditions and only after some time(?).


Here is the server config (don't mind IP addresses, this is a lab network):

port 1194
multihome   
proto udp

dev tap0
ca ca.crt
cert server.crt
key server.key
script-security 2
up up.sh
down down.sh
dh dh1024.pem
server-bridge 10.0.1.251 255.255.255.0 10.0.1.10 10.0.1.20
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 6

And here is the client config:

client
remote 1.1.1.1 1194
remote 2.2.2.2 1194
remote-random
proto udp
dev tap0
ca ca.crt
cert client.crt
key client.key
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

What I've noticed is that the very first connection from a client, regardless 
of the interface it hits, works fine. But for example, if that same client 
disconnects and then reconnects to the other interface (because of the remote-
random option), then the problem happens. However, if another client connects 
second (rather than the first one disconnecting and reconnecting), the second 
client doesn't have problems, regardless of the interface it connects to.
Here is an excerpt of the server log taken during the very first client 
connection:


--
Thu Nov 12 19:58:16 2009 us=7043 192.168.2.2:1194 TLS: Initial packet from 
192.168.2.2:1194 (via 2.2.2.2), sid=68a926bd 92b98d25
Thu Nov 12 19:58:16 2009 us=7235 192.168.2.2:1194 UDPv4 WRITE [26] to 
192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] 
pid=0 DATA len=0


Thu Nov 12 19:58:16 2009 us=146570 192.168.2.2:1194 Data Channel Encrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146664 192.168.2.2:1194 Data Channel Encrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 12 19:58:16 2009 us=146802 192.168.2.2:1194 Data Channel Decrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146886 192.168.2.2:1194 Data Channel Decrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication

...
Thu Nov 12 19:58:16 2009 us=151489 192.168.2.2:1194 Control Channel: TLSv1, 
cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 12 19:58:16 2009 us=151588 192.168.2.2:1194 [Test-Client] Peer 
Connection Initiated with 192.168.2.2:1194 (via 2.2.2.2)
Thu Nov 12 19:58:17 2009 us=181119 Test-Client/192.168.2.2:1194 UDPv4 READ 
[104] from 192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_V1 kid=0 [ ] pid=26 DATA 
len=90
Thu Nov 12 19:58:17 2009 us=181558 Test-Client/192.168.2.2:1194 PUSH: Received 
control message: 'PUSH_REQUEST'
Thu Nov 12 19:58:17 2009 us=181841 Test-Client/192.168.2.2:1194 SENT CONTROL 
[Test-Client]: 'PUSH_REPLY,route-gateway 10.0.1.251,ping 10,ping-restart 
120,ifconfig 10.0.1.10 255.255.255.0' (status=1)

...
Thu Nov 12 19:58:30 2009 us=170924 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[77] to 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76
Thu Nov 12 19:58:30 2009 us=172448 Test-Client/192.168.2.2:1194 UDPv4 READ 
[77] from 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76

Thu Nov 12 19:58:30 2009 us=172747 Test-Client/192.168.2.2:1194 TUN WRITE [42]
---

As you can see, the connection keeps using the 2.2.2.2 IP address. The 
connection works fine indeed. So far so good. But here's what happens if the 
client disconnects and reconnects to the other IP address (excerpts):


---
Thu Nov 12 19:58:47 2009 us=536468 Test-Client/192.168.2.2:1194 TLS: new 
session incoming connection from 192.168.2.2:1194 (via 1.1.1.1)
Thu Nov 12 19:58:47 2009 us=536712 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[26] to 192.168.2.2:1194 (via 1.1.1.1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 
0 ] pid=0 DATA len=0
Thu Nov 12 19:58:47 2009 us=538918 Test-Client/192.168.2.2:1194 UDPv4 READ 
[22] from 192.168.2.2:1194 (via 1.1.1.1): P_ACK_V1 kid=0 [ 0 ]
Thu Nov 12 19:58:47 2009 

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf
On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


James, this option is not documented in the man pages, AFAICS.  Could
that be the reason the needed use was not discovered?


I've documented --multihome in the man page.  The change has been 
checked into svn and will be in the next release.


James