9.2. Starting and Testing OpenVPN

Problem

You followed the previous recipe and your little test lab works, and you're ready to start running OpenVPN. Now what?

Solution

First, check both OpenVPN machines to see if OpenVPN is already running:

	$ ps ax | grep vpn

If it is, stop it:

	# killall openvpn

Then, open a quick, insecure tunnel between the remote PC and your OpenVPN server with these commands:

	root@xena:~# openvpn --remote 192.168.2.100 --dev tun0 \
	--ifconfig 10.0.0.1 10.0.0.2
	root@stinkpad:~# openvpn --remote 192.168.3.10 \
	--dev tun0 --ifconfig 10.0.0.2 10.0.0.1

This message shows success, and should be seen on both sides of the connection:

	Wed Feb 14 12:53:45 2007 Initialization Sequence Completed

Now, open some new terminals, and try pinging your new virtual IP addresses:

	carla@xena:~$ ping 10.0.0.2
	PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
	64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.421 ms
	64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.314 ms
	carla@stinkpad:~$ ping 10.0.0.1
	PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
	64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.360 ms
	64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.317 ms

You may also specify which interface for ping to use:

	carla@xena:~$ ping -I tun0 10.0.0.2
	carla@stinkpad:~$ ping -I tun0 10.0.0.1

Go ahead and give your tunnels a test drive by opening SSH sessions everywhere:

	carla@xena:~$ ssh 10.0.0.2
	carla@stinkpad:~$ ssh 10.0.0.1

Exit your SSH sessions, and hit Ctrl-C to shut down OpenVPN and close the tunnels.

Discussion

What you did here was create an unencrypted tunnel between a remote PC, Stink-pad, and Xena, which is functioning like a border router. Stinkpad and Xena can exchange TCP and UDP traffic, but the LAN behind Xena is not yet accessible to Stinkpad. Because these are routed connections, broadcast traffic like Samba will not cross the router.

If you see UDPv4 [ECONNREFUSED]: Connection refused (code=111), it means only one tunnel endpoint has been created, so you still need to create the other end.

The message TCP/UDP Socket bind failed on local address [ip-address]:1194:Address already in use means OpenVPN is already running.

The --ifconfig option first sets the local tunnel endpoint address, then the remote tunnel endpoint. These can be pretty much anything you want, as long as they are different from your other subnets.(Subnets and broadcast domains are the same things.) You don't have to use completely different address classes; for example, you could stick to using IPv4 class C addresses for everything, which is 192.168.0.0–192.168.255.255.

Use ifconfig to see the new tun0 interface:

	$  /sbin/ifconfig -i tun0
	tun0      Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
	          inet addr:10.0.0.2 P-t-P:10.0.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)

Use route to see your new routes:

	carla@xena:~$ /sbin/route
	Kernel IP routing table
	Destination     Gateway        Genmask         Flags Metric Ref   Use Iface
	10.0.0.2        *              255.255.255.255 UH    0      0       0 tun0
	192.168.3.0     *              255.255.255.0   U     0      0       0 eth1
	192.168.2.0     192.168.3.10   255.255.255.0   UG    0      0       0 eth1
	192.168.1.0     *              255.255.255.0   U     0      0       0 eth0
	carla@stinkpad:~$ /sbin/route
	Kernel IP routing table
	Destination	    Gateway        Genmask         Flags Metric Ref   Use Iface
	10.0.0.1        *              255.255.255.255 UH    0      0       0 tun0
	192.168.3.0     192.168.2.100  255.255.255.0   UG    0      0       0 eth0
	192.168.2.0     *              255.255.255.0   U     0      0       0 eth0
	default         192.168.2.100  0.0.0.0         UG    0      0       0 eth0

See Also