OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].

OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].

−

==Install OpenVPN==

+

== Install OpenVPN ==

+

[[pacman|Install]] {{Pkg|openvpn}} from the [[official repositories]].

[[pacman|Install]] {{Pkg|openvpn}} from the [[official repositories]].

{{Note|The software contained in this package supports both server and client mode, so install it on all machines that need to create vpn connections.}}

{{Note|The software contained in this package supports both server and client mode, so install it on all machines that need to create vpn connections.}}

−

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

+

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

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

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

−

Read [[Kernel Modules]] for more information.

+

Read [[Kernel modules]] for more information.

−

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|1=CONFIG_TUN=n}}, make the following change to the kernel config file and rebuild the kernel.

{{hc|Kernel config file|

{{hc|Kernel config file|

Line 36:

Line 37:

[M] Universal TUN/TAP device driver support}}

[M] Universal TUN/TAP device driver support}}

−

==Connect to a VPN provided by a third party==

+

== Connect to a VPN provided by a third party ==

To connect to a VPN provided by a third party, most of the following can most likely be ignored. Use the certificates and instructions given by your provider, for instance see: [[Airvpn]].

To connect to a VPN provided by a third party, most of the following can most likely be ignored. Use the certificates and instructions given by your provider, for instance see: [[Airvpn]].

−

==Create a Public Key Infrastructure (PKI) from scratch==

+

== Create a Public Key Infrastructure (PKI) from scratch ==

If you are setting up OpenVPN from scratch, you will need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]].

If you are setting up OpenVPN from scratch, you will need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]].

Line 48:

Line 49:

The final step of the key creation process is to copy the files needed to the correct machines through a secure channel.

The final step of the key creation process is to copy the files needed to the correct machines through a secure channel.

−

{{Note|The rest of this article assumes that the keys and certificates are placed in /etc/openvpn.}}

+

{{Note|The rest of this article assumes that the keys and certificates are placed in {{ic|/etc/openvpn}}.}}

The public ca.crt certificate is needed on all servers and clients. The private ca.key key is secret and only needed on the key generating machine.

The public ca.crt certificate is needed on all servers and clients. The private ca.key key is secret and only needed on the key generating machine.

Line 56:

Line 57:

A client needs client.crt (public), and client.key and ta.key (private).

A client needs client.crt (public), and client.key and ta.key (private).

−

==A basic L3 IP routing configuration==

+

== A basic L3 IP routing configuration ==

{{Note|Unless otherwise explicitly stated, the rest of this article assumes this basic configuration.}}

{{Note|Unless otherwise explicitly stated, the rest of this article assumes this basic configuration.}}

Line 75:

Line 76:

For more advanced configurations, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].

