{{Expansion|(at least) add support for ipv6 and L2 ethernet bridging}}

{{Expansion|(at least) add support for ipv6 and L2 ethernet bridging}}

Line 24:

Line 25:

==Configure the system for TUN/TAP support==

==Configure the system for TUN/TAP support==

−

OpenVPN requires TUN/TAP support. Make sure to load the TUN module.

+

OpenVPN requires TUN/TAP support. Make sure to load at boot the {{ic|tun}} module.

−

{{hc|/etc/modules-load.d/tun.conf|<nowiki>

+

Read [[Kernel Modules]] for more information.

−

# Load tun.ko at boot

−

tun</nowiki>}}

The default kernel is already properly configured, but if you use another kernel make sure to enable the TUN/TAP module. If {{ic|$ zgrep CONFIG_TUN /proc/config.gz}} returns {{ic|<nowiki>CONFIG_TUN=n</nowiki>}}, make the following change to the kernel config file and rebuild the kernel.

The default kernel is already properly configured, but if you use another kernel make sure to enable the TUN/TAP module. If {{ic|$ zgrep CONFIG_TUN /proc/config.gz}} returns {{ic|<nowiki>CONFIG_TUN=n</nowiki>}}, make the following change to the kernel config file and rebuild the kernel.

To start as a daemon at boot, add openvpn to the daemons array in {{ic|/etc/rc.conf}}

+

=== Systemd service configuration ===

+

Since version 2.2.2-2, a service file is included by default.

+

+

The name of the daemon would be <tt>openvpn@''configuration-filename''.service</tt>

+

+

If the filename of the configuration is {{ic|/etc/openvpn/client.conf}}, then the daemon would be {{ic|openvpn@client.service}}

−

{{Note|Starting as a daemon will start one process per valid configuration file found.}}

+

Start the daemon and configure it to start at boot, both on the server and on the client(s).

−

=== Systemd service configuration ===

+

Read [[Daemons]] for more information.

−

Since version 2.2.2-2, a service file is included by default.

−

To start an OpenVPN daemon using <tt>/etc/openvpn/''client''.conf</tt> and enable it permanently:

−

