openvpn-devel Mailing List for OpenVPN

Hey, we did it -- OpenVPN 1.5.0 is here! While pretty exciting, the change log is (as it should be) quite mundane from 1.5-beta14 to 1.5.0. It's basically just a version number increment. I've had some requests for more file release security. I suppose the recent incident where a trojan was nearly snuck into the Linux kernel is a wake-up call. Henceforth, all file releases will be signed by GnuPG. See the "File Signatures" section on the home page for more info. I've pasted the public key which will be used to sign file releases at the end of this message. It is also available on the web site. James ************************* MD5 Sums 55d7ce958bb2ccf3d3204d1350c27179 openvpn-1.5.0.tar.gz 1c3098b4116892ff5b854250efd2345c openvpn-1.5.0.zip 483295f7a99b8cee16f05ad274a6b01e openvpn-1.5.0-install.exe SHA1 Sums 13f443adbff5c657cfd8400011e8df804b57f7ff openvpn-1.5.0.tar.gz 0bfff3bc837ff896d679b186a5d45368e0be81d7 openvpn-1.5.0.zip 8ac42299fb042d96580ea509f366e343ad102303 openvpn-1.5.0-install.exe -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.3 (GNU/Linux) mQGiBD+9OaARBAC41lHwut4og8RL+QvChit93Yg8JloaZzqvKQHMKvcb14OY27QB 00oEtwxotBRkvJHy/cR4feK9Itje556FbzC7ODesYtjZh1V81B2ep4tfwRQSPqZT xy2jwzW5SwReBuIPxBOFts+OeeLQuKFU/VSItU9abA51cvKEvaV0CZx6ZwCg/h70 OgABmkCl8u+nHK2EHMSjZAUD/RP1jLNub1wlg2vJvfty+Nu7PoDJxSG7LzsSFC6W a5KiryIMvokp3cZQ7EnTG1Jc5y5tsZrRfTa7QLcooQrYivWSCSldkAowEh/tUGwb CurQZtDAmmuqLJAG+zDh6qFINHPnkVZBMuN+Lhkg0gqo+Mgsjn0ZzuGgQYb2b3wn pXckBACZE6EJSnICN/Cn5657of5znOwixZUdl4Pvsv7X5LuUJ0SeUtfSjNfUFu0b j/s0BXpQ/Y933rS+m0axbiElRNHzwtBb4W+TzwLvkwHw5WrIw5tcZXcZpos1NkhW lUDKLQ63WMqg5SBpilo3/wFU4+ngvPMcfbL1vgMYuuWfSPRt5LQbSmFtZXMgWW9u YW4gPGppbUB5b25hbi5uZXQ+iF4EExECAB4FAj+9OaACGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQHQtJlh+/UfMaFgCeOIDuybiePnFpYbm7faiqT34NvzYAoLjO ob+WiwJECbjpV62fmItBsYI9uQINBD+9OcAQCAC4wi4knBzA3bGbb2XSnZcIt+Tf 9JGXoG7+cpLT6wGZqzaAHNdgiZZf5Gdod9ud3CcLwrc1WXJljZXBhnpNNypen6O9 uGCb9OXKO7PuYV014D0pKv96rYtgPNE7MUO101lDt7bE8Zmw+HmOpyf6TnIg8GWw 3Vj8n0HfGvsx/WW2PZ1tXxUFAbsVIU/W5EJlCAhJbaZZCBj+P0QJFGuP41E7V0iO 2UMGRbzoQrwmGQopjVrzXcWAr5NvKKd8HL4ESkp8xdZrhCukNIBE9EEt6H+EvPut KdvpH2fIUTyEeZY4zDtm0ZS0zGZBET9SdcX/+sAuseiojPKd/D67oMG5FcF7AAMG CACfOcVjPcqYAhkGo6HNrpU7HMuaxy3Tuy5HI+4kU/POlLlm2AsfmHr4BtRCFMBt uNxybJwMMew1o1E4H4RvTEfPpVS0WW2lkOcpet429xf4oX1HL2nvlLmOAaMKgLhL ZxPPTCzmjyIVIeRF8BC+VQYh346v/LocO2obbD0chO0mApVgxVhO4E0vlu0Rdmsp d7+mCuani1wS9n0lgYVnHYdxRPL/AWj11KDgKm2LjoJt0WHHyEHGMjJTUB0JhM2a EfWkimDELeAb3pjdVEtmW6aF+q8sd6tn+mM0Z2I+6kwiMsdoWzjosuvXPzFsvkWq 0QY2wWyYYsNaXscfjKnjBUcpiEkEGBECAAkFAj+9OcACGwwACgkQHQtJlh+/UfOR TACgpg5MZJMgULtP31swTRmPGZ3driAAniP+Xg3U2KxAiS9Mxf0BOen8FgW5 =eZlZ -----END PGP PUBLIC KEY BLOCK----- Public key signature: C699 B264 0C6D 404E 6454 A9AD 1D0B 4996 1FBF 51F3 