For more advanced configurations, please see the official [http://openvpn.net/index.php/manuals/427-openvpn-22.html OpenVPN 2.2 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].

* 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.

* 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'''.

* 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.

+

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

{{hc|/etc/openvpn/server.conf|

{{hc|/etc/openvpn/server.conf|

Line 104:

Line 105:

{{Note|Note that if the server is behind a firewall or a NAT translating router, you will have to forward the OpenVPN UDP port (1194) to the server.}}

{{Note|Note that if the server is behind a firewall or a NAT translating router, you will have to forward the OpenVPN UDP port (1194) to the server.}}

You now have a working OpenVPN installation, and your client (bugs) will be able to use services on the server (elmer), and vice versa.

You now have a working OpenVPN installation, and your client (bugs) will be able to use services on the server (elmer), and vice versa.

Line 213:

Line 216:

{{Note|If using a firewall, make sure that ip packets on the TUN device are not blocked.}}

{{Note|If using a firewall, make sure that ip packets on the TUN device are not blocked.}}

−

===Configure the MTU with Fragment and MSS===

+

=== Configure the MTU with Fragment and MSS ===

{{Note|If you do not configure MTU then you will notice that small packets like ping and DNS will work, however web browsing will not work.}}

{{Note|If you do not configure MTU then you will notice that small packets like ping and DNS will work, however web browsing will not work.}}

Line 219:

Line 222:

Now it is time to configure the maximum segment size (MSS). In order to do this we need to discover what is the smallest MTU along the path between the client and server. In order to do this you can ping the server and disable fragmentation. Then specify the max packetsize.

Now it is time to configure the maximum segment size (MSS). In order to do this we need to discover what is the smallest MTU along the path between the client and server. In order to do this you can ping the server and disable fragmentation. Then specify the max packetsize.

We received an ICMP message telling us the MTU is 576 bytes. The means we need to fragment the UDP packets smaller then 576 bytes to allow for some UDP overhead.

We received an ICMP message telling us the MTU is 576 bytes. The means we need to fragment the UDP packets smaller then 576 bytes to allow for some UDP overhead.

−

{{hc|# ping -c5 -M do -s 548 elmer.acmecorp.org|<nowiki>

+

{{hc|# ping -c5 -M do -s 548 elmer.acmecorp.org|2=

PING elmer.acmecorp.org (99.88.77.66) 548(576) bytes of data.

PING elmer.acmecorp.org (99.88.77.66) 548(576) bytes of data.

556 bytes from 99.88.77.66: icmp_seq=1 ttl=48 time=206 ms

556 bytes from 99.88.77.66: icmp_seq=1 ttl=48 time=206 ms

Line 244:

Line 247:

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

rtt min/avg/max/mdev = 206.027/210.603/224.158/6.832 ms

rtt min/avg/max/mdev = 206.027/210.603/224.158/6.832 ms

−

</nowiki>}}

+

}}

After some trial and error..., we discover that we need to fragment packets on 548 bytes. In order to do this we specify this fragment size in the configuration and instruct OpenVPN to fix the Maximum Segment Size (MSS).

After some trial and error..., we discover that we need to fragment packets on 548 bytes. In order to do this we specify this fragment size in the configuration and instruct OpenVPN to fix the Maximum Segment Size (MSS).

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 (enp1s0 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 set the {{ic|enp1s0}} in promiscuous mode using systemd use [[ Systemd/Services#Set_network_interface_in_promiscuous_mode | this service file ]] and enable it using:

To set the {{ic|eth0}} in promiscuous mode using systemd use [[ Systemd/Services#Set_network_interface_in_promiscuous_mode | this service file ]] and enable it using:

−

# systemctl enable promiscuous@eth0.service

+

==== Routing tables ====

−

−

====Routing tables====

{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}

{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}

Line 342:

Line 342:

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

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

−

===Connect the server LAN to a client===

+

=== 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:{{hc|/etc/openvpn/server.conf|push "route 10.66.0.0 255.255.255.0"}}

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:{{hc|/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|

−

+

* 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.}}

+

* 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===

+

=== Connect the client LAN to a server ===

Prerequisites:

Prerequisites:

Line 360:

Line 361:

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.

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.

−

{{bc|# mkdir -p /etc/openvpn/ccd}}

+

# mkdir -p /etc/openvpn/ccd

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

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

Line 373:

Line 374:

}}

}}

−

{{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|

+

* 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.

+

* 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|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.}}

+

=== Connect both the client and server LANs ===

−

−

===Connect both the client and server LANs===

Combine the two previous sections:

Combine the two previous sections:

Line 388:

Line 390:

route 192.168.4.0 255.255.255.0

route 192.168.4.0 255.255.255.0

}}

}}

−

{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}

{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}

−

{{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.}}

{{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===

+

=== 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: {{hc|/etc/openvpn/server.conf|client-to-client}}

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: {{hc|/etc/openvpn/server.conf|client-to-client}}

Line 411:

Line 411:

{{Note|As always, make sure that the routing is properly configured.}}

{{Note|As always, make sure that the routing is properly configured.}}

−

==L2 Ethernet bridging==

+

== L2 Ethernet bridging ==

{{Expansion|Please add a well thought out section on L2 bridging.}}

{{Expansion|Please add a well thought out section on L2 bridging.}}

Line 417:

Line 417:

For now see: [[OpenVPN Bridge]]

For now see: [[OpenVPN Bridge]]

−

==Contributions that do not yet fit into the main article==

+

== Contributions that do not yet fit into the main article ==

{{Accuracy|Not quite sure where this fits into the main article yet}}

{{Accuracy|Not quite sure where this fits into the main article yet}}

−

===Routing client traffic through the server===

+

=== Routing client traffic through the server ===

Append the following to your server's openvpn.conf configuration file:

Append the following to your server's openvpn.conf configuration file:

−

{{bc|

+

−

push "redirect-gateway def1"

+

push "redirect-gateway def1"

−

push "dhcp-option DNS 192.168.1.1"

+

push "dhcp-option DNS 192.168.1.1"

−

}}

+

Change "192.168.1.1" to your preferred DNS IP address.

Change "192.168.1.1" to your preferred DNS IP address.

If you have problems with non responsive DNS after connecting to server, install [[BIND]] as simple DNS forwarder and push openvpn ip address of server as DNS to clients.

If you have problems with non responsive DNS after connecting to server, install [[BIND]] as simple DNS forwarder and push openvpn ip address of server as DNS to clients.

You must change default forward policy, edit /etc/sysctl.conf to permanently enable ipv4 packet forwarding. Takes effect at the next boot.

You must change default forward policy, edit /etc/sysctl.conf to permanently enable ipv4 packet forwarding. Takes effect at the next boot.

−

{{hc|/etc/sysctl.conf|<nowiki>

+

{{hc|/etc/sysctl.conf|2=

# Enable packet forwarding

# Enable packet forwarding

net.ipv4.ip_forward=1

net.ipv4.ip_forward=1

−

</nowiki>}}

+

}}

−

And then configure ufw in '''/etc/default/ufw'''

+

And then configure ufw in {{ic|/etc/default/ufw}}:

−

{{hc|/etc/default/ufw|<nowiki>

+

{{hc|/etc/default/ufw|2=

DEFAULT_FORWARD_POLICY="ACCEPT"

DEFAULT_FORWARD_POLICY="ACCEPT"

−

</nowiki>}}

+

}}

−

Now change '''/etc/ufw/before.rules''', and add the following code after the header and before the "*filter" line. Don't forget to change the IP/subnet mask to match the one in '''/etc/openvpn/server.conf'''.

+

Now change {{ic|/etc/ufw/before.rules}}, and add the following code after the header and before the "*filter" line. Don't forget to change the IP/subnet mask to match the one in {{ic|/etc/openvpn/server.conf}}.

−

{{hc|/etc/ufw/before.rules|<nowiki>

+

{{hc|/etc/ufw/before.rules|2=

# NAT (Network Address Translation) table rules

# NAT (Network Address Translation) table rules

*nat

*nat

:POSTROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [0:0]

−

# Allow traffic from clients to eth0

+

# Allow traffic from clients to enp1s0

−

-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE

+

-A POSTROUTING -s 10.8.0.0/8 -o enp1s0 -j MASQUERADE

# don't delete the "COMMIT" line or the NAT table rules above won't be processed

# don't delete the "COMMIT" line or the NAT table rules above won't be processed

COMMIT

COMMIT

−

</nowiki>}}

+

}}

−

Open openvpn port 1194

+

Open openvpn port 1194:

−

{{bc|

+

ufw allow 1194

−

ufw allow 1194

−

}}

−

====Using iptables====

+

==== Using iptables ====

Use an iptable for NAT forwarding:

Use an iptable for NAT forwarding:

−

{{bc|

−

echo 1 > /proc/sys/net/ipv4/ip_forward

−

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

−

}}

−

If running ArchLinux in a OpenVZ VPS environment [http://thecodeninja.net/linux/openvpn-archlinux-openvz-vps/]:

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

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

−

=====DNS=====

+

===== 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''':

+

The DNS servers used by the system are defined in {{ic|/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 {{ic|/usr/share/openvpn/update-resolv-conf}}:

Now, when your launch your OpenVPN connection, you should find that your resolv.conf file is updated accordingly, and also returns to normal when your close the connection.

Now, when your launch your OpenVPN connection, you should find that your resolv.conf file is updated accordingly, and also returns to normal when your close the connection.

−

=====Webmin=====

+

===== Webmin =====

{{AUR|webmin-plugin-openvpn}} is available in the [[AUR]].

{{AUR|webmin-plugin-openvpn}} is available in the [[AUR]].

{{Note|You must add "openvpn" to the end of /etc/webmin/webmin.acl.}}

{{Note|You must add "openvpn" to the end of /etc/webmin/webmin.acl.}}

−

====Connecting to the Server====

+

==== Connecting to the server ====

+

You need to start the service on the server

You need to start the service on the server

−

{{bc|

+

/etc/rc.d/openvpn start

/etc/rc.d/openvpn start

−

}}

+

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

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

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:

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:

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.

You now have a working OpenVPN installation, and your client (bugs) will be able to use services on the server (elmer), and vice versa.

Note: If using a firewall, make sure that ip packets on the TUN device are not blocked.

Configure the MTU with Fragment and MSS

Note: If you do not configure MTU then you will notice that small packets like ping and DNS will work, however web browsing will not work.

Now it is time to configure the maximum segment size (MSS). In order to do this we need to discover what is the smallest MTU along the path between the client and server. In order to do this you can ping the server and disable fragmentation. Then specify the max packetsize.

After some trial and error..., we discover that we need to fragment packets on 548 bytes. In order to do this we specify this fragment size in the configuration and instruct OpenVPN to fix the Maximum Segment Size (MSS).

Note: This will add about 3min's to OpenVPN start time. It is advisable to configure the fragment size unless your client is a laptop that will be connecting over many different networks and the bottle neck is on the client side.

You can also allow OpenVPN to do this for you by having OpenVPN do the ping testing every time the client connects to the VPN.

Promiscuous LAN interface

The forwarding host's NIC (enp1s0 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 set the enp1s0 in promiscuous mode using systemd use this service file and enable it using:

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.

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.

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 permanent.

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: