openvpn-devel Mailing List for OpenVPN

Sorry..... I want to help, changing the code to support HPUX. I'm trying some solutions, and when I have the ifconfig script working on HPUX, I'll tell you. Raphael ----- Original Message ----- From: "Charles Duffy" <cd...@sp...> To: <ope...@li...> Sent: Wednesday, August 31, 2005 6:56 PM Subject: [Openvpn-devel] Re: OpenVPN and HPUX > This question should be posted to the openvpn-users list. If you were > asking how to change the code to support HPUX, for instance, that would be > appropriate for -devel; usage issues (as this is) are not. > > (Hint: Read the error message and do what it says). > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

On Wednesday 2005-August-31 16:56, Charles Duffy wrote: > This question should be posted to the openvpn-users list. Oops, my reply went to openvpn-users; I didn't even notice this was on openvpn-devel. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header 

This question should be posted to the openvpn-users list. If you were asking how to change the code to support HPUX, for instance, that would be appropriate for -devel; usage issues (as this is) are not. (Hint: Read the error message and do what it says). 

HI, I have a HP machine (HPUX 11.00), and I'm trying to run openvpn. The = compilation was ok, but when I try to run openvpn: root@hpux-/root# /usr/local/sbin/openvpn --config openvpn_server.conf Wed Aug 31 15:27:04 2005 OpenVPN 2.0 hppa2.0w-hp-hpux11.00 [SSL] [LZO] = built on Aug 15 2005 Wed Aug 31 15:27:04 2005 Diffie-Hellman initialized with 1024 bit key Wed Aug 31 15:27:04 2005 TLS-Auth MTU parms [ L:1544 D:140 EF:40 EB:0 = ET:0 EL:0 ] Wed Aug 31 15:27:04 2005 TUN/TAP device /dev/tun0 opened Wed Aug 31 15:27:04 2005 Sorry, but I don't know how to do 'ifconfig' = commands on this operating system. You should ifconfig your TUN/TAP = device manually or use an --up script. Wed Aug 31 15:27:04 2005 Exiting I'm not an expert on HPUX. I'm trying to configure tun interface = manually, but no success. Anybody can help? Thanks. Raphael 

On Sat, 27 Aug 2005, Arkadiusz Patyk wrote: > Hi > > I have the same problem as was descriptions > http://sourceforge.net/tracker/index.php?func=detail&aid=1253117&group_id=48978&atid=454719 > > Where can I find this patch ? > Please merge this patch in next release - it's necessary. http://openvpn.net/patch/openvpn-2.0_rc16MH.patch Other than a couple trivial conflicts in ChangeLog and configure.ac, it merges fine with 2.0.2. Note that the standard Berkeley Sockets API doesn't support getting the dest address on received UDP packets or setting the source address on outgoing UDP packets, functionality which is necessary for UDP multihoming to work correctly, so this patch currently uses some nonportable Linux-only syscalls. James > BTW: > > In 2.x wishlist http://openvpn.net/wiki/OpenVPN_2.x_wishlist > I found: > # Server support to listen on TCP/UDP simultaneously > # Client support for multiple --remote directives to specify TCP or > UDP usage > > It's cool features - I'am waiting for it a long time ;) It's a high priority for 2.1. James 

Hi I have the same problem as was descriptions http://sourceforge.net/tracker/index.php?func=detail&aid=1253117&group_id=48978&atid=454719 Where can I find this patch ? Please merge this patch in next release - it's necessary. BTW: In 2.x wishlist http://openvpn.net/wiki/OpenVPN_2.x_wishlist I found: # Server support to listen on TCP/UDP simultaneously # Client support for multiple --remote directives to specify TCP or UDP usage It's cool features - I'am waiting for it a long time ;) Cheers, -- Arkadiusz Patyk [areq(at)pld-linux.org] [http://rescuecd.pld-linux.org/] [IRC:areq skype:arekpatyk GG:1383] [AP3-6BONE] [AP6067-RIPE] 