"Ian D. Bjorhovde" <ia...@mo...> said: > Hi, > > I am using 1.5-beta14, connecting from a Windows client to a Linux > server. > > I am using the TCP server/client support, and I have come across > what I think is a bug. > > I have set the --user nobody --group nobody options for my connection. > On the linux server, I have --proto tcp-server. > > When I first start openvpn (as root), I can make one connection from > my client successfully. However, if I disconnect the client, and > attempt to reconnect, I get a failure. Here is an excerpt from my > syslog (sorry for the wrapped messages): > > > Nov 18 20:38:09 sidi openvpn[22546]: OpenVPN 1.5_beta14 > i386-redhat-linux-gnu [SSL] [LZO] [PTHREAD] built on Nov 13 2003 > Nov 18 20:38:09 sidi openvpn[22546]: Static Encrypt: Cipher 'BF-CBC' > initialized with 128 bit key > Nov 18 20:38:09 sidi openvpn[22546]: Static Encrypt: Using 160 bit > message hash 'SHA1' for HMAC authentication > Nov 18 20:38:09 sidi openvpn[22546]: Static Decrypt: Cipher 'BF-CBC' > initialized with 128 bit key > Nov 18 20:38:09 sidi openvpn[22546]: Static Decrypt: Using 160 bit > message hash 'SHA1' for HMAC authentication > Nov 18 20:38:09 sidi openvpn[22546]: LZO compression initialized > Nov 18 20:38:09 sidi openvpn[22546]: TUN/TAP device tap0 opened > Nov 18 20:38:09 sidi openvpn[22546]: /sbin/ifconfig tap0 10.3.1.1 > netmask 255.255.255.0 mtu 1500 broadcast 10.3.1.255 > Nov 18 20:38:09 sidi openvpn[22546]: Data Channel MTU parms [ L:1579 > D:1579 EF:47 EB:19 ET:32 ] > Nov 18 20:38:09 sidi openvpn[22546]: Local Options hash (VER=V3): 'ecc62251' > Nov 18 20:38:09 sidi openvpn[22546]: Expected Remote Options hash > (VER=V3): '65fc6f3f' > Nov 18 20:38:09 sidi openvpn: succeeded > Nov 18 20:38:09 sidi openvpn[22551]: GID set to nobody > Nov 18 20:38:09 sidi openvpn[22551]: UID set to nobody > Nov 18 20:38:09 sidi openvpn[22551]: PTHREAD support initialized > Nov 18 20:38:09 sidi openvpn[22551]: Listening for incoming TCP > connection on 10.3.2.4:5000 > Nov 18 20:38:09 sidi openvpn[22551]: TCP connection established with > 1.1.1.1:3961 > Nov 18 20:38:09 sidi openvpn[22551]: TCPv4_SERVER link local (bound): > 10.23.8.4:5000 > Nov 18 20:38:09 sidi openvpn[22551]: TCPv4_SERVER link remote: 1.1.1.1:3961 > Nov 18 20:38:09 sidi openvpn[22551]: Peer Connection Initiated with > 1.1.1.1:3961 > Nov 18 20:38:09 sidi /etc/hotplug/net.agent: invoke ifup tap0 > Nov 18 20:38:52 sidi openvpn[22551]: Connection reset, restarting [-1] > Nov 18 20:38:52 sidi openvpn[22551]: Closing TCP/UDP socket > Nov 18 20:38:52 sidi openvpn[22551]: Closing TUN/TAP device > Nov 18 20:38:52 sidi openvpn[22551]: Restart pause, 1 second(s) > Nov 18 20:38:53 sidi /etc/hotplug/net.agent: NET unregister event not > supported > Nov 18 20:38:53 sidi openvpn[22551]: Cannot open file key file > 'speedplay.key': Permission denied (errno=13) > Nov 18 20:38:53 sidi openvpn[22551]: Exiting > > > > Notice the 'Permission denied' error on the second-to-last line. This > is directly related to the --user and --group options. If I remove > these options I can reconnect with no problem. > > I do not run into this issue if I use the UDP client. > > If I change the permissions of the key file (i.e. mode 666), I don't > get an error (rather a warning about open permissions on the key file), > but then I get the same permission denied error when trying to open the > TUN device (/dev/net/tun, mode 0600 owner: root). > > I suspect I can get around this problem with the --persist-key and > --persist-tun options, but I don't understand what's different between > the TCP and UDP clients when it comes to dropping priviliges. If you want to drop root privileges with --user and/or --group, restarts won't work unless you plan for them. In this case a restart is defined as a SIGHUP, SIGUSR1, TCP connection reset, etc. Because UDP is connectionless, there is no restart if a peer goes away, unless you are also using --ping/--ping-restart. Use one of the --persist options if you are having trouble with restarts not working because of insufficient privilege to reaccess certain resources. Also keep in mind that this sort of posting belongs more on the openvpn-users list. The -devel list is really for development issues such as patches, porting, etc. > Thanks for a great piece of software! You're welcome! James 

Ian D. Bjorhovde wrote: > I do not run into this issue if I use the UDP client. this, IS strange ... > > If I change the permissions of the key file (i.e. mode 666), I don't > get an error (rather a warning about open permissions on the key file), > but then I get the same permission denied error when trying to open the > TUN device (/dev/net/tun, mode 0600 owner: root). put a chgrp nogroup/nobody on /dev/net/tun and keys with a chmod 640 for keys and 660 for tun and it will be ok something like that # ll /dev/net/tun crw-rw-r-- 1 nobody root 10, 200 Oct 3 2002 /dev/net/tun Regards	Julien 

