Hyper-V und VLAN tagging innerhalb einer VM (Firewall)

[MetalForLive]

Hallo zusammen,

ich habe hier ein kleines Problem wo ich nicht so recht weiter komme.
Ich habe hier einen Hyper-V Host, dieser ist mit zwei NICs (Teaming) per LACP an einen Switch angeschlossen.
Native VLAN ist 10, dort hat der Host auch eine IP, die restlichen VLANs werden tagged übertragen.

Wenn ich jetzt einer VM einen neuen Netzwerkadapter zuweise und diesem einen VLAN Tag verpasse, funktioniert das auch alles soweit ohne Probleme.

Allerdings habe ich hier eine Palo Alto Netwoks Firewall als VM, dort habe ich einen Netzwerkadapter fürs MGMT Interface im VLAN 100 und dann einen weiteren Adapter wo eigentlich der Daten Traffic drüber laufen soll (Bild unten Ethernet1/1).
Dort ist ebenfalls der gleiche virtuelle Switch konfiguriert allerdings ohne VLAN tag, also bekommt er erst mal das Native VLAN (10) untagged, dort kann ich der Firewall eine IP geben und kann diese auch pingen.
Wenn ich jetzt aber ein L3 Subinterface innerhalb der VM anlege und dort einen VLAN Tag vorgebe (VLAN 9 ) dann kann ich dieses Vlan nur über routing pingen(Bild unten Ethernet1/1.9).

Also ich habe einen Client im VLAN 10 dieser schickt den Ping an meine eigentliche Firewall (Ubiquti USG) da dort das L3 Interface (Gateway) anliegt, dort gibt es eine Route für das VLAN 9 wo der next hop eben die IP der Palo Alto VM im VLAN 10 ist.

Wenn ich jetzt aber einen Client direkt ins VLAN 9 stecke also nur per Layer 2 Verbindung, kann ich die IP nicht pingen.

Wenn ich der Firewall nun aber im Hyper-V einen neuen Netzwerkadapter hinzufüge, diesen per VLAN Tag 9 konfiguriere und in der Firewall das Interface auf untagged stelle, funktioniert alles wie es soll (Bild unten ist das Ethernet1/2 dann).

Finde ich aber sehr unschön, da die VM nur 7 "Physikalische virtuelle Interface" besitzt und Hyper-V auch nur maximal 8 Netzwerkadapter pro VM zulässt.

Mir kommt es so vor, dass der Hyper-V Adapter irgendwie die VLAN tags verwirft, wenn ich es über subinterface versuche.

Vermutlich würde das Problem nicht bestehen, wenn ich eine Physikalische Netzwerkkarte nur für diese VM nutzen würde, leider habe ich keine mehr frei und jetzt auch keinen USB zu Ethernetadapter zur Hand um es zu testen...

Das Verhalten ist mir bei einer Sophos XG VM auch schon aufgefallen.
Gibt es hier vielleicht irgend eine spezielle Einstellung im Hyper-V damit er die VLAN tags richtig forwardet oder sowas ?

 

[ayngush]

VLAN-Tags innerhalb der VM werden nicht direkt nach draußen auf den Hyper-V Netzwerkadapter gehoben. Deswegen konfiguriert man das ja in den Einstellungen der VM.

Ich verstehe nicht so ganz, wo das Problem mit der Anzahl der NIC ist? Was hast du da vor?! Die NASA virtuell nachbauen?

 

[MetalForLive]

Heißt, wenn ich einen Physikalischen Port für diese VM verwenden würde, würde es aber funktionieren, ist das richtig ?
Sonst besorg ich mir noch eine weitere Netzwerkkarte und schieb die da rein.
Bzw. kann das Teaming auflösen, brauch das sowieso nicht zwingend.

Ich bin es eben von den Physikalischen Palo Altos gewohnt mit Subinterfacen zu arbeiten was L3 Vlans angeht.
Daher würde ich das hier gerne auch so umsetzen.

 

[onedread]

Ist denn das Interface als trunk konfiguriert für die VM?

Get-VMNetworkAdapterVlan -ComputerName {hvhost} -VMName {vm} -VMNetworkAdapterName {nicname}

VMName VMNetworkAdapterName Mode VlanList

------ -------------------- ---- --------

{vm} {nicname} Trunk 1,2,3

 

[ayngush]

Du brauchst eine physikalische Netzwerkkarte, einen externen Virtuellen Switch ohne "gemeinsame Verwendung" auf dieser Karte und musst diese dann in Powershell mit den Befehl Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "200,300,500-600" -VMName "VmName" -VMNetworkAdapterName "TrunkNic" -NativeVlanId 0 im Trunk Mode, eigentlich ja verwendet um Switche untereinander zu verbinden, an die VM koppeln.
Da deine PaloAlto VM jedoch quasi wie ein Switch zu betrachten ist, ist der Trunk Mode dafür richtig. Ob das jedoch zu Problemen führt kann ich dir nicht sagen, da wir unsere Firewall als Hardware Appliance im Schrank hängen haben....

