NATed proxmox host, DSL with dynamic IP

B

Bärtchen

New Member
Feb 13, 2026
7
1
3
I'm using Proxmox for my private home server system behind a dynamic DSL network connectivity. So IPv4 is NATed and the IPv6 prefix is changing once a day.

As it turned out, with the default Proxmox install and Debians default ifupdown2 system this is very unstable. Host and VMs sporadically lose internet connectivity. This is a headless system without any monitor connected to it and I do not even own a monitor for this old low-power business system business-system without HDMI, only display port. I do only own one DP-monitor which is for my desktop system and I have to move it to the basement, where the headless server is, every time the network is broken; therefore a stable network connectivity is mandatory. I tried several options within /etc/network/interfaces and nothing worked fully reliable.

The solution was to switch to Systemd's networkctl. I did this on the operating system level outside of Proxmox' configuration tree. I removed eno1 and vmbr0 from /etc/network/interfaces and added it to service files within /etc/systemd/network/. (the content of the files is shown below).

This works really stable. Dynamic IPv6 connectivity simply works this way.

The drawback is: I have to configure the vmbr0 interface manually to VMs and CTs, as Proxmox itself is unaware of its network connectivity. The network configuration in the GUI is broken and I cannot add interface vmbr0 to any VM/CT within the GUI. If I create a new VM or CT I always have to create it without a network interface and afterwards I have to manually edit the configuration files below /etc/pve.

This is generally fine for me, with a low count of VMs/CTs which change seldomly. Yet if there is a simple way to inlcude the hosts network to proxmox's network awareness, then I'd still prefer to do so.

###

Does anyone know of a better solution to this problem? Is there some simple way to let proxmox know of systemd/networkctl host managed network interfaces?

###

networkctl output:
Code: 
# networkctl | head -n4
IDX LINK      TYPE     OPERATIONAL SETUP
  1 lo        loopback carrier     unmanaged
  2 eno1      ether    enslaved    configured
  3 vmbr0     bridge   routable    configured


Systemd network configuration (including a fix for the e1000e loosing its link, this is a known bug with this old Intel devices):
Code: 
# for i in /etc/systemd/network/*; do echo "$i"; cat "$i"; done
/etc/systemd/network/20-eno1.link
[Match]
OriginalName=eno1

[Link]
TCPSegmentationOffload=false
GenericSegmentationOffload=false
GenericReceiveOffload=false
#LargeReceiveOffload=false

/etc/systemd/network/25-vmbr0-en.network
[Match]
Name=eno1

[Network]
Bridge=vmbr0

/etc/systemd/network/25-vmbr0.link
[Match]
OriginalName=vmbr0

[Link]
MACAddressPolicy=none

/etc/systemd/network/25-vmbr0.netdev
[NetDev]
Name=vmbr0
Kind=bridge
MACAddress=none

/etc/systemd/network/25-vmbr0.network
[Match]
Name=vmbr0

[Network]
DHCP=yes

[DHCPv4]
UseDomains=true

[DHCPv6]
UseDomains=true

[IPv6AcceptRA]
UseDomains=true
 
Last edited:
Hi @Bärtchen

thank you for posting in the forum!

I think i don't fully understand your network needs and why it is necessary to use DHCP v4 as well as v6.
If your server is behind some form of ISP router with an exposed host configuration (?) why do you need DHCPv4.

Two things on that topic:
1.) Please see the docs on network interface pinning, since newer kernel versions might introduce new naming for your NICs which will also break network connectivity, see [1]
2.) Are you using any form of firewall in front of the Proxmox host or is it completely exposed to the internet? If the latter i recommend looking into fail2ban [2] and stress the point that this instance needs to be updated very frequently.

Yours sincerely
Jonas

[1] https://pve.proxmox.com/wiki/Network_Configuration#:~:text=Overriding Network Device Names
[2] https://pve.proxmox.com/wiki/Fail2ban
 
Hi @j.theisen

thank you for your help

you are right, DHCP for IPv4 is not needed. Like it is quite typical for IPv4 behind a NAT router the private IPv4 could be static. Anyways, IPv4 wasn't the main problem for me with the classic ifupdown2 in Debian. It was mostly loosing IPv6 connectivity because of the dynamic IPv6 dialup connection. This is gone with using systemd/networkctl, now.

While using DHCP for IPv4 is not needed, it is just a nice addition. And it works. At least with system/networkctl, now.

Regarding the firewall: It is a typical dialup connection and therefore firewalled also for IPv6 besides the NAT on IPv4. No exposed host configuration.