Hi, I am using 1.5-beta14, connecting from a Windows client to a Linux server. I am using the TCP server/client support, and I have come across what I think is a bug. I have set the --user nobody --group nobody options for my connection. On the linux server, I have --proto tcp-server. When I first start openvpn (as root), I can make one connection from my client successfully. However, if I disconnect the client, and attempt to reconnect, I get a failure. Here is an excerpt from my syslog (sorry for the wrapped messages): Nov 18 20:38:09 sidi openvpn[22546]: OpenVPN 1.5_beta14 i386-redhat-linux-gnu [SSL] [LZO] [PTHREAD] built on Nov 13 2003 Nov 18 20:38:09 sidi openvpn[22546]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 18 20:38:09 sidi openvpn[22546]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 18 20:38:09 sidi openvpn[22546]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Nov 18 20:38:09 sidi openvpn[22546]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 18 20:38:09 sidi openvpn[22546]: LZO compression initialized Nov 18 20:38:09 sidi openvpn[22546]: TUN/TAP device tap0 opened Nov 18 20:38:09 sidi openvpn[22546]: /sbin/ifconfig tap0 10.3.1.1 netmask 255.255.255.0 mtu 1500 broadcast 10.3.1.255 Nov 18 20:38:09 sidi openvpn[22546]: Data Channel MTU parms [ L:1579 D:1579 EF:47 EB:19 ET:32 ] Nov 18 20:38:09 sidi openvpn[22546]: Local Options hash (VER=V3): 'ecc62251' Nov 18 20:38:09 sidi openvpn[22546]: Expected Remote Options hash (VER=V3): '65fc6f3f' Nov 18 20:38:09 sidi openvpn: succeeded Nov 18 20:38:09 sidi openvpn[22551]: GID set to nobody Nov 18 20:38:09 sidi openvpn[22551]: UID set to nobody Nov 18 20:38:09 sidi openvpn[22551]: PTHREAD support initialized Nov 18 20:38:09 sidi openvpn[22551]: Listening for incoming TCP connection on 10.3.2.4:5000 Nov 18 20:38:09 sidi openvpn[22551]: TCP connection established with 1.1.1.1:3961 Nov 18 20:38:09 sidi openvpn[22551]: TCPv4_SERVER link local (bound): 10.23.8.4:5000 Nov 18 20:38:09 sidi openvpn[22551]: TCPv4_SERVER link remote: 1.1.1.1:3961 Nov 18 20:38:09 sidi openvpn[22551]: Peer Connection Initiated with 1.1.1.1:3961 Nov 18 20:38:09 sidi /etc/hotplug/net.agent: invoke ifup tap0 Nov 18 20:38:52 sidi openvpn[22551]: Connection reset, restarting [-1] Nov 18 20:38:52 sidi openvpn[22551]: Closing TCP/UDP socket Nov 18 20:38:52 sidi openvpn[22551]: Closing TUN/TAP device Nov 18 20:38:52 sidi openvpn[22551]: Restart pause, 1 second(s) Nov 18 20:38:53 sidi /etc/hotplug/net.agent: NET unregister event not supported Nov 18 20:38:53 sidi openvpn[22551]: Cannot open file key file 'speedplay.key': Permission denied (errno=13) Nov 18 20:38:53 sidi openvpn[22551]: Exiting Notice the 'Permission denied' error on the second-to-last line. This is directly related to the --user and --group options. If I remove these options I can reconnect with no problem. I do not run into this issue if I use the UDP client. If I change the permissions of the key file (i.e. mode 666), I don't get an error (rather a warning about open permissions on the key file), but then I get the same permission denied error when trying to open the TUN device (/dev/net/tun, mode 0600 owner: root). I suspect I can get around this problem with the --persist-key and --persist-tun options, but I don't understand what's different between the TCP and UDP clients when it comes to dropping priviliges. Thanks for a great piece of software! -Ian 

Jon Nelson <jne...@ja...> said: > On Tue, 18 Nov 2003, James Yonan wrote: > > > I'm not running 2.6 yet, but if someone gives me ssh access, I will > > fix. > > No offence, but you're not about to get access to my network. ;-) That's just a generic request, not aimed at you in particular. Most of reason why OpenVPN runs on a lot of different platforms is because remote access to these platforms has been provided in the past to ease development and testing. James 

On Tue, 18 Nov 2003, James Yonan wrote: > > That should allow openvpn to open the tun interface. > > If that works, and you can't figure out what lines in the devfs > > configuration to edit, post to this list and I'll see if I can determine > > what exactly it is that I changed in the (devfsd) config. > > I'm not running 2.6 yet, but if someone gives me ssh access, I will fix. I can offer you daytime/evening (European time zones) access on a 2.6 BK (post -test9) machine if need be, however, I don't see any difficulties on my 2.6 machine talking to a FreeBSD 4.9 hosted OpenVPN 1.4.2. I don't use devfs, so my machine may not be what you need. James, if you still need ssh access, please send your ssh2 public key. It seems the problem is devfs related (and then might be worked around with the new --dev-* options). 

On Tue, 18 Nov 2003, James Yonan wrote: > I'm not running 2.6 yet, but if someone gives me ssh access, I will > fix. No offence, but you're not about to get access to my network. ;-) > What precisely needs to be done? Honestly, I don't know. All I did was edit the devfs configuration for 'misc' devices, restarted devfsd, and it worked. > Is it just a matter of trying an alternate device node name, or is > there more involved in porting to 2.6? Again, not sure. BTW, beta14 shows nothing different over beta12, which is to say it runs just fine (with the aforementioned devfs config changes). Also note that since devfsd is now deprecated, I do *not* know what interface (if any) replaces it. I'm dipping my toe into this 2.6 water just as many others are. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jne...@ja...> 

Jon Nelson <jne...@ja...> said: > On Tue, 18 Nov 2003, Matt wrote: > > > I've had a simular problem too. 2.6 and Openvpn are a no go. > > Why? I easily got it running after just a few minutes of debugging. > Indeed, it's been working fine for me for the last few days. > Didn't you read the whole email? The solution is contained within. > If you want to simply test it out, do this: > > cd /dev/net > ln -s ../misc . > > That should allow openvpn to open the tun interface. > If that works, and you can't figure out what lines in the devfs > configuration to edit, post to this list and I'll see if I can determine > what exactly it is that I changed in the (devfsd) config. I'm not running 2.6 yet, but if someone gives me ssh access, I will fix. What precisely needs to be done? Is it just a matter of trying an alternate device node name, or is there more involved in porting to 2.6? James > > On Tuesday 18 November 2003 08:18 am, Jon Nelson wrote: > > > Just so you all know, I'm using OpenVPN 1.5beta12 (soon to be beta14) > > > with Linux 2.6.0-test9 (vanilla, no patching). > > > > > > The only problem I encountered is that I had to alter by devfs > > > configuration because the tun device has moved from /dev/net/tun to > > > /dev/misc/net/tun -- fortunately there are existing (commented out) > > > directives in the devfs configuration for this. > > -- > Democracy is two wolves and a sheep voting on what to have for dinner. > Liberty is two wolves attempting to have a sheep for dinner and > finding a well-informed, well-armed sheep. > > Jon Nelson <jne...@ja...> > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > -- 

