http://openvpn.net/index.php/documentation/howto.html#examples
openvpn –config server.ovpn –lport 1194
openvpn –config client.ovpn –remote 10.10.10.22 1194 –lport 7890
Expanding the scope of the VPN to include additional machines on either the client or server subnet.Including multiple machines on the server side when using a routed VPN (dev tun)
Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.
For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24 and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.
First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:
push "route 10.66.0.0 255.255.255.0"
Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).
Make sure that you’ve enabled IP and TUN/TAP forwarding on the OpenVPN server machine.
Including multiple machines on the client side when using a routed VPN (dev tun)
In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.
For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.
Before setup, there are some basic prerequisites which must be followed:
- The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
- The client must have a unique Common Name in its certificate ("client2" in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.
First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.
Enabling TCP/IP Forwarding 1. Use Registry Editor (Regedt32.exe) to view the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters 2. Set the following registry value: Value Name: IPEnableRouterValue type: REG_DWORD
Value Data: 1 NOTE: A value of 1 enables TCP/IP forwarding for all network connections installed and used by this computer.
Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:
client-config-dir ccd
In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually Program FilesOpenVPNconfig. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.
The next step is to create a file called client2 in the ccd directory. This file should contain the line:
iroute 192.168.4.0 255.255.255.0
This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.
Next, add the following line to the main server config file (not the ccd/client2 file):
route 192.168.4.0 255.255.255.0
Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.
Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.
client-to-client
push "route 192.168.4.0 255.255.255.0"
This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.
The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.
Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.
Pushing DHCP options to clients
The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreignoptionn environmental variable list. See the man page or openvpn-users mailing list archive for non-Windows foreignoptionn documentation and script examples.
For example, suppose you would like connecting clients to use an internal DNS server at 10.66.0.4 or 10.66.0.5 and a WINS server at 10.66.0.8. Add this to the OpenVPN server configuration:
push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"
To test this feature on Windows, run the following from a command prompt window after the machine has connected to an OpenVPN server:
ipconfig /all
The entry for the TAP-Win32 adapter should show the DHCP options which were pushed by the server.
Routing all client traffic (including web-traffic) through the VPNOverview
By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.
In certain cases this behavior might not be desirable – you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.
ImplementationAdd the following directive to the server configuration file:
push "redirect-gateway def1"
If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:
push "redirect-gateway local def1"
Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site’s HTTP proxy.
On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.
When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:
push "dhcp-option DNS 10.8.0.1"
will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.
CaveatsRedirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:
- Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
- Issues exist with respect to pushing DNS addresses to Windows clients.
- Web browsing performance on the client will be noticably slower.
For more information on the mechanics of the redirect-gateway directive, see the manual page.
Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients Overview
The first step in building an OpenVPN 2.0 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.
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 a set of scripts bundled with OpenVPN.
If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the easy-rsa subdirectory of the OpenVPN distribution. If you installed OpenVPN from an RPM file, the easy-rsa directory can usually be found in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn-2.0 (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 .tar.gz 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 FilesOpenVPNeasy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting vars.bat and openssl.cnf files):
init-config
Now edit the vars file (called vars.bat 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
On Windows:
vars
clean-all
build-ca
The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive openssl command:
ai:easy-rsa # ./build-ca
Generating a 1024 bit RSA private key
…………++++++
………..++++++
writing new private key to ‘ca.key’
—–
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 [me@myhost.mydomain]:
Note that in the above sequence, most queried parameters were defaulted to the values set in the vars or vars.bat 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 serverNext, we will generate a certificate and private key for the server. On Linux/BSD/Unix:
./build-key-server server
On Windows:
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 clientsGenerating client certificates is very similar to the previous step. On Linux/BSD/Unix:
./build-key client1
./build-key client2
./build-key client3
On Windows:
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 parametersDiffie Hellman parameters must be generated for the OpenVPN server. On Linux/BSD/Unix:
./build-dh
On Windows:
build-dh
Output:
ai:easy-rsa # ./build-dhKey Files
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:
Filename Needed By Purpose Secret ca.crt server + all clients Root CA certificate NO ca.key key signing machine only Root CA key YES dh{n}.pem server only Diffie Hellman parameters NO server.crt server only Server Certificate NO server.key server only Server Key YES client1.crt client1 only Client1 Certificate NO client1.key client1 only Client1 Key YES client2.crt client2 only Client2 Certificate NO client2.key client2 only Client2 Key YES client3.crt client3 only Client3 Certificate NO client3.key client3 only Client3 Key YESThe 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 .key file leave the hard drive of the machine on which it was generated.
Controlling a running OpenVPN processRunning 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 in a Windows command prompt windowOn Windows, you can start OpenVPN by right clicking on an OpenVPN configuration file (.ovpn 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
The default server.conf file has a line
status openvpn-status.log
which will output a list of current client connections to the file openvpn-status.log once per minute.
Using the management interfaceThe 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.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
>INFO:OpenVPN Management Interface Version 1 – type ‘help’ for more info
help
Management Interface for OpenVPN 2.0_rc14 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 15 2005
Commands:
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 level if n is absent.
net : (Windows only) Show network info and routing table.
password type p : Enter password p for a queried OpenVPN password.
signal s : Send signal s to daemon,
s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2.
state [on|off] [N|all] : Like log, but show state history.
status [n] : Show current daemon status info using format #n.
test n : Produce n lines of output for testing/debugging.
username type u : Enter username u for a queried OpenVPN username.
verb [n] : Set log verbosity level to n, or show if n is absent.
version : Show current version number.
END
exit
Connection closed by foreign host.
ai:~ #
#end