Datacenter Firewall enable (cluster), nur für einen Host?

[itNGO]

Hallo zusammen,

vielleicht kann mich jemand erleuchten.
Ich möchte nachträglich auf einem 3-Node-Cluster die Firewall aktivieren.
Um das einigermassen problemlos zu testen, habe ich einen Node geräumt und bei den anderen beiden in den Firewall-Options die Firewall auf "NO" gestellt.

Wenn ich jetzt den Schalter für die Firewall auf "yes" umlege im Datacenter-Bereich, wird die Firewall dann nur für den leeren Node aktiviert oder ändert Proxmox den Schalter für die beiden anderen Nodes dann auch auf yes.

Ich meine was gelesen zu haben das genau sowas passiert seinsoll?

PVE 8.1.10....

Danke für sachdienliche Hinweise....

 

[shanreich]

Die Firewall sollte dann nur auf den Hosts aktiviert sein auf denen auch tatsächlich in den Optionen die Firewall aktiv ist.

 

[itNGO]

Die Firewall sollte dann nur auf den Hosts aktiviert sein auf denen auch tatsächlich in den Optionen die Firewall aktiv ist.

Würde ich auch so meinen, wir haben das grad mal getestet. Es hat keine 5 Minuten gedauert bis erste Beschwerden kamen. Die Firewall ist im Datacenter und auf einem Host auf enabled, auf keiner VM.

Trotzdem kam es direkt zu Unterbrechungen auf VMs auf den anderen Hosts.
Wo setze ich an?

 

[shanreich]

Ist, die Firewall u.U. auf VM-Ebene aktiviert?

 

[itNGO]

Ist, die Firewall u.U. auf VM-Ebene aktiviert?

Hi,
nein war nicht auf VM-Ebene aktiviert. Aber generell scheint das Aktivieren/Deaktivieren in der Firewall auf Datacenter-Ebene einen "hicks" zu erzeugen. Das mag bei wenigen VMs/Usern gar nicht auffallen, aber wenn ordentlich was los ist, dann wohl schon.

Noch mal zum Verständniss. Wenn die Option Firewall auf einer VM "aus" ist, dann ist egal was Datacenter/Host eingestellt haben, es ist für die VM irrelevant?

 

[shanreich]

Die Einstellung auf Datacenter-Ebene ist global, d.h. wenn diese auf 'Aus' ist, dann ist gar keine Firewall für irgendeinen Host / VM aktiviert (auch wenn sie dort auf 'Ein' ist).

Wenn sie auf DC-Ebene aktiv ist, dann gelten die Regeln auf Datacenter-Ebene (für die Hosts!). Die Host-Firewall sollte keinen Einfluss haben auf VMs, d.h. wenn ich auf Host-Ebene bestimmten Traffic blockiere, dann können VMs immer noch diesen Traffic erhalten (außer man verwendet NAT).

 

[itNGO]

Wenn sie auf DC-Ebene aktiv ist, dann gelten die Regeln auf Datacenter-Ebene (für die Hosts!). Die Host-Firewall sollte keinen Einfluss haben auf VMs, d.h. wenn ich auf Host-Ebene bestimmten Traffic blockiere, dann können VMs immer noch diesen Traffic erhalten (außer man verwendet NAT).

Kann ich so leider nicht bestätigen. Wenn die Firewall auf Datacenter und Host-Ebene aktiv ist, aber für die VMs "explizit" auf "aus", haben wir trotzdem Änderungen im Verhalten der VMs.

Beispiel. Eine VM bei der die Firewall auf "aus" ist, aber eben auf Datacenter und Host-Ebene aktiv wird als IPSEC-Router genutzt.
Zwischen den beiden IPSEC-Punkten gibt es Exchange-Server. Diese bauen bei aktiver Firewall/Datacenter und Host 100% zuverlässig sofort "Warteschlangen" für den Sync auf. Schalter Firewall im Datacenter auf "aus", "Warteschlange" innerhalb von Sekiunden wieder leer.

Ich vermute also das der "Dienst" Firewall so bald er läuft, das Verhalten des Netzwerktraffics bereits so sehr beeinflusst, das bestimmte Funktionen nicht mehr wie erwartet ablaufen.

2tes Beispiel. VPN-Clients die sich auf einem RAS-Server einwählen (komplett anderer Cluster) können plötzlich Server die hinter einem VPN-Tunnel liegen, nicht mehr erreichen. Auch hier wird der Tunnel durch eine VM geleitet, die auf dem besagten Hosts liegt, wo Dataccenter und Host-Firewall auf ein aber eben für die VM auf "aus" ist.

Ich hab son bisschen den Eindruck das die aktive Firewall MTU oder ip Options oder irgendwas an der Adressierung beeinflusst?

