summaryrefslogtreecommitdiff
path: root/docs/configuration/interfaces
diff options
context:
space:
mode:
Diffstat (limited to 'docs/configuration/interfaces')
-rw-r--r--docs/configuration/interfaces/bonding.rst20
-rw-r--r--docs/configuration/interfaces/bridge.rst12
-rw-r--r--docs/configuration/interfaces/dummy.rst4
-rw-r--r--docs/configuration/interfaces/ethernet.rst3
-rw-r--r--docs/configuration/interfaces/geneve.rst2
-rw-r--r--docs/configuration/interfaces/index.rst2
-rw-r--r--docs/configuration/interfaces/l2tpv3.rst16
-rw-r--r--docs/configuration/interfaces/loopback.rst4
-rw-r--r--docs/configuration/interfaces/macsec.rst6
-rw-r--r--docs/configuration/interfaces/openvpn.rst22
-rw-r--r--docs/configuration/interfaces/pppoe.rst14
-rw-r--r--docs/configuration/interfaces/pseudo-ethernet.rst4
-rw-r--r--docs/configuration/interfaces/tunnel.rst20
-rw-r--r--docs/configuration/interfaces/vxlan.rst30
-rw-r--r--docs/configuration/interfaces/wireguard.rst162
15 files changed, 216 insertions, 105 deletions
diff --git a/docs/configuration/interfaces/bonding.rst b/docs/configuration/interfaces/bonding.rst
index d19ecb59..13203d15 100644
--- a/docs/configuration/interfaces/bonding.rst
+++ b/docs/configuration/interfaces/bonding.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _bond-interface:
#######################
@@ -47,7 +49,7 @@ Bond options
the :cfgcmd:`hash-policy` option, documented below.
.. note:: Not all transmit policies may be 802.3ad compliant, particularly
- in regards to the packet mis-ordering requirements of section 43.2.4
+ in regards to the packet misordering requirements of section 43.2.4
of the 802.3ad standard.
* ``active-backup`` - Active-backup policy: Only one slave in the bond is
@@ -133,9 +135,9 @@ Bond options
This option only affects 802.3ad mode.
- The default value is 0. This will cause carrier to be asserted (for 802.3ad
- mode) whenever there is an active aggregator, regardless of the number of
- available links in that aggregator.
+ The default value is 0. This will cause the carrier to be asserted
+ (for 802.3ad mode) whenever there is an active aggregator,
+ regardless of the number of available links in that aggregator.
.. note:: Because an aggregator cannot be active without at least one
available link, setting this option to 0 or to 1 has the exact same
@@ -222,7 +224,7 @@ Bond options
This algorithm is not fully 802.3ad compliant. A single TCP or UDP
conversation containing both fragmented and unfragmented packets will see
packets striped across two interfaces. This may result in out of order
- delivery. Most traffic types will not meet this criteria, as TCP rarely
+ delivery. Most traffic types will not meet these criteria, as TCP rarely
fragments traffic, and most UDP traffic is not involved in extended
conversations. Other implementations of 802.3ad may or may not tolerate
this noncompliance.
@@ -267,7 +269,7 @@ Bond options
be given for ARP monitoring to function.
The maximum number of targets that can be specified is 16. The default value
- is no IP addresses.
+ is no IP address.
Offloading
----------
@@ -498,9 +500,9 @@ Lets assume the following topology:
!
.. note:: When using EVE-NG to lab this environment ensure you are using e1000
- as the desired driver for your VyOS network interfaces. When using the regular
- virtio network driver no LACP PDUs will be sent by VyOS thus the port-channel
- will never become active!
+ as the desired driver for your VyOS network interfaces. When using the
+ regular virtio network driver no LACP PDUs will be sent by VyOS thus the
+ port-channel will never become active!
*********
Operation
diff --git a/docs/configuration/interfaces/bridge.rst b/docs/configuration/interfaces/bridge.rst
index 7f49f9a8..2374da4d 100644
--- a/docs/configuration/interfaces/bridge.rst
+++ b/docs/configuration/interfaces/bridge.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _bridge-interface:
######
@@ -48,7 +50,7 @@ Member Interfaces
and a cost, that is used to decide which is the shortest path to
forward a packet. The lowest cost path is always used unless the
other path is down. If you have multiple bridges and interfaces then
- you may need to adjust the priorities to achieve optimium
+ you may need to adjust the priorities to achieve optimum
performance.
@@ -71,7 +73,7 @@ Bridge Options
Bridge maximum aging `<time>` in seconds (default: 20).
- If a another bridge in the spanning tree does not send out a hello
+ If an another bridge in the spanning tree does not send out a hello
packet for a long period of time, it is assumed to be dead.
.. cfgcmd:: set interfaces bridge <interface> igmp querier
@@ -98,8 +100,8 @@ links providing fault tolerance if an active link fails.
Spanning Tree Protocol forwarding `<delay>` in seconds (default: 15).
- Forwarding delay time is the time spent in each of the Listening and
- Learning states before the Forwarding state is entered. This delay is
+ The forwarding delay time is the time spent in each of the listening and
+ learning states before the Forwarding state is entered. This delay is
so that when a new bridge comes onto a busy network it looks at some
traffic before participating.
@@ -183,7 +185,7 @@ Examples
Create a basic bridge
=====================
-Creating a bridge interface is very simple. In this example we will
+Creating a bridge interface is very simple. In this example, we will
have:
* A bridge named `br100`
diff --git a/docs/configuration/interfaces/dummy.rst b/docs/configuration/interfaces/dummy.rst
index f5b72e0c..8440feca 100644
--- a/docs/configuration/interfaces/dummy.rst
+++ b/docs/configuration/interfaces/dummy.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _dummy-interface:
#####
@@ -50,7 +52,7 @@ Operation
.. opcmd:: show interfaces dummy
- Show brief interface information.information
+ Show brief interface information.
.. code-block:: none
diff --git a/docs/configuration/interfaces/ethernet.rst b/docs/configuration/interfaces/ethernet.rst
index 1d99019c..dcc9e529 100644
--- a/docs/configuration/interfaces/ethernet.rst
+++ b/docs/configuration/interfaces/ethernet.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _ethernet-interface:
########
@@ -312,4 +314,3 @@ Operation
XDP_PASS 0 pkts ( 0 pps) 0 Kbytes ( 0 Mbits/s) period:2.000414
XDP_TX 0 pkts ( 0 pps) 0 Kbytes ( 0 Mbits/s) period:2.000414
XDP_REDIRECT 0 pkts ( 0 pps) 0 Kbytes ( 0 Mbits/s) period:2.000414
-
diff --git a/docs/configuration/interfaces/geneve.rst b/docs/configuration/interfaces/geneve.rst
index 9e00d621..b13e2ece 100644
--- a/docs/configuration/interfaces/geneve.rst
+++ b/docs/configuration/interfaces/geneve.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _geneve-interface:
######
diff --git a/docs/configuration/interfaces/index.rst b/docs/configuration/interfaces/index.rst
index 3c75f482..23792203 100644
--- a/docs/configuration/interfaces/index.rst
+++ b/docs/configuration/interfaces/index.rst
@@ -16,12 +16,12 @@ Interfaces
loopback
macsec
openvpn
+ wireguard
pppoe
pseudo-ethernet
tunnel
vti
vxlan
- wireguard
wireless
wwan
diff --git a/docs/configuration/interfaces/l2tpv3.rst b/docs/configuration/interfaces/l2tpv3.rst
index 8fe905a1..ca0ce2c9 100644
--- a/docs/configuration/interfaces/l2tpv3.rst
+++ b/docs/configuration/interfaces/l2tpv3.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. include:: /_include/need_improvement.txt
.. _l2tpv3-interface:
@@ -9,7 +11,7 @@ L2TPv3
Layer 2 Tunnelling Protocol Version 3 is an IETF standard related to L2TP that
can be used as an alternative protocol to :ref:`mpls` for encapsulation of
multiprotocol Layer 2 communications traffic over IP networks. Like L2TP,
-L2TPv3 provides a pseudo-wire service, but scaled to fit carrier requirements.
+L2TPv3 provides a pseudo-wire service but is scaled to fit carrier requirements.
L2TPv3 can be regarded as being to MPLS what IP is to ATM: a simplified version
of the same concept, with much of the same benefit achieved at a fraction of the
@@ -49,13 +51,13 @@ L2TPv3 options
Set the IP address of the local interface to be used for the tunnel.
- This address must be the address of a local interface. May be specified as an
- IPv4 address or an IPv6 address.
+ This address must be the address of a local interface. It may be specified as
+ an IPv4 address or an IPv6 address.
.. cfgcmd:: set interfaces l2tpv3 <interface> remote <address>
- Set the IP address of the remote peer. May be specified as an IPv4 address or
- an IPv6 address.
+ Set the IP address of the remote peer. It may be specified as
+ an IPv4 address or an IPv6 address.
.. cfgcmd:: set interfaces l2tpv3 <interface> session-id <id>
@@ -65,7 +67,7 @@ L2TPv3 options
.. cfgcmd:: set interfaces l2tpv3 <interface> peer-session-id <id>
- Set the peer session id, which is a 32-bit integer value assigned to the
+ Set the peer-session-id, which is a 32-bit integer value assigned to the
session by the peer. The value used must match the session_id value being
used at the peer.
@@ -100,7 +102,7 @@ Over IP
tunnel-id 200
}
-Inverse configuration has to be applied to the remote side.
+The inverse configuration has to be applied to the remote side.
Over UDP
========
diff --git a/docs/configuration/interfaces/loopback.rst b/docs/configuration/interfaces/loopback.rst
index 4d0c8fb6..ec2976b6 100644
--- a/docs/configuration/interfaces/loopback.rst
+++ b/docs/configuration/interfaces/loopback.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-06-30
+
.. _loopback-interface:
########
@@ -53,7 +55,7 @@ Operation
.. opcmd:: show interfaces loopback lo
- Show detailed information on given loopback interface `lo`.
+ Show detailed information on the given loopback interface `lo`.
.. code-block:: none
diff --git a/docs/configuration/interfaces/macsec.rst b/docs/configuration/interfaces/macsec.rst
index 9a20c425..544bd4fc 100644
--- a/docs/configuration/interfaces/macsec.rst
+++ b/docs/configuration/interfaces/macsec.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-05
+
.. _macsec-interface:
######
@@ -40,7 +42,7 @@ MACsec options
.. cfgcmd:: set interfaces macsec <interface> source-interface <physical-source>
A physical interface is required to connect this MACsec instance to. Traffic
- leaving this interfac will now be authenticated/encrypted.
+ leaving this interface will now be authenticated/encrypted.
Key Management
--------------
@@ -50,7 +52,7 @@ individual peers.
.. cfgcmd:: set interfaces macsec <interface> security mka cak <key>
- IEEE 802.1X/MACsec pre-shared key mode. This allows to configure MACsec with
+ IEEE 802.1X/MACsec pre-shared key mode. This allows configuring MACsec with
a pre-shared key using a (CAK,CKN) pair.
.. cfgcmd:: set interfaces macsec <interface> security mka ckn <key>
diff --git a/docs/configuration/interfaces/openvpn.rst b/docs/configuration/interfaces/openvpn.rst
index a30a0b81..877b5d60 100644
--- a/docs/configuration/interfaces/openvpn.rst
+++ b/docs/configuration/interfaces/openvpn.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-05
+
.. _openvpn:
#######
@@ -95,7 +97,7 @@ Remote Configuration:
set interfaces openvpn vtun1 remote-address '10.255.1.1'
The configurations above will default to using 256-bit AES in GCM mode
-for encryption (if both sides supports NCP) and SHA-1 for HMAC authentication.
+for encryption (if both sides support NCP) and SHA-1 for HMAC authentication.
SHA-1 is considered weak, but other hashing algorithms are available, as are
encryption algorithms:
@@ -120,7 +122,7 @@ OpenVPN version < 2.4.0.
aes256gcm AES algorithm with 256-bit key GCM
This sets the accepted ciphers to use when version => 2.4.0 and NCP is
-enabled (which is default). Default NCP cipher for versions >= 2.4.0 is
+enabled (which is the default). Default NCP cipher for versions >= 2.4.0 is
aes256gcm. The first cipher in this list is what server pushes to clients.
.. code-block:: none
@@ -168,7 +170,7 @@ Remote Configuration:
set protocols static route 10.0.0.0/16 interface vtun1
Firewall policy can also be applied to the tunnel interface for `local`, `in`,
-and `out` directions and function identically to ethernet interfaces.
+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
@@ -358,7 +360,7 @@ updates
set interfaces openvpn vtun0 openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"
-The required config file may look like:
+The required config file may look like this:
.. code-block:: none
@@ -472,12 +474,12 @@ example:
Client
======
-VyOS can not only act as an OpenVPN site-to-site or Server for multiple clients.
+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.
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
+and another VyOS router acting as 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.
@@ -529,7 +531,7 @@ Client
Options
=======
-We do not have CLI nodes for every single OpenVPN options. If an option is
+We do not have CLI nodes for every single OpenVPN option. If an option is
missing, a feature request should be opened at Phabricator_ so all users can
benefit from it (see :ref:`issues_features`).
@@ -547,7 +549,7 @@ if you pass invalid options/syntax.
Will add ``push "keepalive 1 10"`` to the generated OpenVPN config file.
-.. note:: Sometimes option lines in the generated OpenVPN configurarion require
+.. note:: Sometimes option lines in the generated OpenVPN configuration require
quotes. This is done through a hack on our config generator. You can pass
quotes using the ``&quot;`` statement.
@@ -583,11 +585,11 @@ The following commands let you reset OpenVPN.
.. opcmd:: reset openvpn client <text>
- Use this command to reset specified OpenVPN client.
+ Use this command to reset the specified OpenVPN client.
.. opcmd:: reset openvpn interface <interface>
- Uset this command to reset the OpenVPN process on a specific interface.
+ Use this command to reset the OpenVPN process on a specific interface.
diff --git a/docs/configuration/interfaces/pppoe.rst b/docs/configuration/interfaces/pppoe.rst
index 64aca858..41f22ed6 100644
--- a/docs/configuration/interfaces/pppoe.rst
+++ b/docs/configuration/interfaces/pppoe.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-09
+
.. _pppoe-interface:
#####
@@ -19,7 +21,7 @@ Operating Modes
***************
VyOS supports setting up PPPoE in two different ways to a PPPoE internet
-connection. This is due to most ISPs provide a modem that is also a wireless
+connection. This is because most ISPs provide a modem that is also a wireless
router.
Home Users
@@ -45,7 +47,7 @@ your DSL Modem/Router switch into a Bridged Mode so it only acts as a DSL
Transceiver device to connect between the Ethernet link of your VyOS and the
phone cable. Once your DSL Transceiver is in Bridge Mode, you should get no
IP address from it. Please make sure you connect to the Ethernet Port 1 if
-your DSL Transeiver has a switch, as some of them only work this way.
+your DSL Transceiver has a switch, as some of them only work this way.
Once you have an Ethernet device connected, i.e. `eth0`, then you can
configure it to open the PPPoE session for you and your DSL Transceiver
@@ -101,7 +103,7 @@ PPPoE options
When set the interface is enabled for "dial-on-demand".
- Use this command to instruct the system to establish a PPPoE connections
+ Use this command to instruct the system to establish a PPPoE connection
automatically once traffic passes through the interface. A disabled on-demand
connection is established at boot time and remains up. If the link fails for
any reason, the link is brought back up immediately.
@@ -225,12 +227,12 @@ Connect/Disconnect
.. opcmd:: disconnect interface <interface>
Test disconnecting given connection-oriented interface. `<interface>` can be
- ``pppoe0`` as example.
+ ``pppoe0`` as the example.
.. opcmd:: connect interface <interface>
Test connecting given connection-oriented interface. `<interface>` can be
- ``pppoe0`` as example.
+ ``pppoe0`` as the example.
*******
Example
@@ -253,7 +255,7 @@ Requirements:
change the ``default-route`` option to ``force``. You could also install
a static route and set the ``default-route`` option to ``none``.
* With the ``name-server`` option set to ``none``, VyOS will ignore the
- nameservers your ISP sens you and thus you can fully rely on the ones you
+ nameservers your ISP sends you and thus you can fully rely on the ones you
have configured statically.
.. note:: Syntax has changed from VyOS 1.2 (crux) and it will be automatically
diff --git a/docs/configuration/interfaces/pseudo-ethernet.rst b/docs/configuration/interfaces/pseudo-ethernet.rst
index 06b7bd86..b2849772 100644
--- a/docs/configuration/interfaces/pseudo-ethernet.rst
+++ b/docs/configuration/interfaces/pseudo-ethernet.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-09
+
.. _pseudo-ethernet-interface:
#########################
@@ -36,7 +38,7 @@ Ethernet interfaces:
applies to:
- VMware machines using default settings
- Network switches with security settings allowing only a single MAC address
- - xDSL modems that try to lear the MAC address of the NIC
+ - xDSL modems that try to learn the MAC address of the NIC
*************
Configuration
diff --git a/docs/configuration/interfaces/tunnel.rst b/docs/configuration/interfaces/tunnel.rst
index 7f7cd709..6a5fb171 100644
--- a/docs/configuration/interfaces/tunnel.rst
+++ b/docs/configuration/interfaces/tunnel.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-09
+
.. _tunnel-interface:
Tunnel
@@ -99,8 +101,8 @@ A full example of a Tunnelbroker.net config can be found at
Generic Routing Encapsulation (GRE)
-----------------------------------
-A GRE tunnel operates at layer 3 of the OSI model and is repsented by IP
-protocol 47.The main benefit of a GRE tunnel is that you are able to carry
+A GRE tunnel operates at layer 3 of the OSI model and is represented by IP
+protocol 47. The main benefit of a GRE tunnel is that you are able to carry
multiple protocols inside the same tunnel. GRE also supports multicast traffic
and supports routing protocols that leverage multicast to form neighbor
adjacencies.
@@ -112,12 +114,12 @@ over either IPv4 (gre) or IPv6 (ip6gre).
Configuration
^^^^^^^^^^^^^
-A basic configuration requires a tunnel source (source-address), a tunnel destination
-(remote), an encapsulation type (gre), and an address (ipv4/ipv6).Below is a
-basic IPv4 only configuration example taken from a VyOS router and a Cisco IOS
-router. The main difference between these two configurations is that VyOS
-requires you explicitly configure the encapsulation type. The Cisco router
-defaults to gre ip otherwise it would have to be configured as well.
+A basic configuration requires a tunnel source (source-address), a tunnel
+destination (remote), an encapsulation type (gre), and an address (ipv4/ipv6).
+Below is a basic IPv4 only configuration example taken from a VyOS router and
+a Cisco IOS router. The main difference between these two configurations is
+that VyOS requires you explicitly configure the encapsulation type. The Cisco
+router defaults to GRE IP otherwise it would have to be configured as well.
**VyOS Router:**
@@ -224,7 +226,7 @@ GRE is a well defined standard that is common in most networks. While not
inherently difficult to configure there are a couple of things to keep in mind
to make sure the configuration performs as expected. A common cause for GRE
tunnels to fail to come up correctly include ACL or Firewall configurations
-that are discarding IP protocol 47 or blocking your source/desintation traffic.
+that are discarding IP protocol 47 or blocking your source/destination traffic.
**1. Confirm IP connectivity between tunnel source-address and remote:**
diff --git a/docs/configuration/interfaces/vxlan.rst b/docs/configuration/interfaces/vxlan.rst
index ca25d21e..9b2f42a1 100644
--- a/docs/configuration/interfaces/vxlan.rst
+++ b/docs/configuration/interfaces/vxlan.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2021-07-09
+
.. _vxlan-interface:
#####
@@ -12,8 +14,8 @@ encapsulate OSI layer 2 Ethernet frames within layer 4 UDP datagrams, using
endpoints, which terminate VXLAN tunnels and may be either virtual or physical
switch ports, are known as :abbr:`VTEPs (VXLAN tunnel endpoints)`.
-VXLAN is an evolution of efforts to standardize on an overlay encapsulation
-protocol. It increases scalability up to 16 million logical networks and
+VXLAN is an evolution of efforts to standardize an overlay encapsulation
+protocol. It increases the scalability up to 16 million logical networks and
allows for layer 2 adjacency across IP networks. Multicast or unicast with
head-end replication (HER) is used to flood broadcast, unknown unicast,
and multicast (BUM) traffic.
@@ -100,10 +102,10 @@ the same broadcast domain.
Let's assume PC4 on Leaf2 wants to ping PC5 on Leaf3. Instead of setting Leaf3
as our remote end manually, Leaf2 encapsulates the packet into a UDP-packet and
sends it to its designated multicast-address via Spine1. When Spine1 receives
-this packet it forwards it to all other Leafs who has joined the same
+this packet it forwards it to all other leaves who has joined the same
multicast-group, in this case Leaf3. When Leaf3 receives the packet it forwards
it, while at the same time learning that PC4 is reachable behind Leaf2, because
-the encapsulated packet had Leaf2's IP-address set as source IP.
+the encapsulated packet had Leaf2's IP address set as source IP.
PC5 receives the ping echo, responds with an echo reply that Leaf3 receives and
this time forwards to Leaf2's unicast address directly because it learned the
@@ -111,13 +113,13 @@ location of PC4 above. When Leaf2 receives the echo reply from PC5 it sees that
it came from Leaf3 and so remembers that PC5 is reachable via Leaf3.
Thanks to this discovery, any subsequent traffic between PC4 and PC5 will not
-be using the multicast-address between the Leafs as they both know behind which
+be using the multicast-address between the leaves as they both know behind which
Leaf the PCs are connected. This saves traffic as less multicast packets sent
-reduces the load on the network, which improves scalability when more Leafs are
+reduces the load on the network, which improves scalability when more leaves are
added.
-For optimal scalability Multicast shouldn't be used at all, but instead use BGP
-to signal all connected devices between leafs. Unfortunately, VyOS does not yet
+For optimal scalability, Multicast shouldn't be used at all, but instead use BGP
+to signal all connected devices between leaves. Unfortunately, VyOS does not yet
support this.
Example
@@ -164,9 +166,9 @@ Topology:
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
-Multicast-routing is required for the leafs to forward traffic between each
+Multicast-routing is required for the leaves to forward traffic between each
other in a more scalable way. This also requires PIM to be enabled towards the
-Leafs so that the Spine can learn what multicast groups each Leaf expect
+leaves so that the Spine can learn what multicast groups each Leaf expects
traffic from.
**Leaf2 configuration:**
@@ -228,7 +230,7 @@ descriptions are placed under the command boxes:
set interfaces bridge br241 address '172.16.241.1/24'
This commands creates a bridge that is used to bind traffic on eth1 vlan 241
-with the vxlan241-interface. The IP-address is not required. It may however be
+with the vxlan241-interface. The IP address is not required. It may however be
used as a default gateway for each Leaf which allows devices on the vlan to
reach other subnets. This requires that the subnets are redistributed by OSPF
so that the Spine will learn how to reach it. To do this you need to change the
@@ -247,8 +249,8 @@ interfaces of the same bridge.
set interfaces vxlan vxlan241 group '239.0.0.241'
-The multicast-group used by all Leafs for this vlan extension. Has to be the
-same on all Leafs that has this interface.
+The multicast-group used by all leaves for this vlan extension. Has to be the
+same on all leaves that has this interface.
.. code-block:: none
@@ -269,7 +271,7 @@ multicast-address.
set interfaces vxlan vxlan241 port 12345
The destination port used for creating a VXLAN interface in Linux defaults to
-its pre-standard value of 8472 to preserve backwards compatibility. A
+its pre-standard value of 8472 to preserve backward compatibility. A
configuration directive to support a user-specified destination port to override
that behavior is available using the above command.
diff --git a/docs/configuration/interfaces/wireguard.rst b/docs/configuration/interfaces/wireguard.rst
index ddfbe620..bb2418b1 100644
--- a/docs/configuration/interfaces/wireguard.rst
+++ b/docs/configuration/interfaces/wireguard.rst
@@ -1,7 +1,5 @@
.. _wireguard:
-.. include:: /_include/need_improvement.txt
-
#########
WireGuard
#########
@@ -10,10 +8,24 @@ WireGuard is an extremely simple yet fast and modern VPN that utilizes
state-of-the-art cryptography. See https://www.wireguard.com for more
information.
+****************
+Site to Site VPN
+****************
+
+This diagram corresponds with the example site to site configuration below.
+
+.. figure:: /_static/images/wireguard_site2site_diagram.jpg
+
*************
Configuration
*************
+
+
+********
+Keypairs
+********
+
WireGuard requires the generation of a keypair, which includes a private
key to decrypt incoming traffic, and a public key for peer(s) to encrypt
traffic.
@@ -55,8 +67,9 @@ own keypairs.
vyos@vyos:~$ generate wireguard named-keypairs KP02
+***********************
Interface configuration
-=======================
+***********************
The next step is to configure your local side as well as the policy
based trusted destination addresses. If you only initiate a connection,
@@ -71,18 +84,31 @@ you want to tunnel (allowed-ips) to configure a WireGuard tunnel. The
public key below is always the public key from your peer, not your local
one.
-**local side**
+**local side - commands**
.. code-block:: none
- set interfaces wireguard wg01 address '10.1.0.1/24'
+ set interfaces wireguard wg01 address '10.1.0.1/30'
set interfaces wireguard wg01 description 'VPN-to-wg02'
- set interfaces wireguard wg01 peer to-wg02 allowed-ips '10.2.0.0/24'
- set interfaces wireguard wg01 peer to-wg02 address '192.168.0.142'
- set interfaces wireguard wg01 peer to-wg02 port '12345'
+ set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.2.0/24'
+ set interfaces wireguard wg01 peer to-wg02 address '<Site1 Pub IP>'
+ set interfaces wireguard wg01 peer to-wg02 port '51820'
set interfaces wireguard wg01 peer to-wg02 pubkey 'XMrlPykaxhdAAiSjhtPlvi30NVkvLQliQuKP7AI7CyI='
- set interfaces wireguard wg01 port '12345'
- set protocols static route 10.2.0.0/24 interface wg01
+ set interfaces wireguard wg01 port '51820'
+ set protocols static route 192.168.2.0/24 interface wg01
+
+**local side - annotated commands**
+
+.. code-block:: none
+
+ set interfaces wireguard wg01 address '10.1.0.1/30' # Address of the wg01 tunnel interface.
+ set interfaces wireguard wg01 description 'VPN-to-wg02'
+ set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.2.0/24' # Subnets that are allowed to travel over the tunnel
+ set interfaces wireguard wg01 peer to-wg02 address '<Site2 Pub IP>' # Public IP of the peer
+ set interfaces wireguard wg01 peer to-wg02 port '58120' # Port of the Peer
+ set interfaces wireguard wg01 peer to-wg02 pubkey '<pubkey>' # Public Key of the Peer
+ set interfaces wireguard wg01 port '51820' # Port of own server
+ set protocols static route 192.168.2.0/24 interface wg01 # Static route to remote subnet
The last step is to define an interface route for 10.2.0.0/24 to get
through the WireGuard interface `wg01`. Multiple IPs or networks can be
@@ -90,7 +116,7 @@ defined and routed. The last check is allowed-ips which either prevents
or allows the traffic.
.. note:: You can not assign the same allowed-ips statement to multiple
- WireGuard peers. This a a design decission. For more information please
+ WireGuard peers. This a a design decision. For more information please
check the `WireGuard mailing list`_.
.. cfgcmd:: set interfaces wireguard <interface> private-key <name>
@@ -106,33 +132,70 @@ or allows the traffic.
public key, which needs to be shared with the peer.
-**remote side**
+**remote side - commands**
.. code-block:: none
- set interfaces wireguard wg01 address '10.2.0.1/24'
+ set interfaces wireguard wg01 address '10.1.0.2/30'
set interfaces wireguard wg01 description 'VPN-to-wg01'
- set interfaces wireguard wg01 peer to-wg02 allowed-ips '10.1.0.0/24'
- set interfaces wireguard wg01 peer to-wg02 address '192.168.0.124'
- set interfaces wireguard wg01 peer to-wg02 port '12345'
+ set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.1.0/24'
+ set interfaces wireguard wg01 peer to-wg02 address '<Site1 Pub IP>'
+ set interfaces wireguard wg01 peer to-wg02 port '51820'
set interfaces wireguard wg01 peer to-wg02 pubkey 'u41jO3OF73Gq1WARMMFG7tOfk7+r8o8AzPxJ1FZRhzk='
- set interfaces wireguard wg01 port '12345'
- set protocols static route 10.1.0.0/24 interface wg01
+ set interfaces wireguard wg01 port '51820'
+ set protocols static route 192.168.1.0/24 interface wg01
+
+**remote side - annotated commands**
+
+.. code-block:: none
+
+ set interfaces wireguard wg01 address '10.1.0.2/30' # Address of the wg01 tunnel interface.
+ set interfaces wireguard wg01 description 'VPN-to-wg01'
+ set interfaces wireguard wg01 peer to-wg02 allowed-ips '192.168.1.0/24' # Subnets that are allowed to travel over the tunnel
+ set interfaces wireguard wg01 peer to-wg02 address 'Site1 Pub IP' # Public IP address of the Peer
+ set interfaces wireguard wg01 peer to-wg02 port '51820' # Port of the Peer
+ set interfaces wireguard wg01 peer to-wg02 pubkey '<pubkey>' # Public key of the Peer
+ set interfaces wireguard wg01 port '51820' # Port of own server
+ set protocols static route 192.168.1.0/24 interface wg01 # Static route to remote subnet
+
+*******************
+Firewall Exceptions
+*******************
-Assure that your firewall rules allow the traffic, in which case you
-have a working VPN using WireGuard.
+For the WireGuard traffic to pass through the WAN interface, you must create a firewall exception.
.. code-block:: none
- wg01# ping 10.2.0.1
- PING 10.2.0.1 (10.2.0.1) 56(84) bytes of data.
- 64 bytes from 10.2.0.1: icmp_seq=1 ttl=64 time=1.16 ms
- 64 bytes from 10.2.0.1: icmp_seq=2 ttl=64 time=1.77 ms
+ set firewall name OUTSIDE_LOCAL rule 10 action accept
+ set firewall name OUTSIDE_LOCAL rule 10 description 'Allow established/related'
+ set firewall name OUTSIDE_LOCAL rule 10 state established enable
+ set firewall name OUTSIDE_LOCAL rule 10 state related enable
+ set firewall name OUTSIDE_LOCAL rule 20 action accept
+ set firewall name OUTSIDE_LOCAL rule 20 description WireGuard_IN
+ set firewall name OUTSIDE_LOCAL rule 20 destination port 51820
+ set firewall name OUTSIDE_LOCAL rule 20 log enable
+ set firewall name OUTSIDE_LOCAL rule 20 protocol udp
+ set firewall name OUTSIDE_LOCAL rule 20 source
- wg02# ping 10.1.0.1
- PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data.
- 64 bytes from 10.1.0.1: icmp_seq=1 ttl=64 time=4.40 ms
- 64 bytes from 10.1.0.1: icmp_seq=2 ttl=64 time=1.02 ms
+You should also ensure that the OUTISDE_LOCAL firewall group is applied to the WAN interface and a direction (local).
+
+.. code-block:: none
+
+ set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL'
+
+Assure that your firewall rules allow the traffic, in which case you have a working VPN using WireGuard.
+
+.. code-block:: none
+
+ wg01# ping 192.168.1.1
+ PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
+ 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.16 ms
+ 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.77 ms
+
+ wg02# ping 192.168.2.1
+ PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
+ 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=4.40 ms
+ 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.02 ms
An additional layer of symmetric-key crypto can be used on top of the
asymmetric crypto. This is optional.
@@ -151,8 +214,10 @@ its content. Make sure you distribute the key in a safe manner,
wg01# set interfaces wireguard wg01 peer to-wg02 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc='
wg02# set interfaces wireguard wg01 peer to-wg01 preshared-key 'rvVDOoc2IYEnV+k5p7TNAmHBMEGTHbPU8Qqg8c/sUqc='
-Road Warrior Example
---------------------
+
+***********************************
+Remote Access "RoadWarrior" Example
+***********************************
With WireGuard, a Road Warrior VPN config is similar to a site-to-site
VPN. It just lacks the ``address`` and ``port`` statements.
@@ -182,7 +247,7 @@ the peers. This allows the peers to interact with one another.
}
The following is the config for the iPhone peer above. It's important to
-note that the ``AllowedIPs`` setting directs all IPv4 and IPv6 traffic
+note that the ``AllowedIPs`` wildcard setting directs all IPv4 and IPv6 traffic
through the connection.
.. code-block:: none
@@ -198,9 +263,9 @@ through the connection.
Endpoint = 192.0.2.1:2224
PersistentKeepalive = 25
-
-This MacBook peer is doing split-tunneling, where only the subnets local
-to the server go over the connection.
+However, split-tunneling can be achieved by specifing the remote subnets.
+This ensures that only traffic destined for the remote site is sent over the tunnel.
+All other traffic is unaffected.
.. code-block:: none
@@ -222,6 +287,25 @@ Operational Commands
Status
======
+.. opcmd:: show interfaces wireguard wg0 summary
+
+ Show info about the Wireguard service.
+ Also shows the latest handshake.
+
+ .. code-block:: none
+
+ vyos@vyos:~$ show interfaces wireguard wg0 summary
+ interface: wg0
+ public key:
+ private key: (hidden)
+ listening port: 51820
+
+ peer: <peer pubkey>
+ endpoint: <peer public IP>
+ allowed ips: 10.69.69.2/32
+ latest handshake: 23 hours, 45 minutes, 26 seconds ago
+ transfer: 1.26 MiB received, 6.47 MiB sent
+
.. opcmd:: show interfaces wireguard
Get a list of all wireguard interfaces
@@ -252,8 +336,9 @@ Status
TX: bytes packets errors dropped carrier collisions
0 0 0 0 0 0
+***************
Encryption Keys
-===============
+***************
.. opcmd:: show wireguard keypair pubkey <name>
@@ -284,15 +369,16 @@ Encryption Keys
vyos@vyos:~$ delete wireguard keypair default
-Mobile "RoadWarrior" clients
-============================
+***********************************
+Remote Access "RoadWarrior" clients
+***********************************
Some users tend to connect their mobile devices using WireGuard to their VyOS
router. To ease deployment one can generate a "per mobile" configuration from
the VyOS CLI.
.. warning:: From a security perspective it is not recommended to let a third
- party create the private key for a secured connection. You should create the
+ party create and share the private key for a secured connection. You should create the
private portion on your own and only hand out the public key. Please keep this
in mind when using this convenience feature.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 03:24:30 +0000