Download: http://openvpn.net/download.html Changes since 2.0.1: * Fixed regression bug in Win32 installer, introduced in 2.0.1, which incorrectly set OpenVPN service to autostart. * Don't package source code zip file in Windows installer in order to reduce the size of the installer. The source zip file can always be downloaded separately if needed. * Fixed bug in route.c in FreeBSD, Darwin, OpenBSD and NetBSD version of get_default_gateway. Allocated socket for route manipulation is never freed so number of mbufs continuously grow and exhaust system resources after a while (Jaroslav Klaus). * Fixed bug where "--proto tcp-server --mode p2p --management host port" would cause the management port to not respond until the OpenVPN peer connects. * Modified pkitool script to be /bin/sh compatible (Johnny Lam). James 

On Wed, Aug 24, 2005 at 02:12:26PM -0600, James Yonan wrote: > Due to several requests, I've put together a set of isolated > patches which fix the individual security issues addressed by OpenVPN=20 > 2.0.1, and which can be applied to any major version of OpenVPN going > back to 1.3.2. >=20 > Out of the 4 patches, only CAN-2005-2531 is relevant for the > 1.x branch. >=20 > These patches will individually apply the specific security fixes > released in OpenVPN 2.0.1 to an OpenVPN 2.0 or 1.x tree. >=20 > Patches are available in: >=20 > http://openvpn.net/patch/2.0.1-security-patches/ [...] James, Thanks a LOT! Peter --=20 SUSE LINUX Products GmbH Thought is limitation. Research & Development Free your mind. 

Due to several requests, I've put together a set of isolated patches which fix the individual security issues addressed by OpenVPN 2.0.1, and which can be applied to any major version of OpenVPN going back to 1.3.2. Out of the 4 patches, only CAN-2005-2531 is relevant for the 1.x branch. These patches will individually apply the specific security fixes released in OpenVPN 2.0.1 to an OpenVPN 2.0 or 1.x tree. Patches are available in: http://openvpn.net/patch/2.0.1-security-patches/ ----------------------------------------- openvpn-2.0-sslerrqfix.patch openvpn-1.6.0-sslerrqfix.patch (also applicable to 1.5.0) openvpn-1.4.3-sslerrqfix.patch (also applicable to 1.3.2) * Security Fix -- DoS attack against server when run with "verb 0" and without "tls-auth". If a client connection to the server fails certificate verification, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2531). Affects OpenVPN 1.x and 2.0. ----------------------------------------- openvpn-2.0-sslerrqfix.patch * Security Fix -- DoS attack against server by authenticated client. This bug presents a potential DoS attack vector against the server which can only be initiated by a connected and authenticated client. If the client sends a packet which fails to decrypt on the server, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2532). Affects OpenVPN 2.0 only, 1.x is unaffected. ----------------------------------------- openvpn-2.0-iroutequota.patch * Security Fix -- DoS attack against server by authenticated client. A malicious client in "dev tap" ethernet bridging mode could theoretically flood the server with packets appearing to come from hundreds of thousands of different MAC addresses, causing the OpenVPN process to deplete system virtual memory as it expands its internal routing table. A --max-routes-per-client directive has been added (default=256) to limit the maximum number of routes in OpenVPN's internal routing table which can be associated with a given client (CAN-2005-2533). Affects OpenVPN 2.0 only, 1.x is unaffected. ----------------------------------------- openvpn-2.0-assert-mtcp411.patch * Security Fix -- DoS attack against server by authenticated client. If two or more client machines try to connect to the server at the same time via TCP, using the same client certificate, and when --duplicate-cn is not enabled on the server, a race condition can crash the server with "Assertion failed at mtcp.c:411" (CAN-2005-2534). Affects OpenVPN 2.0 only, 1.x is unaffected. ----------------------------------------- James 