On Tue, 18 Nov 2003, Matt wrote: > I've had a simular problem too. 2.6 and Openvpn are a no go. Why? I easily got it running after just a few minutes of debugging. Indeed, it's been working fine for me for the last few days. Didn't you read the whole email? The solution is contained within. If you want to simply test it out, do this: cd /dev/net ln -s ../misc . That should allow openvpn to open the tun interface. If that works, and you can't figure out what lines in the devfs configuration to edit, post to this list and I'll see if I can determine what exactly it is that I changed in the (devfsd) config. > On Tuesday 18 November 2003 08:18 am, Jon Nelson wrote: > > Just so you all know, I'm using OpenVPN 1.5beta12 (soon to be beta14) > > with Linux 2.6.0-test9 (vanilla, no patching). > > > > The only problem I encountered is that I had to alter by devfs > > configuration because the tun device has moved from /dev/net/tun to > > /dev/misc/net/tun -- fortunately there are existing (commented out) > > directives in the devfs configuration for this. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jne...@ja...> 

I've had a simular problem too. 2.6 and Openvpn are a no go. Matt H. On Tuesday 18 November 2003 08:18 am, Jon Nelson wrote: > Just so you all know, I'm using OpenVPN 1.5beta12 (soon to be beta14) > with Linux 2.6.0-test9 (vanilla, no patching). > > The only problem I encountered is that I had to alter by devfs > configuration because the tun device has moved from /dev/net/tun to > /dev/misc/net/tun -- fortunately there are existing (commented out) > directives in the devfs configuration for this. > > -- > Democracy is two wolves and a sheep voting on what to have for dinner. > Liberty is two wolves attempting to have a sheep for dinner and > finding a well-informed, well-armed sheep. > > Jon Nelson <jne...@ja...> > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Just so you all know, I'm using OpenVPN 1.5beta12 (soon to be beta14) with Linux 2.6.0-test9 (vanilla, no patching). The only problem I encountered is that I had to alter by devfs configuration because the tun device has moved from /dev/net/tun to /dev/misc/net/tun -- fortunately there are existing (commented out) directives in the devfs configuration for this. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jne...@ja...> 

We're getting close to a 1.5 final release... I would like to nominate OpenVPN 1.5-beta14 to be release candidate 1 for OpenVPN 1.5. Beta14 has been out for a week or so without any bugs reported thus far. If you think you've found a bug, please report it ASAP. There have been a number of reports about certain things working on early versions of the beta cycle running on Windows, i.e. before beta 8 or 9, then not working on later versions. Most of these problems have been attributed to the new --ip-win32 option which changed default behavior. The default is now --ip-win32 ipapi, but two other methods exist, "netsh" and "manual" -- please consult the man page and try these other options if you are running the Windows version of the beta and experienced problems after upgrading to recent versions of OpenVPN, i.e. beta12 or greater. If you follow the CVS, I've merged beta14 back into the HEAD branch as 1.5-rc1, and started a new branch BETA20 for ongoing development of major new features such as forking server support and point-to-multipoint mode which will ultimately be released as OpenVPN 2.0. Bug fixes and minor or moderate feature additions will go into the HEAD branch for release on a shorter development & test cycle. James 

i'm testing ntop2 (2.2.95 to be precise on linux) to monitor some openvpn tunnel. one question arise: how could ntop get Headersize/mtu/maybe others from openvpn/proc/else ? Thanks & Regards	Julien -------- Original Message -------- Subject: [Ntop] Unknown DLT types (was a useless title) Date: Fri, 31 Oct 2003 16:21:22 -0600 From: Burton M. Strauss III <Bu...@nt...> Reply-To: nt...@un... Organization: Centro di Servizi per la rete di Ateneo - Pisa - Italy To: <nt...@Un...> CC: <jul...@ly...> If you can figure out the data link level header length and the associated DLT code, you can try adding them to the table in globals-core.c at 380ff: _mtuSize[DLT_NULL] = 8232 /* no link-layer encapsulation */; _headerSize[DLT_NULL] = CONST_NULL_HDRLEN; /* 1500 + 14 bytes header Courtesy of Andreas Pfaller <a.p...@po...> */ _mtuSize[DLT_EN10MB] = 1500+sizeof(struct ether_header) /* Ethernet (10Mb) */; _headerSize[DLT_EN10MB] = sizeof(struct ether_header); ... -----Burton 

> - Generic OpenVPN settings: > cipher bf-cbc > dev tap > tun-mtu 1500 > tun-mtu-extra 32 > - OpenVPN-TCP settings: > proto tcp-client > - OpenVPN-UDP settings: > proto udp > - OpenVPN-UDP-LZO settings: > proto udp > comp-lzo You could improve the UDP performance of this config with two changes: (1) Use "dev tun". (2) Clamp the TCP MSS using the --mssfix option. You want to use the largest mssfix value which will not cause fragmentation. Try 1400 or 1450. James 

