Block incoming ARP requests if destination ip is not part of ipfilter-net[n]

[linushstge]

Hey there,

on a large PVE cluster all vms are flooded with many ARP Requests.
(PVE 8.1.10 / Linux 6.5.13-3-pve)

tcpdump -ennqti any arp

ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46
ens18 B   ifindex 2 88:30:37 Request who-has <redacted> tell <router-ip>, length 46

With the implementation of ebtables the replies are filtered correctly to prevent ARP spoofing:

ebtables --list

Bridge chain: tap25272i0-OUT, entries: 3, policy: ACCEPT
-s ! <vm-mac-address> -j DROP
-p ARP -j tap25272i0-OUT-ARP
-j ACCEPT

Bridge chain: tap25272i0-OUT-ARP, entries: 2, policy: ACCEPT
-p ARP --arp-ip-src <vm-ipv4> -j RETURN
-j DROP

Goal:
How can another chain implemented to also filter incoming ARP requests that the VM only gets the ARP request for itself instead of only replies to ARP requests for itself?

If a custom chain is created for a tap device, the chain will be removed after seconds.

For example, if I try to block all incoming ARP requests at all:

ebtables --new-chain tap25272i0-IN
ebtables --append tap25272i0-IN -p ARP -j DROP

The chain is created successfully but removed after some seconds.

Are there any plans to integrate Inbound filtering of ARP requests to ebtables in proxmox by default?

Other related topics:
- Filter ARP replies (not requests) (https://forum.proxmox.com/threads/filter-arp.34973)
- Proxmox Docs (Disable Bridge Mac Learning) (https://pve.proxmox.com/wiki/Network_Configuration)

 

[linushstge]

After some testing, figured out by myself.
The default Proxmox ebtables look like the following:

ebtables --list
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 1, policy: ACCEPT
-j PVEFW-FORWARD

Proxmox does not insert rules directly to the FORWARD chain to support custom rules (thank you so much), because the PVEFW-FORWARD chain is maintained by PVE and is modified dynamically.

Custom rules can be prepended to the FORWARD chain to prevent any conflicts with PVE dynamic chain:

ebtables -I FORWARD 1 -i fwln<vmid>i<port> -p ARP --arp-ip-dst ! <target-ip> -j DROP

# example:
ebtables -I FORWARD 1 -i fwln25272i0 -p ARP --arp-ip-dst ! 1.2.3.4 -j DROP

This rule drops any ARP requests which are broadcasted to the bridge out device before reaching the tap device.

ebtables --list
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-p ARP -i fwln25272i0 --arp-ip-dst ! 1.2.3.4 -j DROP
-j PVEFW-FORWARD

@ Proxmox:
I would really appreciate it if this rule could be part of the default ARP filter to prevent incoming ARP Broadcast flooding to each vm. In the current implementation of the ipfilter-netX ARP-OUT rule, replies are only allowed if the ipfilter-netX ip is matching anyway.

Bugzilla Feature Request (5351)

 

[YsztyKox]

What is <port> and how to get this value? Is it index of NIC attached to VM?
Best regards

 

[linushstge]

What is <port> and how to get this value? Is it index of NIC attached to VM?

Yes, its the netX Index which you can find in the hardware section of any vm.
From shell you can use qm config <vmid> | grep "net" .

I'm currently working on a contribution to support incoming ARP request filters natively based on the ipfilter-netX groups, which already filters ARP replies. (More Information)

If you would like to allow multiple IP destinations for your ARP requests, you should consider creating an own chain for each of your ports like:

1. create a dedicated chain which contain all allowed IP addresses with a default policy DROP:

ebtables --new-chain fwln100i0-IN-ARP -P DROP

2. Insert all allowed IPs / subnets into the new ARP Request filter chain:

ebtables -I fwln100i0-IN-ARP -p ARP --arp-ip-dst 1.2.3.4 -j RETURN
ebtables -I fwln100i0-IN-ARP -p ARP --arp-ip-dst 1.2.3.5 -j RETURN
ebtables -I fwln100i0-IN-ARP -p ARP --arp-ip-dst 1.2.3.6 -j RETURN

3. Install the new ARP IN chain into the FORWARD chain (at the beginning):

ebtables -I FORWARD 1 -p ARP -i fwln100i0 -j fwln100i0-IN-ARP