Proxmox claiming MAC address

HellBz · Sep 14, 2021

I got 3 VMS and i fixed after many hours all with this Script, because Proxmox Claim MAC's fom Network.

I simply set the Main-Mac to all tap-Instances
With Crontab i execute this script every Minute and its logging changes
If anyone change something in Network of VMS, it creates a new tap-Instance and my script set this back to the correct MAC

Hope, this help everyone

Code:

#/home/mac-fixer.sh
#!/bin/bash

tap100=$(ip addr show tap100i0 | grep "link/ether" | awk '{print $2}' | cut -d/ -f1)
if [ $tap100 != "MY:AW:SO:ME:AD:RR" ]
then
   echo "tap100 is NOT MY:AW:SO:ME:AD:RR CHANGING NOW"
   echo [$(date +"%d.%m.%Y-%H:%M:%S")][tap100] Set Mac to MY:AW:SO:ME:AD:RR  >> mac-fix.log
   ip link set dev tap100i0 down
   ip link set dev tap100i0 address MY:AW:SO:ME:AD:RR
   ip link set dev tap100i0 up
else
   echo "tap100 is MY:AW:SO:ME:AD:RR"
fi


tap200=$(ip addr show tap200i0 | grep "link/ether" | awk '{print $2}' | cut -d/ -f1);
if [ $tap200 != "MY:AW:SO:ME:AD:RR" ]
then
   echo "tap200 is NOT MY:AW:SO:ME:AD:RR CHANGING NOW"
   echo [$(date +"%d.%m.%Y-%H:%M:%S")][tap200] Set Mac to MY:AW:SO:ME:AD:RR  >> mac-fix.log
   ip link set dev tap200i0 down
   ip link set dev tap200i0 address MY:AW:SO:ME:AD:RR
   ip link set dev tap200i0 up
else
   echo "tap200 is MY:AW:SO:ME:AD:RR"
fi


tap500=$(ip addr show tap500i0 | grep "link/ether" | awk '{print $2}' | cut -d/ -f1);
if [ $tap500 != "MY:AW:SO:ME:AD:RR" ]
then
   echo "tap500 is NOT MY:AW:SO:ME:AD:RR CHANGING NOW"
   echo [$(date +"%d.%m.%Y-%H:%M:%S")][tap500] Set Mac to MY:AW:SO:ME:AD:RR  >> mac-fix.log
   ip link set dev tap500i0 down
   ip link set dev tap500i0 address MY:AW:SO:ME:AD:RR
   ip link set dev tap500i0 up
else
   echo "tap500 is MY:AW:SO:ME:AD:RR"
fi

@proxmox-Team
Best will be, if is possible to define static-MAC's for the tap-Instances

spirit · Sep 14, 2021

@HellBz

I'm not sure you have the same problem, do you also use pve-firewall ?
What kind of packets do you see coming from tap wrong mac interface ?

spirit · Sep 14, 2021

@HellBz

tap mac shouldn't be same than mac inside the guest,
if not, you'll have kernel messages like

"received packet on tap100i0 with own address as source address ..."

see:
https://bugzilla.redhat.com/show_bug.cgi?id=798467

thommie · Sep 15, 2021

@proxmox Team: aside from the workarounds presented here: doesnt't this qualify for a general solution (patch) in PVE as there are a number of affected customers with running PVE servers on Hetzner? I am surprised that this thread dates back to 2019 and there still is no "real" solution (at least it looks like that) ...

tafkaz · Sep 15, 2021

That'd be completely desirable!
Thanks
Sascha

AI-Daniel · Sep 17, 2021

Hi,
we have the same issue, icluding an abuse message from hetzner.
I just installed the update for the pve-firewall from Post #59, now i'm waitng for the next hetzner check.

Greetings Daniel

Edit: Hetzner closed the ticket, everyfing seems to be fine

redroom · Sep 17, 2021

AI-Daniel said:
Hi,
we have the same issue, icluding an abuse message from hetzner.
I just installed the update for the pve-firewall from Post #59, now i'm waitng for the next hetzner check.

Greetings Daniel

Edit: Hetzner closed the ticket, everyfing seems to be fine

it it possible to install this update without subscription?

spirit · Sep 18, 2021

redroom said:
it it possible to install this update without subscription?

yes, it's already available in non subscription repo
http://download.proxmox.com/debian/...ion/binary-amd64/pve-firewall_4.2-3_amd64.deb

All packages between non-subscription && enterprise are same.

arhimede · Sep 18, 2021

spirit said:
yes, it's already available in non subscription repo
http://download.proxmox.com/debian/...ion/binary-amd64/pve-firewall_4.2-3_amd64.deb

All packages between non-subscription && enterprise are same.

Can this be available for Proxmox 6.4 too ?

The above package is for Proxmox 7

spirit · Sep 20, 2021

arhimede said:
Can this be available for Proxmox 6.4 too ?

I have asked to pve-devel mailing list, but maybe can you requesit it yourself ? (pve-user, proxmox bugzilla, ...)

arhimede said:
The above package is for Proxmox 7

"maybe" it could work, I don't have checked the dependencies.

you can hack yourself if you want, it's only 2 lines removal.

https://git.proxmox.com/?p=pve-fire...;hpb=dcdbb559323c132897426073391ed18a838df024

