openvpn-devel Mailing List for OpenVPN

OpenVPN 2.1_rc2 has been released which includes a number of miscellaneous fixes, including better Vista support on 32-bit x86. Download: http://openvpn.net/download.html Change Log: http://openvpn.net/changelog-beta.html James 

Good day, I have recently posted an issue on the users mailing list about a loss of connectivity when adding new pushed routes to an existing configuration with live clients. As I already posted a lot of data on that list I didn't want to flood this list as well (unless someone wants more data). In my test scenario, I have a CentOS 4 Linux based OpenVPN server running v2.0.7. I have two clients running Windows XP SP2 and v2.0.9 (I also tested with v2.1-RC1). I am using TCP and am using a TUN interface. The problem occurs when I modify the openvpn.conf file on the server and perform a "service openvpn reload" (the same occurs if I completely restart the openvpn service as well). The clients will lose their connection and attempt to reconnect. During the reconnect process, they will delete the existing push routes and attempt to add the new set of routes. In my first test one client succeeded while the other failed (OpenVPN 2.0.9). In my second test (OpenVPN 2.1-RC1) both clients failed on configuring the new routes. Lastly, both clients appear to be connected to OpenVPN, but since they have no usable routes, they cannot communicate with the server. Completely stopping and restarting the client resolves the issue. The problem appears to be caused by the reconnect process missing one key step. For the client that succeeded, I noticed this entry in the log right before it added the new routes: Mon Feb 26 19:35:13 2007 Route: Waiting for TUN/TAP interface to come up... The times that it failed I did not see this line. So it appears that there is a bug in the client software that allows the process to continue before waiting for the TUN/TAP interface to come back up. Can anyone else verify that this is a bug? Any thoughts on how to resolve this? I have a situation where I can have 50+ active clients at any given time. I need to add two routes to my configuration and it is not feasible to ask everyone to close and reconnect their VPN client every time a change is made. Thanks! Jeff 