SGkNCg0KCUkgYnVpbGQgdGhlIHNvdXJjZSBjb2RlcyBvZiBPcGVuVlBOIG9uIFdpbmRvdyBYUCwg dGhlIGx6byBpcyBpbiBIOlx2cG4tYnVpbGRcbHpvLTEuMDguIFRoZSBpbmNsdWRlIGRpcmVjdG9y eSB1bmRlciBsem8tMS4wOCBjb250YWlucyBsem8uaCxsem9jb25mLmgsbHpvdXRpbC5oIGx6bzEu aCwgLi4uIFRoZSBsaWIgZGlyZWN0b3J5IHVuZGVyIGx6by0xLjA4IGNvbnRhaW5zIGxpYmx6by5h IGFuZCBsaWJsaXoubGEuIChwbGVhc2Ugc2VlIHRoZSBhdHRhY2htZW50KQ0KDQoJU28gSSBzZXQg IkxaTyA9IC9oL3Zwbi1idWlsZC9sem8tMS4wOCIsIkxJQl9ESVJTID0gLUwke09QRU5TU0x9L2xp Yi9NaW5HVyAgLUwke0xaT30vbGliIiwiSU5DTFVERV9ESVJTID0gLUkke09QRU5TU0x9L2luY2x1 ZGUgLUkke0xaT30vaW5jbHVkZSIgaW4gdGhlIG1ha2VmaWxlLnczMi4gTm90ZSB0aGUgb3BlbnNz bCBpcyBvayB3aGVuIGJ1aWxkaW5nLg0KCXdoZW4gSSBidWlsZCB0aGUgY29kZXMgd2l0aCAnbWFr ZSAtZiBtYWtlZmlsZS53MzInLCBJIGZhY2UgdGhlIGZvbGxvd2luZyBlcnJvcnM6DQoNCg0KLyot LS0tLS0tLS0tLS0tLS0tLS0tIHRoZSBtYWtpbmcgcHJvY2Vzc2VzIGFuZCB0aGUgZXJyb3MtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovDQpIOlx2cG5cc291cmNlY29kZVx3aW5kb3dzXG9w ZW52cG4tMi4wPm1ha2UgLWYgbWFrZWZpbGUudzMyICAgICAgICAgICAgICAgICAgICAgIA0KZ2Nj IC1nIC1PMiAtV2FsbCAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLXVudXNlZC12YXJpYWJsZSAt bW5vLWN5Z3dpbiAtbyBvcGVudnBuLmV4ZSBiYXNlNjQubyAgYnVmZmVyLm8gY3J5cHRvLm8gY3J5 cHRvYXBpLm8gZXJyb3IubyBldmVudC5vIGZkbWlzYy5vIGZvcndhcmQubyBmcmFnbWVudC5vIGdy ZW1saW4ubyBoZWxwZXIubyBpbml0Lm8gaW50ZXJ2YWwubyBsaXN0Lm8gbHpvLm8gbWFuYWdlLm8g bWJ1Zi5vIG1pc2MubyBtcm91dGUubyBtc3MubyBtdGNwLm8gbXR1Lm8gbXVkcC5vIG11bHRpLm8g bnRsbS5vIG9jYy5vIG9wZW52cG4ubyBvcHRpb25zLm8gb3RpbWUubyBwYWNrZXRfaWQubyBwZXJm Lm8gcGluZy5vIHBsdWdpbi5vIHBvb2wubyBwcm90by5vIHByb3h5Lm8gcHVzaC5vIHJlbGlhYmxl Lm8gcm91dGUubyBzY2hlZHVsZS5vIHNlc3Npb25faWQubyBzaGFwZXIubyBzaWcubyBzb2NrZXQu byBzb2Nrcy5vIHNzbC5vIHN0YXR1cy5vIHRocmVhZC5vIHR1bi5vIHdpbjMyLm8gLUwvaC92cG4t YnVpbGQvT3BlblNTTC9saWIvTWluR1cgLUwvaC92cG4tYnVpbGQvbHpvLTEuMDgvbGliIC1sc3Ns MzIgLWxlYXkzMiAtbGx6byAtbGNyeXB0MzIgLWx3czJfMzIgLWxnZGkzMiAtbGlwaGxwYXBpIC1s d2lubW0gICAgICANCmx6by5vKC50ZXh0KzB4YmQpOiBJbiBmdW5jdGlvbiBgbHpvX2NvbXByZXNz X2luaXQnOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSDovdnBuL3NvdXJjZWNvZGUvd2lu ZG93cy9vcGVudnBuLTIuMC9sem8uYzoxMTI6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fbHpv X2luaXQyJyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGx6by5vKC50ZXh0KzB4Y2MpOkg6L3Zwbi9zb3VyY2Vj b2RlL3dpbmRvd3Mvb3BlbnZwbi0yLjAvbHpvLmM6MTE0OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBsem9fbWFsbG9jJw0KbHpvLm8oLnRleHQrMHgxNjQpOiBJbiBmdW5jdGlvbiBgbHpvX2NvbXBy ZXNzX3VuaW5pdCc6ICAgICAgICAgICAgICAgICAgICAgICAgICAgSDovdnBuL3NvdXJjZWNvZGUv d2luZG93cy9vcGVudnBuLTIuMC9sem8uYzoxMjQ6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGx6 b19mcmVlJyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGx6by5vKC50ZXh0KzB4MmJjKTogSW4gZnVuY3Rp b24gYGx6b19jb21wcmVzcyc6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSDovdnBu L3NvdXJjZWNvZGUvd2luZG93cy9vcGVudnBuLTIuMC9sem8uYzoxNTU6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYGx6bzF4XzFfMTVfY29tcHJlc3MnICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGx6by5vKC50ZXh0KzB4Njlh KTogSW4gZnVuY3Rpb24gYGx6b19kZWNvbXByZXNzJzogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSDovdnBuL3NvdXJjZWNvZGUvd2luZG93cy9vcGVudnBuLTIuMC9sem8uYzoyMDk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGx6bzF4X2RlY29tcHJlc3Nfc2FmZScgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMN Cm1ha2U6ICoqKiBbZHluYW1pY10gRXJyb3IgMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIHRoZSBtYWtp bmcgcHJvY2Vzc2VzIGVuZC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovDQoNCg0K SGFzIEFueW9uZSAgZmFjZWQgdGhlc2UgcHJvYmxlbXMgd2l0aCBNaW5HVy9NU1lTIGluIHdpbmRv d3MgcGxhdGZvcm0sIG9yIElmIGFueW9uZSBoYXMgdGhlIGx6byBsaWIgdGhhdCBjYW4gbWFrZSBz dWNjZXNzZnVsbHkgaW4gd2luZG93cyBwbGF0Zm9ybSwgcGxlYXNlIHNlbmQgaXQgdG8gbWUoZGVo dWE5OTlAc2p0dS5lZHUuY24pLCB0aGFua3MgYSBsb3QhDQqhoaGhoaGhoaGhoaGhoaGhDQqhoaGh oaGhoaGhoaGhoaGhICAgICAgICAgICAgICAgICAgIGRld2FyZA0KDQoNCg== 

 On Wed, 17 Aug 2005, Johnny C. Lam wrote: > On Wed, Aug 17, 2005 at 06:52:50AM -0600, James Yonan wrote: > > On Tue, 16 Aug 2005, Johnny Lam wrote: > > > > > James Yonan wrote: > > > > > > > > * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 > > > > > > I am maintaining OpenVPN in the NetBSD Packages Collection and was in > > > the process of updating our package to 2.0.1 when I noticed that the > > > pkitool script uses bash. If I provide them, will patches be accepted > > > into the OpenVPN sources to use Bourne shell syntax instead so as to > > > relax the requirement on bash? > > > > Yes, that's probably okay. Hopefully we can get bash/sh portability > > without complexifying the code too much. > > I've attached a patch that does the following things: > > (1) Bourne shell fix: function foo {...} -> foo() {...} > > (2) Bourne shell fix: avoid use of bash's substring selection >	${foo:M:N} by replacing with an equivalent options-processing >	loop. > > (3) Solaris /bin/sh fix: don't set and export in one command; >	rather, export all the variables after setting them. > > (4) Solaris /bin/sh fix: "if ! cmd ; then ... fi" isn't understood, >	so change it to "if cmd; then :; else ... fi". > > (5) Don't require GNU grep -- -E isn't needed since we're matching >	a basic RE, and -q can be avoided by attaching stdout to >	/dev/null. > > (6) Use GREP and OPENSSL variables instead of "grep" and "openssl" >	so that it's easier to hard-code the full paths to the two >	utilities in the pkitool script by setting them at the top of >	the script. > > I've tested this script on both NetBSD 2.0.2 and Solaris 8. Thanks, I've merged your patch with 2.0.2-rc1. James 