Teemu Kiviniemi <te...@ik...> said: > Hi, > > I had some performance problems with TINC running on Windows XP. I had a > VPN tunnel running over a wireless network to a Linux VPN server. Web > browsing through the tunnel was a pain. Big web pages with lots of > pictures loaded very slow compared to a plain network connection. > > When the VPN client was running on a Linux computer, and a Windows > computer was browsing the web through the VPN tunnel, everything worked > just fine. The performance of web browsing through the tunnel was about > the same as with a plain unencrypted network connection. > > I recently tested the setup with OpenVPN on Windows too, but the > performance of web browsing didn't get better. Were you using --dev tun or --dev tap? I have found that --dev tun has a speed advantage, especially between linux and windows. > The speed of a single file transfer through the tunnel was quite good. > Browsing a complex web page creates a lot of simultaneous transfers from > the web server to the browser. I thought that the problem must have > something to do with simultaneous transfers. > > I did some tests of OpenVPN and TINC performance on a Windows client. > Specifically, I was looking at the performance of multiple simultaneous > transfers and PING latency/packet loss during the transfer. Performance here will really be a function of the TCP implementation's algorithms for rate and congestion control. > Test method: > - three simultaneous FTP downloads are started on the Windows computer > (file size 7612995 bytes) > - at the same time, the Linux computer pings the Windows computer to see > the latency and packet loss of the tunnel during the transfer. > - record the transfer times, packet loss and latency > - repeat three times, calculate the average > > **** > > Test setup: > > Network: 10Mbps switched Ethernet, only test computers connected > > VPN client: > - Windows Server 2003 > - TINC 1.0.1 (Windows installer version) > - OpenVPN 1.5 beta12 (Windows installer version) > - Windows command line FTP client > > VPN server: > - Debian Woody > - 2.4.20 kernel > - TINC 1.0pre8 > - OpenVPN 1.5 beta12 > - OpenBSD FTP server > > VPN client settings: > > - Generic OpenVPN settings: > cipher bf-cbc > dev tap > tun-mtu 1500 > tun-mtu-extra 32 > - OpenVPN-TCP settings: > proto tcp-client > - OpenVPN-UDP settings: > proto udp > - OpenVPN-UDP-LZO settings: > proto udp > comp-lzo > > - Generic TINC settings: > Mode = switch > PriorityInheritance = no > Cipher = blowfish > Compression = 0 > MACLength = 4 > - TINC-TCP settings: > TCPonly = yes > - TINC-UDP settings: > TCPonly = no > > **** > > Test results: > > PING: packet loss: > - plain network:	0% > - OpenVPN-TCP:	0% > - OpenVPN-UDP:	27,3% > - OpenVPN-UDP-LZO:	25% > - TINC-TCP:	19,3% > - TINC-UDP:	52% > > OpenVPN-TCP works as well as the plain network connection during the > transfers. The other tunnels drop too much packets to be usable. > > PING: latency, min/avg/max (ms): > - plain network:	1,2/9,1/50,7 > - OpenVPN-TCP:	4,5/121,1/352,6 > - OpenVPN-UDP:	3,7/25,7/88,9 > - OpenVPN-UDP-LZO:	3,5/25,4/79,0 > - TINC-TCP:	7,3/34,4/88,9 > - TINC-UDP:	4,1/14,5/75,9 > > The maximum latency of TINC-TCP doesn't get as big as the latency of > OpenVPN-TCP, but that might have something to do with the large packet > loss TINC-TCP is having. > > FTP: transfer times FTP1/FTP2/FTP3/total (s): > - plain network:	24,0/24,6/24,9/73,5 > - OpenVPN-TCP:	52,2/52,3/52,3/156,9 > - OpenVPN-UDP:	57,5/56,8/68,9/183,1 > - OpenVPN-UDP-LZO:	62,8/64,5/70,4/197,7 > - TINC-TCP:	160,1/148,1/137,7/445,9 > - TINC-UDP:	57,6/85,9/63,9/207,3 > > OpenVPN-TCP is clearly the fastest tunnel. TINC-TCP is way too slow, and > UDP tunnels are somewhat slower than OpenVPN-TCP. > > FTP: difference of the simultaneous transfer times: > (slowest transfer time/fastest transfer time*100-100) > - plain network:	3,9% > - OpenVPN-TCP:	0,4% > - OpenVPN-UDP:	35,0% > - OpenVPN-UDP-LZO:	37,9% > - TINC-TCP:	17,4% > - TINC-UDP:	75,9% > > OpenVPN-TCP wins again. It provides the most consistent transfer times > for the simultaneous transfers. > > Subjective analysis: > > I had the hash printing of the FTP clients enabled, so I could see the > transfer progress. All the UDP tunnels and TINC-TCP provided very > inconsistent transfer speeds. One FTP client could transfer very fast, > while two were transferring slower, if transferring anything at all. The > transfers over a plain network connection and OpenVPN-TCP ran without > delays, and the speed of all the transfers looked the same. It's interesting that you got better TCP performance. In my experience, on "clean" networks with negligable packet loss, TCP does slightly worse than UDP. My guess is that you are seeing OpenVPN in TCP mode working correctly, but there may be some kind of network or configuration problem causing the poor UDP results. > **** > > I have had these performance problems only with a Windows client. A > TINC-UDP VPN tunnel between two Linux computers runs perfectly. > > Has anyone else had problems like this? Can anyone verify my results > with another setup? I haven't got access to other computers at the > moment. What could cause the problems on Windows? The only performance problem I've noticed is with the linux tap driver (the tun driver is fine). On a Windows <-> Linux FTP, locally connected to a 100mbps ethernet hub, the bandwidth is much more consistent if I use tun rather than tap. James 

