Professional Documents
Culture Documents
Introduction
This article will describe a configuration of Virtual Private Network connection by using an OpenVPN application. Firstly, you will be exposed to some basic theory behind Virtual Private Networks. Then, the article will guide you with step-by-step instructions on how to setup a OpenVPN virtual private network by using Symmetric Key Encryption and Public Key Encryption. This article is meant for everybody who possesses a basic knowledge of linux administration and networking.
2. Why VPN
If you work in IT industry, it is very common that you do not use only a single computer sitting on your work desk, but you also utilize other systems connected to the same local area network. As long as you are sitting on your office chair this approach should not be a problem. However, this situation can become complicated once you are in hurry, and therefore, you need to take some of your work home. You are able to take you company laptop with you, but to fully utilize company resources you would also need to be connected to the company's local area network. The solution to this problem depends on what resources are needed to complete your job. If you need some shared files available on the company's network, you may just simply copy these file to your laptop's hard drive or to USB stick. In case you need to work on the system installed on your company's PC you can also use some virtualization tools such as VirtualBox or VMware. Soon enough you will realize that this approach is not as convenient as you would like it to be, and that you spent more time by copying files and synchronizing virtual systems than concentrating on your work. The ideal solution in this case should allow employees to access company's local resources from an external network. This can be done by forwarding ports of the local services via firewall. Exposing local ports to the Internet is not entirely the safest approach. The more ports are exposed from your local network to an external network such as the Internet, the more vulnerable your local system will become. The ideal approach in this situation could be a use of just single port for all services coupled with encryption and user authentication. This can be achieved, for example, by using a Virtual Private Network (VPN) .
of packets between two distant networks via the Internet. Services, which a VPN client can connect to, can furthermore be defined by firewall rules. This way firewall ensures that VPN client can connect only to services it is allowed to connect. If the previous couple sentences looked to you little difficult to understand, do not despair! Everything will become clearer once we see how encrypted tunnel works in an example.
When looking at the previous figure it is apparent that this kind of network data transfer over the VPN is a waste of transfer rate because original packet has a smaller payload space just because it needs to fit into the VPN tunnel packet. In VPN analogical sense this can be considered as a drawback.
In case that an employee wants to connect to some company's services from outside world, his/her attempt would be rejected by the firewall. Not just because this attempt is coming from completely different subnet but also because the ports to the particular services are not open. Once the VPN server starts functioning on the gateway, it automatically creates a virtual network interface with subnet 192.168.2.0/24, which would then start accepting a connection from external network. Once employee passes VPN server's authentication, a VPN server will assign an IP address from a 192.168.2.0/24. For 192.168.1.0/24 hosts would be the systems on 192.168.2.0/24 network appear that they are located on the separate local subnet, but in fact the communication is done by encrypted VPN tunnel over the Internet.
1/14: VPN Client establishes a connection with a VPN Server via external network interface. 2/14: VPN Server assigns IP address to a vpn client from a local virtual subnet 192.168.2.0/24. 3/14: VPN Client prepares a packet for a host 192.168.1.3 located within a private subnet 192.168.1.0/24. 4/14: VPN Client encrypts and hides an original packet inside the outer public packet. 5/14: The packet is dispatched by the VPN client via public network to the VPN Server. 6/14: A network packet acquired from the public network is decrypted and decapsulated by the vpn server. This way VPN server obtains a packet for the private network. 7/14: VPN Server handles a newly acquired packet as it was sent locally on a 192.168.1.0/24 subnet. 8/14: Packet is delivered to the host with destination IP address 192.168.1.3. 9/14: Host with IP address 192.168.1.3 creates a network packet with destination IP 192.168.2.2. 10/14: VPN Server receives a reply packet. 11/14: According to the VPN Server's routing table, this packet links up with the Virtual Private Network.
12/14: VPN server encrypts and hides an original packet inside the outer public packet. 13/14: The packet is dispatched by the VPN server via public network to the VPN client. 14/14: The network packet acquired from the public network is decrypted and decapsulated by the vpn Client. This way VPN client obtains a packet from the private network.
symmetric encryption simple configuration no Certificate Authority ( CA ) is required server can serve only single client at the same time key must be stored in text file on the both systems which increases a risk that it will fall to the wrong hands difficult key exchange
asymmetric encryption
more complicated configuration Certificate Authority ( CA ) is required server can server many clients simultaneously
A VPN tunell will be created as point-to-point 192.168.0.1 - 192.168.0.2. However, for VPN tunnel created with use of Public Key Encryption ( OpenVPN certification mode ) the client's IP address will differ and will be assigned from 192.168.0.0/16 subnet IP address pool. In our case the client will obtain a IP address 192.168.0.6.
8. Installation of OpenVPN
OpenVPN application consists only from one binary file which name is equal to the application name itself, thus openvpn. This binary file is used to start an OpenVPN server as well as OpenVPN client and therefore it is important to install the same OpenVPN packages on both sides. To be more precise, a difference between an OpenVPN Server and OPenVPN Client is just in how the configuration is carried out on both sides. It is recommended to install OpenVPN packages from the official repository of your Linux Distribution you intent to use for this purpose. If, from some reason the packages for OpenVPN are not included in the official
repository of your linux distribution feel free to install from source code. Both installations will be briefly covered in the following paragraphs. Repeat a following installation steps for vpnserver as well as a vpn-client.
Apt-get will automatically fetch required prerequisites as in this case it is a liblzo2-2 package.
What happens here, is that openvpn binary file will be created by the source code compilation and installed in a /usr/local/sbin directory.
and in Debian a TUN driver is supported by default in the form of a kernel module. This can by confirmed by the following command:
grep CONFIG_TUN= /boot/config-
eth0 interface directly represents a hardware device, which can be, for example a PCI network card. On the other hand, TUN/TAP devices represent a virtual network interface. Packets traveling via TUN/TAP interface are sent to the application before they reach eth0 network interface. This allows an application such as OpenVPN encrypt or decrypt packets before they reach a physical network.
Before we can start a OpenVPN tunnel, a symmetric key neds to be generated and exchanged between server and client. To generate a Symmetric Key run a following command:
linux_VPN_Server:~# openvpn --genkey --secret staticVPN.key linux_VPN_Server:~# cat staticVPN.key # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----00e5dea65588eec9800f72607c6fb050 62a58ad4a44039d22635bdd817886c8b 69dbe38384eed05dcdca54c604e46d74 daec8f0e074f2a142db0efafe25520cb a71a0c0314800be297275205bc6d18e3
852419caac500dc4135c2ce375c5020a dd4ed783c1f47518e74c6b10124173ca 8ef3b52cfc297daf21683bb4f735856f 825c7ee868385dfcf4c3363d261e0e13 dfb60d3e3abc6a2075b8d243d3976eee 1afdff0e865d5973e2f6b6418f603aca 1923053d44ac0021ff74efbf00e60e3f b928d4cc32f9d3d65566f8c1aaa5eb45 e1ebc134a1b060b6dde30ca5b9a54900 a1a5e0746ba7778285f163317433fb19 c0d5669677d9e921051c1fa6d3c75d47 -----END OpenVPN Static key V1-----
At this stage a Static Symmetric Key can be used to start an OpenVPN server with will create a one side of a Virtual Private Network tunnel ready for connections:
linux_VPN_Server:~# openvpn --dev tun --ifconfig 192.168.0.1 192.168.0.2 -secret staticVPN.key Wed Jan 28 03:48:09 2009 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007 Wed Jan 28 03:48:09 2009 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. Wed Jan 28 03:48:09 2009 TUN/TAP device tun0 opened Wed Jan 28 03:48:09 2009 ifconfig tun0 192.168.0.1 pointopoint 192.168.0.2 mtu 1500 Wed Jan 28 03:48:09 2009 UDPv4 link local (bound): [undef]:1194 Wed Jan 28 03:48:09 2009 UDPv4 link remote: [undef]
Parameter "--dev tun" instructs an OpenVPN application to use a virtual network interface TUN. The following parameter "--ifconfig 192.168.0.1 192.168.0.2" specifies IP addresses for both sides of virtual tunnel. OpenVPN consequently sets a virtual network interface tun0 to an IP address 192.168.0.1 and will enable a slot for a connection form a OpenVPN client on a IP address 192.168.0.2. Last parameter "--secret staticVPN.key" specifies a file with Static Symmetric Key created in the previous step. Let's confirm a correctness of the previous statements with ifconfig command:
linux_VPN_Server:~# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-0000-00-00 inet addr:192.168.0.1 P-t-P:192.168.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
The procedure for setting up a OpneVPN client is very similar the the one which was used to set up a OpenVPN server. At this point we assume established connecton via 10.0.0.0 netowrk, client has installed and ready to use an OpenVPN application as well as a Symmetric key generated previously was copied over to the client by means of USB key or SCP. If this is the case nothing can stop us to start a OpenVPN client:
linux_VPN_Client:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:00:C1:42 inet addr:10.1.1.4 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::20c:29ff:fe00:c142/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:456 errors:0 dropped:0 overruns:0 frame:0 TX packets:293 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:434285 (424.1 KiB) TX bytes:28413 (27.7 KiB) Interrupt:169 Base address:0x2000
Following command and paramaters can be used to start a OpenVPN client with static symmetric key:
linux_VPN_Client:~# openvpn --remote 10.1.1.3 --dev tun --ifconfig 192.168.0.2 192.168.0.1 \ --secret staticVPN.key Wed Jan 28 03:51:02 2009 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007 Wed Jan 28 03:51:02 2009 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. Wed Jan 28 03:51:02 2009 TUN/TAP device tun0 opened Wed Jan 28 03:51:02 2009 ifconfig tun0 192.168.0.2 pointopoint 192.168.0.1 mtu 1500 Wed Jan 28 03:51:02 2009 UDPv4 link local (bound): [undef]:1194 Wed Jan 28 03:51:02 2009 UDPv4 link remote: 10.1.1.3:1194
Parameter "--remote 10.1.1.3" speciefies a real IP address of the OpenVPN server which is waiting for a connection and therefore a OpenVPN client will connect to socket 10.1.1.3:1194/UDP. rest of the parameters has a exactly the same meaning as it was in case of OpenVPN server. The only difference is an order of IP addresses which are passed to the "-ifconfig" parameter. This way an OpenVPN application sets a local tun0 virtual network interface to 192.168.0.2 and will expect the OpenVPN Server to be set on 192.168.0.1. Agian confirm a corectenss of of these settings by ifconfig command:
linux_VPN_Client:~# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-0000-00-00 inet addr:192.168.0.2 P-t-P:192.168.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
tun0 00-00-00
inet addr:192.168.0.1 P-t-P:192.168.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) linux_VPN_Client:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:29:00:C1:42 inet addr:10.1.1.4 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::20c:29ff:fe00:c142/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1953 errors:0 dropped:0 overruns:0 frame:0 TX packets:1376 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:569341 (555.9 KiB) TX bytes:372027 (363.3 KiB) Interrupt:169 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) tun0 00-00-00 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-
inet addr:192.168.0.2 P-t-P:192.168.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
If everything went smoothly and there is no firewall set between both endpoint which may interfere with the VPN tunnel, it should be easy to confirm a VPN connection with ping command.
linux_VPN_Server:~# ping -c 5 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=3.24 64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=4.30 64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=1.76 64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=1.83 64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=2.52
ms ms ms ms ms
--- 192.168.0.2 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/avg/max/mdev = 1.766/2.733/4.305/0.952 ms
If at the same time we would start a tcpdump program on the OpenVPN client's virtual tun0 network interface we see an ICMP packets transmitted by ping program, including a replay packets.
linux_VPN_Client:~# tcpdump -i tun0 03:54:11.648040 IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 32520, seq 1, length 64
However on the OpenVPN client's real eth0 network interface the tcpdump program will produce a following ouptut:
linux_VPN_Client:~# tcpdump -i eth0 03:54:11.803616 IP 10.1.1.3.openvpn > 10.1.1.3.openvpn: UDP, length 124
This output from a tcpdump program can be used as a proof of what we have learn previously, that a packets from a virtual tun0 network interface are encapsulated into public network packets and are sent to the recipient encrypted via single 1194/UDP port.
become a very tiresome work. Therefore, we should complete this section on how to create a VPN connection using a Static Symmetric Key and OpenVPN configuration files. Here is a solution which involves a configuration files to achieve the same goal as shown previously.
OpenVPN Server config file Create a vpn-server.conf file with a following content:
# OpenVPN configuration file for VPN SERVER dev tun ifconfig 192.168.0.1 192.168.0.2 secret /root/staticVPN.key comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key user openvpn group openvpn daemon
OpenVPN Client config file Create a vpnclient.conf file with a following content:
# OpenVPN configuration file for VPN CLIENT dev tun remote 10.1.1.3 ifconfig 192.168.0.2 192.168.0.1 secret /root/staticVPN.key comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key user openvpn group openvpn daemon
dev - use a TUN virtual network device remote - specifies a IP address or name of a VPN Server ifconfig - specifies local and remote endpoint secret - a path to the pre-shared static key file comp-lzo - enable a fast LZO data compression keepalive - keep connection alive by sending a regular ping packets, in our case the ping packet is sent every 10 seconds where reply packet must come within 60 seconds otherwise assume that the other endpoi is down. ping-timer-rem - should be used only on VPN server side where daemo started without explicit remote IP address, this way timeout starts only after VPN client connection. persist-tun - do not re-create a virtual network interface TUN after automatic restart persist-key - no need to read pre-shared static key file again after automatic restart user - run openvpn tunnel a user openvpn group - run openvpn tunnel a group openvpn daemon - once the initialization functions are completed run in the background as a daemon
It is time to put those two OpenVPN configuration files into the action. As stated in both config files we need to create an openvpn user and group first. OpenVPN can run as a root. However, run a vpn tunnel as a non-privileged user "openvpn" is a smart move, and it will greatly enhance a security of your hosts. To create an openvpn group an addgroup command can be used:
NOTE: openvpn user and group need to be created on both sides of the VPN tunnel (VPN Server and VPN Clients )
# addgroup openvpn
At this point we are ready to engage both configuration files in OpenVPN tunnel creation: Start OpenVPN Server:
linux_VPN_Server:~# openvpn --config /root/vpn-server.conf linux_VPN_Server:~# ps aux | grep openvpn openvpn 2310 0.2 0.6 4060 988 ? Ss 01:00 0:00 openvpn --config vpn-server.conf root 2313 0.0 0.1 1512 224 pts/1 R+ 01:00 0:00 grep openvpn
and that username "openvpn" and "openvpn" group does exist on both endpoints ( vpn-client and vpn-server ) of your future VPN connection.
# addgroup openvpn # useradd --shell=/bin/false -g openvpn openvpn
You will need to supply some details and more importantly pass-phrase which you would use to sign CSR's. The output will look something like this:
linux_VPN_Server:~# openssl req -new -x509 -extensions v3_ca -keyout caprivate-key.pem \ -out ca-certificate.pem -days 365 Generating a 1024 bit RSA private key ...............++++++ ...++++++ writing new private key to 'ca-private-key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----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) [AU]:SK State or Province Name (full name) [Some-State]:Slovakia Locality Name (eg, city) []:Bratislava Organization Name (eg, company) [Internet Widgits Pty Ltd]:linuxconfig.org Organizational Unit Name (eg, section) []: Certificate Authority ( CA ) Common Name (eg, YOUR name) []:Certificate Authority ( CA ) Email Address []: linux_VPN_Server:~#
If everything went well, now you have established your own CA ready to sign CSR. You can find two new files in a directory from where you have issued openssl command:
linux_VPN_Server:~# ls ca-certificate.pem ca-private-key.pem linux_VPN_Server:~#
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) [AU]:SK State or Province Name (full name) [Some-State]:Slovakia Locality Name (eg, city) []:Bratislava Organization Name (eg, company) [Internet Widgits Pty Ltd]:linuxconfig.org Organizational Unit Name (eg, section) []:VPN-SERVER Common Name (eg, YOUR name) []:10.1.1.3 Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: linux_VPN_Server:~#
After creating a Certificate Signing Request you should have acquired two new files. vpn-serverCSR.pem - vpn-server Certificate Signing Request privkey.pem - vpn-server private key
linux_VPN_Server:~# ls ca-certificate.pem ca-private-key.pem privkey.pem vpn-server-CSR.pem linux_VPN_Server:~# inux_VPN_Client:~# openssl req -new -nodes -out vpn-client-CSR.pem Generating a 1024 bit RSA private key ............++++++ .....++++++ writing new private key to 'privkey.pem' ----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) [AU]:SK State or Province Name (full name) [Some-State]:Slovakia Locality Name (eg, city) []:Bratislava Organization Name (eg, company) [Internet Widgits Pty Ltd]:linuxconfig.org Organizational Unit Name (eg, section) []:VPN-CLIENT Common Name (eg, YOUR name) []:10.1.1.4 Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: linux_VPN_Client:~#
After creating a Certificate Signing Request you shoud have accquired two new files. * vpnclient-CSR.pem - vpn-client Certificate Signing Request * privkey.pem - vpn-client private key
linux_VPN_Client:~# ls privkey.pem vpn-client-CSR.pem linux_VPN_Client:~#
Since our signing Certificate Authority resides on our vpn-server we copy clients signing a request to be signed there:
linux_VPN_Client:~# scp vpn-client-CSR.pem root@10.1.1.3:~/ root@10.1.1.3's password: vpn-client-CSR.pem 100% 672 0.7KB/s 00:00 linux_VPN_Client:~#
vpn-server-CSR.pem vpn-client-CSR.pem
For that we could create an openssl config file similar to bellow and use it with conjunction of openssl command. Use your favorite text editor and create a file called CA-openssl.config with content shown below:
linux_VPN_Server:~# cat CA-openssl.config [ ca ] default_ca = ca_default [ ca_default ] dir = . new_certs_dir = . private_key = ca-private-key.pem certificate = ca-certificate.pem database = index.txt default_md = md5 serial = serial default_days = 365 x509_extensions = usr_cert policy = generic_policy [ generic_policy ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ usr_cert ]
Certificate Authority needs to keep a track of all signed certificates ( index.txt ) and assigned a serial numbers to each of them ( serial ). Therefore, we need to create these two files:
touch index.txt; echo 01 > serial;
Server certificated is ready, we need to amend CA-openssl.config to sign VPN-Client's public key. Change line:
extendedKeyUsage = serverAuth TO: extendedKeyUsage = clientAuth
The Subject's Distinguished Name is as follows countryName :PRINTABLE:'SK' stateOrProvinceName :PRINTABLE:'Slovakia' localityName :PRINTABLE:'Bratislava' organizationName :PRINTABLE:'linuxconfig.org' organizationalUnitName:PRINTABLE:'VPN-CLIENT' commonName :PRINTABLE:'10.1.1.4' Certificate is to be certified until Feb 25 21:37:53 2010 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries
linux_VPN_Server:~# ls 01.pem ca-certificate.pem ca-private-key.pem index.txt.attr index.txt.old serial vpn-client-CSR.pem 02.pem CA-openssl.config index.txt index.txt.attr.old privkey.pem serial.old vpn-server-CSR.pem linux_VPN_Server:~#
At this stage we need to copy vpn-vlient's certificate to the vpn-client system (10.1.1.4) and change the name to something like vpn-client-certificate.pem. Along with the vpn-client certificate we also need to copy a CA's certificate:
linux_VPN_Server:~# scp 02.pem root@10.1.1.4:~/vpn-client-certificate.pem root@10.1.1.4's password: 02.pem 100% 3173 3.1KB/s 00:00 linux_VPN_Server:~# scp ca-certificate.pem root@10.1.1.4:~/ root@10.1.1.4's password: ca-certificate.pem 100% 1367 1.3KB/s 00:00 linux_VPN_Server:~#
linux_VPN_Server:~# ls 02.pem ca-private-key.pem vpn-client-CSR.pem ca-certificate.pem index.txt vpn-server-certificate.pem CA-openssl.config index.txt.attr vpn-server-CSR.pem linux_VPN_Server:~#
OpenVPN Server config file Create a openvpn-server.conf file with a following content:
# OpenVPN server configuration file example local 10.1.1.3 dev tun server 192.168.0.0 255.255.0.0 ca ca-certificate.pem cert vpn-servercertificate.pem key privkey.pem dh dh.pem push "redirect-gateway" comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key user openvpn group openvpn daemon
dev - use a TUN virtual network device server - assign IP addresses to the clients from a given subnet ca - path to the Certificate Authority's certificate cert - path to the vpn-server's signed certificate key - path to the vpn-server's private key dh - path to the Diffie-Hellman Key Agreement file remote - specifies a IP address or name of a VPN Server ifconfig - specifies local and remote endpoint secret - a path to the pre-shared static key file comp-lzo - enable a fast LZO data compression push - push a config file to the clients. Available options are: --route, -route-gateway, --route-delay, --redirect-gateway, --ip-win32, --dhcp-opti --inactive, --ping, --ping-exit, --ping-restart, --setenv, --persist-key, --pers tun, --echo, --comp-lzo, --socket-flags, --sndbuf, --rcvbuf keepalive - keep connection alive by sending a regular ping packets, in o case the ping packet is sent every 10 seconds where reply packet must come within 60 seconds otherwise assume that the other endpoint is down.
OpenVPN Client config file Create a openvpn-client.conf file with a following content:
# OpenVPN client configuration file example client dev tun remote 10.1.1.3 tls-remote 10.1.1.3 ca ca-certificate.pem cert vpn-clientcertificate.pem key privkey.pem comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key user openvpn group openvpn daemon linux_VPN_Client:~#
ping-timer-rem - should be used only on VPN server side where daemon started without explicit remote IP address, this way timeout starts only after VPN client connection. persist-tun - do not re-create a virtual network interface TUN after automatic restart persist-key - no need to read pre-shared static key file again after automatic restart user - run openvpn tunnel a user openvpn group - run openvpn tunnel a group openvpn daemon - once the initialization functions are completed run in the background as a daemon