Zwei OPNsense auf einem ProxmoxVE Host

[superwinni2]

Hallo

Ich habe hier folgende Konstellation:
Ich habe 2 Proxmox Hypervisoren. Auf jedem Hypervisor laufen 2 OPNsense VMs.
Hypervisor PMFW1:

• FW1
• FWInternBackup

Hypervisor PMFW2:

• FW2
• FWIntern

Die FW1 ist mit FW2 eine Hochverfügbare Firewall
Die FWIntern mit der FWInternBackup.
Durch die CARP Hochverfügbarkeit ist natürlich auch überall der Promiscuous Mode aktiviert.

Warum das ganze?:
Ich möchte eine Lastverteilung zwischen "Internet Traffic" und "Internem Traffic" haben.
Internet Traffic ist FW1 / FW2 und läuft somit über die Hardware PMFW1
Interner Traffic ist FWIntern / FWInternBackup und läuft somit über die Hardware PMFW2

Eigentlich sind die VMs ziemlich voneinander getrennt.
FW1 hat die VLANs 1,2,3,4,5,6,7,8
FWIntern hat die VLANs 1,102,103,104
Die anderen VLANs sind irgendwelche kleineren Netze für Maschinen, DMZ, Drucker oder ähnliche Dinge.

VLAN1 ist das wo Client und Server drin hängen.
VLAN7 wäre das Internet / WAN.

Das Problem ist hier das (gemeinsame) VLAN 1.
Beispiel:
Ein Client welcher ebenfalls in VLAN 1 ist surft im Internet. Pakete von Client zur FW1 werden sauber geswitched, landen bei der FW1. Dieser geht in Richtung Internet und schickt nun das Antwortpaket an den Client.
Der Client bekommt das Paket.
Nun wird es speziell...
Es kann vorkommen, dass zusätzlich auch die FWInternBackup das Paket mitbekommt!
Da diese das nun auch mitbekommt gibt es einen Eintrag in die FW Log
Oft wird solch etwas natürlich geblockt da es keine passende Regel gibt.
Allerdings schreibt mir der Spaß die Log Datei voll. Statt wenigen MB pro Tag bin ich nun bei 10-20 GB pro Tag.

Was ich mithilfe von Wireshark bemerkt habe:
Es handelt sich vermehrt um "Rückantworten". Sprich die FW senden einem Client ein Paket welches den Ursprung aus dem Internet hat. Nur selten sieht man ein Paket welches zur vom Client zur FW1 wollte.

Hat jemand eine Idee wie ich den Fehler eingrenzen kann?

 

[Falk R.]

Ob du das virtuell oder Physisch betreibst ist erst einmal egal.
Da würde ich mir mal die Carp Konfigurationen anschauen. Eigentlich sollte die interne FW nichts mitbekommen.
Eventuell hast du auch etwas extremes Logging aktiv?

Die beste Hilfe bekommst du sehr Wahrscheinlich im OPNsense Forum. Das ist auch sehr gut. Mir wurde da immer sehr schnell geholfen.

 

[superwinni2]

Ob du das virtuell oder Physisch betreibst ist erst einmal egal.
Da würde ich mir mal die Carp Konfigurationen anschauen. Eigentlich sollte die interne FW nichts mitbekommen.
Eventuell hast du auch etwas extremes Logging aktiv?

Das wäre auch meine Vermutung. Nur kann ich mir nicht erklären warum dem so ist.
Ich betreibe inzwischen eine ganze Hand voll OPNsensen. Das ist der einzige Standort an dem ich ich aufgrund der Last das trennen sollte.
In der Carp Konfiguration hat jede Carp IP (unternehmensweit) eine separate VHID bekommen.
Hatte hier Angst, dass bestimmte Mac Adressen dann doppelt vorkommen könnten. Bin aktuell bei insgesamt 37.

Eventuell hast du auch etwas extremes Logging aktiv?

Alles Standart.

Die beste Hilfe bekommst du sehr Wahrscheinlich im OPNsense Forum. Das ist auch sehr gut. Mir wurde da immer sehr schnell geholfen.

Leider nicht


Meine Aktuelle Vermutung ist, dass sich die Bridge nicht wirklich wie ein Switch sondern ein Hub verhaltet.
Testweise habe ich auch mal eine VM mit Kali Linux gestartet und via Wireshark mitgelauscht. Auch hier sieht die VM Traffic die die VM nichts angehen sollte.

Die Source Mac ist die FW1 auf VLAN1
Destination ist ein Client welcher ebenfalls im VLAN1 vertreten ist.

Nun habe ich eben gedacht ich schaue auf dem ProxmoxHost nach ob er die Mac-Adresse des Ziels kennt.
Daher habe ich ein

ip neigh | grep b4:45:06:5a:04:12

auf dem Host gemacht. Es kam, nichts zurück.
Dann habe ich gedacht ich pinge die IP Adresse 10.46.16.81 mal. In dem Moment hört der Traffic auf. Ebenfalls bekomme ich einen Eintrag für den obigen Befehl.
Somit sieht es für mich so aus, wie wenn der ProxmoxHost es einfach an alle Ports sendet da er nicht weiß wo sich die Mac Adresse befindet.
Wäre das nur kurz wäre es ja normal.
Dies habe ich eben mehrere Male nachprüfen können.

Ich habe mal einen kompletten ARP Scan mithilfe von

nmap -sn -PR 10.46.16.0/21

gemacht. Seitdem sehe ich sogar nur Multicast und bissel SpanningTreeProtocol Einträge.

Somit liegt es meiner Meinung nach daran, dass der Proxmox Switch keine MAC-Adressen lernen möchte oder so?!?
Zufällig eine Idee außer, dass ich regelmäßig das ganze Netzwerk scannen muss?

 

[superwinni2]

Das ganze hält auch nur eine kurze Begrenzte Zeit von ~ 290 Sekunden.
Ich habe es hier mal mit Wireshark Visualisiert indem ich den bekannten Traffic rausgenommen habe. Da wo es so gut wie gegen 0 geht habe ich den "nmap arp scan" gemacht.

 

[Bu66as]

Ja das ist klassisches Unknown-Unicast-Flooding auf der Linux Bridge. Deine Analyse stimmt, der Host kennt die Ziel-MAC nicht (mehr) und flutet das Paket an alle Ports auf dem VLAN.

Die 290 Sekunden passen zur Default Ageing Time der Bridge (300s). Check mal:

cat /sys/class/net/vmbr0/bridge/ageing_time

(Wert ist in Centisekunden, also 30000 = 300s)

Und ip neigh ist die ARP-Tabelle vom Host, nicht die Bridge FDB. Was du willst ist:

bridge fdb show | grep b4:45:06:5a:04:12

Da siehst du ob und auf welchem Port die Bridge die MAC gelernt hat.

Das Problem ist, dass FW1 und FWInternBackup sich auf PMFW1 das gleiche VLAN 1 teilen. Wenn die Bridge die MAC vom Ziel-Client nicht kennt (weil aged out), flutet sie an alle Ports auf dem VLAN, und durch Promiscuous Mode sieht FWInternBackup den ganzen Kram. Das bestätigt auch der nmap-Scan: Er zwingt alle Clients zu antworten, und die Bridge lernt alle MACs neu.

Du könntest die Ageing Time hochdrehen, z.B. auf 3600s:

ip link set vmbr0 type bridge ageing_time 360000

Aber sauberer wär's, wenn FWInternBackup auf VLAN 1 nicht am selben Bridge-Port hängt wie FW1. Oder du unterbindest das Flooding mit bridge link set dev <tap> flood off. Aber Vorsicht, CARP braucht noch Multicast.

Welche PVE-Version und Bridge-Config hast du (cat /etc/network/interfaces)?

 

[superwinni2]

Aging Time passt mit den 30000.
Allerdings finde ich die lösung länger laufender ARP Einträge auch nicht sonderlich schön.

root@pmfw1:~# cat /sys/class/net/vmbr001/bridge/ageing_time
30000

Das die Bridge aufgrund fehlender MAC/ARP Einträge das flooding macht ist mir bewusst. Was mich jedoch zusätzlich wundert ist, warum sie das so lange macht?
Wäre es mal hin und wieder einmal kurz bis die MAC Adresse gelernt worden wäre, wäre das meiner Meinung nach kein Problem. Aber es bleibt ja über Minuten/Stunden/Tage so. Ich habe bisher immer gedacht, dass der Switch das beim ersten Paket nicht kennt, daher flooded aber entsprechend zügig irgendwie mitbekommt das die MAC dann hinter "Port" X steckt und dann den Verkehr nur noch da hin sendet. Der Client hat mit seiner MAC Adresse ja wenige (Milli-)Sekunden vorher mit der MAC Adresse Daten an die FW1 gesendet.


Proxmox ist komplett aktuell:

Spoiler: PVEVersion

root@pmibm:~# pveversion
pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.6-2-pve)
root@pmibm:~# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
pve-manager: 9.2.2 (running version: 9.2.2/b9984c6d90a4bd80)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.6-2
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
proxmox-kernel-6.17: 6.17.13-13
proxmox-kernel-6.17.13-13-pve-signed: 6.17.13-13
proxmox-kernel-6.17.13-11-pve-signed: 6.17.13-11
proxmox-kernel-6.17.13-9-pve-signed: 6.17.13-9
ceph-fuse: 19.2.3-pve4
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.5
libpve-cluster-perl: 9.1.5
libpve-common-perl: 9.1.12
libpve-guest-common-perl: 6.0.3
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.5
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.5
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.0-1
proxmox-backup-file-restore: 4.2.0-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.3
pve-cluster: 9.1.5
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.7.4
pve-qemu-kvm: 11.0.0-3
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.15
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1

Zur Interfaces Datei.
Diese habe ich aufgrund der komplexität etwas gekürzt.
Ich habe insgesamt 18 VLANs auf dem Host welche sich auch nur an meine Anfangs-Beschreibung anlehnen.
Daher habe ich viele der unnötigen VLANs einfach mal weg gelassen. Sie sehen jedoch gleich aus wie die anderen -> Nur eine andere VLAN Tag ID.
vmbr000 (enp27s0f0) ist eine separate Kupfer Verbindung zwischen der FW1 und FW2 für den Statesync der OPNsense.
Bei FWIntern und FWInternBackup mache ich dies via Unicast über die VLAN1 IP Adresse.
Der Rest läuft über das Interface enp27s0f1.

Spoiler: /etc/network/interfaces

root@pmfw1:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp27s0f0 inet manual

iface enp27s0f1 inet manual

iface enx9abe942b0381 inet manual

iface eno2 inet manual

iface eno3 inet manual

iface eno4 inet manual

iface eno5 inet manual


auto vmbr000
iface vmbr000 inet manual
bridge-ports enp27s0f1
bridge-stp off
bridge-fd 0
#ClusterLink

auto vmbr001
iface vmbr001 inet static
address 10.46.20.116/21
gateway 10.46.23.2
bridge-ports enp27s0f0
bridge-stp off
bridge-fd 0
#SERVER VLAN0

auto vmbr020
iface vmbr020 inet manual
bridge-ports enp27s0f0.20
bridge-stp off
bridge-fd 0
#BUVERP VLAN20

auto vmbr031
iface vmbr031 inet manual
bridge-ports enp27s0f0.31
bridge-stp off
bridge-fd 0
#MGMT2 VLAN31

auto vmbr045
iface vmbr045 inet manual
bridge-ports enp27s0f0.45
bridge-stp off
bridge-fd 0
#Solar VLAN45

auto vmbr073
iface vmbr073 inet manual
bridge-ports enp27s0f0.73
bridge-stp off
bridge-fd 0
#Telekom VLAN73

auto vmbr099
iface vmbr099 inet manual
bridge-ports enp27s0f0.99
bridge-stp off
bridge-fd 0
#GAST VLAN99

source /etc/network/interfaces.d/*

Unter /etc/network/interfaces.d/ liegt nur eine Datei "sdn" welche jedoch leer ist.

Aber sauberer wär's, wenn FWInternBackup auf VLAN 1 nicht am selben Bridge-Port hängt wie FW1.

Wie kann ich das anstellen? Einfach eine weitere Bridge machen die ebenfalls "bridge-ports enp27s0f0" eingetragen hat?
Ich möchte ungerne einen weiteren Port an meinem Physikalischen Switch belegen.

 

[Bu66as]

Dass das Flooding nicht nur kurz sondern dauerhaft auftritt ist schon komisch. Normalerweise lernt die Bridge die MAC ja beim nächsten Paket vom Client (ACK zurück etc.) sofort wieder. Check mal wie voll die FDB überhaupt ist:

bridge fdb show br vmbr001 | wc -l
cat /sys/class/net/vmbr001/bridge/hash_max

Default hash_max ist 512. Bei deinem /21er Netz mit vielen Clients überläuft die FDB-Tabelle schnell und Einträge fliegen schneller raus als die Ageing Time vorgibt. Wenn die Zahl der gelernten MACs in die Nähe von hash_max kommt, wärs das. Kannst du hochsetzen mit echo 4096 > /sys/class/net/vmbr001/bridge/hash_max.

Zu der Frage mit der zweiten Bridge: Nein, ein physisches Interface kann unter Linux nur in einer Bridge sein, das geht nicht. Aber brauchst du auch nicht. Die sauberste Lösung ohne extra Switch-Port ist flood off auf dem tap-Device der FWInternBackup, das hatte ich schon kurz angerissen.

# Rausfinden welches tap die FWInternBackup auf vmbr001 hat:
bridge link show | grep vmbr001

# Flooding abschalten:
bridge link set dev tapXXXi0 flood off

Damit kriegt die FWInternBackup keinen Unknown-Unicast mehr, Broadcast (ARP) und Multicast (CARP) kommen weiterhin durch. Problem: Das tap wird bei VM-Restart neu erstellt. Dafür ein Hookscript an die VM hängen:

#!/bin/bash
# /var/lib/vz/snippets/flood-off.sh
vmid=$1
phase=$2
if [ "$phase" == "post-start" ]; then
    sleep 2
    for tap in $(bridge link show | grep vmbr001 | grep "tap${vmid}" | awk '{print $2}' | tr -d ':'); do
        bridge link set dev "$tap" flood off
    done
fi

Dann qm set <vmid> --hookscript local:snippets/flood-off.sh und das bleibt auch nach Reboot aktiv.

 

[superwinni2]

Die FDB hat zwar einträge, jedoch noch lange in im Max bereich:

root@pmfw1:~# bridge fdb show br vmbr001 | wc -l
437
root@pmfw1:~# cat /sys/class/net/vmbr001/bridge/hash_max
4096

Das Deaktivieren des floodings wäre vermutlich der Workaround wenn nichts anderes funktioniert.

Sonst noch eine Idee?

 

[Bu66as]

FDB-Overflow ist raus, gut. Dann müssen wir rausfinden warum die Bridge die MACs nicht dauerhaft lernt. Wenn das Flooding gerade aktiv ist, check mal ob die betroffene Client-MAC überhaupt in der FDB steht:

bridge fdb show br vmbr001 | grep b4:45:06:5a:04:12

Und dann die Port-Flags prüfen:

bridge -d link show master vmbr001

Da muss bei allen Ports learning on stehen, besonders auf enp27s0f0. Wenn das off ist, lernt die Bridge nix vom physischen Netz und flutet dauerhaft.

Live kannst du mit bridge monitor fdb zuschauen ob Einträge reinkommen und sofort wieder verschwinden, das wär ein Hinweis auf MAC-Flapping. Auch dmesg | grep -i moved hilft oft weiter.

Noch ne Sache: ist br_netfilter geladen? (lsmod | grep br_netfilter) Das Modul kann zu unerwarteten Problemen führen.

 

[Bob.Dig]

Nur aus Neugierde, wie geht das überhaupt mit dem Routing im gemeinsamen VLAN1? Normalerweise kann man keine zwei Router gleichzeitig benutzen.

 

[superwinni2]

@Bu66as
MAC Adressen stehen (manchmal) in der FDB Datenbank.
MAC learning ist überall auf "on". Zur besseren Auffindbarkeit mit "____":

5:enp27s0f0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr001 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off    ____learning on____ flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress off vlan_tunnel off isolated off locked off mab off mcast_n_groups 17 mcast_max_groups 0
44:tap100i0:<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master vmbr001 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off ____learning on____ flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress off vlan_tunnel off isolated off locked off mab off mcast_n_groups 0 mcast_max_groups 0
93:tap101i1:<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master vmbr001 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off ____learning on____ flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress off vlan_tunnel off isolated off locked off mab off mcast_n_groups 0 mcast_max_groups 0
102:tap102i0:<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master vmbr001 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off ____learning on____ flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress off vlan_tunnel off isolated off locked off mab off mcast_n_groups 0 mcast_max_groups 0

Einfach auch für die Nachwelt falls jemand es auch bequemer suchen möchte:

Ich habe mithilfe von

bridge -t monitor fdb >> /tmp/bridge.log

jeden Monitor Eintrag in eine Datei umgeleitet. Während das dann im Hintergrund lief habe ich mithilfe von

tail -f -n+1 /tmp/bridge.log  |egrep -B1 -e '(MAC-ADRESSE)'

mir die Einträge zur MAC Adresse ausgeben lassen. So könnte man das dann auch nachträglich auswerten und jede MAC-Adresse einzeln anschauen.

Ich habe mir nun paar mal immer wieder eine MAC rausgenommen und beobachtet:
Ein schönes Ergebnis bekomme ich wenn ich die MAC Adresse vom AdGuard (Public DNS Resolver) nehme. Das Teil ist ständig mit Netzwerktraffic unterwegs. Vor allem Tagsüber. Redet daher ständig mit der FW1 und sollte daher auch einen "Dauereintrag" in der FDB haben.

Spoiler: Bridge Monitoring Einträge

root@pmfw1:~# tail -f -n+1 /tmp/bridge.log |egrep -B1 -e '(bc:24:11:5c:7d:54)'
Timestamp: Thu Jun 11 11:52:26 2026 214144 usec
Deleted bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001 stale
--
Timestamp: Thu Jun 11 12:07:21 2026 999867 usec
bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001
--
Timestamp: Thu Jun 11 12:12:51 2026 302058 usec
Deleted bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001 stale
--
Timestamp: Thu Jun 11 12:27:17 2026 999705 usec
bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001
--
Timestamp: Thu Jun 11 12:32:18 2026 278050 usec
Deleted bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001 stale
--
Timestamp: Thu Jun 11 12:47:13 2026 999672 usec
bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001
--
Timestamp: Thu Jun 11 12:52:14 2026 310127 usec
Deleted bc:24:11:5c:7d:54 dev enp27s0f0 master vmbr001 stale

Man sieht:
Nach ~300 Sekunden (5 Minuten) wird gelöscht.
Nach ~900 Sekunden ( 15 Minuten ) wird er wieder aufgenommen
Das dann im Kreis...
Solange der Eintag nicht existiert wird natürlich geflooded und die FWInternBackup bekommt es mit.


Ich habe das mal mit Wireshark rausgefiltert und entsprechend die Einträge miteinander verbunden:



Das Modul br_netfilter ist nicht geladen.

Spoiler: lsmod | sort

root@pmfw1:~# lsmod |sort
8021q 49152 0
acpi_ipmi 20480 0
aesni_intel 94208 0
autofs4 57344 2
binfmt_misc 24576 1
bonding 253952 0
btrfs 2154496 0
cdc_ether 28672 0
coretemp 20480 0
dca 20480 3 igb,ioatdma,ixgbe
dm_bio_prison 24576 1 dm_thin_pool
dm_bufio 57344 2 dm_persistent_data,dm_snapshot
dmi_sysfs 20480 0
dm_persistent_data 118784 1 dm_thin_pool
dm_snapshot 65536 0
dm_thin_pool 94208 6
ebtable_filter 12288 0
ebtables 45056 1 ebtable_filter
efi_pstore 12288 0
ehci_hcd 102400 1 ehci_pci
ehci_pci 16384 0
garp 20480 1 8021q
ghash_clmulni_intel 12288 0
i2c_algo_bit 16384 2 igb,mgag200
ics932s401 16384 0
igb 311296 0
inet_diag 20480 1 tcp_diag
intel_cstate 20480 0
intel_powerclamp 24576 0
intel_rapl_common 49152 1 intel_rapl_msr
intel_rapl_msr 20480 0
ioatdma 73728 0
ip6table_filter 12288 0
ip6table_raw 12288 0
ip6_tables 32768 2 ip6table_filter,ip6table_raw
ipmi_devintf 20480 0
ipmi_msghandler 86016 4 ipmi_devintf,ipmi_si,acpi_ipmi,ipmi_ssif
ipmi_si 86016 1
ipmi_ssif 45056 0
ip_set 61440 0
iptable_filter 12288 0
iptable_raw 12288 0
ip_tables 32768 2 iptable_filter,iptable_raw
irqbypass 16384 1 kvm
ixgbe 532480 0
kvm 1441792 15 kvm_intel
kvm_intel 507904 20
libblake2b 20480 1 btrfs
libie_fwlog 28672 1 ixgbe
lpc_ich 28672 0
mac_hid 12288 0
mdio 12288 1 ixgbe
megaraid_sas 196608 5
mgag200 73728 0
mii 20480 1 usbnet
Module Size Used by
mrp 24576 1 8021q
nfnetlink 20480 5 nf_tables,ip_set,nfnetlink_log
nfnetlink_log 24576 1
nf_tables 372736 0
pcspkr 12288 0
raid6_pq 122880 1 btrfs
rapl 20480 0
sb_edac 32768 0
sch_fq_codel 28672 52
softdog 12288 2
spl 151552 1 zfs
sunrpc 815104 1
tap 32768 1 vhost_net
tcp_diag 20480 0
tls 147456 1 bonding
usbnet 65536 1 cdc_ether
veth 40960 0
vhost 69632 1 vhost_net
vhost_iotlb 16384 1 vhost
vhost_net 36864 49
wmi 36864 0
x86_pkg_temp_thermal 16384 0
xfrm_algo 16384 1 ixgbe
xor 24576 1 btrfs
x_tables 61440 7 ebtables,ip6table_filter,ip6table_raw,iptable_filter,ip6_tables,iptable_raw,ip_tables
zfs 6258688 6

 

[superwinni2]

Nur aus Neugierde, wie geht das überhaupt mit dem Routing im gemeinsamen VLAN1? Normalerweise kann man keine zwei Router gleichzeitig benutzen.

Gleichzeitig nutzen kann man diese schon. Kommt eben ein bisschen aufs Routing an.
So kann man mithilfe von Routen festlegen, dass

• wenn man auf das Netzwerk / VLAN 1,2,3,4,5,6,7,8 möchte, dass man als Router / Gateway die FW1 nutzen möchte.
• wenn man auf das Netzwerk / VLAN 1,102,103,104 möchte, dass man als Router / Gateway die FWIntern nutzen möchte.

Routentabelle Beispiel mit einem Client welcher sich in VLAN1 befindet.
(Ich habe diese eben aus dem Kopf runter geschrieben da das produktiv bei mir noch komplizierter ist. Daher kann es zu Ungenauigkeiten kommen.)

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle 
          0.0.0.0          0.0.0.0        10.46.1.1       10.46.1.230     Wenn nichts spezifischeres angegeben nehme FW1
        10.46.2.0    255.255.255.0        10.46.1.1       10.46.1.230    VLAN 2 über FW1    
        10.46.3.0    255.255.255.0        10.46.1.1       10.46.1.230    VLAN 3 über FW1    
        10.46.4.0    255.255.255.0        10.46.1.1       10.46.1.230    VLAN 4 über FW1    
      10.46.102.0    255.255.255.0        10.46.1.4       10.46.1.230    VLAN 102 über FWIntern    
      10.46.103.0    255.255.255.0        10.46.1.4       10.46.1.230    VLAN 103 über FWIntern    
      10.46.104.0    255.255.255.0        10.46.1.4       10.46.1.230    VLAN 104 über FWIntern    
      10.46.1.255  255.255.255.255   Auf Verbindung       10.46.1.230    VLAN 1 ohne Routing da gleiches Netz    
        10.46.1.0    255.255.255.0   Auf Verbindung       10.46.1.230        
      10.46.1.230  255.255.255.255   Auf Verbindung       10.46.1.230        
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1        
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1        
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1        
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1        
        224.0.0.0        240.0.0.0   Auf Verbindung       10.46.1.230        
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1        
  255.255.255.255  255.255.255.255   Auf Verbindung       10.46.1.230        
===========================================================================
Ständige Routen:
  Keine

Theoretisch und auch praktisch kann man die Einträge für 10.46.2.0, 10.46.3.0, 10.46.4.0 auch weglassen, da dies über das Default Gateway abgedeckt ist.

So habe ich dann in der FW1 eingestellt, dass die IP-Bereiche von VLAN 102,103 und 104 erreichbar sind indem man mit dem Router FWIntern spricht.
Bei der FWIntern ist eingestellt, dass die IP-Bereiche von VLAN 2-8 (VLAN 1 braucht er nicht da er da selbst drin ist) über die FW1 erreichbar sind.

 

[Bu66as]

Sehr schönes Debugging. Das Muster ist jetzt klar: MAC wird nach 300s gelöscht, erst ~10min später neu gelernt.

Die Bridge lernt nur aus der SOURCE-MAC eingehender Frames. Dein AdGuard redet hauptsächlich mit Clients die am selben physischen Switch hängen, der Switch wickelt das L2-mäßig selber ab. Die Bridge auf dem PVE-Host sieht die AdGuard-MAC nur bei direktem Verkehr zwischen AdGuard und VMs, z.B. bei DNS-Queries zu FW1. Mit gutem Cache kann das locker 10-15min dauern und passt zu deinem Muster.

Kannst du gegenprüfen:

tcpdump -nei enp27s0f0 ether src bc:24:11:5c:7d:54

Wette das kommen deutlich weniger Frames rein als du denkst.

Dann ist flood off auf dem tap der FWInternBackup die saubere Lösung für diese Topologie. Zwei Firewalls am gleichen VLAN auf einer Bridge, eine davon promisc, da wurst du immer Flooding haben sobald MACs altern. Das ist halt wie Bridges funktionieren, wenn Source-Frames zu selten reinkommen. Mit Ageing Time oder hash_max wird das nicht besser, solange manche Geräte selten genug direkt mit dem Host reden.

 

[superwinni2]

Sehr schönes Debugging.

Danke

Wette das kommen deutlich weniger Frames rein als du denkst

Wette hast du gewonnen Und ich glaube das war der entsprechende Schuss damit ich es verstanden habe.

Ich bin eben auf den Gedanken gekommen, dass ja der AdGuard auch viel mit dem Internet und somit mit der FW1 spricht.
Jedoch spricht der AdGuard nicht ganz direkt mit der FW1.

Es sieht so aus:
Adguard -> IBM CoreSwitch (welcher aus historischen Gründen ebenfalls Routet und als Default Gateway bei vielen Geräten eingetragen ist) -> FW1 -> Internet Router -> Internet

Durch das (zusätzliche) Routing am Coreswitch kommen die MAC-Adressen vom Coreswitch an dem Interface enp27s0f0 vom Proxmox an und nicht die des Clients. Daher wird die MAC auch nicht in die FDB eingetragen und daher wird dann geflooded.

Alle ~900 Sekunden sendet der AdGuard vermutlich irgendeine (Broad- oder Multicast) Nachricht durch die Gegend. Da diese an das Interface bzw. die Bridge geht trägt diese es in die FDB ein. Dann ist mal für ~300 Sekunden die Welt in Ordnung bis es wieder gelöscht wird.

Ich glaube die schlauere und endgültige Lösung wird sein, den Coreswitch nur noch Layer 2 machen zu lassen und die beiden OPNsensen kümmern sich um Layer 3 bzw. das Routing. Dann wäre auch der nächste Schritt Richtung Netztrennung da.

Zwei Firewalls am gleichen VLAN auf einer Bridge, eine davon promisc

Beide Firewalls sind im Promisc Mode.
Da die FWinternBackup jedoch nur Backup ist und nicht wirklich was raussendet gibt es hier eine Verzerrung der Wahrnehmung.