Edit: Folgende Baustellen könnte ich mir vorstellen:
* Verlust sämtlicher Routen bei Ausfall der VM.
* Probleme bei der Hyper-V Live Migration.
* Probleme beim Disaster Recovery des Hyper-V Servers.
* Probleme bei der Verwendung vom Hyper-V Failovercluster.

Nicht zum Spaß haben wir da bei uns zwei Appliances im HA-Betrieb Das ist echt ätzend, wenn man alles schön mit VLANs segmentiert und dann der "Router" dafür ausfällt... und VMs fallen immer mal aus Gründen aus. Und ob das noch performant ist... Am besten wären dafür wohl L3 routing fähige Switche (von Ruckus z.B.)

 

[MetalForLive]

Dann werde ich mich daran mal versuchen, danke.
Ja wir haben auch Hardware Firewalls, das ist nur bei mir Zuhause auf meinem Homeserver, da ich gerne mein Ubiquiti USG ablösen würde.

 

[ayngush]

Ich habe vor wenigen Tagen mein Homelab auf Proxmox umgestellt.

Kein Nerv mehr gehabt mich zu Hause auch noch mit Hyper-V zu quälen, reicht mir schon in der Firma.
Bei Proxmox hätte man da wohl die Hardware direkt in die VM durchschieben können...
Und die Performance von Linux-VM und vor allem von den Linux Containern ist um Längen besser als unter Hyper-V...

Hauptgrund war jedoch, dass ich Debmatic verwende und dieses vom Raspberry Pi in eine VM auf meinen "Server" (Intel NUC...) bringen wollte, dafür jedoch das USB-Modul direkt in die VM durchreichen muss. Das funktioniert mit Hyper-V halt nicht.

 

[MetalForLive]

Hat funktioniert mit Physikalischer NIC
Bin soweit eigentlich mit Hyper-V zufrieden, bis auf das mit den Netzwerkadapter jetzt aber naja passt schon.
Auf der Arbeit haben wir ESX aber damit habe ich nur am Rande zu tun, damit dürfen sich die VMware Jungs rum ärgern


Edit:
Kommando zurück, hab es gar nicht von der VM im selben VLAN versucht...
Da geht es nicht.

Wie finde ich den den Namen raus, den der Powershell Script haben will ?
Mit Fragezeichen oder Tab kann man hier leider nicht arbeiten.

Ah mit

Get-NetAdapter

Aber geht trotzdem nicht...
Ich hasse Powershell

 

[ayngush]

Das müsste der Name des "Virtuellen externen Switches" für den Adapter sein, den man selbst festlegen kann.

 

[MetalForLive]

Mit folgendem Befehl konnte ich jetzt herausfinden, wie die entsprechende NIC heißt.

Get-VMNetworkAdapterVlan

Lustigerweise kann man beim erstellen einer Netzwerkkarte im Hyper-V Manager den Namen der virtuellen Netzwerkkarte nicht festlegen.
Heißt, alle Karten heißen gleich und der Befehl wird für alle ausgeführt.
Holy shit, wer denkt sich denn so einen Müll aus !?

Mit dem Befehl

Rename-VMNetworkAdapter –VMName "ROPANVM01" –Name “Netzwerkkarte” –NewName “MGMT”

kann man jetzt die NICs entsprechend umbenennen.
Hier gilt wieder das selbe Spiel, da alle "Netzwerkkarte" heißen, werden auch alle umbenannt.
Ich versuch jetzt mal eine Karte nach der anderen hinzuzufügen und umzubenennen.
Mal sehen ob ich dann weiter komme...

Kein Nerv mehr gehabt mich zu Hause auch noch mit Hyper-V zu quälen, reicht mir schon in der Firma.

So langsam verstehe ich die Aussage.



Edit:
Hmm das selbe Problem noch immer, Subinterfaces sind nicht aus dem gleichen Layer 2 VLAN erreichbar.
Och man, das nervt.

 

[ayngush]

Joa... Je tiefer man in das Hyper-V System eintaucht, desto unflexibler stellt es sich in einigen Bereichen heraus.

Da ich ohnehin nur Debian-Server zu Hause betreibe brauche ich dann auch kein Hyper-V dafür.
Das ging ja schon los mit der Installation, dass auf den NUC, da keine Server-Hardware, die Netzwerkkarte erst nicht erkannt wurde, dann mit der Automatisierung von Backups, dem generellen Management, usw.
Dazu kommt noch die Windows-Linux-Spezialität. Wenn man die Virtuellen Festplatten und das Linux-Dateisystem nicht entsprechend konfiguriert, was über die Assistenten nicht so einfach möglich ist, dann wachsen einen die Dynamischen Datenträger schnell über den Kopf hinaus. Für meinen Webserver, auf den halt ständig Logs und Datenbank-Datendateien verändert wurden und der nicht nach den "Best Practises" installiert war, sah das So aus: ~6 GB Daten auf dem Server Vorhanden, die dynamische vhdx-Platte wuchs dabei jedoch auf ~49 GB von 50 GB an... so ein Unfug.