The only "problem" I have now is that proxmox' network config depends on ifupdown2 and /etc/network/interfaces and thereofore my network configuration is uncommon - the proxmox network configuration in the proxmox wiki is not applicable for me and of no help. I have to figure out some way to make proxmox aware of this uncommon configuration.

But, like I already said, this is not mandatory as all VMs and CTs do indeed have a working network configuration. But I have to edit the configuration files by hand, as the GUI is not aware of the fact that there is a working Bridge interface (vmbr0). Proxmox thinks there is no valid network configuratuion (as /etc/network/interfaces does not contain a valid configuration)

Last but not least, thank you for your hint regarding network name pinning. But as proxmox is a release distribution I do not expect this kind of changes within a release cycle. For full dist-upgrades changes of these kind are manageable and therefore I will not pin my network names.

To be clear: The problem I describe here is caused by me, as I'm using some uncommon network configuration. It is not Proxmox' fault. My intend is NOT to blame Proxmox here.
Yet if I find a way to make proxmox aware of the vmbr0, which is not handley by proxmox, this would be great.:)
 
Last edited:
Not to my knowledge. The /etc/pve/firewall directory on the node is empty. The default for node level seems "firewall=yes". But it is disabled on datacenter level, anyway.
 
Last edited:
currently /etc/network/interface is very simple:
Code: 
auto lo
iface lo inet loopback

In the past, before transition to networkd, it had a little more content.
I have tried to find a configuration that is stable with dynamic IPs, like for example:
Code: 
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet dhcp
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
iface vmbr0 inet6 auto
or
Code: 
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.2/24
        gateway 192.168.1.2

iface vmbr0 inet6 dhcp
       accept_ra 2
       privext 0
(edit: the third example I had here probably was some previous non-proxmox system, so I removed this example here)

.... and several different combinations of static and dynamic IPv4 plus IPv6 via DHCPv6, RAs, etcpp. - nothing was fully stable in the end. Either the host or VMs/containers were losing connectivity. These are examples only. Since this is more than a year ago I have only a limited selection of backups from that time.

Now, with networkd managing the bridge device and IP assignment, all problems except one are gone: proxmox (esp. the GUI) doesn't know of the bridge device. However, assigning network devices manually via text-editor works (like for example with net0: name=eth0,bridge=vmbr0,hwaddr=11:22:33:44:55:66,ip=dhcp,type=veth in the CT.conf or net0: virtio=11:22:33:44:55:66,bridge=vmbr0,firewall=1 in the VM.conf)
 
Last edited:
PS: "all problems except one are gone" is for the network configuration part only, as I'm using btrfs here with per-VM/CT-subvolumes for years now, which is (or was?) also not supported with proxmox and needs manual interactions. ;)

For example: creating a container works only at command line for me and I have to manually adjust filesystem permissions for unprivileged containers between creation and the first start. But that's a completely different story.

Yet again: I do not want to blame proxmox. I am aware of the fact that problems are quite common in the software world if one is using some uncommon configuration. With proxmox it is at least possible to do unanticipated things which are not provided by the proxmox developers :cool:, while other commercial systems do not even allow to use uncommom configurations which are not provided by the vendor. Think of trying to use a non-VMware filesystem with ESXi. ;)
 
Thanks for your answer. That's probably a good advice for those who do not want to switch to systemd's networkd, even if the whole boot process, including parts of the network configuration (like device naming), is already managed by systemd by default and therefore also networkd has a really good reasoning.

Nevertheless, I won't switch back to ifupdown and will continue using networkd as it simply works and doesn't need so much attention (like ifupdown does!). Your advice to use a pre-up script command for basic configuration like forwarding router advertisements, even if the officiall man page for ifupdown (man interfaces) nominates an option for this functionality (accept_ra 2), is a very good demonstration example that ifupdown is broken.

On my Debian desktop systems I also switched from ifupdown to networkd to solve several problems - for example losing internet connectivity after suspend. On my Debian laptops I'm using Network Manager, also for good reasons. So I have several Debian systems and none of these depends on any of the ifupdown implementations (ifupdown2, ifupdown-ng).

I don't think Proxmox will change its default any time soon, as AFAIK even the Debian community is still discussing this. But I, for myself, am pretty sure ifupdown's days are numbered. And I'm pretty sure also Proxmox will switch to something different the day when Debian does. Yet currently no one knows.
 
You must log in or register to reply here.
Top Bottom
Back