vyos/vyos-documentation
1
0
Fork 0
mirror of https://github.com/vyos/vyos-documentation.git synced 2025-10-26 08:41:46 +01:00
Code Issues Packages Projects Releases Wiki Activity

proofread openvpn interface

Browse Source
This commit is contained in:
whyrlpool 2024-07-04 14:11:49 +01:00 committed by GitHub
parent d9401f959e
commit aa526355b2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 41 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
docs/configuration/interfaces/openvpn.rst
View File

@ -1,4 +1,4 @@
:lastproofread: 2021-07-05
:lastproofread: 2024-07-04
.. _openvpn:
@ -9,8 +9,8 @@ OpenVPN
Traditionally hardware routers implement IPsec exclusively due to relative
ease of implementing it in hardware and insufficient CPU power for doing
encryption in software. Since VyOS is a software router, this is less of a
concern. OpenVPN has been widely used on UNIX platform for a long time and is
a popular option for remote access VPN, though it's also capable of
concern. OpenVPN has been widely used on the UNIX platform for a long time and
is a popular option for remote access VPN, though it's also capable of
site-to-site connections.
Advantages of OpenVPN are:
@ -45,14 +45,15 @@ remains a relatively obscure feature, and many router appliances
still don't support it. However, it's very useful for quickly setting up
tunnels between routers.
As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or x.509 certificates.
As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or
x.509 certificates.
The pre-shared key mode is deprecated and will be removed from future OpenVPN versions,
so VyOS will have to remove support for that option as well. The reason is that using pre-shared keys
is significantly less secure than using TLS.
The pre-shared key mode is deprecated and will be removed from future OpenVPN
versions, so VyOS will have to remove support for that option as well. The
reason is that using pre-shared keys is significantly less secure than using TLS.
We'll configure OpenVPN using self-signed certificates, and then discuss the legacy
pre-shared key mode.
We'll configure OpenVPN using self-signed certificates, and then discuss the
legacy pre-shared key mode.
In both cases, we will use the following settings:
@ -168,10 +169,11 @@ Remote Configuration:
Pre-shared keys
===============
Until VyOS 1.4, the only option for site-to-site OpenVPN without PKI was to use pre-shared keys.
That option is still available but it is deprecated and will be removed in the future.
However, if you need to set up a tunnel to an older VyOS version or a system with older OpenVPN,
you need to still need to know how to use it.
Until VyOS 1.4, the only option for site-to-site OpenVPN without PKI was to use
pre-shared keys. That option is still available but it is deprecated and will
be removed in the future. However, if you need to set up a tunnel to an older
VyOS version or a system with older OpenVPN, you need to still need to know how
to use it.
First, you need to generate a key by running ``run generate pki openvpn shared-secret install <name>`` from configuration mode.
You can use any name, we will use ``s2s``.
@ -311,11 +313,11 @@ not come up.
Firewall policy can also be applied to the tunnel interface for `local`, `in`,
and `out` directions and functions identically to ethernet interfaces.
If making use of multiple tunnels, OpenVPN must have a way to distinguish
between different tunnels aside from the pre-shared-key. This is either by
referencing IP address or port number. One option is to dedicate a public IP
to each tunnel. Another option is to dedicate a port number to each tunnel
(e.g. 1195,1196,1197...).
If you're making use of multiple tunnels, OpenVPN must have a way to
distinguish between different tunnels aside from the pre-shared-key. This is
done either by referencing IP addresses or port numbers. One option is to
dedicate a public IP to each tunnel. Another option is to dedicate a port
number to each tunnel (e.g. 1195,1196,1197...).
OpenVPN status can be verified using the `show openvpn` operational commands.
See the built-in help for a complete list of options.
@ -327,7 +329,7 @@ Server
Multi-client server is the most popular OpenVPN mode on routers. It always uses
x.509 authentication and therefore requires a PKI setup. Refer this topic
:ref:`configuration/pki/index:pki` to generate a CA certificate,
a server certificate and key, a certificate revocation list, a Diffie-Hellman
a server certificate and key, a certificate revocation list, and a Diffie-Hellman
key exchange parameters file. You do not need client certificates and keys for
the server setup.
@ -340,14 +342,14 @@ all client subnets belong to 10.23.0.0/20. All clients need access to the
192.168.0.0/16 network.
First we need to specify the basic settings. 1194/UDP is the default. The
``persistent-tunnel`` option is recommended, it prevents the TUN/TAP device from
closing on connection resets or daemon reloads.
``persistent-tunnel`` option is recommended, as it prevents the TUN/TAP device
from closing on connection resets or daemon reloads.
.. note:: Using **openvpn-option -reneg-sec** can be tricky. This option is
used to renegotiate data channel after n seconds. When used at both server
and client, the lower value will trigger the renegotiation. If you set it to
0 on one side of the connection (to disable it), the chosen value on the
other side will determine when the renegotiation will occur.
used to renegotiate data channel after n seconds. When used on both the
server and client, the lower value will trigger the renegotiation. If you
set it to 0 on one side of the connection (to disable it), the chosen value
on the other side will determine when the renegotiation will occur.
.. code-block:: none
@ -357,7 +359,7 @@ closing on connection resets or daemon reloads.
set interfaces openvpn vtun10 protocol udp
Then we need to generate, add and specify the names of the cryptographic materials.
Each of the install command should be applied to the configuration and commited
Each of the install commands should be applied to the configuration and commited
before using under the openvpn interface configuration.
.. code-block:: none
@ -392,7 +394,7 @@ installing that route on clients.
set interfaces openvpn vtun10 server push-route 192.168.0.0/16
set interfaces openvpn vtun10 server subnet 10.23.1.0/24
Since it's a HQ and branch offices setup, we will want all clients to have
Since it's a HQ with branch offices setup, we will want all clients to have
fixed addresses and we will route traffic to specific subnets through them. We
need configuration for each client to achieve this.
@ -413,9 +415,9 @@ internally, so we need to create a route to the 10.23.0.0/20 network ourselves:
set protocols static route 10.23.0.0/20 interface vtun10
Additionally, each client needs a copy of ca cert and its own client key and
cert files. The files are plaintext so they may be copied either manually from the CLI.
Client key and cert files should be signed with the proper ca cert and generated on the
server side.
cert files. The files are plaintext so they may be copied manually from the CLI.
Client key and cert files should be signed with the proper ca cert and generated
on the server side.
HQ's router requires the following steps to generate crypto materials for the Branch 1:
@ -570,12 +572,12 @@ example:
Client
******
VyOS can not only act as an OpenVPN site-to-site or server for multiple clients.
You can indeed also configure any VyOS OpenVPN interface as an OpenVPN client
connecting to a VyOS OpenVPN server or any other OpenVPN server.
VyOS can not only act as an OpenVPN site-to-site or server for multiple clients
but you can also configure any VyOS OpenVPN interface as an OpenVPN client that
connects to a VyOS OpenVPN server or any other OpenVPN server.
Given the following example we have one VyOS router acting as OpenVPN server
and another VyOS router acting as OpenVPN client. The server also pushes a
Given the following example we have one VyOS router acting as an OpenVPN server
and another VyOS router acting as an OpenVPN client. The server also pushes a
static client IP address to the OpenVPN client. Remember, clients are identified
using their CN attribute in the SSL certificate.
@ -754,7 +756,7 @@ between kernel and user space for encryption and packet handling.
As a result, the processing of each packet becomes more efficient, potentially
leveraging hardware encryption offloading support available in the kernel.
.. note:: OpenVPN DCO is not full OpenVPN features supported , is currently
.. note:: OpenVPN DCO is not a fully supported OpenVPN feature, and is currently
considered experimental. Furthermore, there are certain OpenVPN features and
use cases that remain incompatible with DCO. To get a comprehensive
understanding of the limitations associated with DCO, refer to the list of
@ -770,9 +772,9 @@ DCO support is a per-tunnel option and it is not automatically enabled by
default for new or upgraded tunnels. Existing tunnels will continue to function
as they have in the past.
DCO can be enabled for both new and existing tunnels,VyOS adds an option in each
tunnel configuration where we can enable this function .The current best
practice is to create a new tunnel with DCO to minimize the chance of problems
DCO can be enabled for both new and existing tunnels. VyOS adds an option in
each tunnel configuration where we can enable this function. The current best
practice is to create a new tunnel with DCO to minimize the chance of problems
with existing clients.
.. cfgcmd:: set interfaces openvpn <name> offload dco