Proxmox kann man halt vom Browser aus bedienen, wirf da ein Bash-Skript für das Backup in einen Cronjob, der vorher das NAS startet und hinterher wieder herunterfährt und den Swap aufräumt, und gut ist. Für Hyper-V muss man wieder einen Windows-PC haben mit den Management Tools, muss da diese Authentifizierungs-Nummer abziehen, damit man sich damit überhaupt verbinden darf, muss mit Powershell und Remote Powershell für das Backup herum hantieren, uvm.

Für die Firma funktioniert Hyper-V mit Veeam, Live Migration, Live Replication, den produktionsprüfpunkten, Inkrementellen Backups, und vielen Windows-Servern ja ganz gut, da ist die Sicherheit, dass da keine direkte Hardware an die VM geht, auch höher zu bewerten als bei mir zu Hause. Für mein Homelab möchte ich jedoch einfach eine Umgebung haben, die funktioniert und die mir keine Kopfschmerzen bereitet

 

[MetalForLive]

Hmm, hab ma n Wireshak angeschmissen und auf der VM im gleichen VLAN gesnifft.
Der bekommt nicht mal die MAC Adresse von der Firewall in dem Subinterface zurück.
Hab dann mal einen statischen ARP Eintrag gesetzt aber da kommt dann dennoch kein Response.
Das fuchst mich jetzt schon ein wenig, hätte das ganz gerne vernünftig am laufen.


Edit:
Ich geb es auf, stand jetzt brauch ich sowieso nicht mehr als 7 VLANs.
Sollte sich das in Zukunft ändern, muss ich wohl nach ESX mal schauen oder mir eine Hardware Lab Unit beschaffen.

Falls noch jemandem was einfallen sollte, bin ich dennoch für Tipps offen

 

[ayngush]

Proxmox testen

 

[MetalForLive]

Die Palo Alto Networks VM gibt es leider nicht als Iso oder ähnliches zum installieren, sondern nur als fertige vhdx oder für VM Ware oder halt AWS Google cloud etc.
Deshalb fällt das leider raus.

Ich werd bei Gelegenheit mal unseren Firewall Dienstleister fragen wenn ich den mal sowieso an der Strippe hab ob er was weiß.

 

[ayngush]

OK, Tipp: Sophos XG Firewall. Kost nichts für Privat, gibt es als ISO. Hatte ich mir mal selbst in einer VM unter Hyper-V angeschaut. Ansonsten ist OPNSense auch immer ein Blick wert.

Palo Alto & Fortinet fallen vor allem durch garstige Artikel bei Heise Security auf. Geht so in Richtung: SSH Backdoor entfernt (Fortinet), Bekommt Sicherheitspatch nicht ordentlich implementiert (Palo Alto).
Nicht unbedingt gute Werbung für ein Sicherheitsprodukt, dort solche Aufmerksamkeit zu bekommen. Außerdem: Closed Source, US-Ami, ... da kannst auch gleich nen Cisco-Router benutzen

 

[Bob.Dig]

Ist denn das Interface als trunk konfiguriert für die VM?



VMName VMNetworkAdapterName Mode VlanList

------ -------------------- ---- --------

{vm} {nicname} Trunk 1,2,3

Ich klinke mich hier mal ein. Habe pfSense in Hyper-V auf Win 10 laufen und vlans sind meine neuste Herausforderung.
Ich könnte wohl die vlans in Hyper-V konfigurieren und diese dann einzeln für jede vlanID einbinden via GUI. Eigentlich keine schlechte Idee...

Was wäre nun aber, wenn ich dies unbedingt in pfsense selbst machen wollte, auch wenn ich gerade keinen guten Grund finde, das machen zu wollen, aber ich bin auch absoluter Noob was vlan betrifft.
Müsste ich dann einen Switch als "Trunk" konfigurieren mittels cmdlet? Was wären die Vor und Nachteile davon?

 

[ayngush]

Ja, das müsstest du. Trunk in diesen Kontext bedeutet, dass der Anschluss sozusagen "VLAN unkonfiguriert" an die VM übergeben wird und auch keine VLAN-Informationen entfernt, wenn die VM welche setzt.

Das ist quasi das gleiche Verhalten wie bei einen als Trunk konfigurierter Port an einen physikalischen Switch, der VLAN kann. Das benutzt man in der Regel für die Up- / Downlinks von Switchen, also für die Verbindung der Switche untereinander.

Der Limitierende Faktor, warum man das ggf. als Trunk machen will, ist bei Hyper-V halt die maximale Anzahl an Netzwerkkarten. Oder es gibt halt gute Gründe, wie ein einheitliches Management innerhalb der VM, was bei Dingen wie pfSense usw. natürlich Sinn ergibt.

VLAN muss übrigens deine gesamte Infrastruktur können, wenn du es benutzen möchtest. Sobald deine Verbindung über einen physikalischen Switch läuft, der kein VLAN kann, funktioniert der ganze Spaß nicht mehr.