Vor- und Nachteile: VLAN in proxmox oder in opnsense anlegen?

torwag

Member
Oct 5, 2020
13
3
8
46
Hallo,
Einer dieser ewigen proxmox+router Dinger. Gefühlt schon 1000mal gelesen aber keine definite Antwort gefunden.

Es gibt im Prinzip 2 Möglichkeiten:

1. Proxmox-Bridge (vlan aware, z.B. vmbr0) mit einer einzigen virtuelle NIC der VM verbinden. opnsense, pfsense, etc. müssen sich dann um die vlan getaggte packete kümmern. In opnsense lege ich also vlans an basierend auf der NIC (z. B. vtnet0.10, vtnet0.20,etc.) Diese VLAN network ports ordne ich interfaces zu (LAN, SERVER, DMZ, etc.).

2. Proxmox selbst dröselt alle vlans in unterschiedliche bridges auf (vmbr0.100, vmbr0.200, etc.) und ordnet dann jede dieser VLAN-bridges einer virtuellen Netzwerkarte der opnsense-VM zu.(Bin mir gerade nicht sicher evtl. reicht es auch in der virtuellen Netzwerkkarte die VLAN Nummer zu setzen, wenn da stimmt spart man sich die ganzen bridges) Für opnsense sieht es dann aus, als ob der Server N Netzwerkkarten besitzt, die alle an unterschiedlichen Netzwerken hängen. Diesen wieder Interfaces zuordnen.

Ab hier ist es dann wieder gleich.... DHCP Server anlegen, Firewall regeln definieren.

Nun die Frage : Was ist besser? Vor und Nachteile? Mir geht es eher um praktische Punkte als "esoterische" Performancevorteile.
Das ich die vlans in opnsense als Router "sehe" fühlt sich zumindest logisch an. Anderseits habe ich gelesen das die Firewall Regeln komplexer werden sollen.

Wie sieht es auf der proxmox Seite aus? Eine weitere VM kann ich dann trotzdem mit beiden Methoden auf der proxmox Seite einem beliebigen VLAN zuordnen. So das der Client in der VM sich mit VLAN gar nicht beschäftigen muss.
 
(Bin mir gerade nicht sicher evtl. reicht es auch in der virtuellen Netzwerkkarte die VLAN Nummer zu setzen, wenn da stimmt spart man sich die ganzen bridges)
Ja, spart man sich. Das wäre dann Option 3 mit einer einzelnen vlan-aware bridge + eine vNIC pro VLAN wo du der dann das VLAN Tag mitgibst.
 
@Dunuin und als Famous Member.... 1, 2 oder 3?


Ich würde gerne lernen wo die Vor und Nachteile liegen.
Bei Methode 1:
Wenn ich die in opnsense anlege, dann könnte ich eine neue VM mit einem neuen VLAN taggen und in opnsense das neue Netzwerk konfigurieren.
Bei Methode 2 und 3:
Müsste ich ne neue NIC der VM hinzufügen und die VM und damit den Router und somit das ganze Netzwerk neu booten?

Das spräche für Methode 1. Was ist weniger fehleranfällig und einfacher administrierbar?
 
@Dunuin und als Famous Member.... 1, 2 oder 3?
Bei mir aktuell Option 2, aber das hat eher Legacy Gründe. Ging halt damals nicht anders. Hatte OPNsense als HA betrieben mit einer VM auf PVE und einer VM auf TrueNAS Core und wenn man die HA betreibt müssen alle NICs gleich heißen und das FreeBSD von TrueNAS Core kennt keine Vlan-aware Bridges. Ging also nur mit 13 Bridges für die 13 VLANs... . Netzwerk steht und läuft und wäre viel zu viel Arbeit das jetzt noch zu ändern, auch wenn beide OPNsenses jetzt auf PVE Servern laufen und nun auch Option 1 und 3 möglich wären.
Würde ich das heute neu aufsetzen würde ich wohl Option 3 wählen.
Aber ich sehe da jetzt weder für Option 1 noch 3 irgendwelche große Nachteile. Ist wohl eher die Frage wie du es lieber verwaltest. Ich mag das einheitlich und ich muss die VLANs für die VMs/LXCs sowieso über PVE verwalten. Dann kann ich da auch gleich die OPNsense VM über PVE mitverwalten und spare mir das mit den VLANs in der OPNsense.

Müsste ich ne neue NIC der VM hinzufügen und die VM und damit den Router und somit das ganze Netzwerk neu booten?
Nein, vNICs sind eigentlich hot-pluggable. Heißt die kann man hinzufügen ohne die VM neustarten zu müssen. Außerdem würde ich HA für die OPNsense empfehlen. Dann wäre es völlig egal, wenn du mal die OPNsense VM neu startest, weil dann die Backup OPNsense augenblicklich dessen Platz einnimmt und alles ohne abgerissene Verbindungen fröhlich weiter läuft. Im Idealfall natürlich auf zwei verschiedenen PVE Servern aber auf einem einzelnen auch praktisch, wenn man mal eine OPNsense für ein Upgrade rebooten muss und dann nicht kurz offline sein will. Mir ging es da aber eher darum, dass wenn mal ein PVE Server den Geist aufgibt und ich 2 Wochen zum Ersetzen brauche, dann nicht der ganze Haushalt für 2 Wochen offline ist. Siehe: https://www.thomas-krenn.com/de/wiki/OPNsense_HA_Cluster_einrichten
 
