"description":"Network-related optimizations in the ProxMenux Customizable post-install script: force APT over IPv4, apply a curated sysctl tuning profile, install Open vSwitch, enable TCP BBR + Fast Open, and pin interface names to their MAC addresses."
},
"header":{
"title":"Post-Install: Network",
"section":"Settings post-install Proxmox"
},
"intro":{
"title":"What this category covers",
"body":"Five independent network options. Two are small (<strong>APT over IPv4</strong>, <strong>Open vSwitch install</strong>), two tune TCP behaviour (<strong>network sysctl profile</strong>, <strong>BBR + Fast Open</strong>), and one fixes a common operational headache — <strong>pinning interface names</strong> so a new NIC or a BIOS update doesn't rename <code>enp3s0</code> to <code>enp4s0</code> and break your bridges."
},
"ipv4":{
"heading":"Force APT to use IPv4",
"intro":"Writes <code>Acquire::ForceIPv4 \"true\";</code> to <code>/etc/apt/apt.conf.d/99-force-ipv4</code>. APT then refuses to use IPv6 for package downloads, even if the host has IPv6 connectivity.",
"tipTitle":"Who benefits",
"tipBody":"Useful when your IPv6 path is flaky, slower than IPv4, or the Debian/Proxmox mirror occasionally breaks over IPv6 (it happens). Harmless on hosts without IPv6. On a healthy dual-stack network, it's just a guarantee of predictable behaviour — apt won't surprise you with an IPv6 timeout."
},
"sysctl":{
"heading":"Apply network optimizations",
"intro":"Writes a curated sysctl profile to <code>/etc/sysctl.d/99-network.conf</code> covering core socket buffers, ICMP hardening, basic spoof protection, and TCP buffer sizes that make sense on a hypervisor with lots of concurrent flows.",
"sourceOutro":"It also adds <code>source /etc/network/interfaces.d/*</code> to <code>/etc/network/interfaces</code> if not already present — standard practice so you can drop modular interface snippets without editing the main file.",
"fwbrTitle":"Automatic tuning of virtual firewall bridges",
"fwbrBody":"Alongside the sysctl profile, ProxMenux installs a helper at <code>/usr/local/sbin/proxmenux-fwbr-tune</code> that applies <code>rp_filter=0</code> and <code>log_martians=0</code> to the <code>fwbr*</code> / <code>fwln*</code> / <code>fwpr*</code> / <code>tap*</code> interfaces Proxmox creates around VMs and containers. The helper is invoked by the <code>proxmenux-fwbr-tune.service</code> one-shot unit at boot, and by the <code>/etc/udev/rules.d/99-proxmenux-fwbr-tune.rules</code> rule on every <code>net add</code> event matching those prefixes — covering interfaces that Proxmox recreates on VM start/stop, reboot and live migration.",
"rpFilterTitle":"Why rp_filter=2 (loose) instead of 1 (strict)",
"rpFilterBody":"Strict reverse-path filtering drops packets whose source would be routed out a <em>different</em> interface. That's the right default on a client machine, but breaks badly on a Proxmox host where VM traffic often arrives on a bridge and leaves on an uplink with asymmetric routes. <code>rp_filter=2</code> (loose) only drops packets with truly unroutable sources. It's a pragmatic trade-off — slight reduction in local-IP-spoof detection in exchange for not breaking your VM network."
},
"ovs":{
"heading":"Install Open vSwitch",
"intro":"Installs <code>openvswitch-switch</code> + <code>openvswitch-common</code>. These packages add OVS as a bridge implementation alternative to the standard Linux bridges that Proxmox uses by default. The install alone doesn't change any networking — existing <code>vmbrX</code> bridges keep working. OVS becomes available in the Proxmox UI when you <em>create</em> a new bridge and pick it from the type dropdown.",
"tipTitle":"When OVS makes sense",
"tipBody":"Consider OVS if you need <strong>VLAN trunking with non-contiguous VLAN IDs</strong>, <strong>LACP with LLDP on specific modes</strong>, <strong>fine-grained flow programming</strong> (OpenFlow), or interoperation with SDN controllers. For a home lab with a couple of VLANs and a single LACP uplink, standard Linux bridges + <code>vmbrX.VID</code> are simpler and perfectly fine.",
"revertTitle":"Not reversible from the Uninstall menu",
"revertBody":"Installing OVS is not tracked in Uninstall Optimizations. If you decide you don't want it, remove it manually — but only after migrating any bridges back to Linux bridges first:"
},
"bbr":{
"heading":"Enable TCP BBR + TCP Fast Open",
"intro":"Writes two sysctl files and reloads them. BBR replaces the default CUBIC congestion control with Google's bandwidth-based algorithm, which handles long-fat pipes and lossy links much better. TCP Fast Open (TFO) eliminates a round trip on repeat TCP connections by piggy-backing data on the SYN.",
"verifyTitle":"Verification",
"impactTitle":"Impact is workload-dependent",
"impactBody":"BBR shines on high-latency or lossy links (cross-continent replication, VPN tunnels, mobile clients). On a LAN between two machines on the same switch, the difference is often within noise. TFO helps short, repeated HTTP connections the most.",
"revertTitle":"Not reversible from the Uninstall menu",
"revertBody":"BBR/TFO aren't tracked. To revert, remove the two sysctl files and reload:"
},
"names":{
"heading":"Interface Names (persistent)",
"intro":"Iterates over every physical NIC the host has (skipping loopback, Docker veths, bridges, TAP devices, bonds, Cilium, ZeroTier, WireGuard) and writes a systemd <code>.link</code> file binding the current interface name to the current MAC address. The kernel's naming logic can then no longer rename that NIC — the MAC wins.",
"whyTitle":"Why this matters",
"whyItems":[
"Adding or removing PCIe devices can shift the bus numbering, turning <code>enp3s0</code> into <code>enp4s0</code>. If your <code>/etc/network/interfaces</code> references the old name, the bridge vanishes on reboot.",
"BIOS / firmware updates sometimes change how devices enumerate, with the same effect.",
"LXC containers with <code>hotplug</code> NICs and bonded links can race on boot and end up named inconsistently. Pinning fixes that."
"writtenIntro":"One file per physical NIC, at <code>/etc/systemd/network/10-proxmenux-<iface>.link</code>. Each file starts with the header <code># Managed by ProxMenux — do not edit</code> so ProxMenux can distinguish its own files from user- or package-provided <code>.link</code> files.",
"writtenOutro":"<code>.link</code> files from other packages or hand-written by the user are left in place — only files carrying the ProxMenux header are managed. On re-run, the function reconciles its own set: it re-reads <code>MACAddress=</code> from every <code>10-proxmenux-*.link</code> and drops any whose MAC no longer appears under <code>/sys/class/net/</code>. Files written by an earlier ProxMenux release in the old <code>10-<iface>.link</code> format are migrated automatically the first time.",
"pveBody":"On Proxmox VE 9 (<code>systemd-networkd</code> native), the script reloads udev rules after writing the <code>.link</code> files so new hotplug NICs pick up the correct name without a reboot. On PVE 8 (<code>ifupdown2</code>), interface naming is resolved at boot anyway — a reboot is required for the changes to take effect. The script sets the reboot flag either way so Customizable prompts you.",
"reviewBody":"If your host has legacy configuration in <code>/etc/network/interfaces</code> that references NIC names generated by the kernel's default scheme, pinning <em>today's</em> names is exactly what you want. But if you've already manually customised the config around specific names, double-check the pinning matches what the interfaces file expects before rebooting.",
"revertTitle":"Reversible from the Uninstall menu",
"revertBody":"<link>Uninstall Optimizations</link> deletes only the <code>10-proxmenux-*.link</code> files carrying the ProxMenux header from <code>/etc/systemd/network/</code>. Any <code>.link</code> file added by the user or by another package is preserved. Interface names return to systemd's default behaviour on next reboot."