Apologize for putting this problem on the developer list. Just not getting to many hits else where. When I log into my server and manually restart the server, all is well with my VPN connections. After a short time, login attempts result in failures. The passwords come back as auth failed or critical errors (in the openvpn.log file). Did some research and it appears the login attempts that are passed to PAM and pam_access.so (via login module) are not showing an originating tty. The /var/log/auth.log shows: Aug 21 18:31:11 nssab2-ada-jenkins pam_access[6060]: couldn't get the tty name Aug 21 19:28:09 nssab2-ada-jenkins pam_access[6060]: couldn't get the tty name Aug 21 19:32:03 nssab2-ada-jenkins pam_access[6060]: couldn't get the tty name Aug 21 19:33:50 nssab2-ada-jenkins pam_access[6060]: couldn't get the tty name Aug 21 19:45:53 nssab2-ada-jenkins pam_access[6060]: couldn't get the tty name The requesting tty that pam_access expects is not there, NULL value. It then kills the login process and OpenVPN will not work till manually stopped and restarted from a SSH session. Using PAM .78 and openvpn-2.0_rc17 

Greetings, the attached patch was submitted to me in my role as FreeBSD port maintainer by Jaroslav Klaus a while ago, and it hasn't made openvpn 2.0.1. My fault for not sending this on earlier, I simply forgot and figured, when doing the 2.0.1 port, that Jaroslav's patch still applied to the code. Jaroslav writes: "The current version of OpenVPN in ports tree - 2.0 - has a bug in route.c in FreeBSD, Darwin, OpenBSD and NetBSD version of get_default_gateway. Allocated socket for route manipulation is never freed so number of mbufs continuously growing and exhaust system resources after a while.. Patch is attached." Please consider Jaroslav's patch for inclusion. -- Matthias Andree 

