9.6. Configuring the OpenVPN Server for Multiple Clients

Problem

You have your PKI (Public Key Infrastructure) all set up, and clients keys copied to your clients. Now, how do you configure your server and clients?

Solution

Follow these examples:

	## server3.conf
	local 192.168.3.10
	port 1194
	proto udp
	dev tun
	daemon
	server 10.0.0.0 255.255.255.0
	push "route 192.168.1.0 255.255.255.0"
	push "dhcp-option DNS 192.168.1.50"
	max-clients 25
	
	ca    /etc/openvpn/keys/ca.crt
	cert  /etc/openvpn/keys/xena.crt
	key  /etc/openvpn/keys/xena.key
	dh   /etc/openvpn/keys/dh1024.pem
	tls-auth /etc/openvpn/keys/ta.key 0

	cipher BF-CBC
	comp-lzo
	keepalive 10 120
	log-append  /var/log/openvpn.log
	status /var/log/openvpn-status.log
	ifconfig-pool-persist  /etc/openvpn/ipp.txt

	mute 20
	verb 4
	
	## client3.conf
	client
	pull
	dev tun
	proto udp
	remote 192.168.3.10 1194

	ca    /etc/openvpn/keys/ca.crt
	cert  /etc/openvpn/keys/xena.crt
	key  /etc/openvpn/keys/xena.key
	tls-auth /etc/openvpn/keys/ta.key 1

	cipher BF-CBC
	comp-lzo
	verb 4
	mute 20
	ns-cert-type server

Fire up OpenVPN in the usual way:

	root@xena:~# openvpn /etc/openvpn/server3.conf
	root@stinkpad:~# openvpn /etc/openvpn/client3.conf

Copy the client configuration file to as many Linux clients as you want and try connecting. Your OpenVPN server should welcome all of them.

Discussion

You now have an excellent, strong, genuine Virtual Private Network up and running. Now, your remote clients can access your network almost as if they were physically present. There are a few limitations: remote clients cannot see each other, and broadcast traffic, with Samba being the most famous example, cannot cross a router.

I like to keep different versions of configuration files, like server2.conf and server3.conf, for quick and easy testing different setups. You are welcome to call them anything you want.

Let's take a quick cruise over the configuration options. The manpage is thorough, so we'll hit the high points.

The server line tells OpenVPN to run in server mode, and to automatically configure routing and client addressing. The syntax is server network netmask. The server assigns itself the .1 address for its end of the tunnel, automatically reserves a pool of client addresses, and pushes out the correct VPN route to clients. You can see this when you run the route command on the clients.

The push "route" option sends the correct route so that VPN clients can access the LAN behind the OpenVPN server.

push "dhcp-option DNS" tells your remote clients where your DNS server is, which is a very nice thing for them to know.

The ns-cert-type server option in client files prevents clients from connecting to a server that does not have the nsCertType=server designation in its certificate. The build-key-server script does this for you. It's an extra bit of prevention that helps prevent man-in-the-middle attacks.

To add another layer of verification, use the tls-remote option in client configuration files. This takes the Common Name from the server certificate, like this:

	tls-remote xena.alrac.net

If the client doesn't see the correct Common Name, it won't connect.

See Also