Hi, I had some performance problems with TINC running on Windows XP. I had a VPN tunnel running over a wireless network to a Linux VPN server. Web browsing through the tunnel was a pain. Big web pages with lots of pictures loaded very slow compared to a plain network connection.=20 When the VPN client was running on a Linux computer, and a Windows computer was browsing the web through the VPN tunnel, everything worked just fine. The performance of web browsing through the tunnel was about the same as with a plain unencrypted network connection. I recently tested the setup with OpenVPN on Windows too, but the performance of web browsing didn't get better. The speed of a single file transfer through the tunnel was quite good. Browsing a complex web page creates a lot of simultaneous transfers from the web server to the browser. I thought that the problem must have something to do with simultaneous transfers. I did some tests of OpenVPN and TINC performance on a Windows client. Specifically, I was looking at the performance of multiple simultaneous transfers and PING latency/packet loss during the transfer. **** Test method: - three simultaneous FTP downloads are started on the Windows computer (file size 7612995 bytes) - at the same time, the Linux computer pings the Windows computer to see the latency and packet loss of the tunnel during the transfer. - record the transfer times, packet loss and latency - repeat three times, calculate the average **** Test setup: Network: 10Mbps switched Ethernet, only test computers connected VPN client: - Windows Server 2003 - TINC 1.0.1 (Windows installer version) - OpenVPN 1.5 beta12 (Windows installer version) - Windows command line FTP client VPN server: - Debian Woody - 2.4.20 kernel - TINC 1.0pre8 - OpenVPN 1.5 beta12 - OpenBSD FTP server VPN client settings: - Generic OpenVPN settings: cipher bf-cbc dev tap tun-mtu 1500 tun-mtu-extra 32 - OpenVPN-TCP settings: proto tcp-client - OpenVPN-UDP settings: proto udp - OpenVPN-UDP-LZO settings: proto udp comp-lzo - Generic TINC settings: Mode =3D switch PriorityInheritance =3D no Cipher =3D blowfish Compression =3D 0 MACLength =3D 4 - TINC-TCP settings: TCPonly =3D yes - TINC-UDP settings: TCPonly =3D no **** Test results: PING: packet loss: - plain network:	0% - OpenVPN-TCP:	0% - OpenVPN-UDP:	27,3% - OpenVPN-UDP-LZO:	25% - TINC-TCP:	19,3% - TINC-UDP:	52% OpenVPN-TCP works as well as the plain network connection during the transfers. The other tunnels drop too much packets to be usable. PING: latency, min/avg/max (ms): - plain network:	1,2/9,1/50,7 - OpenVPN-TCP:	4,5/121,1/352,6 - OpenVPN-UDP:	3,7/25,7/88,9 - OpenVPN-UDP-LZO:	3,5/25,4/79,0 - TINC-TCP:	7,3/34,4/88,9 - TINC-UDP:	4,1/14,5/75,9 The maximum latency of TINC-TCP doesn't get as big as the latency of OpenVPN-TCP, but that might have something to do with the large packet loss TINC-TCP is having. FTP: transfer times FTP1/FTP2/FTP3/total (s): - plain network:	24,0/24,6/24,9/73,5 - OpenVPN-TCP:	52,2/52,3/52,3/156,9 - OpenVPN-UDP:	57,5/56,8/68,9/183,1 - OpenVPN-UDP-LZO:	62,8/64,5/70,4/197,7 - TINC-TCP:	160,1/148,1/137,7/445,9 - TINC-UDP:	57,6/85,9/63,9/207,3 OpenVPN-TCP is clearly the fastest tunnel. TINC-TCP is way too slow, and UDP tunnels are somewhat slower than OpenVPN-TCP. FTP: difference of the simultaneous transfer times: (slowest transfer time/fastest transfer time*100-100) - plain network:	3,9% - OpenVPN-TCP:	0,4% - OpenVPN-UDP:	35,0% - OpenVPN-UDP-LZO:	37,9% - TINC-TCP:	17,4% - TINC-UDP:	75,9% OpenVPN-TCP wins again. It provides the most consistent transfer times for the simultaneous transfers. Subjective analysis: I had the hash printing of the FTP clients enabled, so I could see the transfer progress. All the UDP tunnels and TINC-TCP provided very inconsistent transfer speeds. One FTP client could transfer very fast, while two were transferring slower, if transferring anything at all. The transfers over a plain network connection and OpenVPN-TCP ran without delays, and the speed of all the transfers looked the same. **** I have had these performance problems only with a Windows client. A TINC-UDP VPN tunnel between two Linux computers runs perfectly. Has anyone else had problems like this? Can anyone verify my results with another setup? I haven't got access to other computers at the moment. What could cause the problems on Windows? Thanks, Teemu 

Release notes: The often-requested HTTP proxy feature has been added to allow OpenVPN to connect to its remote peer through an HTTP proxy using the HTTP CONNECT method. Basic HTTP authentication is supported as an option. For more info, see the --http-proxy option. The --redirect-gateway feature has been added which redirects all IP traffic into the tunnel. Many of the changes in this release involve minor additions to the crypto layer. The --secret and --tls-auth options now support key directionality, where different keys can be used for both data flow directions. To use the new key directionality feature, you must generate a new key with --genkey, then add a direction parameter to --secret or --tls-auth. See the man page for details. The --tls-auth option now accepts an OpenVPN static key file generated by --genkey. Freeform files can still be used with --tls-auth -- they will be hashed to generate an HMAC key. The replay protection logic now exports two parameters which previously were held constant. See the --replay-window option. A --key-method option has been added which can be used to select one of two different data channel key generation methods to be used in TLS mode. Key method 1 is the original, default key generation method. Key method 2 is new and uses the TLS PRF function. A Certificate Revocation List capability has been added. None of the crypto changes affect key file or protocol compatibility with previous releases, however all of the new crypto options (with the exception of --replay-window) require current versions of OpenVPN on both sides of the connection. 