Matthias Andree wrote: > On Wed, 17 Aug 2005, Johnny C. Lam wrote: > >> (3) Solaris /bin/sh fix: don't set and export in one command; >>	rather, export all the variables after setting them. >> >> (4) Solaris /bin/sh fix: "if ! cmd ; then ... fi" isn't understood, >>	so change it to "if cmd; then :; else ... fi". > > These are no "fixes", but workarounds for a truly rotten and unusable > /bin/sh on Solaris. Sun should have replaced /bin/sh by something POSIX > compliant by now... Working as I do on pkgsrc which supports NetBSD and Solaris (as well as several other operating systems), I don't disagree with this sentiment. For larger scripting jobs within pkgsrc, I tend to use a more appropriate shell than Solaris' /bin/sh. However, if you look at the patch, you can see that the changes are extremely minor to get pkitool to work with the stock /bin/sh on Solaris, which is still a popular Unix platform, and I think that the benefit is quite worthwhile of not needing some configure script magic to detect the operating system and select an appropriate shell.	Cheers,	-- Johnny Lam <jl...@Ne...> 

On Wed, 17 Aug 2005, Johnny C. Lam wrote: > (3) Solaris /bin/sh fix: don't set and export in one command; >	rather, export all the variables after setting them. > > (4) Solaris /bin/sh fix: "if ! cmd ; then ... fi" isn't understood, >	so change it to "if cmd; then :; else ... fi". These are no "fixes", but workarounds for a truly rotten and unusable /bin/sh on Solaris. Sun should have replaced /bin/sh by something POSIX compliant by now... Solaris however ships with a decent shell, namely /usr/xpg4/bin/sh, also known as /usr/bin/ksh. The XPG4 manual page on Solaris suggests putting /usr/xpg4/bin and /usr/ccs/bin up front in the path, and that is what Solaris systems should do. Solaris' XPG4 sh and ksh understand both "export VAR=value" and "if ! cmd1 ; then cmd2 ; fi", here are my tests (Solaris 8 SPARC): SHELL=/usr/xpg4/bin/sh $SHELL -c 'if ! false ; then echo true ; fi' $SHELL -c 'export A=test ; echo $A' Both tests pass, and both fail with SHELL=/bin/sh. We can lift auto* magic to get this working on Solaris from bogofilter if desired for #! lines. -- Matthias Andree 

