diff options
| -rw-r--r-- | docs/contributing/build-vyos.rst | 4 | ||||
| -rw-r--r-- | docs/firewall.rst | 107 | ||||
| -rw-r--r-- | docs/interfaces/bridge.rst | 121 |
3 files changed, 136 insertions, 96 deletions
diff --git a/docs/contributing/build-vyos.rst b/docs/contributing/build-vyos.rst index 28d7b96d..5c7f5205 100644 --- a/docs/contributing/build-vyos.rst +++ b/docs/contributing/build-vyos.rst @@ -29,10 +29,10 @@ Installing Docker_ and prerequisites: $ apt-get update $ apt-get install -y docker-ce -To be able to use Docker_, the current non-root user should be added to the +To be able to use Docker_ without ``sudo``, the current non-root user can be added to the ``docker`` group by calling: ``usermod -aG docker yourusername`` -.. note:: It is recommended to use that non-root user for the remaining steps. +.. note:: Doing so grants privileges equivalent to the ``root`` user! It is recommended to remove the non-root user from the ``docker`` group after building the VyOS ISO. See also https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user .. note:: The build process needs to be built on a local file system, building on SMB or NFS shares will result in the container failing to build properly! diff --git a/docs/firewall.rst b/docs/firewall.rst index 9426b87d..12eae726 100644 --- a/docs/firewall.rst +++ b/docs/firewall.rst @@ -3,53 +3,63 @@ Firewall ======== -VyOS makes use of Linux `netfilter <https://netfilter.org/>`_ for packet filtering. - -The firewall supports the creation of groups for ports, addresses, and networks -(implemented using netfilter ipset) and the option of interface or zone based -firewall policy. - -**Important note on usage of terms:** The firewall makes use of the terms -`in`, `out`, and `local` for firewall policy. Users experienced with netfilter -often confuse `in` to be a reference to the `INPUT` chain, and `out` the -`OUTPUT` chain from netfilter. This is not the case. These instead indicate the -use of the `FORWARD` chain and either the input or output interface. The -`INPUT` chain, which is used for local traffic to the OS, is a reference to -as `local` with respect to its input interface. +VyOS makes use of Linux `netfilter <https://netfilter.org/>`_ for packet +filtering. + +The firewall supports the creation of groups for ports, addresses, and +networks (implemented using netfilter ipset) and the option of interface +or zone based firewall policy. + +.. note:: **Important note on usage of terms:** + The firewall makes use of the terms `in`, `out`, and `local` + for firewall policy. Users experienced with netfilter often confuse + `in` to be a reference to the `INPUT` chain, and `out` the `OUTPUT` + chain from netfilter. This is not the case. These instead indicate + the use of the `FORWARD` chain and either the input or output + interface. The `INPUT` chain, which is used for local traffic to the + OS, is a reference to as `local` with respect to its input interface. Zone-based Firewall Policy -------------------------- -As an alternative to applying policy to an interface directly, a zone-based -firewall can be created to simplify configuration when multiple interfaces -belong to the same security zone. Instead of applying to rulesets to interfaces -they are applied to source zone-destination zone pairs. +As an alternative to applying policy to an interface directly, a +zone-based firewall can be created to simplify configuration when +multiple interfaces belong to the same security zone. Instead of +applying to rulesets to interfaces they are applied to source +zone-destination zone pairs. -An example to zone-based firewalls can be found here: :ref:`examples-zone-policy`. +An introduction to zone-based firewalls can be found `here +<https://support.vyos.io/en/kb/articles/a-primer-to-zone-based-firewall>`_, +and an example at :ref:`examples-zone-policy`. Groups ------ -Firewall groups represent collections of IP addresses, networks, or ports. Once -created, a group can be referenced by firewall rules as either a source or -destination. Members can be added or removed from a group without changes to -or the need to reload individual firewall rules. +Firewall groups represent collections of IP addresses, networks, or +ports. Once created, a group can be referenced by firewall rules as +either a source or destination. Members can be added or removed from a +group without changes to or the need to reload individual firewall +rules. .. note:: Groups can also be referenced by NAT configuration. -While **network groups** accept IP networks in CIDR notation, specific IP addresses -can be added as a 32-bit prefix. If you foresee the need to add a mix of -addresses and networks, the network group is recommended. +While **network groups** accept IP networks in CIDR notation, specific +IP addresses can be added as a 32-bit prefix. If you foresee the need +to add a mix of addresses and networks, the network group is +recommended. -Here is an example of a network group for the IP networks that make up the -internal network: +Here is an example of a network group for the IP networks that make up +the internal network: .. code-block:: none set firewall group network-group NET-INSIDE network 192.168.0.0/24 set firewall group network-group NET-INSIDE network 192.168.1.0/24 -Groups need to have unique names. Even though some contain IPv4 addresses and others contain IPv6 addresses, they still need to have unique names, so you may want to append "-v4" or "-v6" to your group names. +Groups need to have unique names. Even though some contain IPv4 +addresses and others contain IPv6 addresses, they still need to have +unique names, so you may want to append "-v4" or "-v6" to your group +names. .. code-block:: none @@ -57,10 +67,11 @@ Groups need to have unique names. Even though some contain IPv4 addresses and ot set firewall group ipv6-network-group NET-INSIDE-v6 network 2001:db8::/64 -A **port group** represents only port numbers, not the protocol. Port groups can -be referenced for either TCP or UDP. It is recommended that TCP and UDP groups -are created separately to avoid accidentally filtering unnecessary ports. -Ranges of ports can be specified by using `-`. +A **port group** represents only port numbers, not the protocol. Port +groups can be referenced for either TCP or UDP. It is recommended that +TCP and UDP groups are created separately to avoid accidentally +filtering unnecessary ports. Ranges of ports can be specified by using +`-`. Here is an example of a port group a server: @@ -73,9 +84,10 @@ Here is an example of a port group a server: Rule-Sets --------- -A rule-set is a named collection of firewall rules that can be applied to an -interface or zone. Each rule is numbered, has an action to apply if the rule -is matched, and the ability to specify the criteria to match. +A rule-set is a named collection of firewall rules that can be applied +to an interface or zone. Each rule is numbered, has an action to apply +if the rule is matched, and the ability to specify the criteria to +match. Example of a rule-set to filter traffic to the internal network: @@ -93,8 +105,8 @@ Applying a Rule-Set to an Interface Once a rule-set is created, it can be applied to an interface. -.. note:: Only one rule-set can be applied to each interface for `in`, `out`, - or `local` traffic for each protocol (IPv4 and IPv6). +.. note:: Only one rule-set can be applied to each interface for `in`, + `out`, or `local` traffic for each protocol (IPv4 and IPv6). .. code-block:: none @@ -113,23 +125,34 @@ first be created): How VyOS replies when being pinged ---------------------------------- -By default, when VyOS receives an ICMP echo request packet destined for itself, it will answer with an ICMP echo reply, unless you avoid it through its firewall. +By default, when VyOS receives an ICMP echo request packet destined for +itself, it will answer with an ICMP echo reply, unless you avoid it +through its firewall. -With the firewall you can set rules to accept, drop or reject ICMP in, out or local traffic. You can also use the general **firewall all-ping** command. This command affects only to LOCAL (packets destined for your VyOS system), not to IN or OUT traffic. +With the firewall you can set rules to accept, drop or reject ICMP in, +out or local traffic. You can also use the general **firewall all-ping** +command. This command affects only to LOCAL (packets destined for your +VyOS system), not to IN or OUT traffic. -.. note:: **firewall all-ping** affects only to LOCAL and it always behaves in the most restrictive way +.. note:: **firewall all-ping** affects only to LOCAL and it always + behaves in the most restrictive way .. code-block:: none set firewall all-ping enable -When the command above is set, VyOS will answer every ICMP echo request addressed to itself, but that will only happen if no other rule is applied dropping or rejecting local echo requests. In case of conflict, VyOS will not answer ICMP echo requests. +When the command above is set, VyOS will answer every ICMP echo request +addressed to itself, but that will only happen if no other rule is +applied dropping or rejecting local echo requests. In case of conflict, +VyOS will not answer ICMP echo requests. .. code-block:: none set firewall all-ping disable -When the command above is set, VyOS will answer no ICMP echo request addressed to itself at all, no matter where it comes from or whether more specific rules are being applied to accept them. +When the command above is set, VyOS will answer no ICMP echo request +addressed to itself at all, no matter where it comes from or whether +more specific rules are being applied to accept them. Example Partial Config ---------------------- diff --git a/docs/interfaces/bridge.rst b/docs/interfaces/bridge.rst index d51f4ec2..a7343a0d 100644 --- a/docs/interfaces/bridge.rst +++ b/docs/interfaces/bridge.rst @@ -4,11 +4,15 @@ Bridge ###### -A Bridge is a way to connect two Ethernet segments together in a protocol -independent way. Packets are forwarded based on Ethernet address, rather than -IP address (like a router). Since forwarding is done at Layer 2, all protocols -can go transparently through a bridge. The Linux bridge code implements a -subset of the ANSI/IEEE 802.1d standard. +A Bridge is a way to connect two Ethernet segments together in a +protocol independent way. Packets are forwarded based on Ethernet +address, rather than IP address (like a router). Since forwarding is +done at Layer 2, all protocols can go transparently through a bridge. +The Linux bridge code implements a subset of the ANSI/IEEE 802.1d +standard. + +.. note:: Spanning Tree Protocol is not enabled by default in VyOS. + :ref:`stp` can be easily enabled if needed. Configuration ############# @@ -16,16 +20,18 @@ Configuration Address ------- -.. cfgcmd:: set interfaces bridge <interface> address <address | dhcp | dhcpv6> +.. cfgcmd:: set interfaces bridge <interface> address <address | dhcp | + dhcpv6> - Configure interface `<interface>` with one or more interface addresses. + Configure interface `<interface>` with one or more interface + addresses. - * **address** can be specified multiple times as IPv4 and/or IPv6 address, - e.g. 192.0.2.1/24 and/or 2001:db8::1/64 - * **dhcp** interface address is received by DHCP from a DHCP server on this - segment. - * **dhcpv6** interface address is received by DHCPv6 from a DHCPv6 server on - this segment. + * **address** can be specified multiple times as IPv4 and/or IPv6 + address, e.g. 192.0.2.1/24 and/or 2001:db8::1/64 + * **dhcp** interface address is received by DHCP from a DHCP server + on this segment. + * **dhcpv6** interface address is received by DHCPv6 from a DHCPv6 + server on this segment. Example: @@ -41,10 +47,12 @@ Address .. include:: common-ipv6-addr-autoconf.txt -.. cfgcmd:: set interfaces bridge <interface> ipv6 address eui64 <prefix> +.. cfgcmd:: set interfaces bridge <interface> ipv6 address eui64 + <prefix> :abbr:`EUI-64 (64-Bit Extended Unique Identifier)` as specified in - :rfc:`4291` allows a host to assign iteslf a unique 64-Bit IPv6 address. + :rfc:`4291` allows a host to assign iteslf a unique 64-Bit IPv6 + address. .. code-block:: none @@ -60,8 +68,8 @@ Address Bridge maximum aging `<time>` in seconds (default: 20). - If a 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. + If a 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. Link Administration @@ -69,14 +77,14 @@ Link Administration .. cfgcmd:: set interfaces bridge <interface> description <description> - Assign given `<description>` to interface. Description will also be passed - to SNMP monitoring systems. + Assign given `<description>` to interface. Description will also be + passed to SNMP monitoring systems. .. cfgcmd:: set interfaces bridge <interface> disable - Disable given `<interface>`. It will be placed in administratively down - (``A/D``) state. + Disable given `<interface>`. It will be placed in administratively + down (``A/D``) state. .. cfgcmd:: set interfaces bridge <interface> disable-flow-control @@ -86,8 +94,8 @@ Link Administration .. cfgcmd:: set interfaces bridge <interface> mac <mac-address> - Configure user defined :abbr:`MAC (Media Access Control)` address on given - `<interface>`. + Configure user defined :abbr:`MAC (Media Access Control)` address on + given `<interface>`. .. cfgcmd:: set interfaces bridge <interface> igmp querier @@ -95,45 +103,53 @@ Link Administration Enable IGMP querier + Member Interfaces ----------------- .. cfgcmd:: set interfaces bridge <interface> member interface <member> - Assign `<member>` interface to bridge `<interface>`. A completion helper - will help you with all allowed interfaces which can be bridged. This includes - :ref:`ethernet-interface`, :ref:`bond-interface`, :ref:`l2tpv3-interface`, - :ref:`openvpn`, :ref:`vxlan-interface`, :ref:`wireless-interface`, + Assign `<member>` interface to bridge `<interface>`. A completion + helper will help you with all allowed interfaces which can be + bridged. This includes :ref:`ethernet-interface`, + :ref:`bond-interface`, :ref:`l2tpv3-interface`, :ref:`openvpn`, + :ref:`vxlan-interface`, :ref:`wireless-interface`, :ref:`tunnel-interface` and :ref:`geneve-interface`. -.. cfgcmd:: set interfaces bridge <interface> member interface <member> priority <priority> +.. cfgcmd:: set interfaces bridge <interface> member interface <member> + priority <priority> Configure individual bridge port `<priority>`. - Each bridge has a relative priority and cost. Each interface is associated - with a port (number) in the STP code. Each has a priority 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 performance. + Each bridge has a relative priority and cost. Each interface is + associated with a port (number) in the STP code. Each has a priority + 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 + performance. -.. cfgcmd:: set interfaces bridge <interface> member interface <member> cost <cost> +.. cfgcmd:: set interfaces bridge <interface> member interface <member> + cost <cost> + + Path `<cost>` value for Spanning Tree Protocol. Each interface in a + bridge could have a different speed and this value is used when + deciding which link to use. Faster interfaces should have lower + costs. - Path `<cost>` value for Spanning Tree Protocol. Each interface in a bridge - could have a different speed and this value is used when deciding which - link to use. Faster interfaces should have lower costs. +.. _stp: STP Parameter ------------- :abbr:`STP (Spanning Tree Protocol)` is a network protocol that builds a -loop-free logical topology for Ethernet networks. The basic function of STP is -to prevent bridge loops and the broadcast radiation that results from them. -Spanning tree also allows a network design to include backup links providing -fault tolerance if an active link fails. +loop-free logical topology for Ethernet networks. The basic function of +STP is to prevent bridge loops and the broadcast radiation that results +from them. Spanning tree also allows a network design to include backup +links providing fault tolerance if an active link fails. .. cfgcmd:: set interfaces bridge <interface> stp @@ -145,9 +161,9 @@ 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 so - that when a new bridge comes onto a busy network it looks at some traffic - before participating. + 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. .. cfgcmd:: set interfaces bridge <interface> hello-time <interval> @@ -156,14 +172,15 @@ fault tolerance if an active link fails. (default: 2). Periodically, a hello packet is sent out by the Root Bridge and the - Designated Bridges. Hello packets are used to communicate information about - the topology throughout the entire Bridged Local Area Network. + Designated Bridges. Hello packets are used to communicate information + about the topology throughout the entire Bridged Local Area Network. -Exammple --------- +Example +------- -Creating a bridge interface is very simple. In this example we will have: +Creating a bridge interface is very simple. In this example we will +have: * A bridge named `br100` * Member interfaces `eth1` and VLAN 10 on interface `eth2` @@ -199,8 +216,8 @@ Operation .. opcmd:: show bridge - The `show bridge` operational command can be used to display configured - bridges: + The `show bridge` operational command can be used to display + configured bridges: .. code-block:: none |