I think if a new version is coming later, the patch will be included.

redroom · Sep 20, 2021

spirit said:
I have asked to pve-devel mailing list, but maybe can you requesit it yourself ? (pve-user, proxmox bugzilla, ...)

"maybe" it could work, I don't have checked the dependencies.

you can hack yourself if you want, it's only 2 lines removal.

https://git.proxmox.com/?p=pve-fire...;hpb=dcdbb559323c132897426073391ed18a838df024

I think if a new version is coming later, the patch will be included.

thanks, it looks like an easy fix

tafkaz · Sep 21, 2021

AI-Daniel said:
Hi,
we have the same issue, icluding an abuse message from hetzner.
I just installed the update for the pve-firewall from Post #59, now i'm waitng for the next hetzner check.

Greetings Daniel

Edit: Hetzner closed the ticket, everyfing seems to be fine

Hi,
so just upgrading Proxmox to 7 and making sure pve-firewall 4.2-3 is installed will fix the issues with Hetzner, you think?
Or do i still need to add some firewall drop then?
Thanks
Sascha

thommie · Sep 22, 2021

I ran into an ugly problem during upgrade PVE 6.4 > 7 and following https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0, I first upgraded ifupdown >> ifupdown2 on the 6.4 and debian 10. The package update failed somehow which resulted in an inaccessible server. The whole networking including the primary network card and vmbr's was down. The only way to access it was with an external console (Hetzner KVM Konsole). The fix was a manual dpkg re-installation of ifupdown2.

But, on the other hand, it looks as if already the update to ifupdown2 helps. The big switch to debian 11 and PVE 7 can be done in a second step.

Thommie

MarvinE · Sep 22, 2021

Hello,

we have the same trouble, I tried a lot to drop the traffic with iptables and ebtabels every times the solve check from hetzner results in ok, but after some days the problem war’s back with new MACs.

Now, I fixed it by activating the hetzner firewall (in robot) and replaced the default „allow all rule“ with rules to only allow our static IPs as destination. It seams to be fine, also the inbound traffic (tcpdump ether host MAC) seams to be droped directly by hetzner.

thommie · Sep 22, 2021

MarvinE said:
Hello,

we have the same trouble, I tried a lot to drop the traffic with iptables and ebtabels every times the solve check from hetzner results in ok, but after some days the problem war’s back with new MACs.

Now, I fixed it by activating the hetzner firewall (in robot) and replaced the default „allow all rule“ with rules to only allow our static IPs as destination. It seams to be fine, also the inbound traffic (tcpdump ether host MAC) seams to be droped directly by hetzner.

In my case the update to Debian Bullseye 11 and PVE 7.0.11 is now finished. According to Hetzner staff the MAC problem is solved.

Would be nice if we can see a statement from proxmox guys here. This bug is causing big trouble when using PVE 6.x in a hosted environment.

spirit · Sep 22, 2021

MarvinE said:
Now, I fixed it by activating the hetzner firewall (in robot) and replaced the default „allow all rule“ with rules to only allow our static IPs as destination. It seams to be fine, also the inbound traffic (tcpdump ether host MAC) seams to be droped directly by hetzner.

Great to known that ti's possible to configure it. I think it should really be done for any hetzner bridged setup.
(I still don't understand why they don't filter it by default ...)

I'm currently working on a final solution to avoid bad traffic coming inside the server, with disabling promiscuous mode, and configure static macs on vmbrX bridge. should be done in 1 or 2 week.

symv · Sep 23, 2021

MarvinE said:
Hello,

we have the same trouble, I tried a lot to drop the traffic with iptables and ebtabels every times the solve check from hetzner results in ok, but after some days the problem war’s back with new MACs.

Now, I fixed it by activating the hetzner firewall (in robot) and replaced the default „allow all rule“ with rules to only allow our static IPs as destination. It seams to be fine, also the inbound traffic (tcpdump ether host MAC) seams to be droped directly by hetzner.

Can you share screen with your rules in Robot Firewall?

MarvinE · Sep 23, 2021

symv said:
Can you share screen with your rules in Robot Firewall?

It's very simple, I created a screenshot replace <Your IP 1 - 5> with your public IP that you can find at the first tab "IPs". The name filed is irrelevant choose everything that describe your rule.

openaspace · Sep 26, 2021

MarvinE said:
It's very simple, I created a screenshot replace <Your IP 1 - 5> with your public IP that you can find at the first tab "IPs". The name filed is irrelevant choose everything that describe your rule.

Hi. thank you for sharing.
Only incoming rules? outgoing are not necessary?

This solution is still working over days and weeks?

Thank you.

openaspace · Sep 26, 2021

MarvinE said:
It's very simple, I created a screenshot replace <Your IP 1 - 5> with your public IP that you can find at the first tab "IPs". The name filed is irrelevant choose everything that describe your rule.

Please let me know if this solution is still working for you!

Thank you!

Proxmox claiming MAC address

New Member

Distinguished Member

Distinguished Member

Member

Renowned Member

New Member

New Member

Distinguished Member

Member

Distinguished Member

New Member

Renowned Member

Member

Active Member

Member

Distinguished Member

New Member

Active Member

Attachments

Active Member

Active Member