On Wed, Aug 17, 2005 at 06:52:50AM -0600, James Yonan wrote: > On Tue, 16 Aug 2005, Johnny Lam wrote: > > > James Yonan wrote: > > > > > > * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 > > > > I am maintaining OpenVPN in the NetBSD Packages Collection and was in > > the process of updating our package to 2.0.1 when I noticed that the > > pkitool script uses bash. If I provide them, will patches be accepted > > into the OpenVPN sources to use Bourne shell syntax instead so as to > > relax the requirement on bash? > > Yes, that's probably okay. Hopefully we can get bash/sh portability > without complexifying the code too much. I've attached a patch that does the following things: (1) Bourne shell fix: function foo {...} -> foo() {...} (2) Bourne shell fix: avoid use of bash's substring selection	${foo:M:N} by replacing with an equivalent options-processing	loop. (3) Solaris /bin/sh fix: don't set and export in one command;	rather, export all the variables after setting them. (4) Solaris /bin/sh fix: "if ! cmd ; then ... fi" isn't understood,	so change it to "if cmd; then :; else ... fi". (5) Don't require GNU grep -- -E isn't needed since we're matching	a basic RE, and -q can be avoided by attaching stdout to	/dev/null. (6) Use GREP and OPENSSL variables instead of "grep" and "openssl"	so that it's easier to hard-code the full paths to the two	utilities in the pkitool script by setting them at the top of	the script. I've tested this script on both NetBSD 2.0.2 and Solaris 8.	Cheers,	-- Johnny Lam <jl...@Ne...> 

On Tue, 16 Aug 2005, Johnny Lam wrote: > James Yonan wrote: > > > > * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 > > I am maintaining OpenVPN in the NetBSD Packages Collection and was in > the process of updating our package to 2.0.1 when I noticed that the > pkitool script uses bash. If I provide them, will patches be accepted > into the OpenVPN sources to use Bourne shell syntax instead so as to > relax the requirement on bash? Yes, that's probably okay. Hopefully we can get bash/sh portability without complexifying the code too much. James 

James Yonan wrote: > > * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 I am maintaining OpenVPN in the NetBSD Packages Collection and was in the process of updating our package to 2.0.1 when I noticed that the pkitool script uses bash. If I provide them, will patches be accepted into the OpenVPN sources to use Bourne shell syntax instead so as to relax the requirement on bash?	Thanks,	-- Johnny Lam <jl...@Ne...> 

On Tue, 16 Aug 2005, Leonard Isham wrote: > On 8/16/05, James Yonan <ji...@yo...> wrote: > > This release fixes a number of bugs in OpenVPN 2.0, including several bugs > > in the server which might be used to mount a DoS attack. > > > > Download: > > > > http://openvpn.net/download.html > > > > Change Log since 2.0: > > > > 2005.08.16 -- Version 2.0.1 > > > > What is the recommended order of upgrade? > > Server then clients or is this, what gets upgraded frst, a non-issue? The DoS security fixes only affect the server, so it's less important to upgrade the clients. James 