Edit: Ist vermutlich das gleiche wie hier in diesem Thread:
https://forum.proxmox.com/threads/pve-firewall-blocks-large-udp-ipsec-packets.123968/

 

[shanreich]

Ja, hier gibt es bei der Firewall/iptables das Problem, dass fragmentierte Pakete gedropped werden - das kann sehr gut sein, dass sie in diese Problematik laufen (wie auch in dem verlinkten Thread beschrieben).

 

[itNGO]

Ja, hier gibt es bei der Firewall/iptables das Problem, dass fragmentierte Pakete gedropped werden - das kann sehr gut sein, dass sie in diese Problematik laufen (wie auch in dem verlinkten Thread beschrieben).

Und die Lösung? Abgesehen von PVE-Firewall nicht verwenden oder ne dedizierte Firewall davor stellen und das System "ungesichert" stehen lassen?

 

[shanreich]

Leider ist das ein inhärentes Problem davon wie iptables mit fragmentierten Paketen umgeht. Mittelfristig wollen wir die Firewall auf nftables umstellen [1], wo die derartige Problematik nicht existieren sollte.

Entweder man löst die Problematik auf Applikationsebene und verhindert das Senden von zu großen Paketen, oder man verwendet - wie bereits erwähnt - keine / eine dezidierte Firewall.

[1] https://lists.proxmox.com/pipermail/pve-devel/2024-April/062511.html

 

[itNGO]

Leider ist das ein inhärentes Problem davon wie iptables mit fragmentierten Paketen umgeht. Mittelfristig wollen wir die Firewall auf nftables umstellen [1], wo die derartige Problematik nicht existieren sollte.

Entweder man löst die Problematik auf Applikationsebene und verhindert das Senden von zu großen Paketen, oder man verwendet - wie bereits erwähnt - keine / eine dezidierte Firewall.

[1] https://lists.proxmox.com/pipermail/pve-devel/2024-April/062511.html

Eine Nachrage nach viel hin und herlesen im Internet und im Forum.

Könnte
sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1
irgendwie Abhilfe schaffen?

Edit: Macht keinen Unterschied... warten wir also bis offiziell nftables verwendet wird. Any timeframe?

 

[shanreich]

warten wir also bis offiziell nftables verwendet wird. Any timeframe?

Mit der heute releasten Version 8.2 bieten wir eine nftables-basierte Firewall als opt-in an. Wäre es vielleicht möglich das mal auf einem Test-System zu probieren?

 

[itNGO]

Mit der heute releasten Version 8.2 bieten wir eine nftables-basierte Firewall als opt-in an. Wäre es vielleicht möglich das mal auf einem Test-System zu probieren?

Habe das Update grad auf einem 3-Node-Cluster der diverse opnsense-firewalls hällt installiert und die Firewall "opt-in" aktiviert....
Das System Log wird mit folgender Meldung zugespammt:

Apr 24 21:24:31 proxmox-firewall[249659]: proxmox_firewall: error creating firewall rules: cannot find macro SPICEproxy

Ansonsten scheint es aber zu laufen....

Edit... nach dem ich die entsprechende Regel in Datacenter deaktiviert habe, ist das Logging wieder normal.
Wobei es das Makro SPICEProxy in der Auswahl-Liste schon gibt....

 

[shanreich]

Edit... nach dem ich die entsprechende Regel in Datacenter deaktiviert habe, ist das Logging wieder normal.
Wobei es das Makro SPICEProxy in der Auswahl-Liste schon gibt....

Danke fuer den Report, ich werde einen Patch dafuer erstellen.

 

[itNGO]

Hi, so ganz 100% ist das wohl noch nicht.
Wenn im Datacenter die Firewall aktiviert wird und entsprechend auf den VMs "greift", dann ist aktuell keine VPN-Client-Einwahl mehr möglich.
Das Konstrukt ist so, das der VPN-Server mit dem Cluster gar nichts zu tun hat, ausser das eine Radius-Authentifizierung gegen einen virtuellen Radius-Server getätigt wird. Das funktioniert dann nicht mehr und im log ist kein Traffic dazu zu sehen. Schalte ich die Firewall im Datacenter ab, funktioniert es sofort wieder....

Ich muss da aber auch noch prüfen, ob nicht evtl. eine Regel vergessen wurde. Wobei ich der Annahme unterliege, das wenn die Firewall für die Radius-VM auf "aus" und auch für die "NICs" auf aus steht, er von dem Traffic doch die "Finger" lassen sollte? Dem scheint aber auch bei nftables nicht so zu sein?

 

[itNGO]

So,

einige Tage und Versuche später.....

