{"id":1925,"date":"2026-02-19T12:20:19","date_gmt":"2026-02-19T04:20:19","guid":{"rendered":"https:\/\/mylinuxsite.com\/wordpress\/?p=1925"},"modified":"2026-02-19T12:29:44","modified_gmt":"2026-02-19T04:29:44","slug":"my-journey-to-proxmox-part-2","status":"publish","type":"post","link":"https:\/\/mylinuxsite.com\/wordpress\/?p=1925","title":{"rendered":"My Journey to Proxmox \u2013 Part 2"},"content":{"rendered":"\n

In Part 1 of this blog, I discussed how my decision to replace my ageing home lab\/server\/workstation led me to adopt Proxmox. I ended the blog with a summary of the new machine’s network setup. In Part 2 of this blog, I will delve into the network configuration of the new machine. In particular, I will discuss Linux bridges, the virtual interfaces that provide network connectivity between guests and to the outside world, and how I assign dynamic IPs to guest machines without using Proxmox’s DHCP feature.<\/p>\n\n\n\n

The Linux Bridges<\/h2>\n\n\n\n

As I mentioned in Part 1, the new machine includes a Wi-Fi adapter designated for ingress and an Ethernet adapter for egress. The Linux bridges created that will use these adapters are summarised in the diagram below. <\/p>\n\n\n\n

Proxmox uses ifupdown2<\/em> as its network manager, so the network configurations are stored in \/etc\/network\/interfaces<\/em>.<\/span> This file can be edited directly or modified through the Proxmox GUI.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

VMBR0<\/h4>\n\n\n\n

The VMBR0 is the Linux bridge that enslaves the Ethernet adapter and is responsible for obtaining the machine’s public IP from the ISP via DHCP. This bridge enslaves the Ethernet adapter via the bridge-ports directive,<\/em> and the IP address is obtained via<\/span> DHCP, hence the dhcp<\/em> method in the configuration file. The Ethernet adapter is not automatically brought up; therefore, it is set to manual<\/em>. <\/p>\n\n\n\n

Since the bridge IP is obtained from the ISP, it will only have one (1) IP address, and it will be dynamic (assuming you are just a home broadband user), so no guest VM will use this bridge directly.<\/p>\n\n\n\n

Below is the complete VMBR0 and Ethernet adapter configuration:<\/p>\n\n\n\n

allow-mgmt enp10s0\niface enp10s0 inet manual<\/strong>\n#       Ethernet network interface.\n\nauto vmbr0\nallow-mgmt vmbr0\niface vmbr0 inet dhcp<\/strong>\n#       Main internet gateway. ISP provided IP Address via DHCP.\n        bridge-ports enp10s0<\/strong>\n        bridge-stp off\n        bridge-fd 0\n\n        post-up   echo 1 > \/proc\/sys\/net\/ipv4\/ip_forward<\/code><\/pre>\n\n\n\n
The allow-mgmt <\/strong><\/em>method on each interface ensures the interface is brought up before any other. It is necessary that these interfaces be the first to go up because they are referenced later in other bridges.<\/p>\n\n\n\n
The post-up<\/strong><\/em> command in this bridge configuration enables IP forwarding on the nodes’ network.<\/p>\n\n\n\n
VMBR1<\/h4>\n\n\n\n
This Linux bridge is designated for virtual machines  that expect ingress traffic from the internet.  Incoming traffic is forwarded from the Ethernet adapter to this bridge via IP Tables port forwarding; therefore, the virtual machines created under this subnet will have static IP addresses. As of this writing, three (3) ports are open, namely: 80 (HTTP), 443 (HTTPS), and 25 (SMTP).  Ports 80 and 443 are served by Nginx<\/em>, which acts as a proxy for this website and file hosting service. Port 25 is served by Postfix<\/em>, the MTA for my mail server.<\/p>\n\n\n\n
Below is the complete VMBR1 bridge configuration.<\/p>\n\n\n\n
auto vmbr1\niface vmbr1 inet static\n#       External services. Fix IP. Gateway via vmbr0.\n        address 192.168.1.1\/24\n        bridge-ports none\n        bridge-stp off\n        bridge-fd 0\n\n        post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 25  -j DNAT --to-destination 192.168.1.2:25\n        post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80  -j DNAT --to-destination 192.168.1.3:80\n        post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.3:443\n        post-up iptables -t nat -A POSTROUTING -s '192.168.1.0\/24' -o vmbr0 -j MASQUERADE\n\n        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 25  -j DNAT --to-destination 192.168.1.2:25\n        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 80  -j DNAT --to-destination 192.168.1.3:80\n        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.3:443\n        post-down iptables -t nat -D POSTROUTING -s '192.168.1.0\/24' -o vmbr0 -j MASQUERADE\n\n        post-up   ip route add 192.168.1.0\/24 dev vmbr1 src 192.168.1.1 table wifi\n        post-down ip route del 192.168.1.0\/24 dev vmbr1 src 192.168.1.1 table wifi<\/code><\/pre>\n\n\n\n
The post-up<\/em> <\/span><\/strong>(and its corresponding post-down<\/em><\/span>) command sets up the port-forwarding rule of each opened port. There is also a post-up<\/em> (and post-down<\/em>) that adds (or deletes) an entry in the custom routing table used for WiFi traffic. Refer to VMBR2 for details on why this configuration exists.<\/p>\n\n\n\n
VMBR2<\/h4>\n\n\n\n
This Linux bridge is intended for guests that require only egress traffic, such as my workstation.  Outgoing traffic is forwarded to the Wi-Fi adapter.   This is accomplished by creating a POSTROUTING NAT rule, a custom routing table named wifi, <\/em>and a custom routing rule that points to it.<\/p>\n\n\n\n
post-up   iptables -t nat -A POSTROUTING -s '192.168.2.0\/24' -o wlp11s0 -j MASQUERADE\n   :\npost-up   ip rule add from 192.168.2.0\/24 table wifi\npost-up   ip rule add to   192.168.2.0\/24 table wifi<\/code><\/pre>\n\n\n\n
For guests in this subnet to reach other guests in other subnets, we need to add a routing entry in this custom table that points to the gateway of the target subnet. You can see this in the VMBR1<\/a> configuration, where a<\/span> post<\/em>-up command adds the VMBR1  CIDR and gateway to the Wi-Fi route table<\/span>. So this would allow my workstation to access VMs on this bridge.<\/p>\n\n\n\n
A Wi-Fi adapter cannot be enslaved by a bridge, unlike an Ethernet adapter, so it will issue a DHCP request for an IP address to the Wi-Fi router independently of the bridge.  The IP address will be dynamic, and since it will be the default gateway in the Wi-Fi<\/em> routing table, we need to <\/span>update the table whenever it changes.  This is accomplished by using DHCP exit hooks, implemented as scripts in the \/etc\/dhcp\/dhclient-exit-hooks directory, <\/em>which are executed whenever a DHCP event occurs<\/span>.<\/p>\n\n\n\n
Below is a snippet of this DHCP exit hook script:<\/p>\n\n\n\n
echo \"${reason}\" >> $LOGFILE\n\ncase ${interface} in\n     wlp11s0)\n        case ${reason} in\n           BOUND)\n                ip route add default via ${new_routers} dev ${interface} table wifi | tee -a \"$LOGFILE\"\n                ip rule add from ${new_ip_address}\/32 table wifi | tee -a \"$LOGFILE\"\n                ip rule add to   ${new_ip_address}\/32 table wifi | tee -a \"$LOGFILE\"<\/code><\/pre>\n\n\n\n
In the script, whenever a new IP is leased (BOUND), the custom table is updated to set the new IP as the default gateway. In addition, a custom rule is added to ensure that incoming and outgoing traffic destined for this IP uses the custom table.<\/p>\n\n\n\n
The complete VMBR2 bridge configuration is shown below:<\/p>\n\n\n\n
auto wlp11s0\niface wlp11s0 inet dhcp\n#       Wifi network interface.\n        wpa-conf \/etc\/wpa_supplicant\/wpa_supplicant.conf\n\nauto vmbr2\niface vmbr2 inet static\n#       Egress only VMs. Gateway is via wlp11s0.\n        address 192.168.2.1\/24\n        bridge-ports none\n        bridge-stp off\n        bridge-fd 0\n\n        post-up   iptables -t nat -A POSTROUTING -s '192.168.2.0\/24' -o wlp11s0 -j MASQUERADE\n        post-down iptables -t nat -D POSTROUTING -s '192.168.2.0\/24' -o wlp11s0 -j MASQUERADE\n\n        #for firewall \n        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1\n        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1\n\n        #routes and rules\n        post-up   ip route add 192.168.2.0\/24 dev vmbr2 src 192.168.2.1 table wifi\n        post-down ip route del 192.168.2.0\/24 dev vmbr2 src 192.168.2.1 table wifi\n\n        post-up   ip rule add from 192.168.2.0\/24 table wifi\n        post-up   ip rule add to   192.168.2.0\/24 table wifi\n        post-down ip rule del from 192.168.2.0\/24 table wifi\n        post-down ip rule del to   192.168.2.0\/24 table wifi<\/code><\/pre>\n\n\n\n
When the entire configuration is applied, the custom routing rule and routing rule tables should resemble the outputs below:<\/p>\n\n\n\n
$ ip route show table wifi\ndefault via 192.168.0.1 dev wlp11s0 \n192.168.1.0\/24 dev vmbr1 scope link src 192.168.1.1 \n192.168.2.0\/24 dev vmbr2 scope link src 192.168.2.1 \n192.168.3.0\/24 dev vmbr3 scope link src 192.168.3.1 \n192.168.4.0\/24 dev vmbr4 scope link src 192.168.4.1 \n\n$ ip rule show\n0:      from all lookup local\n32762:  from all to 192.168.2.0\/24 lookup wifi\n32763:  from 192.168.2.0\/24 lookup wifi\n32764:  from all to 192.168.0.168 lookup wifi\n32765:  from 192.168.0.168 lookup wifi\n32766:  from all lookup main\n32767:  from all lookup default<\/code><\/pre>\n\n\n\n
VMBR3<\/h4>\n\n\n\n
This Linux bridge is intended for a private subnet that does not expect any traffic to and from the internet. So its entry in the configuration file is straightforward, i.e. no NATs or port forwarding. <\/p>\n\n\n\n
The complete VMBR3 bridge configuration is shown below:<\/p>\n\n\n\n
auto vmbr3\niface vmbr3 inet static\n#       Internal VMs. No Ingress or Egress.\n        address 192.168.3.1\/24\n        bridge-ports none\n        bridge-stp off\n        bridge-fd 0\n\n        post-up   ip route add 192.168.3.0\/24 dev vmbr3 src 192.168.3.1 table wifi\n        post-down ip route del 192.168.3.0\/24 dev vmbr3 src 192.168.3.1 table wifi<\/code><\/pre>\n\n\n\n
VMBR4<\/h4>\n\n\n\n
This Linux bridge is intended for services used solely by other guests. Network services such as DNS, DHCP, and storage services like NAS run in this subnet. The network is considered private, although some VMs with services that require internet connectivity, like NTP, are given internet access via VMBR0. VMs created in this bridge have a static IP address because they either need to be referenced directly by IP (e.g., a DNS server) or because internet access is granted per-VM. <\/p>\n\n\n\n
The complete VMBR4 bridge configuration is shown below:<\/p>\n\n\n\n
auto vmbr4\niface vmbr4 inet static\n#       Internal services. Selective Egress. Gateway via vmbr0.\n        address 192.168.4.1\/24\n        bridge-ports none\n        bridge-stp off\n        bridge-fd 0\n\n        post-up   iptables -t nat -A POSTROUTING -s '192.168.4.2\/32' -o vmbr0 -j MASQUERADE\n        post-down iptables -t nat -D POSTROUTING -s '192.168.4.2\/32' -o vmbr0 -j MASQUERADE\n\n        post-up   ip route add 192.168.4.0\/24 dev vmbr4 src 192.168.4.1 table wifi\n        post-down ip route del 192.168.4.0\/24 dev vmbr4 src 192.168.4.1 table wifi<\/code><\/pre>\n\n\n\n
DHCP and Dynamic DNS<\/h4>\n\n\n\n
Proxmox can be configured to provide a DHCP service. This is done through a VNet<\/a> in an SDN. Unfortunately, this feature does not work when the bridge uses a Wi-Fi interface via a custom routing table and routing rule, such as VMBR3<\/strong>.  An alternative is to create a dedicated VM that runs a DHCP service, which is what I end up doing.<\/p>\n\n\n\n
So within the VMB4 subnet, I created a VM running dnsmasq<\/em>.  There are several DHCP packages to choose from, but I chose dnsmasq <\/em>because it not only provides DHCP but also a dynamic DNS service. How this works is that when a client with a hostname, say myworkstation<\/em>,<\/span> requests an IP address, the DNS service automatically maps the client’s hostname to an IP address, giving it a canonical name, hostname.domain_name,<\/em> e.g.,<\/span> myworkstation.mylinuxsite.com.<\/em><\/p>\n\n\n\n
If you are using Fedora as your server to host dnsmasq<\/em>, you can c<\/span>onfigure it as a NetworkManager plugin<\/a>. If you take this option, as I did in my installation, you will be working on a different set of configuration files rather than the standard \/etc\/dnsmasq.conf <\/em>file.<\/p>\n\n\n\n
At a minimum, you need to create three (3) configuration files. <\/p>\n\n\n\n
    \n
  1. \/etc\/NetworkManager\/conf.d\/00-enable-dnsmasq.conf<\/strong><\/li>\n<\/ol>\n\n\n\n
    This configuration file enables the dnsmasq plugin.<\/p>\n\n\n\n
    # \/etc\/NetworkManager\/conf.d\/00-enable-dnsmasq.conf #\n# This enabled the dnsmasq plugin.\n[main]\ndns=dnsmasq<\/code><\/pre>\n\n\n\n
      \n
    1. \/etc\/NetworkManager\/dnsmasq.d\/01-dns.conf<\/strong><\/li>\n<\/ol>\n\n\n\n
      This configuration file is the setting for the DNS service. <\/p>\n\n\n\n
      Two (2) parameter entries in this file are worth noting here, namely: <\/p>\n\n\n\n
        \n
      1. addn-hosts – <\/strong><\/em>This parameter l<\/em>ets you point to a file containing a static mapping.  In this configuration, it points to \/etc\/hosts<\/em>.  Servers with static IP addresses, such as those in VMBR1 and VMBR4, are defined in this file.<\/li>\n\n\n\n
      2. server<\/em>  <\/strong>– This parameter specifies the resolver that dnsmasq <\/em>will use<\/span> if it cannot resolve a given name within itself. In this configuration, it points to Google’s recursive resolvers.<\/li>\n<\/ol>\n\n\n\n
         # \/etc\/NetworkManager\/dnsmasq.d\/01-dns.conf\n # This file sets up DNS for the private local net domain mylinuxsite.com\n local=\/mylinuxsite.com\/\n # file where to find the list of IP - hostname mapping\n addn-hosts=\/etc\/hosts\n \n domain-needed\n bogus-priv\n \n # Automatically add <domain> to simple names in a hosts-file.\n expand-hosts\n \n # interfaces to listen on\n interface=lo\n interface=ens18\n # in case of a bridge don't use the attached server virtual ethernet interface\n \n # The below defines a Wildcard DNS Entry.\n #address=\/.localnet\/10.10.10.zzz\n \n # Upstream public net DNS server (max.three)\n no-poll\n server=8.8.8.8\n server=8.8.4.4<\/code><\/pre>\n\n\n\n
          \n
        1. \/etc\/NetworkManager\/dnsmasq.d\/02-dhcp.conf<\/strong><\/li>\n<\/ol>\n\n\n\n
          The configuration file is the setting for the DHCP service. <\/p>\n\n\n\n
          Parameters worth nothing here include:<\/p>\n\n\n\n