> Farkas Levente <lf...@bn...> said: > >> James Yonan wrote: >> > Farkas Levente <lf...@bn...> said: >> > >> > >> >>Mathias Sundman wrote: >> >> >> >>>Hi! >> >>> >> >>> > we use our linux vpn gateway and some win2000 road warrior clien= ts >> with >> >>> > openvpn. I would like to route all internet traffic trough our >> firewall >> >>> > from the windows clients. >> >>> >> >>> I=B4ve been thinking about doing this too, but never accually trie= d >> it. >> >>> >> >>> What you basicly need to do is: >> >>> >> >>> 1. Don=B4t set a default gateway on your ethernet adapter. >> >> >> >>you have to set otherwise the vpn connection can't estabilished. >> >> >> >> >> >>> 2. Add a route to your openvpn server with a /32 mask pointing to >> the >> >>> gateway on your ethernet. >> >>> >> >>> In your exampel this would be done with the following command o= n >> >>> Win2K where w.x.y.z is the IP of your remote openvpn server, >> >>> and a.b.c.254 is your local gateway. >> >>> >> >>> ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254 >> >>> >> >>> 3. Setup OpenVPN as usual but also add a default gateway route to >> >>> the TAP interface. >> >>> >> >>> >> >>> The reason why I havn=B4t tried this is because I don=B4t know how= to >> solve >> >>> the problem that the ROUTE command will be diffrent for each netwo= rk >> you >> >>> hook your laptop into. So if you don=B4t want to manually do this >> every >> >>> time, you would need to write a little app that looks at the IP an= d >> >>> default gateway that has been assigned by DHCP, switch to static I= P >> and >> >>> add the correct route. >> >>> >> >>> Anyone that has a better solution to this? >> >> >> >>you see exactly the problem! >> >>on linux I can do (eg. in the up script): >> >>---------------------------------- >> >>route add -host <remote-server-ip> dev ppp0 >> >>route del default dev ppp0 >> >>route add default dev tun0 >> >>---------------------------------- >> >>and we got it, but unfotunately on windows you can't route by >> interface >> >>(or to be more precise on windos the interface is defined by it's ip >> >>address even if you can specify the interface). >> >>so I'd like to suggest a new option for openvpn to be portable (like >> in >> >>the case of --route): >> >>--route-internal >> >> which do exactly as the above on all platform. >> >>since openvpn know whcih ip address has the under the tun/tap >> interface. >> >>or may it would be more better if the up script has one more (6th) >> >>paramter and the underlying interface's ip address: >> >>----------------------------------- >> >>cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip >> >>underlying_ip [ init | restart ] >> >>cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask >> >>underlying_ip [ init | restart ] >> >>----------------------------------- >> >>and in this case on linux we cn write an up script as: >> >>---------------------------------- >> >>route add -host $5 dev ppp0 >> >>route del default dev ppp0 >> >>route add default dev tun0 >> >>---------------------------------- >> >>while on windows >> >>---------------------------------- >> >>route add $5 gw $6 >> >>route delete 0.0.0.0 mask 0.0.0.0 $5 >> >>route add 0.0.0.0 mask 0.0.0.0 $4 >> >>---------------------------------- >> >>does it possible? or any better solution? >> > >> > >> > When you say "underlying_ip" I assume you mean the original default >> gateway >> > (before the up script (might have) changed it)? >> > >> > I agree that it would be useful to provide an "original default >> gateway" >> > parameter to up scripts. >> >> yes. >> >> > This would provide the support necessary to conveniently route all I= P >> traffic >> > through the VPN tunnel. >> > >> > Unfortunately, as is often the case with network configuration, ther= e >> is no >> > standard API for doing this. >> > >> > To make this work in OpenVPN, you would need to follow the model of >> tun.c and >> > route.c where there is a function such as get_default_gateway that h= as >> a bunch >> > of #ifdefs for each platform. >> > >> > If you want this to work on Windows right now, I would suggest you r= un >> "route >> > print" in your up script and pipe the output to a program which pars= es >> out the >> > "default gateway" information and returns it to the script. >> >> that's what I wouldn't like to! if openvpn already contains this code >> (get_default_gateway) and you knoe that this is very difficult to find >> out than why openvpn provide it for us? >> that would be a big help! >> thanks in advace:-) > > Good news. I threw together some code under a new flag called > --redirect-gateway that will do the routing smarts to redirect the defa= ult > gateway into the tunnel, and undo its actions on tun/tap close. > > Keep in mind that there's no standard API for getting the current defau= lt > gateway. That means there's yet another #if block at the bottom of > route.c > for each platform's version of get_default_gateway(). I've only > implemented > for Linux and Windows so far. > > It will be out with beta13... If you are adventurous, the patch is alre= ady > committed to the CVS, if you'd like to test or add support for other OS= es > besides Linux and Windows. thanks!!! I'll try tomorrow. I just make this small patch to your code to conform better to your codin= g style:-) ------------------------------------- --- ./route.c.lfarkas 2003-11-02 10:57:38.000000000 +0100 +++ ./route.c 2003-11-02 11:06:46.000000000 +0100 @@ -709,11 +709,12 @@ * to get the current default gateway. */ -#if defined(WIN32) - static bool get_default_gateway (in_addr_t *ret) { + +#if defined(WIN32) + ULONG size =3D 0; DWORD status; @@ -747,14 +748,9 @@ } } } - return false; -} #elif defined(TARGET_LINUX) -static bool -get_default_gateway (in_addr_t *ret) -{ FILE *fp =3D fopen ("/proc/net/route", "r"); if (fp) { @@ -794,15 +790,10 @@ } fclose (fp); } - return false; -} #else +#endif -static bool -get_default_gateway (in_addr_t *ret) -{ return false; } -#endif ------------------------------------- 

Farkas Levente <lf...@bn...> said: > James Yonan wrote: > > Farkas Levente <lf...@bn...> said: > > > > > >>Mathias Sundman wrote: > >> > >>>Hi! > >>> > >>> > we use our linux vpn gateway and some win2000 road warrior clients with > >>> > openvpn. I would like to route all internet traffic trough our firewall > >>> > from the windows clients. > >>> > >>> I´ve been thinking about doing this too, but never accually tried it. > >>> > >>> What you basicly need to do is: > >>> > >>> 1. Don´t set a default gateway on your ethernet adapter. > >> > >>you have to set otherwise the vpn connection can't estabilished. > >> > >> > >>> 2. Add a route to your openvpn server with a /32 mask pointing to the > >>> gateway on your ethernet. > >>> > >>> In your exampel this would be done with the following command on > >>> Win2K where w.x.y.z is the IP of your remote openvpn server, > >>> and a.b.c.254 is your local gateway. > >>> > >>> ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254 > >>> > >>> 3. Setup OpenVPN as usual but also add a default gateway route to > >>> the TAP interface. > >>> > >>> > >>> The reason why I havn´t tried this is because I don´t know how to solve > >>> the problem that the ROUTE command will be diffrent for each network you > >>> hook your laptop into. So if you don´t want to manually do this every > >>> time, you would need to write a little app that looks at the IP and > >>> default gateway that has been assigned by DHCP, switch to static IP and > >>> add the correct route. > >>> > >>> Anyone that has a better solution to this? > >> > >>you see exactly the problem! > >>on linux I can do (eg. in the up script): > >>---------------------------------- > >>route add -host <remote-server-ip> dev ppp0 > >>route del default dev ppp0 > >>route add default dev tun0 > >>---------------------------------- > >>and we got it, but unfotunately on windows you can't route by interface > >>(or to be more precise on windos the interface is defined by it's ip > >>address even if you can specify the interface). > >>so I'd like to suggest a new option for openvpn to be portable (like in > >>the case of --route): > >>--route-internal > >> which do exactly as the above on all platform. > >>since openvpn know whcih ip address has the under the tun/tap interface. > >>or may it would be more better if the up script has one more (6th) > >>paramter and the underlying interface's ip address: > >>----------------------------------- > >>cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip > >>underlying_ip [ init | restart ] > >>cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask > >>underlying_ip [ init | restart ] > >>----------------------------------- > >>and in this case on linux we cn write an up script as: > >>---------------------------------- > >>route add -host $5 dev ppp0 > >>route del default dev ppp0 > >>route add default dev tun0 > >>---------------------------------- > >>while on windows > >>---------------------------------- > >>route add $5 gw $6 > >>route delete 0.0.0.0 mask 0.0.0.0 $5 > >>route add 0.0.0.0 mask 0.0.0.0 $4 > >>---------------------------------- > >>does it possible? or any better solution? > > > > > > When you say "underlying_ip" I assume you mean the original default gateway > > (before the up script (might have) changed it)? > > > > I agree that it would be useful to provide an "original default gateway" > > parameter to up scripts. > > yes. > > > This would provide the support necessary to conveniently route all IP traffic > > through the VPN tunnel. > > > > Unfortunately, as is often the case with network configuration, there is no > > standard API for doing this. > > > > To make this work in OpenVPN, you would need to follow the model of tun.c and > > route.c where there is a function such as get_default_gateway that has a bunch > > of #ifdefs for each platform. > > > > If you want this to work on Windows right now, I would suggest you run "route > > print" in your up script and pipe the output to a program which parses out the > > "default gateway" information and returns it to the script. > > that's what I wouldn't like to! if openvpn already contains this code > (get_default_gateway) and you knoe that this is very difficult to find > out than why openvpn provide it for us? > that would be a big help! > thanks in advace:-) Good news. I threw together some code under a new flag called --redirect-gateway that will do the routing smarts to redirect the default gateway into the tunnel, and undo its actions on tun/tap close. Keep in mind that there's no standard API for getting the current default gateway. That means there's yet another #if block at the bottom of route.c for each platform's version of get_default_gateway(). I've only implemented for Linux and Windows so far. It will be out with beta13... If you are adventurous, the patch is already committed to the CVS, if you'd like to test or add support for other OSes besides Linux and Windows. James 

James Yonan wrote: > Farkas Levente <lf...@bn...> said: >=20 >=20 >>Mathias Sundman wrote: >> >>>Hi! >>> >>> > we use our linux vpn gateway and some win2000 road warrior clients = with >>> > openvpn. I would like to route all internet traffic trough our fire= wall >>> > from the windows clients. >>> >>> I=B4ve been thinking about doing this too, but never accually tried i= t. >>> >>> What you basicly need to do is: >>> >>> 1. Don=B4t set a default gateway on your ethernet adapter. >> >>you have to set otherwise the vpn connection can't estabilished. >> >> >>> 2. Add a route to your openvpn server with a /32 mask pointing to the >>> gateway on your ethernet. >>> >>> In your exampel this would be done with the following command on >>> Win2K where w.x.y.z is the IP of your remote openvpn server, >>> and a.b.c.254 is your local gateway. >>> >>> ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254 >>> >>> 3. Setup OpenVPN as usual but also add a default gateway route to >>> the TAP interface. >>> >>> >>> The reason why I havn=B4t tried this is because I don=B4t know how to= solve >>> the problem that the ROUTE command will be diffrent for each network = you >>> hook your laptop into. So if you don=B4t want to manually do this eve= ry >>> time, you would need to write a little app that looks at the IP and >>> default gateway that has been assigned by DHCP, switch to static IP a= nd >>> add the correct route. >>> >>> Anyone that has a better solution to this? >> >>you see exactly the problem! >>on linux I can do (eg. in the up script): >>---------------------------------- >>route add -host <remote-server-ip> dev ppp0 >>route del default dev ppp0 >>route add default dev tun0 >>---------------------------------- >>and we got it, but unfotunately on windows you can't route by interface= =20 >>(or to be more precise on windos the interface is defined by it's ip=20 >>address even if you can specify the interface). >>so I'd like to suggest a new option for openvpn to be portable (like in= =20 >>the case of --route): >>--route-internal >> which do exactly as the above on all platform. >>since openvpn know whcih ip address has the under the tun/tap interface= . >>or may it would be more better if the up script has one more (6th)=20 >>paramter and the underlying interface's ip address: >>----------------------------------- >>cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip=20 >>underlying_ip [ init | restart ] >>cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask=20 >>underlying_ip [ init | restart ] >>----------------------------------- >>and in this case on linux we cn write an up script as: >>---------------------------------- >>route add -host $5 dev ppp0 >>route del default dev ppp0 >>route add default dev tun0 >>---------------------------------- >>while on windows >>---------------------------------- >>route add $5 gw $6 >>route delete 0.0.0.0 mask 0.0.0.0 $5 >>route add 0.0.0.0 mask 0.0.0.0 $4 >>---------------------------------- >>does it possible? or any better solution? >=20 >=20 > When you say "underlying_ip" I assume you mean the original default gat= eway > (before the up script (might have) changed it)? >=20 > I agree that it would be useful to provide an "original default gateway= " > parameter to up scripts. yes. > This would provide the support necessary to conveniently route all IP t= raffic > through the VPN tunnel. >=20 > Unfortunately, as is often the case with network configuration, there i= s no > standard API for doing this. >=20 > To make this work in OpenVPN, you would need to follow the model of tun= .c and > route.c where there is a function such as get_default_gateway that has = a bunch > of #ifdefs for each platform. >=20 > If you want this to work on Windows right now, I would suggest you run = "route > print" in your up script and pipe the output to a program which parses = out the > "default gateway" information and returns it to the script. that's what I wouldn't like to! if openvpn already contains this code=20 (get_default_gateway) and you knoe that this is very difficult to find=20 out than why openvpn provide it for us? that would be a big help! thanks in advace:-) > Then you can do the little routing dance where you route the VPN endpoi= nt to > the original default gateway, then reset the default gateway to point t= o the > TAP adapter. that's the easier part if we already know it. --=20 Levente "Si vis pacem para bellum!"