No Networking After Proxmox 7 Upgrade - OVH

A

alasdairc

Member
Jun 25, 2021
30
1
8
27
Hi all,

I followed the guide on upgrading from Proxmox 6 to 7: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0

The host I have done it on is a test server before I roll the update out to production servers and after running the upgrade I have no networking. I have seen a number of users with the same issue also however I can't seem to fix the issue with suggestions provided from them posts. All of the pre-installation checks passed with no warnings.

The server is hosted with OVH, the only thing I can think is that I need to set the MAC address for the vmbr0 device, other than that I am completely stumped - I am just waiting to hear back via ticket if a specific MAC address is needed. OVH had to do an intervention last night and confirmed that it was not an issue with the hardware and was a software configuration issue (which is obvious really..)

The initial version 6 image was an OVH template, however I have been assured that this is not a problem and that other users have indeed done the upgrade and not experienced issues.

I only have IPMI access currently, the public web GUI isn't working, neither is SSH and it is not currently pingable

The network interfaces are now starting up as DOWN, I have ifupdown2 installed. When I try to force 'ifup eno1', I get: "error: Another instance of this program is already running.'

pveversion: pve-manager/7.0-13/7aa7e488 (running kernel: 5.11.22-5-pve)

I can just reinstall Proxmox and restore from backup, however this would be a last resort


==========

/etc/network/interfaces :

auto lo
iface lo inet loopback

iface eno1 inet manual
iface eno2 inet manual

auto vmbr0
iface vmbr0 inet dhcp
bridge-ports eno1
bridge-stp off
bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
bridge-ports eno2
bridge-stp off
bridge-fd 0

==========

ping 8.8.8.8:
ping: connect: Network is unreachable

==========

Any help on this would be amazing, thank you

Alasdair
 
What kernel version?
I'm troubleshooting a similar issue where the Proxmox host loses connectivity to the public Interface, but VMs are fine.

I have a suspicion that it's a bug in 5.11.22-5-pve because the server I have running 5.11.22-4-pve is okay.
Maybe try installing pve-kernel-5.11.22-4-pve and then select it in the IPMI interface.

I'm currently testing a continual ping to and from the Proxmox host on the public interface to see if keeping it active keeps it functioning.
-J
 
  • Like
Reactions: _gabriel
And kernel 5.11.22-4 and 5.11.22-5 made no difference.

So after a time, on a wholly working system using the original OVH Proxmox 5 or 6 template, the host OS loses its connection to the OVH network beyond the local /24. Virtual Machines continue to work. (I've seen this on two systems.)

No interface names have change, and the default gateway and anything else on the /24 is pingable. But traffic from the default router does not pass.

Deactivating both vmbr0 and eno1 (the relevant physical and virtual interfaces on the affected system) and reactivating doesn't bring connectivity beyond the /24 back.

There's nothing exciting in iptables.

Whatever this turns out to be is a good one...
 
Yep, it's a good one.

For some reason, my vmbr0 did not have the same HW address as eno1. Changing them to match (and hard setting it in the interfaces(.new) file worked.)

Looks like https://forum.proxmox.com/threads/pve-6-4-to-7-no-network-only-for-host.98198/post-425362 found the same thing

This probably has to do with OVH and their weird networking config - the changed HW address of vmbr0 confuses OVH's spoofing protections, as they limit the MAC addresses which can get out past their routers.
 
Last edited:
To block a MAC address from exiting your Debian network, you can use ebtables, a program that filters, logs, and forwards packets based on MAC addresses, similar to iptables but for Layer 2.

Here's how you can block traffic based on MAC address:

1. Install ebtables

sudo apt-get update
sudo apt-get install ebtables

2. Identify the Network Interface:
  • Determine the name of the network interface (e.g., eth0, wlan0, en0) that you want to block traffic on. You can use the command ip addr to list network interfaces and their addresses.
  • Find the MAC adress using the command ip -c link

3. Block the MAC Address:

  • Deny List: To block traffic from a specific MAC address, use the following command, replacing XX:XX:XX:XX:XX:XX with the MAC address you want to block and eth0 with your interface name:

sudo ebtables -A FORWARD -o eth0 -s XX:XX:XX:XX:XX:XX -j DROP

This rule will drop any traffic originating from the specified MAC address that is forwarded through the specified interface.

  • Allow List (Alternative): You can also create an allow list, where only specific MAC addresses are allowed. First, clear any existing rules:

sudo ebtables -F


Then, add rules to allow traffic from specific MAC addresses, and then drop all other traffic:


sudo ebtables -A FORWARD -o eth0 -s XX:XX:XX:XX:XX:XX -j ACCEPT
sudo ebtables -A FORWARD -o eth0 -j DROP


This will allow traffic from the specified MAC addresses and drop all others.


4. Persist the Changes:

  • To make the rules persistent across reboots, you can save them to a file and load them on startup. The exact method depends on your Debian distribution and how you manage firewall rules. Common methods include:
    • Using ebtables-save and ebtables-restore:

sudo ebtables-save > /etc/ebtables/rules.v
sudo ebtables-restore < /etc/ebtables/rules.v0


You can then add a line to your startup scripts to load these rules on boot.

  • Using a custom script: Create a script that runs the ebtables commands and place it in the appropriate startup directory (e.g., /etc/rc.local).


  • Bridged Interfaces:
    If you are using a bridged interface, you may need to use ebtables in the PREROUTING chain instead of the FORWARD chain.

  • Alternative Tools:
    While ebtables is a good tool for MAC filtering, you can also use other tools like iproute2 or nftables for more advanced network management.
 
Last edited:
because this is what I had to do to get around

"This probably has to do with OVH and their weird networking config - the changed HW address of vmbr0 confuses OVH's spoofing protections, as they limit the MAC addresses which can get out past their routers."
 
You must log in or register to reply here.
Top Bottom