On 8/16/05, James Yonan <ji...@yo...> wrote: > This release fixes a number of bugs in OpenVPN 2.0, including several bug= s > in the server which might be used to mount a DoS attack. >=20 > Download: >=20 > http://openvpn.net/download.html >=20 > Change Log since 2.0: >=20 > 2005.08.16 -- Version 2.0.1 >=20 What is the recommended order of upgrade? Server then clients or is this, what gets upgraded frst, a non-issue? --=20 Leonard Isham, CISSP=20 Ostendo non ostento. 

This release fixes a number of bugs in OpenVPN 2.0, including several bugs in the server which might be used to mount a DoS attack. Download: http://openvpn.net/download.html Change Log since 2.0: 2005.08.16 -- Version 2.0.1 * Security Fix -- DoS attack against server when run with "verb 0" and without "tls-auth". If a client connection to the server fails certificate verification, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2531). * Security Fix -- DoS attack against server by authenticated client. This bug presents a potential DoS attack vector against the server which can only be initiated by a connected and authenticated client. If the client sends a packet which fails to decrypt on the server, the OpenSSL error queue is not properly flushed, which can result in another unrelated client instance on the server seeing the error and responding to it, resulting in disconnection of the unrelated client (CAN-2005-2532). * Security Fix -- DoS attack against server by authenticated client. A malicious client in "dev tap" ethernet bridging mode could theoretically flood the server with packets appearing to come from hundreds of thousands of different MAC addresses, causing the OpenVPN process to deplete system virtual memory as it expands its internal routing table. A --max-routes-per-client directive has been added (default=256) to limit the maximum number of routes in OpenVPN's internal routing table which can be associated with a given client (CAN-2005-2533). * Security Fix -- DoS attack against server by authenticated client. If two or more client machines try to connect to the server at the same time via TCP, using the same client certificate, and when --duplicate-cn is not enabled on the server, a race condition can crash the server with "Assertion failed at mtcp.c:411" (CAN-2005-2534). * Fixed server bug where under certain circumstances, the client instance object deletion function would try to delete iroutes which had never been added in the first place, triggering "Assertion failed at mroute.c:349". * Added --auth-retry option to prevent auth errors from being fatal on the client side, and to permit username/password requeries in case of error. Also controllable via new "auth-retry" management interface command. See man page for more info. * Added easy-rsa 2.0 scripts to the tarball in easy-rsa/2.0 * Fixed bug in openvpn.spec where rpmbuild --define 'without_pam 1' would fail to build. * Implement "make check" to perform loopback tests (Matthias Andree). 2005.07.21 -- Version 2.0.1-rc7 * Support LZO 2.01 which renamed its library to lzo2 (Matthias Andree). * Include linux/types.h before checking for linux/errqueue.h (Matthias Andree). 2005.07.15 -- Version 2.0.1-rc6 * Commented out "user nobody" and "group nobody" in sample client/server config files. * Allow '@' character to be used in --client-config-dir file names. 2005.07.04 -- Version 2.0.1-rc5 * Windows version will log a for-further-info URL when initialization sequence is completed with errors. * Added DLOPEN_PAM parameter to plugin/auth-pam/Makefile to control whether auth-pam plugin links to PAM via dlopen or -lpam. By default, DLOPEN_PAM=1 so pre-existing behavior should be preserved. DLOPEN_PAM=0 is the preferred setting to link via -lpam, but DLOPEN_PAM=1 works around a bug in SuSE 9.1 (and possibly other distros as well) where the PAM modules are not linked with -lpam. See thread on openvpn-devel for more discussion about this patch (Simon Perreault). 2005.06.15 -- Version 2.0.1-rc4 * Support LZO 2.00, including changes to configure script to autodetect LZO version. 2005.06.12 -- Version 2.0.1-rc3 * Fixed a bug which caused standard file handles to not be closed after daemonization when --plugin and --daemon are used together, and if the plugin initialization function forks (as does auth-pam and down-root) (Simon Perreault). * Added client-side up/down scripts in contrib/pull-resolv-conf for accepting server-pushed "dhcp-option DOMAIN" and "dhcp-option DNS" on Linux/Unix systems (Jesse Adelman). * Fixed bug where if client-connect scripts/plugins were cascaded, and one (but not all) of them returned an error status, there might be cases where for an individual script/plugin, client-connect was called but not client-disconnect. The goal of this fix is to ensure that if client-connect is called on a given client instance, then client-disconnect will definitely be called. A potential complication of this fix is that when client-connect functions are cascaded, it's possible that the client-disconnect function would be called in cases where the related client-connect function returned an error status. This fix should not alter OpenVPN behavior when scripts/plugins are not cascaded. * Changed the hard-to-reproduce "Assertion failed at fragment.c:312" fatal error to a warning: "FRAG: outgoing buffer is not empty". Need more info on how to reproduce this one. * When --duplicate-cn is used, the --ifconfig-pool allocation algorithm will now allocate the first available IP address. * When --daemon and --management-hold are used together, OpenVPN will daemonize before it enters the management hold state. 2005.05.16 -- Version 2.0.1-rc2 * Modified vendor test in openvpn.spec file to match against "Mandrakesoft" in addition to "MandrakeSoft". * Using --iroute in a --client-config-dir file while in --dev tap mode is not currently supported and will produce a warning message. Fixed bug where in certain cases, in addition to generating a warning message, this combination of options would also produce a fatal assertion in mroute.c. * Pass --auth-user-pass username to server-side plugin without performing any string remapping (plugins, unlike scripts, don't get any security benefit from string remapping). This is intended to fix an issue with openvpn-auth-pam/pam_winbind where backslash characters in a username ('\') were being remapped to underscore ('_'). * Updated OpenSSL DLLs in Windows build to 0.9.7g. * Documented --explicit-exit-notify in man page. * --explicit-exit-notify seconds parameter defaults to 1 if unspecified. 2005.04.30 -- Version 2.0.1-rc1 * Fixed bug where certain kinds of fatal errors after initialization (such as port in use) would leave plugin processes (such as openvpn-auth-pam) still running. * Added optional openvpn_plugin_abort_v1 plugin function for closing initialized plugin objects in the event of a fatal error by main OpenVPN process. * When the --remote list is > 1, and --resolv-retry is not specified (meaning that it defaults to "infinite"), apply the infinite timeout to the --remote list as a whole, but try each list item only once before moving on to the next item. * Added new --syslog directive which redirects output to syslog without requiring the use of the --daemon or --inetd directives. * Added openvpn.spec option to allow RPM to be built with support for passwords read from a file: rpmbuild -tb [openvpn.x.tar.gz] --define 'with_password_save 1' James 

James, as requested the attached patch is merged with 2.1alpha3. The patch: * Adds a new --bind option to compliment the existing --nobind options. Implicit bind/nobind defaults are left unchanged. * enables --local and --lport on tcp-client connections * fixes a bug with the local_port value passed to scripts/plugins - previously this was incorrectly set to the default port if nobind was used - the patch sets it to '0' in this case. * Also, the patch adds passing of http/socks proxy address and port information to scripts/plugins. * Updates to manpage and help to reflect the changes in the patch. Rgds Ewan 

Greetings, the attached patch adds two shell scripts and two lines to Makefile.am so that the GNU-standard "make check" works. It will first run the loopback test, then the client-server test shown in the INSTALL file. The test scripts will save the output of the respective openvpn commands to a temporary file and only print these files (with cat(1)) if the loopback test or either client or server exit with nonzero code or signal. The whole setup supports VPATH builds (i. e. mkdir build ; cd build ; ../configure && make) and has in fact only been tested on such. Please apply. Kind regards, -- Matthias Andree