Client-server Ethernet-style Networks

Do this in both the client and server configuration files.

The UDP protocol normally gives optimal performance, but some routers and firewalls have problems forwarding UDP traffic. In that case, the TCP protocol often does work.

Making IP fowarding permanent

On most Linux systems, the proper way to permanently set up IP forwarding is:

Add the following line to the /etc/sysctl.con file: net.ipv4.ip_forward=1

Reload the sysctl.conf file using:

[root@server]# sysctl -p

See also

Chapter 2's recipe, Server-side routing, in which a basic TUN-style setup is explained.

Enabling client-to-client traffic

This recipe is a continuation of the previous recipe. It will demonstrate how to set up a

TAP-based connection in client or server mode using certificates. By using the client-to- client directive, it will also enable different OpenVPN clients to contact each other. For TAP-based networks, this has some important side-effects.

Getting ready

We use the following network layout:

74

Chapter 3

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IPonly Networks.

For this recipe, the server was running CentOS 5 Linux and OpenVPN 2.1.1; one client was running Windows 2000 SP4 and OpenVPN 2.1.1, the other client was running Windows XP SP3 and OpenVPN 2.1.1. For the server, keep the configuration file example3-1-server.conf from the previous recipe at hand.

How to do it...

1.Create the server configuration file by adding a line to the example3-1-server. conf file:

client-to-client

Save it as example-3-2-server.conf. 2. Start the server:

[root@server]# openvpn --config example3-2-server.conf

3.Set up IP forwarding and an iptables masquerading rule:

[root@server]# sysctl -w net.ipv4.ip_forward=1

[root@server]# iptables -t nat -I POSTROUTING -i tap+ -o eth0 \ -s 192.168.99.0/24 -j MASQUERADE

4.Next, create the client configuration file for the first client:

client proto udp

remote openvpnserver.example.com port 1194

dev tap nobind

ca	"c:/program files/openvpn/config/ca.crt"
cert	"c:/program files/openvpn/config/client1.crt"
key	"c:/program files/openvpn/config/client1.key"

tls-auth "c:/program files/openvpn/config/ta.key" 1

ns-cert-type server

verb 5

Save it as example-3-2-client1.ovpn.

75

Client-server Ethernet-style Networks

5.Similarly, for the second client create the configuration file:

client proto udp

remote openvpnserver.example.com port 1194

dev tap nobind

ca	"c:/program files/openvpn/config/ca.crt"
cert	"c:/program files/openvpn/config/client2.crt"
key	"c:/program files/openvpn/config/client2.key"

tls-auth "c:/program files/openvpn/config/ta.key" 1

ns-cert-type server

verb 5

And save it as example-3-2-client2.ovpn.

6. Start the Windows clients on the command line or from the OpenVPN GUI:

[WinClient1]C:> cd \program files\openvpn\config [WinClient1]C:> ..\bin\openvpn --config example3-2-client1.ovpn

Client2:

76

Chapter 3

7.After the connection is established, we can verify that it is working by pinging the server:

[WinClient1]C:> ping 192.168.99.1

Pinging 192.168.99.1 with 32 bytes of data:

Reply from 192.168.99.1: bytes=32 time=24ms TTL=64

Reply from 192.168.99.1: bytes=32 time=25ms TTL=64

And also that we can ping the second client:

[WinClient1]C:> ping 192.168.99.3

Pinging 192.168.99.3 with 32 bytes of data:

Reply from 192.168.99.3: bytes=32 time=49ms TTL=128

Reply from 192.168.99.3: bytes=32 time=50ms TTL=128

Notice the higher round-trip time.

8. Finally, verify that we can still ping a host on the server-side LAN:

[WinClient1]C:\> ping -c 2 10.198.0.9

Pinging 10.198.0.9 with 32 bytes of data:

Reply from 10.198.0.9: bytes=32 time=25ms TTL=63

Reply from 10.198.0.9: bytes=32 time=25ms TTL=63

How it works...

Both clients connect to the OpenVPN server in the regular manner. The following directive is all that is needed for the clients to "see" each other:

client-to-client

Communication between the clients will still pass through the OpenVPN server, which explains the higher round-trip time for the ICMP packets. The flow of an ICMP (ping) echo and reply is:

1.The OpenVPN client encrypts the packet and forwards it to the server over a secure link.

2.The server decrypts the packet and determines that the packet needs to be forwarded to another OpenVPN client. Therefore, the packet is not forwarded to the kernel routing modules but is encrypted again and is forwarded to the second client.

3.The second client receives the packet, decrypts it, and sends a reply back to the server over the secure link.

77