https://wiki.archlinux.org/api.php?action=feedcontributions&user=K4rolB&feedformat=atomArchWiki - User contributions [en]2024-03-28T10:13:11ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=OpenVPN&diff=683354OpenVPN2021-06-23T10:48:37Z<p>K4rolB: /* The update-systemd-resolved custom script */ Configuration for AUR package changed</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|OpenVPN Checklist Guide}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [https://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [https://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [https://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
* {{App|eOVPN|Application to connect, manage and update OpenVPN configurations.|https://github.com/jkotra/eOVPN|{{AUR|eovpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic Layer-3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic Layer-3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
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:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI Layer-3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [https://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 0''<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
If TLS with elliptic curves is used, specify {{ic|dh none}} and {{ic|ecdh-curve secp521r1}}. DH parameters file is not used when using elliptic curves. Starting from OpenVPN 2.4.8, it is required to specify the type of elliptic curves in server configuration. Otherwise the server would fail to recognize the curve type and possibly use an incompatible one, resulting in authentication errors.<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{Style|Usage instructions belong into the wiki text, not into code blocks. Avoid subjective terms like "bleeding edge security".}}<br />
<br />
Bleeding edge security<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.3<br />
#Uncomment tls-cipher to limit possible negotiation options to the strongest ciphers, doing so it's no longer possible to generate certs with current easyrsa, [https://wiki.openssl.org/index.php/TLS1.3 more information]<br />
#tls-cipher TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256<br />
.<br />
}}<br />
<br />
{{Style|Compatibility options do not fit into a hardening section.}}<br />
<br />
Compatibility with most devices<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPNās community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
* It is also possible to run OpenVPN from within unprivileged podman container, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser#RunOpenVPNwithinunprivilegedpodmancontainer this section of OpenVPN HowTo]<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|openvpn /etc/openvpn/server/server.conf}} (as the root user) on the server, and {{ic|openvpn /etc/openvpn/client/client.conf}} (as the root user) on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, a NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''configuration''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''configuration''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|''configuration''}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
{{Tip|If {{ic|openvpn-client@''configuration''.service}} units take a long time to start, it might be the network manager is not triggering the {{ic|network-online.target}} systemd target at the right moment. For example, when using [[systemd-networkd]], check that {{ic|systemd-networkd-wait-online.service}} is properly configured.}}<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. by running {{ic|journalctl -b -u NetworkManager}} as root).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
Without further configuration only traffic directly to and from the OpenVPN server's IP passes through the VPN. To have other traffic, like web traffic pass through the VPN, correspondent routes must be added. Either add routes in the client's configuration or configure the server to push these routes to the client.<br />
<br />
To redirect traffic to and from a subnet of the server, add {{ic|push "route <address pool> <subnet>"}} right before the {{ic|remote <address> <port> udp/tcp}}, like:<br />
<br />
route 192.168.1.0 255.255.255.0<br />
<br />
To redirect all traffic including Internet traffic to the server, add the following in the client's configuration:<br />
<br />
redirect-gateway def1 bypass-dhcp ipv6<br />
<br />
If running an IPv4-only server, drop the {{ic|ipv6}} option. If running IPv6-only, use {{ic|redirect-gateway ipv6 !ipv4}}.<br />
<br />
To make the server push routes, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp ipv6"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [https://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If running an IPv4-only server, drop the {{ic|ipv6}} option. If running IPv6-only, use {{ic|push "redirect-gateway ipv6 !ipv4"}}<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [https://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If using the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [https://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
# iptables -A INPUT -i tun+ -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -j ACCEPT<br />
# iptables -A INPUT -i tap+ -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface:<br />
<br />
# iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tap+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#The update-resolv-conf custom script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== Layer-3 IPv4 routing ==<br />
<br />
This section describes how to connect client/server LANs to each other using Layer-3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
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.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
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/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* 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.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
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.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
If accessing a machine in the client LAN from a machine in the server LAN, remember that packet forwarding needs to be enabled on the client ([[Internet sharing#Enable packet forwarding]]).<br />
<br />
{{Note|<br />
* If running openVPN as a daemon with systemd, you may need to specify an absolute path to your {{ic|ccd}} directory.<br />
* 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.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, 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):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
<br />
For Linux, the OpenVPN client can receive DNS host information from the server, but the client expects an external command to act on this information. No such commands are configured by default. They must be specified with the {{ic|up}} and {{ic|down}} config options. There are a few alternatives for what scripts to use, but none are officially recognised by OpenVPN, so in order for any of them to work, {{ic|script-security}} must be set to 2. The {{ic|down-root}} plugin can be used instead of the {{ic|down}} option if [[#Run as unprivileged user|running as an unprivileged user]].<br />
<br />
=== The pull-resolv-conf custom scripts ===<br />
<br />
These scripts are [https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf maintained by] OpenVPN. They are {{ic|client.up}} and {{ic|client.down}}, and they are packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with the {{ic|down-root}} plugin:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /usr/share/openvpn/contrib/pull-resolv-conf/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/usr/share/openvpn/contrib/pull-resolv-conf/client.down tun0"<br />
}}<br />
<br />
These scripts use the {{ic|resolvconf}} command if present. [[Systemd-resolvconf]] and [[Openresolv]] both implement this command. See their wiki pages for more information on getting a working {{ic|resolvconf}} implementation.<br />
<br />
{{Note|As of October 2019, systemd-resolvconf works as long as the systemd-resolved service is running. Openresolv will not work out of the box because {{ic|client.up}} will only create private DNS server entries. These require extra configuration of openresolv to work. See {{ic|man 8 resolvconf}} for more details on private DNS servers in openresolv.}}<br />
<br />
If no implementation of {{ic|resolvconf}} is present, {{ic|client.up}} preserves the existing {{ic|resolv.conf}} at {{ic|/etc/resolv.conf.ovpnsave}} and writes a new one. This new one will not have any of the original DNS servers.<br />
<br />
When editing these scripts, copy them somewhere else and edit them there, so that the changes do not get overwritten by the next {{pkg|openvpn}} package upgrade. {{ic|/etc/openvpn/client}} is a pretty good place.<br />
# cp /usr/share/openvpn/contrib/pull-resolv-conf/* /etc/openvpn/client<br />
# $EDITOR /etc/openvpn/client/client.{up.,down}<br />
# # etc ...<br />
<br />
=== The update-resolv-conf custom script ===<br />
<br />
{{Note|Another script, [[#The update-systemd-resolved custom script|update-systemd-resolved]], is recommended by the author of update-resolv-conf for systems with systemd.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
Users preferring a package may use {{AUR|openvpn-update-resolv-conf-git}} but will still need to do the following:<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== The update-systemd-resolved custom script ===<br />
<br />
{{Note|Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}.}}<br />
<br />
The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn/scripts}} and mark as [[executable]] (or [[install]] {{AUR|openvpn-update-systemd-resolved}}) and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
In order to send all DNS traffic through the VPN tunnel and prevent DNS leaks, also add the following line (see [https://github.com/jonathanio/update-systemd-resolved#dns-leakage]):<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
dhcp-option DOMAIN-ROUTE .<br />
}}<br />
<br />
Make sure that the [[systemd-resolved]] service is configured and running. Also, since openvpn 2.5.0-3 scripts are running as openvpn user instead of root. Thus, add a PolicyKit rule to allow OpenVPN systemd units to call DBus with SetLinkDNS:<br />
<br />
{{hc|/etc/polkit-1/rules.d/00-openvpn-resolved.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id == 'org.freedesktop.resolve1.set-dns-servers' ||<br />
action.id == 'org.freedesktop.resolve1.set-domains' ||<br />
action.id == 'org.freedesktop.resolve1.set-dnssec') {<br />
if (subject.user == 'openvpn') {<br />
return polkit.Result.YES;<br />
}<br />
}<br />
});</nowiki><br />
}}<br />
<br />
{{Note|While using {{AUR|openvpn-update-systemd-resolved}} package, the path to {{ic|update-systemd-resolved}} script in {{ic|client.conf}} should change from {{ic|/etc/openvpn/scripts/}} to {{ic|/usr/bin/}} and polkit rules are already set up.}}<br />
<br />
=== Override DNS servers using NetworkManager ===<br />
<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== Layer-2 Ethernet bridging ==<br />
<br />
Establishing an Ethernet bridge enables access to other devices within a subnet of the server. For example, accessing other machines in the local network of the OpenVPN server via [[Samba]] would be possible with this approach. Clients would be assigned an IP address as if it were within the same subnet.<br />
<br />
This is generally a two step process: 1) establishing the tap interface and the network bridge on the OpenVPN server to bridge the tap interface and the Ethernet interface, and 2) configuring the OpenVPN server.<br />
<br />
See [[OpenVPN Bridge]].<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines. {{ic|foo.ovpn}} will not automatically route all traffic through the VPN, so consider following [[#Routing client traffic through the server]] to enable redirection.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If using a custom script, perhaps for configuring [[#DNS]], add these scripts to the config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network Communication with Stunnel, OpenSSH, and OpenVPN]{{Dead link|2021|05|17|status=SSL error}} (PDF)</div>K4rolBhttps://wiki.archlinux.org/index.php?title=Visual_Studio_Code&diff=618264Visual Studio Code2020-06-04T15:52:01Z<p>K4rolB: /* Unable to debug C# */ Added more comprehensive explanation for using different debugger</p>
<hr />
<div>[[Category:Text editors]]<br />
[[ja:Visual Studio Code]]<br />
[[pt:Visual Studio Code]]<br />
[[zh-hans:Visual Studio Code]]<br />
[https://code.visualstudio.com/ Visual Studio Code] is a cross-platform, free and open-source (licensed under the MIT License) text editor developed by Microsoft and written in JavaScript and TypeScript. It is built on the Electron framework and is extensible using extensions, which can be browsed [https://marketplace.visualstudio.com/VSCode on the web] or from within the text editor itself. While the project is open-source, a proprietary build (licensed under an End-User License Agreement) is also provided by Microsoft. For an explanation of the mixed licensing, see [https://github.com/Microsoft/vscode/issues/60#issuecomment-161792005 this GitHub comment].<br />
<br />
== Installation ==<br />
<br />
The following packages provide VSCode:<br />
<br />
* {{Pkg|code}} (open-source release)<br />
* {{AUR|visual-studio-code-bin}} (Microsoft-branded release)<br />
* {{AUR|visual-studio-code-insiders}} (Microsoft-branded release, updated daily)<br />
* {{AUR|code-git}} (in-development open-source version)<br />
* {{AUR|vscodium-bin}} (another open-source version with a community-driven default configuration)<br />
<br />
The Microsoft [https://github.com/microsoft/ptvsd ptvsd] (Python Tools for Visual Studio Debug) server/module is available at {{AUR|python-ptvsd}}.<br />
<br />
== Usage ==<br />
<br />
Run {{ic|code}} to start the application (or {{ic|code-git}} when using {{AUR|code-git}}).<br />
<br />
If for any reason you wish to launch multiple instances of Visual Studio Code, the {{ic|-n}} flag can be used.<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|code}} stores settings in {{ic|~/.config/Code - OSS/User/settings.json}}.<br />
<br />
{{AUR|visual-studio-code-bin}} stores settings in {{ic|~/.config/Code/User/settings.json}}.<br />
<br />
=== Integrated Terminal ===<br />
<br />
''View > Integrated Terminal'' or {{ic|Ctrl + `}} opens up an integrated terminal.<br />
By default, [[Bash]] is used with no additional arguments, although this can be changed.<br />
{{ic|terminal.integrated.shell.linux}} sets the default shell to be used and<br />
{{ic|terminal.integrated.shellArgs.linux}} sets the arguments to be passed to the shell.<br />
<br />
Example:<br />
<br />
{{hc|~/.config/Code/User/settings.json|<br />
"terminal.integrated.shell.linux": "/usr/bin/fish",<br />
"terminal.integrated.shellArgs.linux": ["-l","-d 3"]<br />
}}<br />
<br />
You might face weird prompts after setting the integrated shell arguments with external terminal, remove the line to solve the problem or use an external terminal.<br />
<br />
=== External terminal ===<br />
<br />
If you are using [[Terminator]] as default terminal for Arch and you have an error on Visual Studio Code: {{ic|Unable to launch debugger worker process (vsdbg) through the terminal. spawn truecolor ENOENT}}, you can change the terminal that will be used by Visual Studio to another terminal (e.g. {{Pkg|gnome-terminal}}).<br />
<br />
{{ic|"terminal.external.linuxExec": "Your alternative terminal"}} sets the default terminal to be used for exec debug.<br />
<br />
Example:<br />
<br />
{{hc|~/.config/Code/User/settings.json|<br />
"terminal.external.linuxExec": "gnome-terminal"<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Global menu not working in KDE/Plasma ===<br />
<br />
Visual Studio Code uses DBus to pass the menu to Plasma, try installing {{Pkg|libdbusmenu-glib}}<br />
<br />
=== Unable to move items to trash ===<br />
<br />
By default, [https://electron.atom.io/ Electron] apps use {{ic|gio}} to delete files. Different trash implementations can be used by setting the {{ic|ELECTRON_TRASH}} [[environment variable]].<br />
<br />
For example, for deleting files under [[Plasma]]:<br />
<br />
$ ELECTRON_TRASH=kioclient5 code<br />
<br />
At the time of writing, Electron supports {{ic|kioclient5}}, {{ic|kioclient}}, {{ic|trash-cli}}, {{ic|gio}} (default) and {{ic|gvfs-trash}} (deprecated). More info is available at this [https://github.com/electron/electron/blob/master/docs/api/environment-variables.md#electron_trash-linux documentation page].<br />
<br />
=== Unable to debug C# ===<br />
<br />
If you want to debug C#[[.NET_Core|.NET]] (using the [http://www.omnisharp.net OmniSharp extension]) then you need to install the Microsoft branded release (from the AUR). This is apparently because the .NET Core debugger is only licensed to be used with official Microsoft products - see [https://github.com/OmniSharp/omnisharp-vscode/issues/1431#issuecomment-297578930 this github discussion].<br />
<br />
When using the open-source package, debugging fails fairly quietly. The debug console will just show the initial message:<br />
<br />
{{bc|You may only use the Microsoft .NET Core Debugger (vsdbg) with<br />
Visual Studio Code, Visual Studio or Visual Studio for Mac software<br />
to help you develop and test your applications.}}<br />
<br />
For debugging with the open-source package {{AUR|netcoredbg}} can be used. To run it in VS Code, add this configuration to .NET Core launch configuration of the project:<br />
<br />
{{hc|./.vscode/launch.json|<br />
"configurations": [<br />
{<br />
...<br />
"pipeTransport": {<br />
"pipeCwd": "${workspaceFolder}",<br />
"pipeProgram": "/usr/bin/bash",<br />
"pipeArgs": ["-c"],<br />
"debuggerPath": "/usr/bin/netcoredbg"<br />
}<br />
...<br />
}}<br />
<br />
=== Unable to open .csproj with OmniSharp server, invalid Microsoft.Common.props location ===<br />
<br />
You have to switch from mono to proper SDK version props.<br />
<br />
{{hc|/opt/dotnet/sdk/{VERSION}/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props|<br />
$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props<br />
}}<br />
<br />
Modify import to look like this:<br />
<br />
{{hc|/opt/dotnet/sdk/{VERSION}/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props|<br />
/opt/dotnet/sdk/{VERSION}/Current/Microsoft.Common.props<br />
}}<br />
<br />
=== Error from OmniSharp that MSBuild cannot be located ===<br />
<br />
It is noted in the [https://github.com/OmniSharp/omnisharp-roslyn#introduction OmniSharp introduction] that Arch Linux users should install the {{AUR|msbuild-stable}} package. Without it, you might get an error like:<br />
<br />
{{hc|1=OmniSharp Log|2=<br />
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator<br />
Registered MSBuild instance: StandAlone 15.0 - "~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin"<br />
MSBuildExtensionsPath = /usr/lib/mono/xbuild<br />
BypassFrameworkInstallChecks = true<br />
CscToolPath = ~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin/Roslyn<br />
CscToolExe = csc.exe<br />
MSBuildToolsPath = ~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin<br />
TargetFrameworkRootPath = /usr/lib/mono/xbuild-frameworks<br />
System.TypeLoadException: Could not load type of field 'OmniSharp.MSBuild.ProjectManager:_queue' (13) due to: Could not load file or assembly 'System.Threading.Tasks.Dataflow, Version=4.5.24.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.<br />
...}}<br />
<br />
You might be able to build anyway (possibly depending whether you have {{Pkg|mono}} installed too)<br />
<br />
=== Saving with "Retry as Sudo" does not work ===<br />
<br />
This feature does not work in the {{Pkg|code}} package, because Microsoft does not support the way the Arch package is packaged (native instead of bundled Electron). See {{Bug|61516}} and the [https://github.com/Microsoft/vscode/issues/70403 upstream bug report] for more information.<br />
<br />
The binary release {{AUR|visual-studio-code-bin}} does not have this issue, and the feature works there.<br />
<br />
=== Keyboard variants or keymappings do not map ===<br />
<br />
As per the [https://github.com/Microsoft/vscode/wiki/Keybinding-Issues#troubleshoot-linux-keybindings wiki on GitHub]:<br />
<br />
: Switching keyboard layouts under some Linux window managers does not result in a change in the low level X window APIs VS Code uses to read the current keyboard layout. This means that VS Code ends up sometimes reading one of the other configured keyboard layouts and not the current active one. PR welcome...<br />
<br />
Per the wiki, there are two possible solutions:<br />
<br />
# make sure {{ic|setxkbmap -query}} returns as the first keyboard layout the one you want to work with in VS Code.<br />
# use {{ic|"keyboard.dispatch": "keyCode"}} in your settings and restart VS Code. This will prevent VS Code from trying to determine your keyboard layout whatsoever.<br />
<br />
=== Command 'remote-containers.openFolder' not found ===<br />
<br />
Open VS Code enabling remote-containers API as commented in {{bug|63374}}<br />
<br />
$ code-oss --enable-proposed-api ms-vscode-remote.remote-containers</div>K4rolBhttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=586017OpenVPN2019-10-14T19:12:33Z<p>K4rolB: Restored the link. The author of this script actually recommends '''different''' script, not his own</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[ru:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic L3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic L3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
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:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 0''<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPNās community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client/client.conf}} on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''<configuration>''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''<configuration>''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|<configuration>}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
Without further configuration only traffic directly to and from the OpenVPN server's IP passes through the VPN. To have other traffic, like web traffic pass through the VPN, correspondent routes must be added. You can either add routes in the client's configuration or configure the server to push these routes to the client.<br />
<br />
To redirect traffic to and from a subnet of the server, add {{ic|push "route <address pool> <subnet>"}} right before the {{ic|remote <address> <port> udp/tcp}}, like:<br />
<br />
route 192.168.1.0 255.255.255.0<br />
<br />
To redirect all traffic including Internet traffic to the server, add the following in the client's configuration:<br />
<br />
redirect-gateway def1 bypass-dhcp ipv6<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|redirect-gateway ipv6 !ipv4}}.<br />
<br />
To make the server push routes, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp ipv6"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|push "redirect-gateway ipv6 !ipv4"}}<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
iptables -A INPUT -i tun+ -j ACCEPT<br />
iptables -A FORWARD -i tun+ -j ACCEPT<br />
iptables -A INPUT -i tap+ -j ACCEPT<br />
iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface.<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#The update-resolv-conf custom script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== L3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using L3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
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.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
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/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* 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.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
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.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, 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):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
For Linux, the OpenVPN client can receive DNS host information from the server, but the client expects an external command to act on this information. No such commands are configured by default. They must be specified with the {{ic|up}} and {{ic|down}} config options. There are a few alternatives for what scripts to use, but none are officially recognised by OpenVPN, so in order for any of them to work, {{ic|script-security}} must be set to 2. The {{ic|down-root}} plugin can be used instead of the {{ic|down}} option if [[#Run as unprivileged user|running as an unprivileged user]].<br />
<br />
=== The pull-resolv-conf custom scripts ===<br />
These scripts are [https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf maintained by] OpenVPN. They are {{ic|client.up}} and {{ic|client.down}}, and they are packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with the {{ic|down-root}} plugin:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /usr/share/openvpn/contrib/pull-resolv-conf/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/usr/share/openvpn/contrib/pull-resolv-conf/client.down tun0"<br />
}}<br />
<br />
These scripts use the {{ic|resolvconf}} command if present. [[Systemd-resolvconf]] and [[Openresolv]] both implement this command. See their wiki pages for more information on getting a working {{ic|resolvconf}} implementation.<br />
<br />
{{Note|As of October 2019, systemd-resolvconf works as long as the systemd-resolved service is running. Openresolv will not work out of the box because {{ic|client.up}} will only create private DNS server entries. These require extra configuration of openresolv to work. See {{ic|man 8 resolvconf}} for more details on private DNS servers in openresolv.}}<br />
<br />
If no implementation of {{ic|resolvconf}} is present, {{ic|client.up}} preserves the existing {{ic|resolv.conf}} at {{ic|/etc/resolv.conf.ovpnsave}} and writes a new one. This new one will not have any of the original DNS servers.<br />
<br />
If you need to edit these scripts, copy them somewhere else and edit them there, so that your changes don't get overwritten by the next {{pkg|openvpn}} package upgrade. {{ic|/etc/openvpn/client}} is a pretty good place.<br />
# cp /usr/share/openvpn/contrib/pull-resolv-conf/* /etc/openvpn/client<br />
# $EDITOR /etc/openvpn/client/client.{up.,down}<br />
# # etc ...<br />
<br />
=== The update-resolv-conf custom script ===<br />
<br />
{{Note|Another script, [[#The update-systemd-resolved custom script|update-systemd-resolved]], is recommended by the author of update-resolv-conf for systems with systemd.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== The update-systemd-resolved custom script ===<br />
<br />
{{Note|Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}.}}<br />
<br />
The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn/scripts}} and mark as [[executable]] (or [[install]] {{AUR|openvpn-update-systemd-resolved}}) and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
In order to send all DNS traffic through the VPN tunnel and prevent DNS leaks, also add the following line (see [https://github.com/jonathanio/update-systemd-resolved#dns-leakage]):<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
dhcp-option DOMAIN-ROUTE .<br />
}}<br />
<br />
Make sure that the [[systemd-resolved]] service is configured and running.<br />
<br />
===Override DNS servers using NetworkManager===<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}. This may result in DNS instability (leakage).<br />
<br />
The NetworkManager GUI does not provide any way to change this behavior, but it is possible to [https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1211110/comments/92 completely override] DNS using connection configuration file.<br />
<br />
If the override is applied, queries for non-public DNS records are sent to the external resolver, see [https://bugs.launchpad.net/network-manager/+bug/1624317].<br />
<br />
To use DNS settings provided by the VPN connection add {{ic|1=dns-priority=-1}} ([https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html ipv4 section]) to the file located at {{ic|/etc/NetworkManager/system-connections/''your_vpn_name''}}, where {{ic|''your_vpn_name''}} is the name of your VPN connection.<br />
<br />
Making changes to the VPN connection with the NetworkManager GUI will remove the setting above.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== L2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines. {{ic|foo.ovpn}} will not automatically route all traffic through the VPN, so you may want to follow [[#Routing client traffic through the server]] to enable redirection.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a custom script, perhaps for configuring [[#DNS]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network Communication with Stunnel, OpenSSH, and OpenVPN] (PDF)</div>K4rolBhttps://wiki.archlinux.org/index.php?title=ProtonVPN&diff=575729ProtonVPN2019-06-16T08:30:42Z<p>K4rolB: /* Graphical interface */ link fix, I guess</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[de:ProtonVPN]]<br />
[[es:ProtonVPN]]<br />
[[ja:ProtonVPN]]<br />
[[ru:ProtonVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN}}<br />
{{Related articles end}}<br />
<br />
[https://www.protonvpn.com ProtonVPN] is a VPN provider that utilizes the OpenVPN protocol.<br />
<br />
Every solution requires a ProtonVPN account and the {{pkg|openvpn}} package.<br />
<br />
== OpenVPN command-line interface ==<br />
<br />
VPN connection can be run manually with interface provided by the {{pkg|openvpn}} package.<br />
<br />
=== Setup ===<br />
<br />
Download one or more OpenVPN configuration files from [https://account.protonvpn.com/downloads ProtonVPN Downloads page].<br />
<br />
Copy the *.ovpn client configuration files into {{ic|/etc/openvpn/client/}} and make backup of original.<br />
<br />
Follow [[OpenVPN#Update_systemd-resolved_script|these steps]] to make sure, that all your network traffic uses VPN. If you use systemd older than 229, follow [[OpenVPN#Update resolv-conf script|these steps]].<br />
<br />
=== Usage ===<br />
<br />
Connect to the VPN:<br />
<br />
# openvpn /etc/openvpn/client/client_config_file.ovpn<br />
<br />
Provide '''OpenVPN / IKEv2 Username''' from the [https://account.protonvpn.com/settings ProtonVPN Account page].<br />
<br />
Press {{ic|Ctrl+C}} to close the VPN connection. <br />
<br />
=== Tips and tricks ===<br />
<br />
==== Saving OpenVPN authentication ====<br />
<br />
OpenVPN credentials can be saved in a separate file and read automatically:<br />
<br />
{{hc|/etc/openvpn/client/client_config_file.ovpn|<br />
auth-user-pass /etc/openvpn/client/login.conf<br />
}}<br />
<br />
{{hc|/etc/openvpn/client/login.conf|<br />
openvpn_username<br />
openvpn_password<br />
}}<br />
<br />
==== Enable VPN on boot ====<br />
<br />
For systemd service configuration, see [[OpenVPN#systemd service configuration]].<br />
<br />
== protonvpn-cli ==<br />
<br />
ProtonVPN supplies a utility to access the VPN. Details can be found on the [https://protonvpn.com/support/linux-vpn-tool/ official website] and the [https://github.com/ProtonVPN/protonvpn-cli GitHub repository].<br />
<br />
=== Setup ===<br />
<br />
[[Install]] the {{AUR|protonvpn-cli}} package.<br />
<br />
Initialize the client:<br />
<br />
# protonvpn-cli -init<br />
<br />
Enter your '''ProtonVPN Login''' username and password, which have to be configured on the [https://account.protonvpn.com/settings ProtonVPN Settings] page. For example:<br />
<br />
{{bc|<br />
Enter OpenVPN username: ProtonVPN.user<br />
Enter OpenVPN password:<br />
}}<br />
<br />
After entering the credentials, you have to select your subscription plan. For example, select the Free plan:<br />
<br />
{{bc|<br />
[.]ProtonVPN Plans:<br />
1) Free<br />
2) Basic<br />
3) Plus<br />
4) Visionary<br />
Enter Your ProtonVPN plan ID: 1<br />
}}<br />
<br />
=== Usage ===<br />
<br />
Connect to the VPN:<br />
<br />
# protonvpn-cli -connect<br />
<br />
You should see detailed country list with all available servers. Select preferred server and click OK.<br />
<br />
Then select UDP or TCP protocol and click OK again.<br />
<br />
If connection was successful, you will see following output:<br />
<br />
{{bc|<br />
Connecting...<br />
Connected!<br />
New IP: X.X.X.X<br />
}}<br />
<br />
== Graphical interface ==<br />
<br />
Graphical interface for setting up OpenVPN connection may be provided by your [[desktop environment]]. Search in connection settings. Otherwise, [[NetworkManager#Installation]], [[NetworkManager#VPN_support]] and [[NetworkManager#Front-ends]] provide useful information.<br />
<br />
{{Note|You still need to follow [[#Setup]].}}<br />
<br />
<!-- This section requires further development --></div>K4rolBhttps://wiki.archlinux.org/index.php?title=ProtonVPN&diff=575728ProtonVPN2019-06-16T08:23:13Z<p>K4rolB: Changed article structure to indicate that these are alternative solutions; added links to ProtonVPN site where it provides config files and credentials; added stub solution with gui</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[de:ProtonVPN]]<br />
[[es:ProtonVPN]]<br />
[[ja:ProtonVPN]]<br />
[[ru:ProtonVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN}}<br />
{{Related articles end}}<br />
<br />
[https://www.protonvpn.com ProtonVPN] is a VPN provider that utilizes the OpenVPN protocol.<br />
<br />
Every solution requires a ProtonVPN account and the {{pkg|openvpn}} package.<br />
<br />
== OpenVPN command-line interface ==<br />
<br />
VPN connection can be run manually with interface provided by the {{pkg|openvpn}} package.<br />
<br />
=== Setup ===<br />
<br />
Download one or more OpenVPN configuration files from [https://account.protonvpn.com/downloads ProtonVPN Downloads page].<br />
<br />
Copy the *.ovpn client configuration files into {{ic|/etc/openvpn/client/}} and make backup of original.<br />
<br />
Follow [[OpenVPN#Update_systemd-resolved_script|these steps]] to make sure, that all your network traffic uses VPN. If you use systemd older than 229, follow [[OpenVPN#Update resolv-conf script|these steps]].<br />
<br />
=== Usage ===<br />
<br />
Connect to the VPN:<br />
<br />
# openvpn /etc/openvpn/client/client_config_file.ovpn<br />
<br />
Provide '''OpenVPN / IKEv2 Username''' from the [https://account.protonvpn.com/settings ProtonVPN Account page].<br />
<br />
Press {{ic|Ctrl+C}} to close the VPN connection. <br />
<br />
=== Tips and tricks ===<br />
<br />
==== Saving OpenVPN authentication ====<br />
<br />
OpenVPN credentials can be saved in a separate file and read automatically:<br />
<br />
{{hc|/etc/openvpn/client/client_config_file.ovpn|<br />
auth-user-pass /etc/openvpn/client/login.conf<br />
}}<br />
<br />
{{hc|/etc/openvpn/client/login.conf|<br />
openvpn_username<br />
openvpn_password<br />
}}<br />
<br />
==== Enable VPN on boot ====<br />
<br />
For systemd service configuration, see [[OpenVPN#systemd service configuration]].<br />
<br />
== protonvpn-cli ==<br />
<br />
ProtonVPN supplies a utility to access the VPN. Details can be found on the [https://protonvpn.com/support/linux-vpn-tool/ official website] and the [https://github.com/ProtonVPN/protonvpn-cli GitHub repository].<br />
<br />
=== Setup ===<br />
<br />
[[Install]] the {{AUR|protonvpn-cli}} package.<br />
<br />
Initialize the client:<br />
<br />
# protonvpn-cli -init<br />
<br />
Enter your '''ProtonVPN Login''' username and password, which have to be configured on the [https://account.protonvpn.com/settings ProtonVPN Settings] page. For example:<br />
<br />
{{bc|<br />
Enter OpenVPN username: ProtonVPN.user<br />
Enter OpenVPN password:<br />
}}<br />
<br />
After entering the credentials, you have to select your subscription plan. For example, select the Free plan:<br />
<br />
{{bc|<br />
[.]ProtonVPN Plans:<br />
1) Free<br />
2) Basic<br />
3) Plus<br />
4) Visionary<br />
Enter Your ProtonVPN plan ID: 1<br />
}}<br />
<br />
=== Usage ===<br />
<br />
Connect to the VPN:<br />
<br />
# protonvpn-cli -connect<br />
<br />
You should see detailed country list with all available servers. Select preferred server and click OK.<br />
<br />
Then select UDP or TCP protocol and click OK again.<br />
<br />
If connection was successful, you will see following output:<br />
<br />
{{bc|<br />
Connecting...<br />
Connected!<br />
New IP: X.X.X.X<br />
}}<br />
<br />
== Graphical interface ==<br />
<br />
Graphical interface for setting up OpenVPN connection may be provided by your [[desktop environment]]. Search in connection settings. Otherwise, [[NetworkManager#Installation]], [[NetworkManager#VPN_support]] and [[NetworkManager#Front-ends]] provide useful information.<br />
<br />
{{Note|You still need to follow [[#OpenVPN_command-line_interface#Setup]].}}<br />
<br />
<!-- This section requires further development --></div>K4rolBhttps://wiki.archlinux.org/index.php?title=ProtonVPN&diff=575233ProtonVPN2019-06-12T09:29:16Z<p>K4rolB: /* Walkthrough */ Simplified steps in walkthrough. Removed resolv-conf script tutorial and linked to OpenVPN article with up to date steps.</p>
<hr />
<div>[[Category:VPN providers]]<br />
[[de:ProtonVPN]]<br />
[[es:ProtonVPN]]<br />
[[ja:ProtonVPN]]<br />
{{Related articles start}}<br />
{{Related|openvpn}}<br />
{{Related articles end}}<br />
[https://www.protonvpn.com ProtonVPN] is a VPN provider that utilizes the OpenVPN protocol.<br />
<br />
In order to use this tutorial, one must have a protonvpn account.<br />
<br />
== Walkthrough ==<br />
<br />
[[Install]] {{pkg|openvpn}}.<br />
<br />
Log into ProtonVPN and download one or more OpenVPN configuration files.<br />
<br />
Copy the *.ovpn client configuration files into {{ic|/etc/openvpn/client/}} and make backup of original.<br />
<br />
Follow [[OpenVPN#Update_systemd-resolved_script|these steps]] to make sure, that all your network traffic uses VPN. If you use systemd older than 229, follow [[OpenVPN#Update resolv-conf script|these steps]].<br />
<br />
Start your VPN:<br />
<br />
# openvpn /etc/openvpn/client/client_config_file.ovpn<br />
<br />
Press {{ic|Ctrl+C}} to close the VPN connection. <br />
<br />
=== Saving OpenVPN Authentication ===<br />
<br />
If you get tired of punching in your username and password, you may save your OpenVPN credentials in a separate file and read them automatically.<br />
<br />
{{hc|/etc/openvpn/client/client_config_file.ovpn|<br />
auth-user-pass /etc/openvpn/client/login.conf<br />
}}<br />
<br />
{{hc|/etc/openvpn/client/login.conf|<br />
openvpn_username<br />
openvpn_password<br />
}}<br />
<br />
=== Enable VPN on Boot ===<br />
<br />
For systemd service configuration, see [[OpenVPN#systemd service configuration]].<br />
<br />
== Use ProtonVPN-cli ==<br />
<br />
ProtonVPN supplies a utility to access the VPN. Details can be found on [https://protonvpn.com/support/linux-vpn-tool/ their website] and the GitHub repository can be found [https://github.com/ProtonVPN/protonvpn-cli here]. This package can be installed directly from [https://aur.archlinux.org/packages/protonvpn-cli/ AUR].</div>K4rolBhttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=575231OpenVPN2019-06-12T09:11:17Z<p>K4rolB: /* Update systemd-resolved script */ Made the paragraph more comprehensible</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[ru:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic L3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic L3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
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:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPNās community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client/client.conf}} on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''<configuration>''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''<configuration>''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|<configuration>}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
By default only traffic directly to and from an OpenVPN server passes through the VPN. To have all traffic (including web traffic) pass through the VPN, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option.<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
iptables -A INPUT -i tun+ -j ACCEPT<br />
iptables -A FORWARD -i tun+ -j ACCEPT<br />
iptables -A INPUT -i tap+ -j ACCEPT<br />
iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface.<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#Update resolv-conf script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== L3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using L3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
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.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
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/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* 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.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
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.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, 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):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
<br />
{{Merge|Openresolv|Some parts of this should be in the openresolv article.}}<br />
<br />
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 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 {{ic|resolv.conf}} without stepping on each-other's toes.<br />
<br />
Before continuing, test openresolv by restarting the network connection and ensuring that {{ic|resolv.conf}} states that it was generated by ''resolvconf'', and that DNS resolution still works as before. No reconfiguration of openresolv should be required; it should be automatically detected and used by the network system.<br />
<br />
For Linux, OpenVPN can send DNS host information, but expects an external process to act on it. This can be done with the {{ic|client.up}} and {{ic|client.down}} scripts packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. See their comments on how to install them to {{ic|/etc/openvpn/client/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with ''resolvconf'' and options to [[#Run as unprivileged user]]:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /etc/openvpn/client/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/etc/openvpn/client/client.down tun0"<br />
}}<br />
<br />
=== Update resolv-conf script ===<br />
<br />
{{Note|Using [[#Update systemd-resolved script|update-systemd-resolved script]] is recommended by update-resolv-conf author.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== Update systemd-resolved script ===<br />
<br />
{{Note|Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}.}}<br />
<br />
The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn/scripts}} and mark as [[executable]] (or [[install]] {{AUR|openvpn-update-systemd-resolved}}) and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
Make sure that systemd service is running. It may happen that it is not:<br />
<br />
systemctl enable systemd-resolved.service<br />
systemctl start systemd-resolved.service<br />
<br />
===Override DNS servers using NetworkManager===<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}. This may result in DNS instability (leakage).<br />
<br />
The NetworkManager GUI does not provide any way to change this behavior, but it is possible to [https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1211110/comments/92 completely override] DNS using connection configuration file.<br />
<br />
If the override is applied, queries for non-public DNS records are sent to the external resolver, see [https://bugs.launchpad.net/network-manager/+bug/1624317].<br />
<br />
To use DNS settings provided by the VPN connection add {{ic|1=dns-priority=-1}} ([https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html ipv4 section]) to the file located at {{ic|/etc/NetworkManager/system-connections/''your_vpn_name''}}, where {{ic|''your_vpn_name''}} is the name of your VPN connection.<br />
<br />
Making changes to the VPN connection with the NetworkManager GUI will remove the setting above.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== L2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a script such as the [[#Update resolv-conf script]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network] Communication with one of Stunnel, OpenSSH, OpenVPN</div>K4rolBhttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=575230OpenVPN2019-06-12T08:55:37Z<p>K4rolB: /* Update systemd-resolved script */ check if service is actually running. It happens that it doesn't</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[ru:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic L3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic L3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
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:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPNās community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client/client.conf}} on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''<configuration>''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''<configuration>''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|<configuration>}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
By default only traffic directly to and from an OpenVPN server passes through the VPN. To have all traffic (including web traffic) pass through the VPN, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option.<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
iptables -A INPUT -i tun+ -j ACCEPT<br />
iptables -A FORWARD -i tun+ -j ACCEPT<br />
iptables -A INPUT -i tap+ -j ACCEPT<br />
iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface.<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#Update resolv-conf script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== L3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using L3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
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.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
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/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* 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.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
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.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, 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):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
<br />
{{Merge|Openresolv|Some parts of this should be in the openresolv article.}}<br />
<br />
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 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 {{ic|resolv.conf}} without stepping on each-other's toes.<br />
<br />
Before continuing, test openresolv by restarting the network connection and ensuring that {{ic|resolv.conf}} states that it was generated by ''resolvconf'', and that DNS resolution still works as before. No reconfiguration of openresolv should be required; it should be automatically detected and used by the network system.<br />
<br />
For Linux, OpenVPN can send DNS host information, but expects an external process to act on it. This can be done with the {{ic|client.up}} and {{ic|client.down}} scripts packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. See their comments on how to install them to {{ic|/etc/openvpn/client/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with ''resolvconf'' and options to [[#Run as unprivileged user]]:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /etc/openvpn/client/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/etc/openvpn/client/client.down tun0"<br />
}}<br />
<br />
=== Update resolv-conf script ===<br />
<br />
{{Note|Using [[#Update systemd-resolved script|update-systemd-resolved script]] is recommended by update-resolv-conf author.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== Update systemd-resolved script ===<br />
<br />
Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}. The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script is another alternative and links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn}} and mark as [[executable]], or [[install]] {{AUR|openvpn-update-systemd-resolved}}, and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
Make sure that systemd service is running. It may happen that it is not:<br />
<br />
systemctl enable systemd-resolved.service<br />
systemctl start systemd-resolved.service<br />
<br />
===Override DNS servers using NetworkManager===<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}. This may result in DNS instability (leakage).<br />
<br />
The NetworkManager GUI does not provide any way to change this behavior, but it is possible to [https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1211110/comments/92 completely override] DNS using connection configuration file.<br />
<br />
If the override is applied, queries for non-public DNS records are sent to the external resolver, see [https://bugs.launchpad.net/network-manager/+bug/1624317].<br />
<br />
To use DNS settings provided by the VPN connection add {{ic|1=dns-priority=-1}} ([https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html ipv4 section]) to the file located at {{ic|/etc/NetworkManager/system-connections/''your_vpn_name''}}, where {{ic|''your_vpn_name''}} is the name of your VPN connection.<br />
<br />
Making changes to the VPN connection with the NetworkManager GUI will remove the setting above.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== L2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a script such as the [[#Update resolv-conf script]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network] Communication with one of Stunnel, OpenSSH, OpenVPN</div>K4rolBhttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=575228OpenVPN2019-06-12T08:43:20Z<p>K4rolB: /* Update resolv-conf script */ Added information about AUR package, added note that systemd-resolved is preferred</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[ru:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic L3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic L3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
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:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI L3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPNās community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|# openvpn /etc/openvpn/server/server.conf}} on the server, and {{ic|# openvpn /etc/openvpn/client/client.conf}} on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''<configuration>''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''<configuration>''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|<configuration>}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
By default only traffic directly to and from an OpenVPN server passes through the VPN. To have all traffic (including web traffic) pass through the VPN, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option.<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
iptables -A INPUT -i tun+ -j ACCEPT<br />
iptables -A FORWARD -i tun+ -j ACCEPT<br />
iptables -A INPUT -i tap+ -j ACCEPT<br />
iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface.<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#Update resolv-conf script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== L3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using L3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
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.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
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/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* 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.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
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.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{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.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
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:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, 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):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
<br />
{{Merge|Openresolv|Some parts of this should be in the openresolv article.}}<br />
<br />
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 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 {{ic|resolv.conf}} without stepping on each-other's toes.<br />
<br />
Before continuing, test openresolv by restarting the network connection and ensuring that {{ic|resolv.conf}} states that it was generated by ''resolvconf'', and that DNS resolution still works as before. No reconfiguration of openresolv should be required; it should be automatically detected and used by the network system.<br />
<br />
For Linux, OpenVPN can send DNS host information, but expects an external process to act on it. This can be done with the {{ic|client.up}} and {{ic|client.down}} scripts packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. See their comments on how to install them to {{ic|/etc/openvpn/client/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with ''resolvconf'' and options to [[#Run as unprivileged user]]:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /etc/openvpn/client/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/etc/openvpn/client/client.down tun0"<br />
}}<br />
<br />
=== Update resolv-conf script ===<br />
<br />
{{Note|Using [[#Update systemd-resolved script|update-systemd-resolved script]] is recommended by update-resolv-conf author.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== Update systemd-resolved script ===<br />
<br />
Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}. The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script is another alternative and links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn}} and mark as [[executable]], or [[install]] {{AUR|openvpn-update-systemd-resolved}}, and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
===Override DNS servers using NetworkManager===<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}. This may result in DNS instability (leakage).<br />
<br />
The NetworkManager GUI does not provide any way to change this behavior, but it is possible to [https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1211110/comments/92 completely override] DNS using connection configuration file.<br />
<br />
If the override is applied, queries for non-public DNS records are sent to the external resolver, see [https://bugs.launchpad.net/network-manager/+bug/1624317].<br />
<br />
To use DNS settings provided by the VPN connection add {{ic|1=dns-priority=-1}} ([https://developer.gnome.org/NetworkManager/stable/settings-ipv4.html ipv4 section]) to the file located at {{ic|/etc/NetworkManager/system-connections/''your_vpn_name''}}, where {{ic|''your_vpn_name''}} is the name of your VPN connection.<br />
<br />
Making changes to the VPN connection with the NetworkManager GUI will remove the setting above.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== L2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on L2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a script such as the [[#Update resolv-conf script]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network] Communication with one of Stunnel, OpenSSH, OpenVPN</div>K4rolBhttps://wiki.archlinux.org/index.php?title=MATLAB&diff=573296MATLAB2019-05-15T15:07:00Z<p>K4rolB: /* Troubleshooting */ Clarified installation dependencies section, added sources for dependencies. Added solution for problem with not enough space in tmpfs</p>
<hr />
<div>[[Category:Numerical analysis]]<br />
[[ja:MATLAB]]<br />
[[zh-hans:MATLAB]]<br />
{{Related articles start}}<br />
{{Related|Octave}}<br />
{{Related|Sage-mathematics}}<br />
{{Related|Mathematica}}<br />
{{Related articles end}}<br />
{{Style|unnecessarily verbose}}<br />
From the [http://www.mathworks.com/products/matlab/ official website]:<br />
<br />
:''MATLAB is a high-level language and interactive environment for numerical computation, visualization, and programming. Using MATLAB, you can analyze data, develop algorithms, and create models and applications. The language, tools, and built-in math functions enable you to explore multiple approaches and reach a solution faster than with spreadsheets or traditional programming languages, such as C/C++ or Java.''<br />
<br />
== Overview ==<br />
<br />
MATLAB is proprietary software produced by The MathWorks and requires a license to obtain, install, and activate. New versions of MATLAB are released twice a year,<br />
release names are composed of {{ic|R}}, the year of the release and {{ic|a}} or {{ic|b}}.<br />
Since R2012b MATLAB has only been available for 64-bit Linux. Arch Linux is not officially supported.<br />
[http://www.mathworks.co.uk/support/sysreq/current_release/index.html]<br />
<br />
== Installation ==<br />
<br />
A complete copy of the MATLAB software must be obtained before it can be installed. The MATLAB software is available to licenses holders on both a DVD and through the [http://www.mathworks.com The MathWorks website]. In addition to the software a file installation key is required for installation. It is possible to install MATLAB either with the {{aur|matlab}} package from the [[AUR]] or from the MATLAB installation software directly. The advantage of the {{aur|matlab}} package is that it manages dependencies and some of the nuances of the installation process while installing directly from the MATLAB installation software can be done by regular users to their home directories and works for any release of MATLAB (the {{aur|matlab}} package only works for releases including and after R2010b).<br />
<br />
=== Installing from the MATLAB installation software ===<br />
<br />
The MATLAB installation software is self contained and does not require any additional packages to install in silent mode. To install with the GUI a working [[Xorg]] graphical display is necessary. [[Wayland]] is not currently supported yet. The installation is handled by the {{ic|install}} script. You can run the script as root to install MATLAB system-wide or your user to install it only for you.<br />
<br />
MATLAB 2016a and earlier is not compatible with {{Pkg|ncurses}} 6, so you must install the {{AUR|ncurses5-compat-libs}} package. See [[#Segmentation fault on startup]] for more info.<br />
<br />
During the installation, you are asked if you want symlinks to be created. If you did not choose to do so, you can now manually create a symlink in {{ic|/usr/local/bin}} to make it easier to launch in terminal:<br />
<br />
# ln -s /{MATLAB}/bin/matlab /usr/local/bin<br />
<br />
Or you could add MATLAB install path to {{ic|PATH}} environment variable.<br />
<br />
==== Desktop entry ====<br />
<br />
Optionally create a [[desktop entry]]. The MIME type of MATLAB files is {{ic|text/x-matlab}}.<br />
<br />
Start {{ic|matlab}} with:<br />
<br />
* {{ic|-desktop}} to run Matlab without a terminal.<br />
* {{ic|-nosplash}} to prevent the splash screen from showing up.<br />
<br />
In order for icons to appear correctly {{ic|StartupWMClass}} needs to be set in the desktop entry. To find it out start MATLAB, run {{ic|xprop {{!}} grep WM_CLASS}} and select the MATLAB window.<br />
<br />
Example desktop entry:<br />
<br />
{{hc|matlab.desktop|<br />
[Desktop Entry]<br />
<nowiki>Version=2018a<br />
Type=Application<br />
Terminal=false<br />
MimeType=text/x-matlab<br />
Exec=matlab -desktop -nosplash<br />
Name=MATLAB<br />
Icon=matlab<br />
Categories=Development;Math;Science<br />
Comment=Scientific computing environment<br />
StartupNotify=true<br />
</nowiki><br />
}}<br />
<br />
If one need to set environment variable, one could prepend {{ic|env}} in {{ic|Exec}}, for example, to system's libfreetype:<br />
{{bc|<br />
<nowiki>Exec=env LD_PRELOAD=/usr/lib/libfreetype.so.6 matlab<br />
</nowiki><br />
}}<br />
<br />
One might wanna use system's {{ic|libstdc++}}.<br />
<br />
=== Installing from the AUR package ===<br />
<br />
The EULA for the proprietary MATLAB software is restrictive. The {{aur|matlab}} package from the [[AUR]] is designed to allow MATLAB to be integrated into and managed by Arch. The package should be built on the system on which it is going to be installed and the package should be deleted from the installation location and the [[Pacman]] cache following installation. Distributing the package is a clear violation of the EULA.<br />
<br />
The {{aur|matlab}} package from the [[AUR]] defaults to building a package for the most recent 64-bit release of MATLAB, one could also install old releases, eg. {{aur|matlab-r2015b}}. The {{aur|matlab}} package from the [[AUR]] requires that both the MATLAB installation software and the file installation key are available in the source directory.<br />
<br />
In order to install Matlab from AUR, download the PKGBUILD file from AUR. Download the zip file containing the Matlab installer and name it <tt>matlab.zip</tt>. Then download the .lic file: Go in [https://mathworks.com/mwaccount/ your MathWorks account] and click on the license number you want to use. Then, go to the Install and Activate tab and select "Activate to Retrieve License File". Follow the instructions and download the license file needed for the installation and name the file <tt>matlab.lic</tt>. Also, the File Installation Key (FIK) is displayed: copy-paste it in a empty file and name it <tt>matlab.fik</tt>. For more details, refer to the PKGBUILD file.<br />
<br />
== Configuration ==<br />
<br />
=== Java ===<br />
<br />
The MATLAB software is bundled with a JVM and therefore it is not necessary to install [[Java]]. The JVM version supported by MATLAB is listed in [https://ww2.mathworks.cn/support/compilers.html System Requirements & Platform Availability] or simply type {{ic|version -java}} in MATLAB. One could set the {{ic|MATLAB_JAVA}} environment variable to use custom JVM, for example, to specify the {{pkg|jre8-openjdk}} JRE, launch MATLAB with:<br />
<br />
$ env MATLAB_JAVA=/usr/lib/jvm/java-8-openjdk/jre matlab<br />
<br />
=== OpenGL acceleration ===<br />
<br />
MATLAB can take advantage of hardware based 2D and 3D OpenGL acceleration. Support for hardware acceleration needs to be configured outside of MATLAB. Appropriate [[video drivers]] need to be installed along with the OpenGL utility library {{Pkg|glu}} package. If X11 forwarding is being used, the video drivers need to be installed on both the client and server. To check if MATLAB is making use of hardware based OpenGL acceleration run:<br />
<br />
$ matlab -nodesktop -nosplash -r "opengl info; exit" | grep Software<br />
<br />
If "software rendering" is not "false", then there is a problem with your hardware acceleration. If this is the case make sure OpenGL is configured correctly on the system. This can be done with the {{ic|glxinfo}} program from the {{Pkg|mesa-demos}} package:<br />
<br />
$ glxinfo | grep "direct rendering"<br />
<br />
If "direct rendering" is not "yes", then there is likely a problem with your system configuration.<br />
<br />
If glxinfo works but not matlab, you can try to run:<br />
$ export LD_PRELOAD=/usr/lib/libstdc++.so; export LD_LIBRARY_PATH=/usr/lib/xorg/modules/dri/; matlab -nodesktop -nosplash -r "opengl info; exit" | grep Software<br />
<br />
If its works, you can edit Matlab launcher script to add:<br />
<br />
export LD_PRELOAD=/usr/lib/libstdc++.so<br />
export LD_LIBRARY_PATH=/usr/lib/xorg/modules/dri/<br />
<br />
=== Sound ===<br />
<br />
To confirm that MATLAB is able to use the default soundcard to present sounds run:<br />
<br />
$ matlab -nodesktop -nosplash -r "load handel; sound(y, Fs); pause(length(y)/Fs); exit" > /dev/null<br />
<br />
This should play an except from Handel's "Hallelujah Chorus." If this fails make sure [[ALSA]] is properly configured. This can be done with the {{ic|speaker-test}} program from the {{Pkg|alsa-utils}} package from the [[official repositories]]:<br />
<br />
$ speaker-test<br />
<br />
If you do not hear anything, then there is likely a problem with your system configuration.<br />
<br />
=== GPU computing ===<br />
<br />
MATLAB can take advantage of [http://www.mathworks.co.uk/discovery/matlab-gpu.html CUDA enabled GPUs] to speed up applications. In order to take advantage of a supported GPU install the {{Pkg|nvidia}}, {{Pkg|nvidia-utils}}, {{Pkg|ocl-icd}}, {{Pkg|opencl-nvidia}}, and {{Pkg|cuda}} packages from the [[official repositories]]. To check if MATLAB is able to utilize the GPU run:<br />
<br />
$ matlab -nodesktop -nosplash -r "x=rand(10, 'single'); g=gpuArray(x); Success=isequal(gather(g), x), exit" | sed -ne '/Success =/,$p'<br />
<br />
=== Install supported compilers ===<br />
<br />
In order to access the full functionality of MATLAB (e.g., to use Simulink, Builder JA, and MEX-file compilation), supported versions of the {{ic|gcc}}, {{ic|g++}}, {{ic|gfortran}}, and {{ic|jdk}} compilers must be installed. Details about the supported compilers for the [https://www.mathworks.com/support/compilers.html current release] and [https://www.mathworks.com/support/sysreq/previous_releases.html previous releases] are available online. Many of the supported {{ic|gcc}}, {{ic|g++}}, {{ic|jdk}} compiler versions for past MATLAB releases are available from the [[AUR]] (e.g., {{AUR|gcc43}}, {{AUR|gcc44}}, {{AUR|gcc47}}, {{AUR|gcc49}}and {{AUR|jdk6}}), while past versions of the {{ic|gfortran}} compilers are not packaged.<br />
<br />
To use previous versions of the the {{ic|gcc}}, {{ic|g++}}, and {{ic|gfortran}} compilers with MEX files, edit {{ic|${MATLAB}/bin/mexopts.sh}} and replace all occurrences of {{ic|<nowiki>CC='gcc'</nowiki>}} with {{ic|<nowiki>CC='gcc-4.X'</nowiki>}}, {{ic|<nowiki>CXX='g++'</nowiki>}} with {{ic|<nowiki>CXX='g++-4.X'</nowiki>}}, and {{ic|<nowiki>FC='gfortran'</nowiki>}} with {{ic|<nowiki>FC='gfortran-4.X'</nowiki>}}, where {{ic|X}} is the compiler version appropriate for the particular MATLAB release.<br />
<br />
{{Note|Newer versions of Matlab (at least 2017a) doesn't seem to respect the {{ic|${MATLAB}/bin/mexopts.sh}} customization. Instead it uses {{ic|${MATLAB}/bin/glnxa64/mexopts/LANG_glnxa64.xml}} file.}}<br />
<br />
{{Note|Though, it's no officially supported, one could still use higher version of compiler, and ignore the warnings.}}<br />
<br />
=== Help browser ===<br />
<br />
The help browser uses valuable slots in the dynamic thread vector and causes competition with core functionality provided by libraries like the BLAS that also depend on the dynamic thread vector. The help browser can be configured to use fewer slots in the dynamic thread vector with<br />
<br />
>> webutils.htmlrenderer('basic');<br />
<br />
This is a persistent change and to reverse it use<br />
<br />
>> webutils.htmlrenderer('default');<br />
<br />
=== Garbled Interface ===<br />
<br />
export J2D_D3D=false<br />
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk/jre<br />
<br />
=== Serial port access ===<br />
<br />
Matlab uses a bundled rxtx library to access serial ports. The built-in version requires the user to have write access directly to /var/run which is no good idea. The easiest way to fix this properly is to install the {{Pkg|java-rxtx}} package first. Follow the instructions shown while installing this package to get your user into the right groups. Then run the following commands to make Matlab use the system rxtx version:<br />
<br />
cd {MATLAB}/java/jarext<br />
mv RXTXcomm.jar RXTXcomm.jar.off<br />
ln -s /usr/share/java/rxtx/RXTXcomm.jar .<br />
<br />
cd {MATLAB}/bin/glnx64<br />
mv librxtxSerial.so librxtxSerial.so.off<br />
ln -s /usr/lib/librxtxSerial.so .<br />
<br />
== Troubleshooting ==<br />
<br />
=== Static TLS errors ===<br />
<br />
MATLAB has a number of libraries that have been compiled with static thread local storage (TLS) including the help browser {{ic|doc}} and the BLAS libraries. For example,<br />
<br />
>> doc('help');<br />
>> ones(10)*randn(10);<br />
Error using * <br />
BLAS loading error:<br />
dlopen: cannot load any more object with static TLS<br />
<br />
is related to the bugs:<br />
<br />
* [http://www.mathworks.de/support/bugreports/961964 961964] for which patched libraries are available from [http://www.mathworks.de/support/bugreports/license/accept_license/5730?fname=attachment_961964_12b_13a_13b_14a_glnxa64_2014-01-30.zip&geck_id=961964 MathWorks]<br />
* [http://www.mathworks.com/support/bugreports/1003952 1003952] for which workarounds exist<br />
<br />
A more general solution of recompiling {{ic|glibc}} has also been suggested. [http://stackoverflow.com/a/19468365/2787723]<br />
<br />
=== MATLAB crashes when displaying graphics ===<br />
<br />
To identify this error, start MATLAB with<br />
<br />
LIBGL_DEBUG=verbose matlab<br />
<br />
from the terminal and try to collect OpenGL information with {{ic|opengl info}} from the MATLAB command prompt. If it crashes again and there is an output line like <br />
<br />
libGL error: dlopen /usr/lib/xorg/modules/dri/swrast_dri.so failed <br />
(/usr/local/MATLAB/R2011b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: <br />
version `GLIBCXX_3.4.15' not found (required by /usr/lib/xorg/modules/dri/swrast_dri.so))<br />
<br />
then the problem is that MATLAB uses its own GNU C++ library, which is an older version than the up-to-date version on your Archlinux system. Make MATLAB use the current C++ library for your system by<br />
<br />
cd /usr/local/MATLAB/R(your release)/sys/os/glnxa64<br />
sudo unlink libstdc++.so.6<br />
sudo ln -s /usr/lib/libstdc++.so.6<br />
<br />
If MATLAB still crashes or corrupts graphics (during startup or when plotting), make sure Java's 2D OpenGL rendering is disabled.<br />
The environment variable {{ic|_JAVA_OPTIONS}} should not contain {{ic|1=-Dsun.java2d.opengl=true}}.<br />
<br />
=== Blank/grey UI when using WM (non-reparenting window manager) ===<br />
<br />
This is a common issue in a number of window managers. (DWM, Awesome, bspwm) Java does not play well with these window managers. There are two methods.<br />
<br />
First try setting the environment variable by running<br />
<br />
$ export _JAVA_AWT_WM_NONREPARENTING=1<br />
<br />
If Matlab works afterwards, export the variable in your {{ic|.xinitrc}}.<br />
<br />
If it doesn't resolve, you have to fool Java into thinking the WM is named LG3D. (It's an old, depreciated WM that Java applications ironically support) Clean the previous environment variable, install the [http://tools.suckless.org/wmname wmname] utility, and run.<br />
<br />
wmname LG3D<br />
<br />
Try running Matlab. If it works, put the fix in your starting script. ({{ic|.xinitrc}}, {{ic|bspwmrc}} and similar should be OK) Do note that other applications (such as {{ic|neofetch}}, or {{ic|tdrop}}) will think your WM is named LG3D, so you will have to configure them accordingly. Another solution is to run the command only before launching Matlab, and fixing the name after you are done with Matlab.<br />
<br />
If it doesn't work, try the combination of both. (The second line works in bspwm) If it still doesn't work, try googling similar issues with java in general.<br />
<br />
=== Garbled or invisible text ===<br />
<br />
Set the environment variable <code>J2D_D3D</code> to <code>false</code>[https://stackoverflow.com/questions/22737535/swing-rendering-appears-broken-in-jdk-1-8-correct-in-jdk-1-7].<br />
<br />
In newer versions of MATLAB (R2015b) [https://www.reddit.com/r/archlinux/comments/3yaga8/matlab_installer_bonked/] this also requires setting <code>MATLAB_JAVA</code> to something openjdk based. Example:<br />
<br />
export J2D_D3D=false<br />
./bin/glnxa64/install_unix -javadir /usr/lib/jvm/java-7-openjdk/jre<br />
<br />
=== Corrupted text and fonts in menus and fields ===<br />
If you notice that the menus or the input fields are corrupted or not appearing correctly then you can try to activate the ''"'''Use antialiasing to smooth desktop fonts'''"'' option in Matlab preferences, it seems to solve the problem. Go to '''''Preferences -> Matlab -> Fonts''''' and activate it. You will need to restart Matlab in order to take affect.<br />
<br />
=== Installation dependencies missing ===<br />
Matlab might complain that it cannot find a package. Look at the package name and install it with [[Pacman]], or in the case of x86_64 there are some libraries only in [[AUR]]. {{AUR|matlab}} and {{AUR|matlab-dummy}} packages contain a list of up-to-date dependencies for the newest Matlab version.<br />
<br />
=== Installation error: archive is not a ZIP archive ===<br />
During the installation you can get:<br />
<br />
The following error was detected while installing ''package_name'': archive is not a ZIP archive <br />
Would you like to retry installing ''package_name''? If you press No, the installer will exit without completing the installation. More information can be found at /tmp/mathworks_root.log<br />
<br />
Matlab downloads all packages to {{ic|/tmp/}} directory which resides in RAM and is maximum size of half of available memory. In this case it is not enough for installation files and Matlab 2019a installer will warn you about this. If it did not, or if you ignored the warning, you will have got the above error.<br />
<br />
You can either [[Tmpfs#Examples|resize tmpfs]] (3,5 GB is not enough, 6 GB works), or remove packages from base install and add them later with built-in Matlab add-on installer.<br />
<br />
=== Install-time library errors ===<br />
* Make sure that the symlink {{ic|bin/glnx64/libstdc++.so.6}} is pointing to the correct version of {{ic|libstdc++.so.xx}} (which is also in the same directory and has numbers where 'xx' is). By default, it may be pointing to an older (and nonexistent) version (different value for 'xx').<br />
<br />
* Make sure the device you're installing from is not mounted as {{ic|noexec}}<br />
<br />
* If you downloaded the files from Mathworks' website, make sure they are not on an NTFS or FAT partition, because that can mess up the symlinks. Ext4 or Ext3 should work.<br />
<br />
=== Resolving start warnings/errors ===<br />
<br />
* Even if all needed libraries are installed, Matlab when starting can still report some missing libraries. This is resolved by symbolic linking of needed libraries to directories that Matlab checks at start-up. For example, if Matlab triggers error/warning about missing {{ic|/lib64/libc.so.6}} library, this can be resolved by:<br />
<br />
# ln -s /lib/libc.so.6 /lib64<br />
<br />
* Matlab R2011b with an up-to-date Arch Linux (as of March 12, 2012) fails on startup with the familiar "Failure loading desktop class." A solution is to point Matlab to the system JVM (confirmed to work with the {{Pkg|jdk7-openjdk}} package):<br />
<br />
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk/jre<br />
<br />
* Matlab R2017b with an up-to-date Arch Linux (as of September 30, 2017) fails on startup with the familiar "Failure loading desktop class." A solution is to install outdated versions of the libraries in the packages {{Pkg|cairo}} (1.14.10 works) and {{Pkg|harfbuzz}} (1.4.6 works) to a local directory and add them to the LD_LIBRARY_PATH for matlab (See also: [https://bbs.archlinux.org/viewtopic.php?id=228944]): <br />
<br />
LD_LIBRARY_PATH="/opt/matlab/outdatedLibraries/:$LD_LIBRARY_PATH" /opt/matlab/R2017b/bin/matlab<br />
<br />
=== Segmentation fault on startup ===<br />
<br />
If Matlab (R2016a or earlier) stops working after upgrading {{Pkg|ncurses}} to v6.x, [[install]] the {{AUR|ncurses5-compat-libs}} package. See [https://bbs.archlinux.org/viewtopic.php?id=202575 BBS#202575].<br />
<br />
In newer versions (e.g. R2017b), the issue could also be due to a font display failing to load.<br />
Try moving the libfreetype.so.6 font display file in $MATLAB/bin/glnxa64/ to an 'exclude' directory; see [https://bbs.archlinux.org/viewtopic.php?id=231299 BBS#231299].<br />
<br />
ncurses compatibility layer is not required anymore for R2018a.<br />
<br />
=== Hangs on rendering or exiting with Intel graphics ===<br />
<br />
Some users have reported issues with DRI3 enabled on Intel Graphics chips. A possible workaround is to disable DRI3 and run MATLAB with hardware rendering on DRI2; to do so, launch MATLAB with the environment variable LIBGL_DRI3_DISABLE set to 1:<br />
<br />
LIBGL_DRI3_DISABLE=1 /{MATLAB}/bin/matlab<br />
<br />
If the previous workaround does not work, the issue can be circumvented by selecting software rendering with the MATLAB command (beware, performance may be very poor when doing e.g. big or complex 3D plots):<br />
<br />
opengl('save','software')<br />
<br />
See [https://bugzilla.redhat.com/show_bug.cgi?id=1357571] and [https://bugs.freedesktop.org/show_bug.cgi?id=96671] for more.<br />
<br />
=== Addon manager not working ===<br />
This section is relevant for both R2017b and R2018a.<br />
<br />
Addon manager requires the {{AUR|libselinux}} package to work.<br />
<br />
Since upgrade from pango-1.40.5 to pango-1.40.6, the MATLABWindow application (responsible for Add-On Manager, Simulation Data Inspector and perhaps something else) cannot be started. [https://bugs.archlinux.org/task/54257]<br />
A workaround is to point MATLAB shipping glib libraries to those glib libraries from your system. There are 5 of those libraries in {{ic|matlabroot/R2017b/cefclient/sys/os/glnxa64}}, namely, as of R2017b:<br />
<br />
libgio-2.0.so<br />
libglib-2.0.so<br />
libgmodule-2.0.so<br />
libgobject-2.0.so<br />
libgthread-2.0.so<br />
<br />
Make it so that these symlinks are pointing to your system glib libraries instead of versions located in {{ic|matlabroot/R2017b/cefclient/sys/os/glnxa64}}.<br />
On a standard arch install the local files reside in {{ic|/usr/lib/}}.<br />
<br />
Do not forget to update the {{ic|*.0}} links as well.<br />
<br />
Relinking of "libfreetype.so.6" is also necessary to open these interfaces. This is found in {{ic|matlabroot/R2017b/bin/glnxa64/}}.<br />
<br />
If the window opens but is blank, consider switching the html renderer to: " webutils.htmlrenderer('basic');" as described in [[#Help browser]].<br />
<br />
=== Live Script Errors ===<br />
If you get the error when attempting to load or create a LiveScript:<br />
{{ic|Viewing matlab live script files is not currently supported by this operating system configuration}}<br />
*It could be because of broken symlinks of {{Pkg|libgcrypt}} and other dependencies, after system updates. On the first start of the Live Editor the components are extracted and these libary symlinks are created (if not existing).<br />
<br />
A solution is to simply delete the whole folder containing the broken symlinks and the extracted components, which are in the installation directory (represented by {{ic|$MATLABROOT}}) under:<br />
$MATLABROOT/sys/jxbrowser-chromium<br />
Or if the installation directory is not user writable in:<br />
~/.matlab/R2017b/HtmlPanel<br />
Matlab will then regenerate the contents on the next Live Editor start.<br />
<br />
A better option is to replace libgcrypt symlink in this extraction directory with a less precise one. For example, after extraction, this link to /lib64/libgcrypt.so.20.2.4 is created. Replace it with e.g. /lib64/libgcrypt.so.20.<br />
*Also the steps in [[#Addon manager not working]] may resolve the issue.<br />
*It can also happen due to missing gconf package. Make sure {{Pkg|gconf}} is installed.<br />
*If the above does not help, execute in the command window<br />
>> com.mathworks.mde.liveeditor.widget.rtc.CachedLightweightBrowserFactory.createLightweightBrowser()<br />
to get a more detailed error message.<br />
* A debugging console can be opened with<br />
>> com.mathworks.mde.webbrowser.HtmlPanelDebugConsole.invoke;<br />
<br />
=== Using webcam/video device ===<br />
Make sure the correct support package addons are installed (webcam or OS Generic Video Interface for example). If running matlab as a user, make sure your user has write permissions to wherever the support packages are being downloaded and installed.<br />
<br />
At least Matlab 2016b doesn't recognize webcams or imaq adapters correctly without gstreamer0.10. The gstreamer0.10 can be found in the aur and installed as a work around.<br />
<br />
Since MATLAB R2017a, Image Acqusition Toolbox is using GStreamer library version 1.0. It previously used version 0.10.<br />
<br />
In general, USB Webcam Support Package does a better job working with UVC and built-in cameras than OS Generic Video Interface Support Package.<br />
<br />
'''Warning:''' As of 2018-08-15 updating gst from 1.14.0 to 1.14.2 breaks video device operation (MATLAB doesn't see the video device anymore). Downgrading fixes this.<br />
<br />
=== MATLAB hangs for several minutes when closing Help Browser ===<br />
Since upgrade of glibc from 2.24 to 2.25, MATLAB (at least R2017a) hangs when closing Help Browser. The issue is related to the particular version of jxbrowser-chromium shipped with MATLAB.<br />
This issue is still present with glibc 2.26 and MATLAB R2017b and R2018a.<br />
<br />
To fix this issue, download the [https://www.teamdev.com/jxbrowser latest jxbrowser] and replace the following jars from MATLAB:<br />
<br />
matlabroot/java/jarext/jxbrowser-chromium/jxbrowser-chromium.jar<br />
matlabroot/java/jarext/jxbrowser-chromium/jxbrowser-linux64.jar<br />
<br />
MATLAB should automatically unpack those jars into {{ic|matlabroot/sys/jxbrowser-chromium/glnxa64/chromium}} when first opening Help Browser.<br />
Remove {{ic|matlabroot/sys/jxbrowser-chromium/glnxa64/chromium}} directory to make sure MATLAB uses the latest jxbrowser.<br />
<br />
Unfortunately, this workaround doesn't work in R2017b anymore. Going deeper into investigation of this issue, it is related to a crash of one of jxbrowser-chromium processes. The parent process of jxbrowser-chromium then sits there and waits for response from a process that is already dead. This causes MATLAB main window to freeze. You can easily unfreeze MATLAB by manually killing all leftover jxbrowser-chromium processes.<br />
<br />
I've come up with this simple script that uses inotify and waits for user to close Help browser in MATLAB. It triggers when user closes Help browser and sends kill signal to all leftover jxbrowser-chromium processes:<br />
<br />
#!/usr/bin/bash<br />
<br />
if [ -z "$1" ]; then<br />
REL=R2017b<br />
else<br />
REL=$1<br />
fi<br />
<br />
JXPATH="/path/to/MATLAB/$REL/sys/jxbrowser-chromium/glnxa64/chromium"<br />
CMD="inotifywait -m -e CLOSE $JXPATH/resources.pak"<br />
<br />
#Exit if the daemon is already active<br />
if ! pgrep -f "$CMD" > /dev/null; then<br />
#Wait for user to close Help Browser, then killall leftover jxbrowser processes<br />
$CMD |<br />
while read line<br />
do<br />
killall "$JXPATH/jxbrowser-chromium"<br />
done<br />
else<br />
exit<br />
fi<br />
<br />
I run this script as part of my MATLAB start script like that:<br />
~/bin/unfreeze_matlab.sh R2017b &<br />
<br />
To make sure that this background job is killed when I exit MATLAB, I use this in the beginning of MATLAB start script:<br />
trap "trap - SIGTERM && kill -- -$$" SIGINT SIGTERM EXIT<br />
<br />
=== Some dropdown menus cannot be selected ===<br />
In some interfaces - such as Simulation Data Inspector or Simulink Test Manager - nothing happens when choosing an item in dropdown menu (for example, when trying to change a number of subplots in Simulation Data Inspector). To work around this issue, hold down the Shift key while clicking the item in dropdown menu.<br />
<br />
=== Not starting - licensing error===<br />
In case MATLAB will not start from a [[desktop environment]] by the call of its [[desktop file]] one should see the output as you start it from the terminal.<br />
<br />
For a ''Licensing error'' such as:<br />
<br />
{{hc<br />
|# matlab|<br />
MATLAB is selecting SOFTWARE OPENGL rendering.<br />
License checkout failed.<br />
License Manager Error -9<br />
This error may occur when: <br />
-The hostid of this computer does not match the hostid in the license file. <br />
-A Designated Computer installation is in use by another user. <br />
If no other user is currently running MATLAB, you may need to activate.<br />
<br />
Troubleshoot this issue by visiting: <br />
http://www.mathworks.com/support/lme/R2017a/9<br />
<br />
Diagnostic Information:<br />
Feature: MATLAB <br />
License path: /home/<USER>/.matlab/R2017a_licenses/license_<NUM>_R2017a.lic:/home/<USER>/.matlab/R2017a_licenses/lice<br />
nse_Darkness_<NUM>_R2017a.lic:/opt/MATLAB/R2017a/licenses/license.dat:/opt/MATLAB/R2017a/licenses/*<br />
.lic <br />
Licensing error: -9,57.<br />
}}<br />
<br />
A re-activation might solve the problem.<br />
<br />
=== MATLAB crashes with "Failure loading desktop class" on startup ===<br />
In case MATLAB won't start and starting it from command line gives you the following error:<br />
{{hc<br />
|$ matlab|<br />
Fatal Internal Error: Internal Error: Failure occurs during desktop startup. Details: Failure loading desktop class.<br />
}}<br />
and you have the option [[Java#GTK_LookAndFeel|{{ic|1=-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel}}]] set in your {{ic|_JAVA_OPTIONS}} environment variable, start MATLAB with<br />
<br />
$ _JAVA_OPTIONS= matlab<br />
<br />
If this works, add the line<br />
<br />
export _JAVA_OPTIONS=<br />
<br />
to your MATLAB launcher script. Optionally re-add other Java options.<br />
<br />
=== Unable to type in text fields of interfaces based on MATLABWindow ===<br />
Since R2018a, it is not possible to type text in interfaces based on MATLABWindow - like Signal Editor, Add-Ons Explorer and others.<br />
MATLABWindow and MATLAB's webwindow infrastructure is based on Chromium Embedded Framework, and it looks like a known and long standing bug: https://bitbucket.org/chromiumembedded/cef/issues/2026/multiple-major-keyboard-focus-issues-on<br />
<br />
One possible workaround is to switch focus from the MATLABWindow to another window and then switch back - so that you can type.<br />
<br />
To elaborate more on this workaround (since the problem is still there in R2018b), here is what i did in my Openbox config (note that the A-Middle keybinding already exist in default config):<br />
<br />
<mousebind button="A-Middle" action="Press"><br />
<action name="Unfocus"/><br />
<action name="Focus"/><br />
</mousebind><br />
<br />
Now, whenever it is not possible to type in a text field, I press Alt+Mouse middle mouse and then I can type again.<br />
<br />
== Matlab in a systemd-nspawn ==<br />
Matlab can be run within a systemd-nspawn container to maintain a static system and avoid the library issues that often plague matlab installs after significant updates to libraries in Arch. Refer to [[Systemd-nspawn]] for detailed information on setting up such containers.<br />
<br />
The following lists instruction to get a MATLAB 2017b install running in a minimal debian 9 environment. It assumes matlab is already installed as normal in "/usr/local/MATLAB/R2017b". <br />
<br />
Use [[Xhost]] to allow the nspawn environment to use the existing X server instance, see also [[Systemd-nspawn#Use an X environment]].<br />
<br />
Create a minimal debian environment in a folder ("deb9" here) with:<br />
<br />
$ debootstrap --arch=amd64 stretch deb9<br />
<br />
Set a password for the root user and then boot the environment with:<br />
<br />
$ systemd-nspawn --bind-ro=/dev/dri --bind=/tmp/.X11-unix --bind=/usr/local/MATLAB/ -b -D deb9<br />
<br />
Install the following packages to have the requisite libraries in the nspawn environment for MATLAB. "mesa-utils" and "usbutils" can be installed to debug graphics acceleration and usb interfaces for I/O with MATLAB.<br />
<br />
$ apt-get install xorg build-essential libgtk2.0-0 libnss3 libasound2 <br />
<br />
Install the MATLAB-support (from contrib source) package in the environment for some convenient integration. <br />
<br />
$ apt-get install matlab-support<br />
<br />
Set the $DISPLAY variable to use your existing X server instance.<br />
<br />
$ export DISPLAY=:0<br />
<br />
MATLAB can be launched from within the environment normally by using the binary at $MATLABROOT/bin.</div>K4rolB