Openvpn Http Proxy
Connecting To An OpenVPN Server Via An HTTP Proxy.
OpenVPN supports connections through an HTTP proxy, with the following authentication modes:
No proxy authentication
Basic proxy authentication
NTLM proxy authentication
First of all, HTTP proxy usage requires that you use TCP as the tunnel carrier protocol. So add the following to both client and server configurations:
Make sure that any proto udp lines in the config files are deleted.
Next, add the -proxy directive to the client configuration file (see the manual page for a full description of this directive).
For example, suppose you have an HTTP proxy server on the client LAN at 192. 168. 4. 1, which is listening for connections on port 1080. Add this to the client config:
-proxy 192. 1 1080
Suppose the HTTP proxy requires Basic authentication:
-proxy 192. 1 1080 stdin basic
Suppose the HTTP proxy requires NTLM authentication:
-proxy 192. 1 1080 stdin ntlm
The two authentication examples above will cause OpenVPN to prompt for a username/password from standard input. If you would instead like to place these credentials in a file, replace stdin with a filename, and place the username on line 1 of this file and the password on line 2.
Layering Security: VPN Proxy Combined – OpenVPN
Why combine rather than compare: VPN | proxy
Do a web search for ‘VPN proxy’ and you’ll get back a list of sites that compare VPN and proxy to each other. From a consumer perspective, this is likely what they’re looking for. They want a way to secure their browsing online. They may choose between a VPN or proxy. However, from a business perspective, it’s more likely you’re searching for using the two together. VPN and web proxies make up important pieces in the multi-layered approach businesses need for strong cybersecurity. Here are the benefits of combining them; how to get started with OpenVPN Access Server and proxy, as well as a use case showing the two working together.
The benefits of combining VPN with proxy
VPN and proxy servers individually provide a layer of security for enterprises, but each alone cannot keep hackers out completely. Together, they’re able to address different areas of threat. Here are three of those areas:
Proxy servers protect you from malicious websites – access out.
VPN protects you from malicious intruders – access in.
Proxy servers help limit the distractions from personal web browsing.
VPN provides secure access to business services so employees can work from anywhere in the world.
Reduced attack surface:
Proxy servers protect employees from the public network.
VPN creates a secure, private network.
Businesses rely on their employees to keep things secure. Unfortunately, they’re only human. We’ve found in recent surveys that show employees don’t always make the best decisions when it comes to cybersecurity.
It’s important for businesses to include human error in their cybersecurity risk mitigation plans. VPN and proxy servers both help keep employees practicing better cyber hygiene. Let’s dive a little deeper into that.
Blocking malicious traffic with a proxy server
Imagine an employee browsing online without any network security in place. Their computer connects with the public Internet through your enterprise Internet Service Provider (ISP). Their PC sits on your private network with an assigned IP address. It sends a request through your ISP to visit a website, which sits on the public network with an assigned IP address. Traffic flows freely from the private IP address to the public sites, and back again. This is a picture of data traffic flow on an open network. Without security in place, this is not a safe environment for businesses. It won’t take long before an employee accidentally visits a malicious site with malware in the code that infects their computer and spreads across the corporate network.
When you add a proxy server in between the private network and the public Internet these are some of the changes:
The proxy provides a layer of anonymity.
The proxy can block malicious traffic from getting into your private network.
The proxy can also block outgoing traffic if a user (knowingly or unknowingly) attempts to access malicious sites.
The proxy can log activity, letting you know if a user continually tries to access a malicious site, which could help you track down something like a malware infection.
The ability of proxy servers to protect your organization from malicious sites is reason, alone, to invest in this layer of security. When you combine the two, VPN-proxy security adds additional safeguards.
Blocking malicious intrusion with a VPN server
When you need to access your private network using the public Internet, you create an encrypted, private communication session using a Virtual Private Network. A VPN session allows you to safely send data across public networks thanks to the use of encrypted tunnels. The only way in is through a device with VPN client software installed and configured to connect to your VPN server(s).
While a proxy server protects your users when they wander out into the public Internet, a VPN provides a secure way to extend your private network; it provides a secure way in. Combining the two gives you the ability to expand your network protection beyond the immediate reach of your network cables and expand the protection of blocking users’ unintended, malicious web clicks.
You can safely extend the encrypted reach of your network and the protection of your proxy when you combine the two.
Getting started with an OpenVPN Access Server and Proxy
OpenVPN Access Server supports connections through a proxy. Looking for information on how to get started? Here are some helpful pages on our site:
Connecting to an OpenVPN server via an HTTP proxy
How do I configure OpenVPN to connect via an HTTP proxy?
Can I have multiple proxies?
How do I edit or delete a proxy?
Can an OpenVPN server push proxy settings to an iOS device?
Your site-to-site network security mapped
Use Case: Expand your proxy to satellite locations with OpenVPN Access Server
You set up your web proxy at the company headquarters. The branch office needs the protection of routing traffic through the web proxy as well. By setting up a site-to-site VPN with OpenVPN Access Server, you can do just that.
Connect the branch office to HQ using Access Server.
All web traffic now goes to HQ web proxy through the VPN.
The rules and browser settings set up at HQ are also applied to traffic from the branch office.
The web proxy applies policies and acts as a web browser.
It fetches web content from the Internet.
It also acts as a web server and sends the content to the branch office employee’s browser.
What happens when an employee at the branch office tries to go to a blacklisted website? The browser blocks it and states a message such as “this site is blocked due to company policy. ”
You are able to provide employees with the security of a transparent web proxy, protecting them from malicious websites and, in turn, protecting your company. Web filtering proxies are common tools used by businesses worldwide. They enforce web policies for Internet access as well as provide visibility into use of network bandwidth. OpenVPN Access Server provides you with a simplified UI for combining the encryption of your VPN with the protection of a proxy server. It’s important for businesses to create a layered approach to cybersecurity.
How browser fingerprinting keeps us from being sneaky online
Site-to-Site VPN: scale your business to new locations securely with a site-to-site VPN
How To Guide: Set Up & Configure OpenVPN Client/server VPN
OpenVPN Community Resources2x HOW TO
OpenVPN is a full-featured SSL VPN which implements OSI layer 2 or 3 secure network extension using the industry standard SSL/TLS protocol, supports flexible client authentication methods based on certificates, smart cards, and/or username/password credentials, and allows user or group-specific access control policies using firewall rules applied to the VPN virtual interface. OpenVPN is not a web application proxy and does not operate through a web browser.
OpenVPN 2. 0 expands on the capabilities of OpenVPN 1. x by offering a scalable client/server mode, allowing multiple clients to connect to a single OpenVPN server process over a single TCP or UDP port. OpenVPN 2. 3 includes a large number of improvements, including full IPv6 support and PolarSSL support.
This document provides step-by-step instructions for configuring an OpenVPN 2. x client/server VPN, including:
Determining whether to use a routed or bridged VPN.
Numbering private subnets.
Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients.
Creating configuration files for server and clients.
Starting up the VPN and testing for initial connectivity.
Configuring OpenVPN to run automatically on system startup.
Controlling a running OpenVPN process.
Expanding the scope of the VPN to include additional machines on either the client or server subnet.
Pushing DHCP options to clients.
Configuring client-specific rules and access policies.
Using alternative authentication methods.
How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards.
Routing all client traffic (including web-traffic) through the VPN.
Running an OpenVPN server on a dynamic IP address.
Connecting to an OpenVPN server via an HTTP proxy.
Connecting to a Samba share over OpenVPN.
Implementing a load-balancing/failover configuration.
Hardening OpenVPN Security.
Additional Security Notes.
The impatient may wish to jump straight to the sample configuration files:
Server configuration file.
Client configuration file.
This HOWTO assumes that readers possess a prior understanding of basic networking concepts such as IP addresses, DNS names, netmasks, subnets, IP routing, routers, network interfaces, LANs, gateways, and firewall rules.
Please take a look at the OpenVPN books page.
OpenVPN 1. x HOWTO
The original OpenVPN 1. x HOWTO is still available, and remains relevant for point-to-point or static-key configurations.
For additional documentation, see the articles page and the OpenVPN wiki.
While this HOWTO will guide you in setting up a scalable client/server VPN using an X509 PKI (public key infrastruction using certificates and private keys), this might be overkill if you are only looking for a simple VPN setup with a server that can handle a single client.
If you would like to get a VPN running quickly with minimal configuration, you might check out the Static Key Mini-HOWTO.
Static Key advantages
No X509 PKI (Public Key Infrastructure) to maintain
Static Key disadvantages
Limited scalability — one client, one server
Lack of perfect forward secrecy — key compromise results in total disclosure of previous sessions
Secret key must exist in plaintext form on each VPN peer
Secret key must be exchanged using a pre-existing secure channel
OpenVPN source code and Windows installers can be downloaded here. Recent releases (2. 2 and later) are also available as Debian and RPM packages; see the OpenVPN wiki for details.
For security, it’s a good idea to check the file release signature after downloading.
The OpenVPN executable should be installed on both server and client machines, since the single executable provides both client and server functions.
Linux Notes (using RPM package)
If you are using a Linux distribution which supports RPM packages (SuSE, Fedora, Redhat, etc. ), it’s best to install using this mechanism. The easiest method is to find an existing binary RPM file for your distribution. You can also build your own binary RPM file:
rpmbuild -tb openvpn-[version]
Once you have the file, you can install it with the usual
rpm -ivh openvpn-[details]
or upgrade an existing installation with
rpm -Uvh openvpn-[details]
Installing OpenVPN from a binary RPM package has these dependencies:
Furthermore, if you are building your own binary RPM package, there are several additional dependencies:
See the file for additional notes on building an RPM package for Red Hat Linux 9 or building with reduced dependencies.
Linux Notes (without RPM)
If you are using Debian, Gentoo, or a non-RPM-based Linux distribution, use your distro-specific packaging mechanism such as apt-get on Debian or emerge on Gentoo.
It is also possible to install OpenVPN on Linux using the universal. /configure method. First expand the file:
tar xfz openvpn-[version]
Then cd to the top-level directory and type:. /configure
OpenVPN for Windows can be installed from the self-installing exe file on the OpenVPN download page. Remember that OpenVPN will only run on Windows XP or later. Also note that OpenVPN must be installed and run by a user who has administrative privileges (this restriction is imposed by Windows, not OpenVPN). The restriction can be sidestepped by running OpenVPN in the background as a service, in which case even non-admin users will be able to access the VPN, once it is installed. More discussion on OpenVPN + Windows privilege issues.
Official OpenVPN Windows installers include OpenVPN-GUI, which allows managing OpenVPN connections from a system tray applet. Other GUI applications are also available.
After you’ve run the Windows installer, OpenVPN is ready for use and will associate itself with files having the extension. To run OpenVPN, you can:
Right click on an OpenVPN configuration file () and select Start OpenVPN on this configuration file. Once running, you can use the F4key to exit.
Run OpenVPN from a command prompt Window with a command such as:
Once running in a command prompt window, OpenVPN can be stopped by the F4 key.
Run OpenVPN as a service by putting one or more configuration files in \Program Files\OpenVPN\config and starting the OpenVPN Service, which can be controlled from Start Menu -> Control Panel -> Administrative Tools -> Services.
Additional Windows install notes.
Mac OS X Notes
Angelo Laub and Dirk Theisen have developed an OpenVPN GUI for OS X.
Some notes are available in the INSTALL file for specific OSes. In general, the. /configure
method can be used, or you can search for an OpenVPN port or package which is specific to your OS/distribution.
Determining whether to use a routed or bridged VPN
See FAQ for an overview of Routing vs. Ethernet Bridging. See also the OpenVPN Ethernet Bridging page for more notes and details on bridging.
Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis.
I would recommend using routing unless you need a specific feature which requires bridging, such as:
the VPN needs to be able to handle non-IP protocols such as IPX,
you are running applications over the VPN which rely on network broadcasts (such as LAN games), or
you would like to allow browsing of Windows file shares across the VPN without setting up a Samba or WINS server.
Numbering private subnets
Setting up a VPN often entails linking together private subnets from different locations.
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets (codified in RFC 1918):
10. 0. 0
10. 255. 255
172. 16. 0
172. 31. 255
(172. 16/12 prefix)
192. 168. 0
(192. 168/16 prefix)
While addresses from these netblocks should normally be used in VPN configurations, it’s important to select addresses that minimize the probability of IP address or subnet conflicts. The types of conflicts that need to be avoided are:
conflicts from different sites on the VPN using the same LAN subnet numbering, or
remote access connections from sites which are using private subnets which conflict with your VPN subnets.
For example, suppose you use the popular 192. 0/24 subnet as your private LAN subnet. Now you are trying to connect to the VPN from an internet cafe which is using the same subnet for its WiFi LAN. You will have a routing conflict because your machine won’t know if 192. 1 refers to the local WiFi gateway or to the same address on the VPN.
As another example, suppose you want to link together multiple sites by VPN, but each site is using 192. 0/24 as its LAN subnet. This won’t work without adding a complexifying layer of NAT translation, because the VPN won’t know how to route packets between multiple sites if those sites don’t use a subnet which uniquely identifies them.
The best solution is to avoid using 10. 0/24 or 192. 0/24 as private LAN network addresses. Instead, use something that has a lower probability of being used in a WiFi cafe, airport, or hotel where you might expect to connect from remotely. The best candidates are subnets in the middle of the vast 10. 0/8 netblock (for example 10. 66. 77. 0/24).
And to avoid cross-site IP numbering conflicts, always use unique numbering for your LAN subnets.
Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients
The first step in building an OpenVPN 2. x configuration is to establish a PKI (public key infrastructure). The PKI consists of:
a separate certificate (also known as a public key) and private key for the server and each client, and
a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.
OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.
Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).
This security model has a number of desirable features from the VPN perspective:
The server only needs its own certificate/key — it doesn’t need to know the individual certificates of every client which might possibly connect to it.
The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.
If a private key is compromised, it can be disabled by adding its certificate to a CRL (certificate revocation list). The CRL allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt.
The server can enforce client-specific access rights based on embedded certificate fields, such as the Common Name.
Note that the server and client clocks need to be roughly in sync or certificates might not work properly.
In this section we will generate a master CA certificate/key, a server certificate/key, and certificates/keys for 3 separate clients.
For PKI management, we will use easy-rsa 2, a set of scripts which is bundled with OpenVPN 2. 2. x and earlier. If you’re using OpenVPN 2. 3. x, you need to download easy-rsa 2 separately from here.
For PKI management, we will use easy-rsa 2, a set of scripts which is bundled with OpenVPN 2. x, you may need to download easy-rsa 2 separately from the easy-rsa-old project page. On *NIX platforms you should look into using easy-rsa 3 instead; refer to its own documentation for details.
If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the easy-rsa subdirectory. If you installed OpenVPN from an RPM or DEB file, the easy-rsa directory can usually be found in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn(it’s best to copy this directory to another location such as /etc/openvpn, before any edits, so that future OpenVPN package upgrades won’t overwrite your modifications). If you installed from a file, the easy-rsa directory will be in the top level directory of the expanded source tree.
If you are using Windows, open up a Command Prompt window and cd to \Program Files\OpenVPN\easy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting and files):
Now edit the vars file (called on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don’t leave any of these parameters blank.
Next, initialize the PKI. On Linux/BSD/Unix:.. /vars. /clean-all. /build-ca
The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive opensslcommand:
ai:easy-rsa #. /build-ca
Generating a 1024 bit RSA private key………… ++++++……….. ++++++
writing new private key to ”
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘. ‘, the field will be left blank.
Country Name (2 letter code) [KG]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [BISHKEK]:
Organization Name (eg, company) [OpenVPN-TEST]:
Organizational Unit Name (eg, section) :
Common Name (eg, your name or your server’s hostname) :OpenVPN-CA
Email Address [domain]:
Note that in the above sequence, most queried parameters were defaulted to the values set in the varsor files. The only parameter which must be explicitly entered is the Common Name. In the example above, I used “OpenVPN-CA”.
Generate certificate & key for server
Next, we will generate a certificate and private key for the server. On Linux/BSD/Unix:. /build-key-server server
As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter “server”. Two other queries require positive responses, “Sign the certificate? [y/n]” and “1 out of 1 certificate requests certified, commit? [y/n]”.
Generate certificates & keys for 3 clients
Generating client certificates is very similar to the previous step. /build-key client1. /build-key client2. /build-key client3
If you would like to password-protect your client keys, substitute the build-key-pass script.
Remember that for each client, make sure to type the appropriate Common Name when prompted, i. e. “client1”, “client2”, or “client3”. Always use a unique common name for each client.
Generate Diffie Hellman parameters
Diffie Hellman parameters must be generated for the OpenVPN server. /build-dh
ai:easy-rsa #. /build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time…………….. +…………………………………………………….. +…………. +…………….. +………………………………………..
Now we will find our newly-generated keys and certificates in the keys subdirectory. Here is an explanation of the relevant files:
server + all clients
Root CA certificate
key signing machine only
Root CA key
Diffie Hellman parameters
The final step in the key generation process is to copy all files to the machines which need them, taking care to copy secret files over a secure channel.
Now wait, you may say. Shouldn’t it be possible to set up the PKI without a pre-existing secure channel?
The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private keys in the same place. With a bit more effort, we could have done this differently. For example, instead of generating the client certificate and keys on the server, we could have had the client generate its own private key locally, and then submit a Certificate Signing Request (CSR) to the key-signing machine. In turn, the key-signing machine could have processed the CSR and returned a signed certificate to the client. This could have been done without ever requiring that a secret file leave the hard drive of the machine on which it was generated.
Creating configuration files for server and clients
Getting the sample config files
It’s best to use the OpenVPN sample configuration files as a starting point for your own configuration. These files can also be found in
the sample-config-files directory of the OpenVPN source distribution
the sample-config-files directory in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn if you installed from an RPM or DEB package
Start Menu -> All Programs -> OpenVPN -> OpenVPN Sample Configuration Files on Windows
Note that on Linux, BSD, or unix-like OSes, the sample configuration files are named and On Windows they are named and
Editing the server configuration file
The sample server configuration file is an ideal starting point for an OpenVPN server configuration. It will create a VPN using a virtual TUN network interface (for routing), will listen for client connections on UDP port 1194 (OpenVPN’s official port number), and distribute virtual addresses to connecting clients from the 10. 8. 0/24 subnet.
Before you use the sample configuration file, you should first edit the ca, cert, key, and dh parameters to point to the files you generated in the PKI section above.
At this point, the server configuration file is usable, however you still might want to customize it further:
If you are using Ethernet bridging, you must use server-bridge and dev tap instead of server and dev tun.
If you want your OpenVPN server to listen on a TCP port instead of a UDP port, use proto tcpinstead of proto udp (If you want OpenVPN to listen on both a UDP and TCP port, you must run two separate OpenVPN instances).
If you want to use a virtual IP address range other than 10. 0/24, you should modify the serverdirective. Remember that this virtual IP address range should be a private range which is currently unused on your network.
Uncomment out the client-to-client directive if you would like connecting clients to be able to reach each other over the VPN. By default, clients will only be able to reach the server.
If you are using Linux, BSD, or a Unix-like OS, you can improve security by uncommenting out the user nobody and group nobody directives.
If you want to run multiple OpenVPN instances on the same machine, each using a different configuration file, it is possible if you:
Use a different port number for each instance (the UDP and TCP protocols use different port spaces so you can run one daemon listening on UDP-1194 and another on TCP-1194).
If you are using Windows, each OpenVPN configuration taneeds to have its own TAP-Windows adapter. You can add additional adapters by going to Start Menu -> All Programs -> TAP-Windows -> Add a new TAP-Windows virtual ethernet adapter.
If you are running multiple OpenVPN instances out of the same directory, make sure to edit directives which create output files so that multiple instances do not overwrite each other’s output files. These directives include log, log-append, status, and ifconfig-pool-persist.
Editing the client configuration files
The sample client configuration file ( on Linux/BSD/Unix or on Windows) mirrors the default directives set in the sample server configuration file.
Like the server configuration file, first edit the ca, cert, and key parameters to point to the files you generated in the PKI section above. Note that each client should have its own cert/key pair. Only the cafile is universal across the OpenVPN server and all clients.
Next, edit the remotedirective to point to the hostname/IP address and port number of the OpenVPN server (if your OpenVPN server will be running on a single-NIC machine behind a firewall/NAT-gateway, use the public IP address of the gateway, and a port number which you have configured the gateway to forward to the OpenVPN server).
Finally, ensure that the client configuration file is consistent with the directives used in the server configuration. The major thing to check for is that the dev (tun or tap) and proto (udp or tcp) directives are consistent. Also make sure that comp-lzo and fragment, if used, are present in both client and server config files.
Starting up the VPN and testing for initial connectivity
Starting the server
First, make sure the OpenVPN server will be accessible from the internet. That means:
opening up UDP port 1194 on the firewall (or whatever TCP/UDP port you’ve configured), or
setting up a port forward rule to forward UDP port 1194 from the firewall/gateway to the machine running the OpenVPN server.
Next, make sure that the TUN/TAP interface is not firewalled.
To simplify troubleshooting, it’s best to initially start the OpenVPN server from the command line (or right-click on the file on Windows), rather than start it as a daemon or service:
openvpn [server config file]
A normal server startup should look like this (output will vary across platforms):
Sun Feb 6 20:46:38 2005 OpenVPN 2. 0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 5 2005
Sun Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key
Sun Feb 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0]
Sun Feb 6 20:46:38 2005 TUN/TAP device tun1 opened
Sun Feb 6 20:46:38 2005 /sbin/ifconfig tun1 10. 1 pointopoint 10. 2 mtu 1500
Sun Feb 6 20:46:38 2005 /sbin/route add -net 10. 0 netmask 255. 0 gw 10. 2
Sun Feb 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1]
Sun Feb 6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194
Sun Feb 6 20:46:38 2005 UDPv4 link remote: [undef]
Sun Feb 6 20:46:38 2005 MULTI: multi_init called, r=256 v=256
Sun Feb 6 20:46:38 2005 IFCONFIG POOL: base=10. 4 size=62
Sun Feb 6 20:46:38 2005 IFCONFIG POOL LIST
Sun Feb 6 20:46:38 2005 Initialization Sequence Completed
Starting the client
As in the server configuration, it’s best to initially start the OpenVPN server from the command line (or on Windows, by right-clicking on the file), rather than start it as a daemon or service:
openvpn [client config file]
A normal client startup on Windows will look similar to the server output above, and should end with the Initialization Sequence Completed message.
Now, try a ping across the VPN from the client. If you are using routing (i. e. dev tun in the server config file), try:
ping 10. 1
If you are using bridging (i. e. dev tap in the server config file), try to ping the IP address of a machine on the server’s ethernet subnet.
If the ping succeeds, congratulations! You now have a functioning VPN.
If the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:
You get the error message: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). This error indicates that the client was unable to establish a network connection with the lutions:
Make sure the client is using the correct hostname/IP address and port number which will allow it to reach the OpenVPN server.
If the OpenVPN server machine is a single-NIC box inside a protected LAN, make sure you are using a correct port forward rule on the server’s gateway firewall. For example, suppose your OpenVPN box is at 192. 4. 4 inside the firewall, listening for client connections on UDP port 1194. The NAT gateway servicing the 192. x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192. 4.
Open up the server’s firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).
You get the error message: Initialization Sequence Completed with errors– This error can occur on Windows if (a) You don’t have the DHCP client service running, or (b) You are using certain third-party personal firewalls on XP lution: Start the DHCP client server and make sure that you are using a personal firewall which is known to work correctly on XP SP2.
You get the Initialization Sequence Completedmessage but the ping test fails — This usually indicates that a firewall on either server or client is blocking VPN network traffic by filtering on the TUN/TAP lution: Disable the client firewall (if one exists) from filtering the TUN/TAP interface on the client. For example on Windows XP SP2, you can do this by going to Windows Security Center -> Windows Firewall -> Advanced and unchecking the box which corresponds to the TAP-Windows adapter (disabling the client firewall from filtering the TUN/TAP adapter is generally reasonable from a security perspective, as you are essentially telling the firewall not to block authenticated VPN traffic). Also make sure that the TUN/TAP interface on the server is not being filtered by a firewall (having said that, note that selective firewalling of the TUN/TAP interface on the server side can confer certain security benefits. See the access policies section below).
The connection stalls on startup when using a proto udpconfiguration, the server log file shows this line:
TLS: Initial packet from x. x. x:x, sid=xxxxxxxx xxxxxxxx
however the client log does not show an equivalent line.
Solution: You have a one-way connection from client to server. The server to client direction is blocked by a firewall, usually on the client side. The firewall can either be (a) a personal software firewall running on the client, or (b) the NAT router gateway for the client. Modify the firewall to allow returning UDP packets from the server to reach the client.
See the FAQ for additional troubleshooting information.
Configuring OpenVPN to run automatically on system startup
The lack of standards in this area means that most OSes have a different way of configuring daemons/services for autostart on boot. The best way to have this functionality configured by default is to install OpenVPN as a package, such as via RPM on Linux or using the Windows installer.
If you install OpenVPN via an RPM or DEB package on Linux, the installer will set up an initscript. When executed, the initscript will scan for configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.
The Windows installer will set up a Service Wrapper, but leave it turned off by default. To activate it, go to Control Panel / Administrative Tools / Services, select the OpenVPN service, right-click on properties, and set the Startup Type to Automatic. This will configure the service for automatic start on the next reboot.
When started, the OpenVPN Service Wrapper will scan the \Program Files\OpenVPN\config folder for configuration files, starting a separate OpenVPN process on each file.
Controlling a running OpenVPN process
Running on Linux/BSD/Unix
OpenVPN accepts several signals:
SIGUSR1 — Conditional restart, designed to restart without root privileges
SIGHUP — Hard restart
SIGUSR2 — Output connection statistics to log file or syslog
SIGTERM, SIGINT — Exit
Use the writepid directive to write the OpenVPN daemon’s PID to a file, so that you know where to send the signal (if you are starting openvpn with an initscript, the script may already be passing a –writepid directive on the openvpn command line).
Running on Windows as a GUI
See the OpenVPN GUI page.
Running in a Windows command prompt window
On Windows, you can start OpenVPN by right clicking on an OpenVPN configuration file ( file) and selecting “Start OpenVPN on this config file”.
Once running in this fashion, several keyboard commands are available:
F1 — Conditional restart (doesn’t close/reopen TAP adapter)
F2 — Show connection statistics
F3 — Hard restart
F4 — Exit
Running as a Windows Service
When OpenVPN is started as a service on Windows, the only way to control it is:
Via the service control manager (Control Panel / Administrative Tools / Services) which gives start/stop control.
Via the management interface (see below).
Modifying a live server configuration
While most configuration changes require you to restart the server, there are two directives in particular which refer to files which can be dynamically updated on-the-fly, and which will take immediate effect on the server without needing to restart the server process.
client-config-dir — This directive sets a client configuration directory, which the OpenVPN server will scan on every incoming connection, searching for a client-specific configuration file (see the the manual page for more information). Files in this directory can be updated on-the-fly, without restarting the server. Note that changes in this directory will only take effect for new connections, not existing connections. If you would like a client-specific configuration file change to take immediate effect on a currently connected client (or one which has disconnected, but where the server has not timed-out its instance object), kill the client instance object by using the management interface (described below). This will cause the client to reconnect and use the new client-config-dir file.
crl-verify — This directive names a Certificate Revocation List file, described below in the Revoking Certificates section. The CRL file can be modified on the fly, and changes will take effect immediately for new connections, or existing connections which are renegotiating their SSL/TLS channel (occurs once per hour by default). If you would like to kill a currently connected client whose certificate has just been added to the CRL, use the management interface (described below).
The default file has a line
which will output a list of current client connections to the file once per minute.
Using the management interface
The OpenVPN management interface allows a great deal of control over a running OpenVPN process. You can use the management interface directly, by telneting to the management interface port, or indirectly by using an OpenVPN GUI which itself connects to the management interface.
To enable the management interface on either an OpenVPN server or client, add this to the configuration file:
management localhost 7505
This tells OpenVPN to listen on TCP port 7505 for management interface clients (port 7505 is an arbitrary choice — you can use any free port).
Once OpenVPN is running, you can connect to the management interface using a telnet client. For example:
ai:~ # telnet localhost 7505
Trying 127. 1…
Connected to localhost.
Escape character is ‘^]’.
>INFO:OpenVPN Management Interface Version 1 — type ‘help’ for more info
Management Interface for OpenVPN 2. 0_rc14 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 15 2005
echo [on|off] [N|all]: Like log, but only show messages in echo buffer.
exit|quit: Close management session.
help: Print this message.
hold [on|off|release]: Set/show hold flag to on/off state, or
release current hold and start tunnel.
kill cn: Kill the client instance(s) having common name cn.
kill IP:port: Kill the client instance connecting from IP:port.
log [on|off] [N|all]: Turn on/off realtime log display
+ show last N lines or ‘all’ for entire history.
mute [n]: Set log mute level to n, or show
Frequently Asked Questions about openvpn http proxy
Go to the Settings App and select OpenVPN in the left pane. All proxy options are available here. Proxy options can also be specified in the OpenVPN profile itself using the http-proxy and http-proxy-option directives.
Web filtering proxies are common tools used by businesses worldwide. They enforce web policies for Internet access as well as provide visibility into use of network bandwidth. OpenVPN Access Server provides you with a simplified UI for combining the encryption of your VPN with the protection of a proxy server.
OpenVPN is not a web application proxy and does not operate through a web browser. OpenVPN 2.0 expands on the capabilities of OpenVPN 1. x by offering a scalable client/server mode, allowing multiple clients to connect to a single OpenVPN server process over a single TCP or UDP port.