Last edited:
Aus Netz-topoligischer Sicht ist deine Sense ja eine Art Router oder Firewall?

Ich kenne die Teile jetzt nicht im Detail, aber üblicherweise will/muss man Firewallregelwerke basierend auf VLAN-interface konfigurieren. Du kannst dir jetzt die Arbeit machen alles doppelt anlegen (in Proxmox und der Sense), oder du belässt es bei einer (1) VLAN-aware-bridge im Proxmox (die alles tagged an die vNIC der Sense durchreicht) und dort legst du die VLAN-Interfaces an. Das wäre für mich der schönere Ansatz, weil sonst alles doppelt gepflegt werden muss.

Du kannst dann beliebig weitere VMs mit einer tagged-vNIC versehen (in Proxmox) und so den Verkehr (aus VM-Sicht) untagged dort ausleiten.
 
Nein, vNICs sind eigentlich hot-pluggable. Heißt die kann man hinzufügen ohne die VM neustarten zu müssen. Außerdem würde ich HA für die OPNsense empfehlen. Dann wäre es völlig egal, wenn du mal die OPNsense VM neu startest, weil dann die Backup OPNsense augenblicklich dessen Platz einnimmt und alles ohne abgerissene Verbindungen fröhlich weiter läuft: https://www.thomas-krenn.com/de/wiki/OPNsense_HA_Cluster_einrichten
Cool, das mit dem hot-pluggable wusste ich nicht. Ich werde, sollte es nicht noch gravierende Nachteile geben, so wie @HalloWelt schreibt option 1 verwenden. Zu oft habe ich in opnsense "rumgespielt" um dann vergessen das ich es nicht mit echten NICs zu tun habe sondern das proxmox auch noch seine Streicheleinheiten braucht (z. B. das neue VLAN nicht durchgereicht, etc.)...
Das mit dem HA ist gemein.... Immer wenn man denkt, bald ist fertig kommt jemand und sagt... Schau mal, cool gell....
 
Ich kenne die Teile jetzt nicht im Detail, aber üblicherweise will/muss man Firewallregelwerke basierend auf VLAN-interface konfigurieren. Du kannst dir jetzt die Arbeit machen alles doppelt anlegen (in Proxmox und der Sense), oder du belässt es bei einer (1) VLAN-aware-bridge im Proxmox (die alles tagged an die vNIC der Sense durchreicht) und dort legst du die VLAN-Interfaces an. Das wäre für mich der schönere Ansatz, weil sonst alles doppelt gepflegt werden muss.
Ich habe da halt meine 13 VLANs als 13x NICs in der OPNsense wo untagged Traffic ankommt. Meine OPNsense routet/NATet dann halt zwischen 13 Subnetzen. Das klappt auch wunderbar, ohne dass da OPNsense irgendetwas von VLANs weiß.
 
