In this recipe, we will focus on the common error experienced by the users when the VPN client machine is running Windows without full or elevated privileges. Under certain circumstances, the OpenVPN client can connect successfully but the routes that are pushed out by the remote server are not correctly set up. This recipe will focus on how to troubleshoot and correct this error.
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.11. The client was running Windows 7 64bit and OpenVPN 2.3.11. Keep the configuration file basic-udp-server.conf from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file basic-udp-client.ovpn from the Using an ifconfig-pool block recipe from Chapter 2, Client-server IP-only Networks.
- Log in on Windows as a non-privileged user, being a user without
Power UserorAdministratorprivileges. Also, make sure to temporarily remove the Run as Administrator flag from OpenVPN to launch OpenVPN without elevated privileges. This can be done by unchecking the Run this program as an administrator flag in the OpenVPN GUI properties:
- Start the server using the configuration file
basic-udp-server.conf:[root@server]# openvpn --config basic-udp-server.conf - Finally, start the client.
The connection will start and the OpenVPN GUI light will turn green. However, the client OpenVPN log file will show the following messages:
... C:WINDOWSsystem32 oute.exe ADD 10.198.0.0 MASK 255.255.0.0 10.200.0.1 ... ROUTE: route addition failed using CreateIpForwardEntry: Network access is denied. [status=65 if_index=2] ... Route addition via IPAPI failed [adaptive] Thu Aug 26 16:47:53 2010 us=187000 Route addition fallback to route.exe
If you attempt to reach a host on the server-side LAN, it will fail:
[WinClient]C:>ping 10.198.0.1 Pinging 10.198.0.1 with 32 bytes of data: Request timed out. Ping statistics for 10.198.0.1: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss)
The solution to this issue is to give the proper networking rights to the user, or to restore elevated privileges for OpenVPN again.
The OpenVPN client tries to open the TAP-Win32 adapter, which is allowed in a default installation. However, when the server pushes out a route to the client using:
push "route 10.198.0.0 255.255.0.0"
Then, the OpenVPN client will not be able to actually add this route to the system routing tables, due to missing administrator privileges. However, the VPN connection is successfully established and the GUI client shows a successful connection.
Note that even without the push "route" statement, the Windows OpenVPN GUI showed a green icon, suggesting the connection had started. Technically speaking, it is true that the connection has been established, but this should still be considered as a bug.
Windows XP and higher versions include a Run As Administrator service that allows a user to temporarily run a program with a higher privilege level. This mechanism was expanded in Windows Vista/7 and was made the default when launching applications. This has actually been the cause of numerous questions on the openvpn-users mailing list when running OpenVPN on these platforms.