Virtual Private Network - VPN 3

A Virtual Private Network (VPN) is a computer network that uses a public telecommunication infrastructure such as the Internet to provide remote offices or individual users with secure access to their organization's network. It aims to avoid an expensive system of owned or leased lines that can be used by only one organization. It encapsulates data transfers between two or more networked devices which are not on the same private network so as to keep the transferred data private from other devices on one or more intervening local or wide area networks. There are many different classifications, implementations, and uses for VPNs.

TUN/TAP Setup
If you are using Linux 2.4 or higher, make the tun device node and load the tun module:
mknod /dev/net/tun c 10 200
modprobe tun
If you installed from RPM, the mknod step may be omitted, because the RPM install does that for you. If you have Linux 2.2 you should obtain version 1.1 of the TUN/TAP driver from http://vtun. sourceforge.net/tun/http://vtun.sourceforge.net/tun/ and follow the installation instructions.
For other platforms, consult the INSTALL file at http://openvpn.net/install.htmlhttp://openvpn.net/install.html for more information.

Firewall Setup
If firewalls exist between the two machines they should be set to forward UDP port 1194 in both directions. If you do not have control over the firewalls between the two machines, you may still be able to use OpenVPN by adding --ping 15 to each of the openvpn commands used below in the examples (this will cause each peer to send out a UDP ping to its remote peer once every 15 seconds which will cause many stateful firewalls to forward packets in both directions without an explicit firewall rule).
If you are using a Linux iptables-based firewall, you may need to enter the following command to allow incoming packets on the TUN device:
iptables -A INPUT -i tun+ -j ACCEPT
See the firewalls section below for more information on configuring firewalls for use with OpenVPN.

VPN Address Setup
For purposes of our example, our two machines will be called may.kg and june.kg. If you are constructing a VPN over the internet, then replace may.kg and june.kg with the internet hostname or IP address that each machine will use to contact the other over the internet.
Now we will choose the tunnel endpoints. Tunnel endpoints are private IP addresses that only have meaning in the context of the VPN. Each machine will use the tunnel endpoint of the other machine to access it over the VPN. In our example, the tunnel endpoint for may.kg will be 10.4.0.1 and for june.kg, 10.4.0.2.
Once the VPN is established you have essentially created a secure alternate path between the two hosts which is addressed by using the tunnel endpoints. You can control which network traffic passes between the hosts (a) over the VPN or (b) independently of the VPN, by choosing whether to use (a) the VPN endpoint address or (b) the public internet address, to access the remote host. For example if you are on may.kg and you wish to connect to june.kg via ssh without using the VPN (since ssh has its own built-in security) you would use the command ssh june.kg. However in the same scenario, you could also use the command telnet 10.4.0.2 to create a telnet session with june.kg over the VPN, that would use the VPN to secure the session rather than ssh.
You can use any address you wish for the tunnel endpoints but make sure that they are private addresses (such as those that begin with 10 or 192.168) and that they are not part of any existing subnet on the networks of either peer, unless you are bridging. If you use an address that is part of your local subnet for either of the tunnel endpoints, you will get a weird feedback loop.

A simple tunnel without security
On may:
openvpn --remote june.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 9
On june:
openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --verb 9
Now verify the tunnel is working by pinging across the tunnel. On may:
ping 10.4.0.2
On june:
ping 10.4.0.1
The --verb 9 option will produce verbose output, similar to the tcpdump program. Omit the --verb 9 option to have OpenVPN run quietly.

A tunnel with full TLS-based security
For this test, we will designate may as the TLS client and june as the TLS server. NOTE: The client or server designation only has meaning for the TLS subsystem. It has no bearing on OpenVPN's peer-to-peer, UDP-based communication model.
uild a separate certificate/key pair for both may and june (see above where --cert is discussed for more info). Then construct Diffie Hellman parameters (see above where --dh is discussed for more info). You can also use the included test files client.crt, client.key, server.crt, server.key and ca.crt. The .crt files are certificates/public-keys, the .key files are private keys, and ca.crt is a certification authority who has signed both client.crt and server.crt. For Diffie Hellman parameters you can use the included file dh1024.pem. Note that all client, server, and certificate authority certificates and keys included in the OpenVPN distribution are totally insecure and should be used for testing only.
On may:
openvpn --remote june.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --tls-client --ca ca.crt --cert client.crt --key client.key --reneg-sec 60 --verb 5
On june:
openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --tls-server --dh dh1024.pem --ca ca.crt --cert server.crt --key server.key --reneg-sec 60 --verb 5
Now verify the tunnel is working by pinging across the tunnel. On may:
ping 10.4.0.2
On june:
ping 10.4.0.1
Notice the --reneg-sec 60 option we used above. That tells OpenVPN to renegotiate the data channel keys every minute. Since we used --verb 5 above, you will see status information on each new key negotiation.
For production operations a key renegotiation interval of 60 seconds is probably too frequent. Omit the --reneg-sec 60 option to use OpenVPN's default key renegotiation interval of one hour.

Routing
Assuming you can ping across the tunnel then the next step is to route a real subnet over the secure tunnel. Suppose that may and june have two network interfaces each, one connected to the internet, and the other to a private network. Our goal is to securely connect both private networks. We will assume that may's private subnet is 10.0.0.0/24 and june's is 10.0.1.0/24. Ensure that IP forwarding is enabled on both peers. On Linux, enable routing:
echo 1 > /proc/sys/net/ipv4/ip_forward
And enable TUN packet forwarding through the firewall:
iptables -A FORWARD -i tun+ -j ACCEPT
On may:
route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2
On june:
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1
Now any machine on the 10.0.0.0/24 subnet can access any machine on the 10.0.1.0/24 subnet over the secure tunnel (or vice versa). In a production environment, you could put the route command(s) in a shell script and execute with the --up option.

Continue next page 1 - 2 - 3 - 4