- Wenn nftables aktiviert ist, dann ist es scheinbar nicht möglich die Firewall zu "disablen" ohne den Node auf dem die Firewall für eine VM aktivier war neu zu starten. Migrieren der VM auf einen anderen Node geht auch um die "Gast-Firewall" zu deaktivieren. Erkennbar ist das, da im Firewall-Log munter weiter Pakete aufgezeichnet werden, obwohl Bridge, VM, Host und sogar Datacenter längst auf Disabled stehen....

- Wenn die Firewall aktiviert ist, scheitert die VPN-Client-Einwahl selbst wenn die Regel-Tür "full-open" ist. SSTP-VPN wobei einzig die Authentifizierung über einen Windows Radius (NPS-Server) mit der Firewall in Berührung kommt. Der VPN-Server steht in einem Subnetz welches über eine opnsense zu einem DC geroutet wird. Ist die Firewall im PVE für die opnsense aktiv, ist die Einwahl nicht mehr möglich. Selbst wenn in der PVE-Fireall die Tür einfach "full open" ist.

Alles in allem, es geht jetzt "mehr" als vorher mit iptables, aber leider noch nicht alles... wobei ich nicht sagen kann ob es einfach noch "Konfigurationsfehler" auf unserer Seite sind, oder wir etwas "wollen" was nftables einfach nicht "kann"...

 

[shanreich]

Hi, sorry für die etwas späte Rückmeldung - ich war die letzte 2 wochen nicht im büro.

Erkennbar ist das, da im Firewall-Log munter weiter Pakete aufgezeichnet werden, obwohl Bridge, VM, Host und sogar Datacenter längst auf Disabled stehen....

Ist es möglich, dass da conntracking mitspielt und deshalb die firewall 'ausgehebelt' wird?

Wenn die Firewall aktiviert ist, scheitert die VPN-Client-Einwahl selbst wenn die Regel-Tür "full-open" ist. SSTP-VPN wobei einzig die Authentifizierung über einen Windows Radius (NPS-Server) mit der Firewall in Berührung kommt. Der VPN-Server steht in einem Subnetz welches über eine opnsense zu einem DC geroutet wird. Ist die Firewall im PVE für die opnsense aktiv, ist die Einwahl nicht mehr möglich. Selbst wenn in der PVE-Fireall die Tür einfach "full open" ist.

Wäre es möglich hier mal mit nft monitor trace [1] zu checken ob bzw welche firewall regeln hier greifen?


[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_firewall_nft_helpful_commands

 

[itNGO]

Hi, sorry für die etwas späte Rückmeldung - ich war die letzte 2 wochen nicht im büro.



Ist es möglich, dass da conntracking mitspielt und deshalb die firewall 'ausgehebelt' wird?


Wäre es möglich hier mal mit nft monitor trace [1] zu checken ob bzw welche firewall regeln hier greifen?


[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_firewall_nft_helpful_commands

Sorry für den "delay"... wir haben da jetzt einige Wochen und Updates weiter mit getestet.... soweit scheint wohl alles nun zu laufen....

Was jedoch auffällt... angenommen wir aktivieren die Firewall nur für einen einzelnen Guest auf einem Node, scheint die ConnTrack-Tabelle trotzdem von allen VMs die Verbindungen zu halten. Wir haben das festgestellt da bei Aktivierung der Firewall auf einem Cluster-Node der ca. 15 Gast-Firewalls gehalten hat nach Aktivierung sofort die die conntrack-tabelle "geplatzt" ist...

Sep 26 15:26:08 RZA-GENOA3 kernel: net_ratelimit: 2225 callbacks suppressed
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
Sep 26 15:26:08 RZA-GENOA3 kernel: nf_conntrack: nf_conntrack: table full, dropping packet

 

[itNGO]

Ergänzend noch. Wie geht man mit dieser Meldung im SYSLOG um?

Sep 26 16:54:56 RZA-GENOA3 proxmox-firewall[2334]: proxmox_firewall: error updating firewall rules: cannot execute nftables commands

 

[shanreich]

Was jedoch auffällt... angenommen wir aktivieren die Firewall nur für einen einzelnen Guest auf einem Node, scheint die ConnTrack-Tabelle trotzdem von allen VMs die Verbindungen zu halten. Wir haben das festgestellt da bei Aktivierung der Firewall auf einem Cluster-Node der ca. 15 Gast-Firewalls gehalten hat nach Aktivierung sofort die die conntrack-tabelle "geplatzt" ist...

Ja, sobald die Firewall aktiv ist, ist auch Conntrack aktiv und tracked saemtliche Verbindungen des Hosts.

Ergänzend noch. Wie geht man mit dieser Meldung im SYSLOG um?

Hier gibt es ein Problem mit dem generierten Ruleset. Ueblicherweise tritt das auf wenn ein IPSet/Alias in den Regeln referenziert wird, das nicht mehr existiert. Hier arbeite ich noch an besserem Error Reporting.