TODO: check this now updated article for accuracy, readability and completeness
This page describes multiple ways to create a network bridge on Arch Linux and host an OpenVPN server using a IP layer-2 based Ethernet bridge (TAP) rather than a IP layer-3 based IP tunnel (TUN). The general OpenVPN page describes setting up PAM authentication or OpenSSL security certificates in more detail.
The OpenVPN documentation pages give a full overview of server-side and client-side options that OpenVPN supports. It is easier to set up OpenVPN in tunneling mode and control routing the traffic and it is generally advised to do so if it serves your purpose. However, some applications, such as Windows file sharing or Samba, rely on network broadcasts at the Ethernet level and benefit from believing they are physically located on the same subnet, and software bridging serves this purpose.
The first thing you want to do is install OpenVPN, the Linux bridging utilities and netcfg.
pacman -S openvpn bridge-utils netcfg
Earlier versions of guides for OpenVPN provided by the OpenVPN team or various Linux packagers give example scripts for constructing a bridge when starting OpenVPN and destroying it when shutting OpenVPN down.
However, this is a somewhat deprecated approach, since OpenVPN as of 2.1.1 defaults to not allowing itself to call external scripts or programs unless explicitly enabled to, for security reasons.
Also, constructing the bridge is relatively slow compared to all other parts of the network initialization process. (In fact, so slow that dhcpcd will time out before the bridge is ready. See #Troubleshooting.) Also, when restarting OpenVPN after configuration changes, there is no reason to rebuild a working bridge, interrupting all your other network applications. So, setting up a static bridge configuration as follows is one recommended method.
To create an OpenVPN bridge for your server, you are going to have to use netcfg and create two network profiles - one for the tap interface and one for the bridge.
Go to /etc/network.d/. Then copy the tuntap example file to the directory.
cd /etc/network.d/ cp examples/tuntap openvpn_tap
Now edit openvpn_tap to create a tap interface. It may look like this.
INTERFACE='tap0' CONNECTION='tuntap' MODE='tap' USER='nobody' GROUP='nobody'
Do not configure the IP address here, this is going to be done for the bridge interface!
To create the bridge profile, copy the example file:
cp examples/bridge openvpn_bridge
Now edit openvpn_bridge. It may look like this:
INTERFACE="br0" CONNECTION="bridge" DESCRIPTION="OpenVPN Bridge" BRIDGE_INTERFACES="eth0 tap0" IP='static' ADDR='192.168.11.1' GATEWAY='192.168.11.254' DNS=('192.168.11.254')
For more information, for example how to use DHCP instead, check the netcfg article.
Now set the NETWORKS array in /etc/rc.conf (order is important!):
Then add net-profiles to your DAEMONS array (net-profiles must be before openvpn!):
DAEMONS=(... net-profiles openvpn ...)
There are a few example server configurations located in /usr/share/openvpn/examples to look at.
Here is a server configuration that uses dhcp, and some features only available since 2.1.1, saved as /etc/openvpn/server.conf
# /etc/openvpn/server.conf # 2009.12.31 # # address to bind to, instead of all available ;local 192.168.3.252 # new features, as of v2.1.1 #can listen on multiple ips over udp multihome # needed to allow internally called scripts like up/down # to call external programs like ifup, etc ;script-security 2 # tcp might work better on certain "dev tun" setups # but not for wrapping more tcp or further encrypted # streams, as that would be redundant, and very slow # "port 1194" and "proto udp" are defaults port 1194 proto udp # could specify interface, like tap0 or tap1 # or use up/down routing scripts to handle # more than one, if needed dev tap0 # simple scripts # for adding/removing to tap ;up "up.sh br0:0" ;down "down.sh br0:0" # identical certificate on server & client ca config/keys/ca.crt # server's own cert/key cert config/keys/server.crt key config/keys/server.key # keep secret # for certificate handshake dh config/keys/dh1024.pem # no arguments will use this subnet's dhcp server # not openvpn dynamic/static assigment # either way is good, but if you know you're not conflicting # with any other IP addressing schemes on your subnet, # this is much faster # this directive expands to include "mode server" and "tls-server" # so including them elsewhere is redundant ;server-bridge 192.168.3.252 255.255.255.0 192.168.3.1 192.168.3.16 # like what dhcp does, reuses IPs ;ifconfig-pool-persist ipp.txt # this one uses a dhcp server, server-side # potentially better for controlling ip addresses from one location # clients must support binding their dhcp client to their tap adapter server-bridge nogw # 'nogw' is optional # openvpn server routes client packets to each other itself # should happen anyway in 'dev tap' mode, but this saves time client-to-client # ping clients to auto close server side connection keepalive 10 60 # 0 for server, 1 for client tls-auth config/keys/ta.key 0 # This file is secret # cryptographic cipher. ;cipher BF-CBC # Blowfish (default) cipher AES-128-CBC # AES # compression is useful for xfer of # not already compressed files, like database # files, otherwise add needless overhead # comp-lzo [mode] ; yes|no|adaptive, adaptive default ;comp-lzo # not needed yet ;max-clients 100 # drop root priveledges once connected # good idea, for servers running on linux user nobody group nobody # avoid accessing things you no longer can persist-key persist-tun # short status file showing current connections # rewritten every minute. status openvpn-status.log # use one or the other, useful for managing multiple # concurrent servers on a system ;log openvpn.log ;log-append openvpn.log # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 # silence repeating messages past certain number, in log ;mute 20
The following is a matching client.ovpn for the options used in server.conf above, tested in Windows.
# /%openvpn%/config/client.conf # 2009.12.31 # defines order of certificate authentification # this directive expands to "pull" "tls-client" # so including them elsewhere is redundant client # type of server dev tap # windows needs tap name, if more than one ;dev-node OpenVPN Bridge Connection # remote <hostname> [port] [proto] remote remote 1194 udp # only works for peers using the "remote" option # ok if the ip address for remote changes during session float # uses a random port client-side nobind # this is for laptops or internet conditions # where openvpn server hostname cannot be resolved easily, # or changes often, etc # infinte is the default, or value for seconds resolv-retry infinite # public ca keys/ca.crt cert keys/satellite.crt # private key keys/satellite.key # needed when specified in server # 0 = server, 1 = client tls-auth keys/ta.key 1 # verify that the server has certificate field "server" # protects against certain attacks ns-cert-type server ;cipher BF-CBC cipher AES-128-CBC # comp-lzo [mode] ; yes|no|adaptive, adaptive default ;comp-lzo # try to preserve some states across restarts persist-key persist-tun verb 3
Q: Why does starting the network [FAIL] ?
A:This is probably because you are using DHCP on the bridge and setting up the bridge takes longer than dhcpcd is willing to wait. You can fix this by setting the FWD_DELAY parameter in your bridge network profile (openvpn_bridge). Start with a value of 5 and decrease it until it works.
OpenVPN | General page on configuring OpenVPN, including setting up authentication methods.
Any additions, clarifications, reorganizations, feedback etc. etc. are more than appreciated.