Hi! =20 After a network failure, OpenVPN client reconnects to the server, but = fails to set up the default route. An USR1 signal then makes it reconnect properly (not visible in the logs = below). Note that the server IP is resolved just fine (how else could it then = connect?) =20 Regards, David =20 server : OpenVPN 2.0.8 on OpenWRT client : OpenVPN 2.0.9 on Windows 2003 =20 timeline : 09:47 establish connection for the first time , OK 10:43 network disconnect 10:44 network is back, reconnect OK, but gateway not set =20 Client log (I replaced real server IP with 99.88.77.66 and FQHN with = my.openvpn.server.example.org): =20 Tue Feb 27 09:47:21 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on = Oct 1 2006 Tue Feb 27 09:47:21 2007 IMPORTANT: OpenVPN's default port number is now = 1194, based on an official port number assignment by IANA. OpenVPN = 2.0-beta16 and earlier used 5000 as the default port. Tue Feb 27 09:47:21 2007 ******* WARNING *******: null cipher specified, = no encryption will be used Tue Feb 27 09:47:21 2007 TAP-WIN32 device [Local Area Connection 2] = opened: \\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap Tue Feb 27 09:47:21 2007 Notified TAP-Win32 driver to set a DHCP = IP/netmask of 10.4.0.2/255.255.255.252 on interface = {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} [DHCP-serv: 10.4.0.1, lease-time: = 31536000] Tue Feb 27 09:47:21 2007 Successful ARP Flush on interface [2] = {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} Tue Feb 27 09:47:21 2007 UDPv4 link local (bound): [undef]:1194 Tue Feb 27 09:47:21 2007 UDPv4 link remote: 99.88.77.66:4500 Tue Feb 27 09:47:25 2007 Peer Connection Initiated with 99.88.77.66:4500 Tue Feb 27 09:47:26 2007 Initialization Sequence Completed Tue Feb 27 10:43:54 2007 Inactivity timeout (--ping-restart), restarting Tue Feb 27 10:43:54 2007 SIGUSR1[soft,ping-restart] received, process = restarting Tue Feb 27 10:43:56 2007 IMPORTANT: OpenVPN's default port number is now = 1194, based on an official port number assignment by IANA. OpenVPN = 2.0-beta16 and earlier used 5000 as the default port. Tue Feb 27 10:43:56 2007 ******* WARNING *******: null cipher specified, = no encryption will be used Tue Feb 27 10:44:08 2007 RESOLVE: Cannot resolve host address: = my.openvpn.server.example.org: [NO_DATA] The requested name is valid but = does not have an IP address. Tue Feb 27 10:44:08 2007 TAP-WIN32 device [Local Area Connection 2] = opened: \\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap Tue Feb 27 10:44:08 2007 Notified TAP-Win32 driver to set a DHCP = IP/netmask of 10.4.0.2/255.255.255.252 on interface = {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} [DHCP-serv: 10.4.0.1, lease-time: = 31536000] Tue Feb 27 10:44:08 2007 Successful ARP Flush on interface [2] = {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} Tue Feb 27 10:44:08 2007 UDPv4 link local (bound): [undef]:1194 Tue Feb 27 10:44:08 2007 UDPv4 link remote: 99.88.77.66:4500 Tue Feb 27 10:44:16 2007 Peer Connection Initiated with 99.88.77.66:4500 Tue Feb 27 10:44:17 2007 NOTE: unable to redirect default gateway -- = Cannot obtain current remote host address Tue Feb 27 10:44:17 2007 Initialization Sequence Completed =20 server log (I replaced real client IP with 1.2.3.4): =20 Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58887 Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Initialization = Sequence Completed Feb 27 09:47:33 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58905 Feb 27 09:48:15 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58923 Feb 27 09:49:03 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58940 Feb 27 09:49:45 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58954 Feb 27 09:50:33 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58968 Feb 27 09:51:13 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58980 Feb 27 09:52:02 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:58995 Feb 27 09:53:45 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59026 Feb 27 09:54:43 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59045 Feb 27 09:55:24 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59060 Feb 27 09:56:04 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59075 Feb 27 09:56:45 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59085 Feb 27 09:58:27 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59129 Feb 27 09:59:18 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59158 Feb 27 09:59:59 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59171 Feb 27 10:02:22 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59216 Feb 27 10:03:02 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59233 Feb 27 10:03:43 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59246 Feb 27 10:04:24 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59260 Feb 27 10:05:15 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59282 Feb 27 10:09:30 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59364 Feb 27 10:10:11 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59381 Feb 27 10:43:19 (none) kern.notice openvpn[7411]: Inactivity timeout = (--ping-restart), restarting Feb 27 10:43:19 (none) kern.notice openvpn[7411]: = SIGUSR1[soft,ping-restart] received, process restarting Feb 27 10:43:21 (none) kern.notice openvpn[7411]: Re-using pre-shared = static key Feb 27 10:43:21 (none) kern.notice openvpn[7411]: Preserving previous = TUN/TAP instance: tun2 Feb 27 10:43:21 (none) kern.notice openvpn[7411]: UDPv4 link local = (bound): [undef]:4500 Feb 27 10:43:21 (none) kern.notice openvpn[7411]: UDPv4 link remote: = [undef] Feb 27 10:43:34 (none) kern.notice openvpn[7411]: Peer Connection = Initiated with 1.2.3.4:59381 Feb 27 10:43:35 (none) kern.notice openvpn[7411]: Initialization = Sequence Completed client config : =20 remote my.openvpn.server.example.org 4500 dev tun1 ifconfig 10.4.0.2 10.4.0.1 route-gateway 10.4.0.1 redirect-gateway def1 ping 10 ping-restart 60 verb 1 mute 5 cipher none secret key 0 server config : =20 port 4500 dev tun2 ifconfig 10.4.0.1 10.4.0.2 secret /etc/openvpn/key_1 1 ping 10 ping-restart 60 ping-timer-rem verb 1 mute 5 cipher none persist-key persist-tun user nobody group nogroup 

Hi there, I've sent this already to the OpenVPN-User list but it might be possible that is better fits here: ---- 8< ----- snip ----- 8< ----- now something tricky: :) I connect to an openvpn server which provides some routes to the clients via push "route <subnet> <mask>" Works fine with all clients. Now I try to re-route some hosts on one of my clients (roadwarrior) to the machine's default gateway and use something like route <address> 255.255.255.255 net_gateway in the client's config-file. But it only tells me Feb 6 11:13:06 mordor ovpn-telefonica[18309]: OpenVPN ROUTE: net_gateway undefined -- unable to get default gateway from system Feb 6 11:13:06 mordor ovpn-telefonica[18309]: OpenVPN ROUTE: failed to parse/resolve route for host/network: <address> The client uses a ADSL DialIn and the routing tables look like this (only the necessary part): <IPADDRESS> 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 An a machine with a 2.4 kernel it looks like <IPADDRESS> 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 0.0.0.0 <IPADDRESS> 0.0.0.0 UG 0 0 0 ppp0 and here it works fine. Is there any solution how I can use the net_gateway option? I'll appreciate any help! Regards, Michael 

Hey Gang, I've just installed a RHEL5 based desktop (based on beta2) and got hold of openvpn and lzo2 from dag wieers. My initial install of openvpn (2.0.9), shows connectivity without any problems (as I have been previously using with a RHEL4 based desktop), however very bad network performance. So I recompiled everything (using the src.rpms on dag wieers site) and still the same problem. I've confirmed its not my laptop, but using my compiled RPMs on a completely differnet laptop (still using the RHEL5 based desktop). If I go back to my RHEL4 based laptop, everything performs quite well. My quick analysis of the performance using ping shows that an idle OpenVPN link having a ping response time of a few milliseconds, however, when I connect to a webserver on the other side of the link, the ping response time increases to over 3000 ms - and making everything from the remote network painfully slow. Anybody got any ideas why it might be this way? (Its unusable). ...deon --- Deon George, Tivoli Storage Technical Pre-Sales Specialist, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816 VOIP: +61 2 8852 3469 mailto:dg...@au..., http://ibm.com/tivoli

<snip> As promised, the necessary patches for the OpenVPN source, along with the binaries and other bits and pieces necessary to get OpenVPN running on Windows Vista RTM. http://blog.tomdot.net/2007/02/openvpn-gui-running-on-windows-vista.html Tom Fanning 

A quick look at the recent archives didn't turn anything obvious up, so I thought I'd post this. I've spent a bit of time getting OpenVPN (and GUI) to run on Windows Vista RTM, with success. Some versions of the TAP driver caused Vista to bluescreen. Someone fixed this*, but in the RTM build of Vista (6000) Microsoft seem to block installation of the TAP driver (with hardware ID 0801) regardless of whether you're using the working version of the TAP driver or not. This is a change from Vista RC2 which allowed the installation of the 0801 TAP driver. (* details and files here http://home.arcor.de/henryn/OpenVPN-2.1beta14-tap32/readme.txt) To get around this, first remove any/all TAP devices from device manager, then follow these steps, working from the OpenVPN folder in Program Files: - rename driver\tap0801.sys to tap0802.sys - replace all occurrences of "0801" in driver\OemWin2k.inf with "0802" - alter bin\addtap.bat and bin\deltapall.bat similarly - run addtap.bat to install the new TAP device - make sure it shows up correctly in device manager. Running openvpn.exe however now causes OpenVPN to not be able to recognise the TAP adapter, presumably because it has a different hardware ID. What I did was to download the latest source for OpenVPN (2.1_rc1) and patch all of the files with 0801 in them, replacing that with 0802, then compiled it as per usual, took the new openvpn.exe and a few SSL-related libraries and placed them on the target box in the openvpn bin folder. Now openvpn.exe can see the TAP adapter with hardware ID 0802, and works perfectly. It also works perfectly with OpenVPN GUI. I plan to package up the changes I made and post them on my blog (http://tomdot.net) shortly under the same license that OpenVPN is distributed with. When I do so I will post the exact URL here. Best Tom Fanning 

hi guys i run into the same problem as some of you, since i need the possibility to push way more routes to the clients. but currently the push buffer is limited which does not let you push more than about 15 routes. so i wrote a patch which removes this limitation. please find the patch attached to this posting. it is agains 2.0.9, tested on linux as client/server. the patch makes the push_list dynamic and sends it to the clients as chunks. in order not to break older clients this will happen only if the push buffer will be exceeded. however if exceeded, older clients can still connect, print out warnings and connect successfully but certainly don't apply the entire push list. there is still a limitation. the openvpn routing table is still static and holds max 100 routes, so you will not be able to push more than 100 routes. that value could be easily increased and/or if necessary this could also made dynamic (however with deeper changes to the source). please let me know what you think. if you find it useful i will port the patch to the 2.1 branch peter -- :: e n d i a n :: open source - open minds :: peter warasin :: http://www.endian.it :: pe...@en...