{{bc|# systemctl enable openvpn@''client''.service

−

# systemctl start openvpn@''client''.service}}

==Advanced L3 IP routing==

==Advanced L3 IP routing==

Line 250:

Line 248:

====Promiscious LAN inteface====

====Promiscious LAN inteface====

−

+

The forwarding host's NIC (eth0 in the following examples) must also be able to accept packets for a different IP address than it is configured for, something known as [[Wikipedia:Promiscuous_mode|promiscious mode]]. To enable, add the following to {{ic|/etc/rc.local}} (takes effect at the next boot):

The forwarding host's NIC (eth0 in the following examples) must also be able to accept packets for a different IP address than it is configured for, something known as [[Wikipedia:Promiscuous_mode|promiscious mode]]. To enable, add the following to {{ic|/etc/rc.local}} (takes effect at the next boot):

Configure the system for TUN/TAP support

The default kernel is already properly configured, but if you use another kernel make sure to enable the TUN/TAP module. If $ zgrep CONFIG_TUN /proc/config.gz returns CONFIG_TUN=n, make the following change to the kernel config file and rebuild the kernel.

A basic L3 IP routing configuration

OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both "servers" and "clients", blurring the distinction between server and client.

What really distinguishes a server from a client (apart from the type of certificate used) is the configuration file itself. The openvpn daemon startup script reads all the .conf configuration files it finds in /etc/openvpn on startup and acts accordingly. In fact if it finds more than one configuration file, it will start one OpenVPN processes per configuration file.

This article explains how to setup a server called elmer, and a client that connects to it called bugs. More servers and clients can easily be added, by creating more key/certificate pairs and adding more server and client configuration files.

The OpenVPN package comes with a collection of example configuration files for different purposes. The sample server and client configuration files make an ideal starting point for a basic OpenVPN setup with the following features:

The server configuration file

The ca, cert, key, and dh parameters to reflect the path and names of the keys and certificates. Specifying the paths will allow you to run the OpenVPN executable from any directory for testing purposes.

Enable the SSL/TLS HMAC handshake protection. Note the use of the parameter 0 for a server.

It is recommended to run OpenVPN with reduced privileges once it has initialized, do this by uncommenting the user and group directives.

Promiscious LAN inteface

The forwarding host's NIC (eth0 in the following examples) must also be able to accept packets for a different IP address than it is configured for, something known as promiscious mode. To enable, add the following to /etc/rc.local (takes effect at the next boot):

/etc/rc.local

ip link set dev eth0 promisc on

To temporarily enable without rebooting: # ip link set dev eth0 promisc on

Routing tables

The factual accuracy of this article or section is disputed.

Reason: Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used (Discuss in Talk:OpenVPN#)

By default, all IP packets on a LAN addressed to a different subnet get sent to the default gateway. If the LAN/VPN gateway is also the default gateway, there is no problem and the packets get properly forwarded. If not, the gateway has no way of knowing where to send the packets. There are a couple of solutions to this problem.

Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.

Add a static route on each host on the LAN that needs to send IP packets back to the VPN.

Use iptables' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.

Connect the server LAN to a client

The server is on a LAN using the 10.66.0.0/24 subnet. To inform the client about the available subnet, add a push directive to the server configuration file:

/etc/openvpn/server.conf

push "route 10.66.0.0 255.255.255.0"

Note: Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the server. Make sure the server LAN knows how to reach the VPN client.

Note: To route more LANs from the server to the client, add more push directives to the server configuration file, but keep in mind that the server side LANs will need to know how to route to the client.

Connect the client LAN to a server

Prerequisites:

Any subnets used on the client side, must be unique and not in use on the server or by any other client. In this example we will use 192.168.4.0/24 for the clients LAN.

Each client's certificate has a unique Common Name, in this case bugs.

The server may not use the duplicate-cn directive in its config file.

Create a client configuration directory on the server. It will be searched for a file named the same as the client's common name, and the directives will be applied to the client when it connects.

# mkdir -p /etc/openvpn/ccd

Create a file in the client configuration directory called bugs, containing the iroute 192.168.4.0 255.255.255.0 directive. It tells the server what subnet should be routed to the client:

/etc/openvpn/ccd/bugs

iroute 192.168.4.0 255.255.255.0

Add the client-config-dir and the route 192.168.4.0 255.255.255.0 directive to the server configuration file. It tells the server what subnet should be routed from the tun device to the server LAN:

/etc/openvpn/server.conf

client-config-dir ccd
route 192.168.4.0 255.255.255.0

Note: Remember to enable ipv4 forwarding and to make the LAN interface promiscuous on the client. Make sure the client LAN knows how to reach the VPN server.

Note: To route more LANs from the client to the server, add more iroute and route directives to the appropriate configuration files, but keep in mind that the client side LANs will need to know how to route to the server.

Note: Remember to enable ipv4 forwarding and to make the LAN interfaces promiscuous on both the client and the server. Make sure that all the LANs or the needed hosts can route to all the destinations.

Connect clients and client LANs

By default clients will not see each other, to allow ip packets to flow between clients and/or client LANs add a client-to-client directive to the server configuration file:

/etc/openvpn/server.conf

client-to-client

In order for another client or client LAN to see a specific client LAN you will need to add a push directive for each client subnet to the server configuration file (this will make the server announce the available subnet(s) to other clients):

To have the tun module loaded automatically at boot time add it to the Modules line in /etc/rc.conf

DNS

The DNS servers used by the system are defined in /etc/resolv.conf. Traditionally, this file is the responsibility of whichever program deals with connecting the system to the network (e.g. Wicd, NetworkManager, etc...) However, OpenVPN will need to modify this file if you want to be able to resolve names on the remote side. To achieve this in a sensible way, install openresolv, which makes it possible for more than one program to modify resolv.conf without stepping on each-other's toes. Before continuing, test openresolv by restarting your network connection and ensuring that resolv.conf states that it was generated by "resolvconf", and that your DNS resolution still works as before. You should not need to configure openresolv; it should be automatically detected and used by your network system.

Next, save the following script at /usr/share/openvpn/update-resolv-conf:

Webmin

Connecting to the Server

You need to start the service on the server

/etc/rc.d/openvpn start

You can add it to rc.conf to make it permanet.

On the client, in the home directory create a folder that will hold your OpenVPN client config files along with the .crt/.key files. Assuming your OpenVPN config folder is called .openvpn and your client config file is vpn1.conf, to connect to the server issue the following command: