- In order to keep everything isolated, I created a new user/group (openvpn/openvpn) on mia and zidler. Instructions for creating users using command line options can be found here I have also set up passwordless login using SSH. PLease refer to this document for the HowTo. However, I still execute openvpn with as a root. Use sudo if you want to execute it as any other user.
- OpenVPN is very easy to configure and install.
- OpenVPN supports conventional encryption using
- Pre-shared secret key.
- Non-encrypted UDP tunnels.
- Public key encryption (TLS) using client & server certificates.
- The openvpn project has maintained a good HowTo and the present document can act as a very good supplement to it. Also, I enjoyed reading the up-to-date manpage, and would recommend it to anyone who wants to use Openvpn solution for setting up a VPN.
- Download the necessary rpm's from rpmfind.net or any such site. Installation should be fairly easy. If for some reason installation fails (in my case, it was asking for libcrypto.so.* and libssl.so.*, though both these libraries were present) consider using the tarball for installation.
- Assuming that you have a running installation, lets use the following setup with mia
as the client and zidler as the server .
- Recipe for setting up VPN using pre-shared secret key
- The first thing that anyone needs to do is generate a shared-secret key that can be shared between the two peers.
Use the following command to generate this:
openvpn@mia:~/certificates> openvpn --genkey --secret temp.key openvpn@mia:~/certificates> cat temp.key -----BEGIN OpenVPN Static key V1----- 3e51dd78f851023b 8f90c386555f7e77 8fb104b6da7ad925 21bf4640b1fea1ed d8122049cea29837 e1f03ce9f6456494 639bd25ea938f9d9 8c7f677c29cf4acc 2ef6608043048f7c 805a8837910092aa 660f7daa903feaba f6768125323a56ca 2a5e04193b9c18c7 ffaf9006f3d74d0f 0d3e331d66b95b34 35dc22fe3748cd30 -----END OpenVPN Static key V1-----
- Place this secret key (temp.key) in a known location.
I usually use $HOME/certificates on all my peers. Copy this secret key in the peer's $HOME/certificates
using scp as follows:
openvpn@mia:~/certificates> scp temp.key openvpn@zidler:~/certificates
- Set up a proper configuration file on both the peers. Read the man page for openvpn to know
the different configuration options. You can leave most of these to their default values. The important ones, that
i wanted to change are shown below:
openvpn@mia:~> cat openvpn.conf dev tun port 5000 #comp-lzo #ping 15 verb 3 #shaper 1000 remote 131.193.50.184 ifconfig 192.168.254.200 192.168.254.201 up /home/openvpn/bin/ip-up.sh down /home/openvpn/bin/ip-down.sh #Using Pre-Shared Secret Key. secret /home/openvpn/certificates/static.key auth MD5 cipher DES-CBC #keysize 192 ------------------------------------------------------------------- openvpn@zidler:~> cat openvpn.conf dev tun port 5000 #comp-lzo #ping 15 verb 3 #shaper 1000 remote 131.193.50.165 ifconfig 192.168.254.201 192.168.254.200 up /home/openvpn/bin/ip-up.sh down /home/openvpn/bin/ip-down.sh #Using Pre-Shared Secret Key. secret /home/openvpn/certificates/static.key auth MD5 cipher DES-CBC #keysize 192
NOTE: Take note of the remote AA.BB.CC.DD and ifconfig 192.168.254.XX 192.168.254.YY options. The IP Address's are reversed at the two peers. Uncomment comp-lzo if you want to use compression, and shaper n if you want to limit the bandwidth to n Bytes/Sec. - You can also select different ciphers (as made available by your openssl implementation). To see what
is available on your platform use the following commands:
openvpn@mia:~> openvpn --show-ciphers --SNIP-- DES-CFB 64 bit default key (fixed) DES-CBC 64 bit default key (fixed) --SNIP--
Specify the selected cipher (DES-CFB, say) in the configuratoin file as cipher DES-CFB. Only one cipher can be specified, and AFAIK there is no negotiation between the two peers. - You can also select different MACs (as made available by your openssl implementation). To see what
is available on your platform use the following commands:
openvpn@mia:~> openvpn --show-digests --SNIP-- MD2 128 bit digest size MD5 128 bit digest size --SNIP--
Specify the selected HMAC (MD5, say) in the configuratoin file as auth MD5. Only one HMAC can be specified, and AFAIK there is no negotiation between the two peers. - start both the peers (in any order) using the command:
[openvpn@mia openvpn]# openvpn --config openvpn.conf Thu Jul 17 16:12:10 2003 0[0]: OpenVPN 1.4.1 i386-redhat-linux-gnu built on May 22 2003 Thu Jul 17 16:12:10 2003 1[0]: UDP link local (bound): [undef]:5000 Thu Jul 17 16:12:10 2003 2[0]: UDP link remote: 131.193.50.184:5000 Thu Jul 17 16:12:10 2003 3[0]: Static Encrypt: Cipher 'DES-CBC' initialized with 64 bit key Thu Jul 17 16:12:10 2003 4[0]: Static Encrypt: Using 128 bit message digest 'MD5' for HMAC authentication Thu Jul 17 16:12:10 2003 5[0]: Static Decrypt: Cipher 'DES-CBC' initialized with 64 bit key Thu Jul 17 16:12:10 2003 6[0]: Static Decrypt: Using 128 bit message digest 'MD5' for HMAC authentication Thu Jul 17 16:12:10 2003 7[0]: Data Channel MTU parms [ udp_mtu=1300 extra_frame=40 extra_buffer=0 extra_tun=0 dynamic = [ mtu_min_initial=MTU_INITIAL_UNDEF mtu_max_initial=MTU_INITIAL_UNDEF mtu_initial=MTU_SET_TO_MAX mtu_min=140 mtu_max=1300 mtu=1300 ]] Thu Jul 17 16:12:10 2003 8[0]: TUN/TAP device tun0 opened Thu Jul 17 16:12:10 2003 9[0]: /sbin/ifconfig tun0 192.168.254.200 pointopoint 192.168.254.201 mtu 1260 Thu Jul 17 16:12:10 2003 10[0]: /home/openvpn/bin/ip-up.sh tun0 1260 1300 192.168.254.200 192.168.254.201 [ip-up] -- tun0 1260 1300 192.168.254.200 192.168.254.201 Thu Jul 17 16:12:10 2003 11[0]: PTHREAD support initialized Thu Jul 17 16:12:40 2003 12[0]: Peer Connection Initiated with 131.193.50.184:5000
Take a look at the messages to check the different parameters.
- The first thing that anyone needs to do is generate a shared-secret key that can be shared between the two peers.
Use the following command to generate this:
- Recipe for setting up VPN using NULL encrypted UDP tunnel
- To acheive this, just set cipher none and auth none in the configuration file in the previous recipe.
- Start openvpn using the same commands as in the first step, but check the messages, to see that the cipher and
MAC are NULL as below:
[openvpn@mia openvpn]# openvpn --config openvpn.conf Thu Jul 17 16:16:52 2003 0[0]: OpenVPN 1.4.1 i386-redhat-linux-gnu built on May 22 2003 Thu Jul 17 16:16:52 2003 1[0]: UDP link local (bound): [undef]:5000 Thu Jul 17 16:16:52 2003 2[0]: UDP link remote: 131.193.50.184:5000 Thu Jul 17 16:16:52 2003 3[0]: ******* WARNING *******: null cipher specified, no encryption will be used Thu Jul 17 16:16:52 2003 4[0]: ******* WARNING *******: null MAC specified, no authentication will be used Thu Jul 17 16:16:52 2003 5[0]: Data Channel MTU parms [ udp_mtu=1300 extra_frame=8 extra_buffer=0 extra_tun=0 dynamic = [ mtu_min_initial=MTU_INITIAL_UNDEF mtu_max_initial=MTU_INITIAL_UNDEF mtu_initial=MTU_SET_TO_MAX mtu_min=108 mtu_max=1300 mtu=1300 ]] Thu Jul 17 16:16:52 2003 6[0]: TUN/TAP device tun0 opened Thu Jul 17 16:16:52 2003 7[0]: /sbin/ifconfig tun0 192.168.254.200 pointopoint 192.168.254.201 mtu 1292 Thu Jul 17 16:16:52 2003 8[0]: /home/openvpn/bin/ip-up.sh tun0 1292 1300 192.168.254.200 192.168.254.201 [ip-up] -- tun0 1292 1300 192.168.254.200 192.168.254.201 Thu Jul 17 16:16:52 2003 9[0]: PTHREAD support initialized
- Recipe for setting up VPN using public-key encryption (with client/server certificates)
- It is better to set up your own CA (Certificate Authority) that will grant and sign certificates. However this is not entirely necessary, and this step can be omitted. But I have preferred to use it and all further steps will assume the existence of a CA. Instructions to create your very own CA, that can sign and approve user requested certifcates can be found here. Make sure that you copy the CA's very own certificate to a known directory.I have kept all such certificates in $HOME/certificates.
- The openvpn user (openvpn) that creates a VPN must request a certificate and get it signed by the CA. PLease remember that the private key must not be protected by a password.Instructions for users to create such keys/certificate requests and get it signed by a CA can be found in Step 8, 9, 10 of this document.
- Change the permission of the private key to 644 or lower. Do the same at the server.
- I have stored the CA certificate, the private key and the signed certificate in $HOME/certificates on both the peers.
- When using the public-key encryption method to set up VPN tunnels, openvpn opens two channels between the peers.
- Data channel: This is used to exchange normal traffic between the the two peers.
- Control Channel: This is used to exchange control information (such as keys etc.) between the peers.
- The ciphers/auth method used on the data and control channels can be selected individually. For example,
the options auth, cipher in the configuration file control the cipher/auth for the data channel, while
the option tls-cipher specifies the ciphers/auth for control channel. The list of available ciphers can be
obtained by using the commands:
- openvpn --show-ciphers
- openvpn --show-digests
- openvpn --show-tls
- For using the public key encryption methods, u have to designate one peer as the client (who initiates the handshake)
and other as the server. Hence the configuration files differ a bit on the two peers. In one config file we have to
place the option tls-client and other tls-server. Both the configuration files are shown below:
openvpn@mia:~> cat openvpn.conf dev tun port 5000 ; user nobody ; group nobody #comp-lzo #ping 15 verb 3 #shaper 1000 remote 131.193.50.184 ifconfig 192.168.254.200 192.168.254.201 up /home/openvpn/bin/ip-up.sh down /home/openvpn/bin/ip-down.sh tls-client #auth alg=none #cipher alg=none #keysize 192 ca /home/openvpn/certificates/cacert.cer cert /home/openvpn/certificates/openvpn_mia_cert.cert key /home/openvpn/certificates/openvpn_mia_key.pem tls-cipher RC4-MD5 ------------------------------------------------------- openvpn@zidler:~> cat openvpn.conf dev tun port 5000 ; user nobody ; group nobody #comp-lzo #ping 15 verb 3 #shaper 1000 remote 131.193.50.165 ifconfig 192.168.254.201 192.168.254.200 up /home/openvpn/bin/ip-up.sh down /home/openvpn/bin/ip-down.sh tls-server #auth alg=none #cipher alg=none #keysize 192 ca /home/openvpn/certificates/cacert.cer cert /home/openvpn/certificates/openvpn_zidler_cert.cert key /home/openvpn/certificates/openvpn_zidler_key.pem dh /home/openvpn/certificates/dh1024.pem tls-cipher RC4-MD5
- Notice the file dh1024.pem on the server. This is a required file if you plan to use the public-key
mode of encryption using client and server certificates for openvpn. You can create this file using the following command.
THIS IS ONLY REQUIRED AT THE SERVER. It takes a few minutes to generate this file.
[openvpn@zidler]# openssl dhparam -out dh1024.pem 1024
- The $HOME/(ip-up.sh|ip-down.sh) scripts (at both client and server) are used to add/delete routes in the routing table.
- openvpn can be invoked at the client and server (first at the server) using
openvpn@zidler:/home/openvpn# openvpn --config openvpn.conf Fri Jul 18 11:01:56 2003 0: OpenVPN 1.4.1 i686-pc-linux-gnu built on Jun 4 2003 Fri Jul 18 11:01:56 2003 1: UDP link local (bound): [undef]:5000 Fri Jul 18 11:01:56 2003 2: UDP link remote: 131.193.50.165:5000 Fri Jul 18 11:01:56 2003 3: Diffie-Hellman initialized with 1024 bit key Enter PEM pass phrase: Fri Jul 18 11:01:58 2003 4: WARNING: file '/home/openvpn/certificates/openvpn_zidler_key.pem' is group or others accessible Fri Jul 18 11:01:58 2003 5: Data Channel MTU parms [ udp_mtu=1300 extra_frame=41 extra_buffer=0 extra_tun=0 dynamic = [ mtu_min_initial=MTU_INITIAL_UNDEF mtu_max_initial=MTU_INITIAL_UNDEF mtu_initial=MTU_SET_TO_MAX mtu_min=141 mtu_max=1300 mtu=1300 ]] Fri Jul 18 11:01:58 2003 6: Control Channel MTU parms [ udp_mtu=1300 extra_frame=38 extra_buffer=0 extra_tun=0 dynamic = [ mtu_min_initial=MTU_INITIAL_UNDEF mtu_max_initial=MTU_INITIAL_UNDEF mtu_initial=MTU_SET_TO_MIN mtu_min=138 mtu_max=1300 mtu=138 ]] Fri Jul 18 11:01:59 2003 7: TUN/TAP device tun0 opened Fri Jul 18 11:01:59 2003 8: /sbin/ifconfig tun0 192.168.254.201 pointopoint 192.168.254.200 mtu 1259 Fri Jul 18 11:01:59 2003 9: /home/openvpn/bin/ip-up.sh tun0 1259 1300 192.168.254.201 192.168.254.200 [ip-up] -- tun0 1259 1300 192.168.254.201 192.168.254.200 Fri Jul 18 11:02:11 2003 10: TLS: tls_pre_decrypt: first response to initial packet sid=6536e1bc d3232430 Fri Jul 18 11:02:11 2003 11: VERIFY OK: depth=1, /CN=Certificate.Authority.Created.by.Shashank.Khanvilkar/ST=Illinois/C=US/[email protected]/O=Root.Certification.Authority Fri Jul 18 11:02:11 2003 12: VERIFY OK: depth=0, /CN=openvpn/ST=Illinois/C=US/[email protected]/O=UIC/OU=ECE Fri Jul 18 11:02:11 2003 13: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jul 18 11:02:11 2003 14: Data Channel Decrypt: Using 160 bit message digest 'SHA1' for HMAC authentication Fri Jul 18 11:02:11 2003 15: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jul 18 11:02:11 2003 16: Data Channel Encrypt: Using 160 bit message digest 'SHA1' for HMAC authentication Fri Jul 18 11:02:11 2003 17: Control Channel: TLSv1, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA Fri Jul 18 11:02:11 2003 18: Peer Connection Initiated with 131.193.50.165:5000 --SNIP--
- Use netstat -rn and ping to verify that the routing is indeed set up properly.
- The tunnel can be discontinued by killing the openvpn process.
- The below diagram traces the path taken by a packet as it travels over the tunnel set up by OpenVPN.
- Each layer of protocol adds some bytes of overhead. This is illustrated in the above diagram. It is quite complicated to pint-point the amount of overhead introduced by the openvpn later, as it depends largely on thhe cipher + HMAC in use, and many other factors. However we were able to find the average overhead introduced by openVPN through experiments.
- We experimented with all the 3 modes of operation, (no encryprtion, shared-secret encryption and tls-mode) and results can be accessed here. For our experiments, we selected the cipher/auth pair for the data channel as BF-CBC/SHA1.
- The input data for this experiment was totally random. An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
- We experimented with all the 3 modes of operation, (no encryprtion, shared-secret encryption and tls-mode) and results can be accessed here. For our experiments, we selected the BF-CBC/SHA1 (cipher/auth) pair for the data channel and compression was acheived using lzo library.
- The input data for this experiment was again totally random. An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
- Using compressionm, it is not possible to estimate the amount of overhead, as the amount of compression really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser in size to the input data. For e.g. when we used an input data of size 1200 bytes (each having a value "S"), we found that the packet size on the wire was just 130 Bytes.
- OpenVPN tunnels, do not have inbuilt routing mechanisms. As a result the user
has to take care of establishing routes to remote networks. This can be done in the following two ways:
- Static routes can be set up within the script itself (as we have done) using the command:
route add -net network/netmask gw gateway-ip
Although this method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network. - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
- Static routes can be set up within the script itself (as we have done) using the command:
- OpenVPN relies on the SSL implementation installted at your site. Hence the available number of cipher suites is limited to those provided by the SSL implementation. We are using the openssl implementation of SSL, which has support for a wide vairety of cipher/MAC algorithms.
- Proprietary algorithms can be used with openvpn, if they can be somehow incorporated in to the OpenSSL implementation.
- Only one compression algorithm (lzo) is supported by openvpn, so there is not much choice.
- The openVPN solution for forming VPN's is highly unscalable. (This may not be true
- For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.