network: add note for possible fix/workaround in NAT setup

[pve-docs.git] / pve-network.adoc

diff --git a/pve-network.adoc b/pve-network.adoc
index b2dae9780247339bbdfdda13deb7fd2bd2d861a5..19134986718c2d74e59405d1ca747f3408b92886 100644 (file)
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -9,16 +9,55 @@ Network configuration can be done either via the GUI, or by manually
 editing the file `/etc/network/interfaces`, which contains the
 whole network configuration. The  `interfaces(5)` manual page contains the
 complete format description. All {pve} tools try hard to keep direct
- user modifications, but using the GUI is still preferable, because it
+user modifications, but using the GUI is still preferable, because it
 protects you from errors.
 
 Once the network is configured, you can use the Debian traditional tools `ifup`
 and `ifdown` commands to bring interfaces up and down.
 
-NOTE: {pve} does not write changes directly to
-`/etc/network/interfaces`. Instead, we write into a temporary file
-called `/etc/network/interfaces.new`, and commit those changes when
-you reboot the node.
+Apply Network Changes
+~~~~~~~~~~~~~~~~~~~~~
+
+{pve} does not write changes directly to `/etc/network/interfaces`. Instead, we
+write into a temporary file called `/etc/network/interfaces.new`, this way you
+can do many related changes at once. This also allows to ensure your changes
+are correct before applying, as a wrong network configuration may render a node
+inaccessible.
+
+Reboot Node to apply
+^^^^^^^^^^^^^^^^^^^^
+
+With the default installed `ifupdown` network managing package you need to
+reboot to commit any pending network changes. Most of the time, the basic {pve}
+network setup is stable and does not change often, so rebooting should not be
+required often.
+
+Reload Network with ifupdown2
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+With the optional `ifupdown2` network managing package you also can reload the
+network configuration live, without requiring a reboot.
+
+NOTE: 'ifupdown2' cannot understand 'OpenVSwitch' syntax, so reloading is *not*
+possible if OVS interfaces are configured.
+
+Since {pve} 6.1 you can apply pending network changes over the web-interface,
+using the 'Apply Configuration' button in the 'Network' panel of a node.
+
+To install 'ifupdown2' ensure you have the latest {pve} updates installed, then
+
+WARNING: installing 'ifupdown2' will remove 'ifupdown', but as the removal
+scripts of 'ifupdown' before version '0.8.35+pve1' have a issue where network
+is fully stopped on removal footnote:[Introduced with Debian Buster:
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945877] you *must* ensure
+that you have a up to date 'ifupdown' package version.
+
+For the installation itself you can then simply do:
+
+ apt install ifupdown2
+
+With that you're all set. You can also switch back to the 'ifupdown' variant at
+any time, if you run into issues.
 
 Naming Conventions
 ~~~~~~~~~~~~~~~~~~
@@ -104,8 +143,8 @@ Default Configuration using a Bridge
 
 [thumbnail="default-network-setup-bridge.svg"]
 Bridges are like physical network switches implemented in software.
-All VMs can share a single bridge, or you can create multiple bridges to
-separate network domains. Each host can have up to 4094 bridges.
+All virtual guests can share a single bridge, or you can create multiple
+bridges to separate network domains. Each host can have up to 4094 bridges.
 
 The installation program creates a single bridge named `vmbr0`, which
 is connected to the first Ethernet card. The corresponding
@@ -204,11 +243,29 @@ iface vmbr0 inet static
         bridge_stp off
         bridge_fd 0
 
-        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
+        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
         post-up   iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
         post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
 ----
 
+NOTE: In some masquerade setups with firewall enabled, conntrack zones might be
+needed for outgoing connections. Otherwise the firewall could block outgoing
+connections since they will prefer the `POSTROUTING` of the VM bridge (and not
+`MASQUERADE`).
+
+Adding these lines in the `/etc/network/interfaces` can fix this problem:
+
+----
+post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
+post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
+----
+
+For more information about this, refer to the following links:
+https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg[Netfilter Packet Flow]
+https://lwn.net/Articles/370152/[Patch on netdev-list introducing conntrack zones]
+https://blog.lobraun.de/2019/05/19/prox/[Blog post with a good explanation by using TRACE in the raw table]
+
+
 
 Linux Bond
 ~~~~~~~~~~