Ja ich glaube ich bleibe bei Option1 mit Option2 (was ich früher hatte, habe ich mir ein paar mal böse ins Bein geschossen, indem ich stundenlang in opnsense nach dem Fehler gesucht habe, der in einer vergessenen Einstellung bei proxmox lag...
Ich bin/war mir halt nur nicht über die Vor--und Nachteile im klaren.
 
Also ich habe alle VLANs in Proxmox erstellt und pro VLAN dann auch ein vNic an OPNSENSE durchgereicht. OPNSENSE kennt so selbst keine VLANs und verwaltet stumpf Interfaces. So kann ich alle VLANs(Quasy Switching Arbeit) in Proxmox pflegen und die eigentlichen Routingfunktionen in OPNSENSE
 
Also ich habe alle VLANs in Proxmox erstellt und pro VLAN dann auch ein vNic an OPNSENSE durchgereicht. OPNSENSE kennt so selbst keine VLANs und verwaltet stumpf Interfaces. So kann ich alle VLANs(Quasy Switching Arbeit) in Proxmox pflegen und die eigentlichen Routingfunktionen in OPNSENSE
Wieso kennt opnsense keine vlans? Kann man dort anlegen, ähnlich wie in proxmox und anschließend Interfaces zuordnen.

Naja, die Methode ist ja nicht in Stein gemeißelt. Wenn es nicht passt kann man es ja noch mal umstellen.
 
Wieso kennt opnsense keine vlans? Kann man dort anlegen, ähnlich wie in proxmox und anschließend Interfaces zuordnen.

Naja, die Methode ist ja nicht in Stein gemeißelt. Wenn es nicht passt kann man es ja noch mal umstellen.
OPNsense könnte in Theorie mit VLANs umgehen. Aber wenn du PVE um die VLANs kümmern lässt, dann filtert PVE ja alles an VLAN-Tags raus, dass da beim Gast (also auch der virtuellen OPNsense) dann nur noch untagged Traffic ankommt. Das kann ja auch ein Sicherheitsfeature sein. VLANs und Firewall-Regeln möchte ich z.B. vom PVE-Host verwaltet haben. Weil wenn da dann mal ein GastOS kompromittiert wird, dann hat es die Schadsoftware deutlich schwerer sich auszubreiten, wenn die VLANs und Firewall-Regeln nur von extern geändert werden können.
 
NICs können der opnsense "hot" hinzugefügt/entfernt/rekonfiguriert werden, wenn das Qemu-Plugin installiert ist.
Der Übersicht wegen machen wir das meist auch so, das wir "viele" NICs der VM mit dem jeweiligen Tag hinzufügen.

Technisch ist es wohl am "Ehesten" eine Geschmacksfrage ob man im Gast oder durch den PVE Taggen lässt.... Beides geht während die VM online ist....
 
Was OPNSENSE aber garnicht mag, ist das anpassen von Multiqueue. Zumindest bei mir bleibt das Interface dann bis zum reboot ohne Funktion... :D Aber klar, hotplug geht.
 
Last edited:
  • Like
Reactions: itNGO
Kurze Frage dazu - welche von die 3 Optionen sind am performanste ?!? Hat jemanden es getestet?? Ich bin zurzeit beim Option2 und kriege nicht die ganze dürchsatz von mein 600MB Glasfaserleitung . . . Danke vorweg!
 
Kurze Frage dazu - welche von die 3 Optionen sind am performanste ?!? Hat jemanden es getestet?? Ich bin zurzeit beim Option2 und kriege nicht die ganze dürchsatz von mein 600MB Glasfaserleitung . . . Danke vorweg!
Wenn du die opnsense "halbwegs" scharf konfiguriert hast (Maltrail, IPS, ZENARMOR, Crowdsec, etc) brennen die CPUs eh weit vor den 600MBit ab.

Ansonsten spielt es eigentlich nur hinterm "komma" ne rolle ob VLAN im Gast oder direkt am PVE. Zumindest mit VirtIO-Nics konnten wir da keinen messbaren Unterschied im "besseren" Router-Modus erkennen.... wenn die opnsense richtig "heiss" ist dann mag es sich vielleicht um 5% gehandelt haben, das kann aber auch andere Gründe gehabt haben.

Was tatsächlich einen merkbaren Unterschied gemacht hat, ist die Firewall im PVE aktiviert und konfiguriert zu haben. Dann muss die opnsense sich nicht mit Paketen beschäftigen ,die eh uninteressant sind. Allerdings sieht man dann halt auch am WAN-Interface nicht mehr alles was da so "vorbeirauscht" an "Dreck"....
 
  • Like
Reactions: rfox
Wenn du die opnsense "halbwegs" scharf konfiguriert hast (Maltrail, IPS, ZENARMOR, Crowdsec, etc) brennen die CPUs eh weit vor den 600MBit ab.

Nun das kann ich so nicht bestätigen.
Ich schaffe locker 940 MBit auf meiner Windows VM auf Proxmox über die OPNsense VM. Und zwar im Down- und Upload.
Damit hat die OPNsense (8 vCPU) ca. 30 % last. Mit Crowdsec und Zenarmor. Mit IPS war der Upload langsamer. Habe ich bei mir aus gemacht weil ich auf dem WAN nun auch Zenarmor habe.
 
Nun das kann ich so nicht bestätigen.
Ich schaffe locker 940 MBit auf meiner Windows VM auf Proxmox über die OPNsense VM. Und zwar im Down- und Upload.
Damit hat die OPNsense (8 vCPU) ca. 30 % last. Mit Crowdsec und Zenarmor. Mit IPS war der Upload langsamer. Habe ich bei mir aus gemacht weil ich auf dem WAN nun auch Zenarmor habe.
Was für ein Prozessor? Ich hab ein R86s gerät mit N5105 CPU (Amazon) - mit 16GB Ram - direkt von die OPNSense VM, Ich kriege 580MB beide Richtungen mit Speedtest-CLI - aber von VLANs und WLAN Ich kriege ungefähr 400MB im schnitt ?!?
 
Was für ein Prozessor? Ich hab ein R86s gerät mit N5105 CPU (Amazon) - mit 16GB Ram - direkt von die OPNSense VM, Ich kriege 580MB beide Richtungen mit Speedtest-CLI - aber von VLANs und WLAN Ich kriege ungefähr 400MB im schnitt ?!?

Nun ja da habe ich schon etwas mehr denke ich.
AMD Ryzen 5 3600. Ist halt auch ein Server im Rechenzentrum mit 1 Gbit I-Net Anbindung.

Es hängt also schon von der CPU ab. Bei einem Kunden habe ich eine OPNsense nativ laufen. Da geht über die Vlans dann noch mal deutlich mehr.
 
  • Like
Reactions: rfox

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!