Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
DDA wäre PCIe Passthrough, wird sonst vorwiegend für GPUs genutzt. Muss dann halt auch das Board & CPU des Hosts unterstützen und ja natürlich macht das einen Unterschied wenn du es am eigentlichen Host testest oder woanders... Ganz brauchbarer Artikel dazu inkl. Verlinkungen zu Voraussetzungen, dem machine profile script etc: https://docs.microsoft.com/de-de/wi...ying-devices-using-discrete-device-assignment
Kein klickibunti, direkt Powershell. Wäre nicht das erste Mal, das MS manche Funktionen nur per CLI zugänglich macht.
Warum willst du unbedingt DDA oder SR-IOV nutzen bzw. was erhoffst du dir davon? Wenn du unterschiedliche VLANs nutzen willst: Warum nicht einfach an jede physikalische NIC (pNIC) einen vSwitch mit VLAN-ID und der pfSense VM vier virtuelle NICs (vNICs) verpassen? Dann hast am Ende vier vSwitche mit den VLAN-IDs 101, 102, 103 und 104 und je einer pNIC und einer vNIC.
Weitere VMs hängen dann einfach an nem eigenen vSwitch und da hängst weitere vNICs der pfSense dran damit Pakete gar nicht erst den Host verlassen müssen.
Ansonsten probiere es doch aus, je einmal mit DDA und einmal mit SR-IOV mit bisschen Lasttests und machst nen schönen Leserartikel daraus
@snaxilian Wie ginge das denn mit SR-IOV? VLAN habe ich nicht. Möchte lediglich pfSense direkten Zugriff auf die NIC geben, weil es sich bei mir komisch verhält. Bin noch auf Hyper-V mit Win10.
Ansonsten wiederhole ich meine Frage: Brauchst du DDA oder SR-IOV in der Realität oder nur Spieltrieb? Gerade wenn letzteres: Welche Anleitungen hast du schon gefunden, wo genau kamst du nicht weiter und an welcher Stelle hakte es?
@snaxilian Will mich nur vorab informieren. Habe jetzt gesehen, dass SR-IOV wohl nur eine Checkbox ist. Noch habe ich den Server aber nicht neu aufgesetzt und das Problem ist, wenn ich das mache, sollte er auch direkt optimal laufen, weil z.B. der Router etc.
Ich will halt optimale Bedingungen für pfSense schaffen, soweit das mit Hyper-V überhaupt möglich ist. Was ich jetzt zu SR-IOV gelesen habe, sollten auf dem Host und Guest die gleichen Treiber laufen? Das geht bei mir nicht mit pfSense, da ja ein anderes OS. Kannst Du dazu was sagen? Klingt auf jeden Fall unlogisch. Wäre das tatsächlich der Fall, dann müsste ich DDA nutzen.
Ich frage mich ja immer wo Leute diesen ganzen Quatsch lesen oder meinen gelesen zu haben denn die Doku ist da ziemlich eindeutig: https://docs.microsoft.com/en-us/wi...linux-and-freebsd-virtual-machines-on-hyper-v
Ja, der Host braucht für die Hardware passende PF Treiber und der Gast, pfsense in deinem Fall, braucht passende Treiber, die die VF Funktionalität unterstützen. Bei plain FreeBSD ist dies seit 11.0 angeblich der Fall, ob und wie das bei pfSense ist ist aber nicht die Baustelle von MS, das musst du bei pfSense heraus finden. Wenn du dem zweiten Link in #4 gefolgt und bis zum Ende gelesen hättest, wüsstest du ob und wie man dies bei pfSense ggf. erzwingen kann.
Aber: SR-IOV ist ein nicht ganz so schöner Kaninchenbau in den man echt nur krabbeln sollte wenn man dies muss. Zuhause, bei einer absolut überschaubaren Anzahl Endgeräte und Anwendern und einer Internetanbindung von in der Regel unter 1GBit/s interessiert SR-IOV absolut niemanden. So gar nicht. Absolut wirklich nicht. Du machst dir Gedanken um Probleme die in deinem Anwendungsfall nicht existent sind.
Mach DDA wenn du wirklich meinst die Performance zu benötigen. Im Vorfeld irgendwelche Gedankengänge sich zu überlegen hilft niemandem. Probier es aus, sammle Erfahrungen, lerne daraus. Reiße Systeme andauernd ab und bau sie neu auf. Gieß dein Setup in Powershell und pack es in ein git deiner Wahl dann hast du es jederzeit neu ausgerollt.
Hinzu kommt: Du schreibst von Win10 mit Hyper-V: Dir ist bewusst, dass SR-IOV dort in keinster Weise unterstützt ist?^^
Probier es aus, sammle Erfahrungen, lerne daraus. Reiße Systeme andauernd ab und bau sie neu auf. Gieß dein Setup in Powershell und pack es in ein git deiner Wahl dann hast du es jederzeit neu ausgerollt.
Äh, ich bin kein ITler und will auch keiner werden, deine Vorschläge mögen für dich passen, bei mir nur Bahnhof. Dazu kommt, das ist kein homelab, das ist mein Homeserver und Router und wird ständig gebraucht, also keine Spielwiese.
snaxilian schrieb:
Hinzu kommt: Du schreibst von Win10 mit Hyper-V: Dir ist bewusst, dass SR-IOV dort in keinster Weise unterstützt ist?^^
Ja, wie schon der Titel aussagt. Deswegen wird ja auch alsbald gewechselt.
Ich will ja nur, dass pfSense seine intel-NIC hat und keine virtuelle. Es scheint als könnte ich das mit beiden "Verfahren" erreichen. Du würdest dann eher DDA empfehlen.
SR-IOV wäre natürlich trotzdem interessant. Werde es wohl mal probieren und bei Problemen zu DDA wechseln.
Was die FreeBSD Versionen betrifft, da scheint pfSense "golden" zu sein.
Ich werde wohl eine meiner M.2 in eine Adapter packen, dann kann ich die direkt durchreichen für TRIM etc. Mal sehen, ob ich mit WinServer zurechtkomme. Mag den Trend zu immer mehr Powershell-Zeugs überhaupt nicht. 😉
Soweit ich das verstehe bedeutet SR-IOV, dass die VMs direkten Zugriff auf die NICs haben. Sofern du kein 10Gb Netz daheim hast, ist es eigentlich irrelevant, die vSwitches in Hyper-V handeln 1Gb Traffic ziemlich gut.
Jetzt wäre noch die Frage, was die Pf bei dir machen soll. Ist sie nur ein Router, der ins Internet raus routet und eingehenden Traffic blockt. Ggf. noch mit Filterregeln und so Schnickschnack. Oder hast du die Pf, weil du auch eingehenden Traffic hast, du also beispielsweise einen eigenen Webserver betreibst?
Szenario 1: mach es mit vSwitches. Verkünstel dich nicht, die Performance ist ausreichend, das läuft.
Szenario 2: schlechte Idee. Lass die Pf nativ auf einem eigenen Blech laufen. Oder nutze, falls eigenes Blech nicht in Frage kommt, DDA. Denn eingehender Traffic würde sonst als erstes an den vSwitch deines Hyper-V Hosts gereicht und der leitet das an die Pf weiter. Ein Angreifer könnte nun mögliche Sicherheitslücken in der vSwitch Implementierung von Hyper-V ausnutzen und ggf. die Kontrolle über den Host übernehmen. Mit DDA landet er direkt auf der pf und würde im Worst Case die VM übernehmen. Aus der dann auszubrechen wäre weiterer Aufwand.
DDA würde aber am Ende auch Powershell bedeuten. Aber die Dokus im Netz dazu sind i.d.R. gut brauchbar.
@Chris_S04 Leider läuft sie bei mir nicht ganz rund. Deswegen soll die virtuelle pfSense ja direkten Zugriff auf die Hardware haben. Ich kann deinem Beitrag nicht entnehmen, ob Du nun gegen SR-IOV bist oder nur für DDA.
Vorteil von SR-IOV wäre es denke ich, dass die vSwitch-Funktionalität erhalten bliebe, nur performanter. Zumindest für einen Port könnte ich dann diesen nicht nur für die pfSense nutzen, sondern auch für den Host, um sich mit einem echten Switch zu verbinden, so wie das jetzt auch schon geht.
Beispiel: pfSense gibt über Port4 Internet an den physischen Switch. Der Host wiederum nimmt das Internet von diesem Switch über die selbe Verbindung.
Powershell = mächtiges CommandLineInterface (CLI) unter Windows mit dem man so ziemlich alles an Windows-Features installieren, deinstallieren und konfigurieren kann.
Git = Versionskontrollsystem, bekannteste privat nutzbare Plattformen dürften github oder gitlab sein
Du überlegst dir also Schritt für Schritt was du alles an Einstellungen und Features brauchst und packst es in ein oder mehrere Powershell Skripte und lädst die bei einem der genannten git-Hoster (oder anderen deiner Wahl) hoch in private(!) Repositories.
Raucht dir dein Serverchen ab durch Hardwareschaden oder ein Update oder Eigenverschulden dann nimmst Ersatzhardware, holst dir deine Skripte aus dem Git, lässt diese drüber laufen und bist wieder bei einem lauffähigen System mit gewünschten Einstellungen.
Bob.Dig schrieb:
dass pfSense seine intel-NIC hat und keine virtuelle
Warum zur Hölle nochmal? Ich stimme da @Chris_S04 vollkommen und 100%ig zu. Du siehst Probleme wo absolut gar keine sind. Warum diese Fixierung auf SR-IOV oder DDA? Ja, bei *BSD auf Hardware hat sich gezeigt, dass NICs von Intel zu bevorzugen sind. Das gilt für Hardware, nicht bei vNICs.
Da steht auch nix von irgendwelchen Performanceproblemen in der Doku von pfSense.
Dann löse dieses Problem anstatt es mit noch mehr beteiligten Komponenten und einer deutlich höheren Komplexität zu bewerfen. SR-IOV fängt bei 10G erst an interessant zu werden weil die vSwitche (der meisten Hypervisoren, nicht nur beschränkt auf Hyper-V) da langsam an ihre Grenzen kommen. Wenn ich also ein 10/25/40G Interface am Host habe und pumpe Unmengen viele Daten in die VM oder hole diese von der VM dann ist das ein absoluter Use-Case für SR-IOV.
Die Lernkurve bei Netzwerken wird sehr schnell sehr steil und noch steiler wenn man man solche Virtualisierungen rein bringt. Ich mach den "Quatsch" beruflich seit vielen Jahren und eine goldene Regel hat sich immer bewahrheitet: KISS - Keep It Simple Stupid.
Bob.Dig schrieb:
Beispiel: pfSense gibt über Port4 Internet an den physischen Switch. Der Host wiederum nimmt das Internet von diesem Switch über die selbe Verbindung.
Damit hast du dann den Sinn und Zweck der Firewall ausgehebelt. Am WAN Port der pfSense sollte einzig und allein das Modem stehen.
Ansonsten sehe ich weiterhin potentielle Probleme bei deinem Vorhaben als Host Win 10 mit HyperV zu verwenden. Du wirst dir nie 100%ig sicher sein, dass "Client"-HyperV und Server-HyperV identisch sind und gleiche Features haben. Ein Großteil der Tutorials basiert jedoch auf der Server-Variante.
Ich schließe mich @snaxilian an.
Versuche das Problem mit der virtuellen pf erst Mal zu lösen. Eigentlich läuft das Teil unter Hyper-V, hatte ich auch Mal testweise laufen, OPNsense auch.
SR-IOV bringt dir erst bei hohen Transferraten einen Vorteil, erhöht die Komplexität des ganzen aber enorm. Ich würde dir raten das sein zu lassen.
Es steht noch immer die Frage im Raum, was die pf nun machen soll. Ist sie einfach der Router, der ggf. Netze voneinander trennen soll und Traffic nach außen filtert (z.B. Blacklist von Domains o.Ä.) oder regelt diese auch eingehenden Traffic?
Falls ersteres: wieso die pf? Ist die notwendig?
Falls zweiteres: Pack die pf auf einen eigenen Rechner. Wieso hatte ich schon Mal geschrieben. Außer eben du verwendest DDA, aber das wäre imho eher die zweitbeste Lösung. Ich würde empfehlen eine FW immer nativ auf einem eigenen Host zu betreiben um die Angriffsfläche und den möglichen Schäden geringer zu halten, bzw. den Aufwand des Angreifers zu erhöhen um "weiter voran" zu kommen in deinem Netz.
Bob.Dig schrieb:
Beispiel: pfSense gibt über Port4 Internet an den physischen Switch. Der Host wiederum nimmt das Internet von diesem Switch über die selbe Verbindung.
Auch da hat @snaxilian absolut Recht. Am WAN Port der Firewall darf maximal dein Internetzugang stehen, also dein Router oder Modem. Mehr nicht, ansonsten hebelst du sämtlichen Sinn der FW aus. Jeder Traffic von intern nach extern oder eben, falls du das wünschst, extern nach intern muss zwingend durch die pf, ansonsten ist das Konstrukt wirkungslos.
Auch da hat @snaxilian absolut Recht. Am WAN Port der Firewall darf maximal dein Internetzugang stehen, also dein Router oder Modem. Mehr nicht, ansonsten hebelst du sämtlichen Sinn der FW aus. Jeder Traffic von intern nach extern oder eben, falls du das wünschst, extern nach intern muss zwingend durch die pf, ansonsten ist das Konstrukt wirkungslos.
Absolut, das war auch nur @snaxilian, der das so interpretiert hat. Selbstverständlich handelt es sich dabei um einen "LAN"-Port.
@snaxilian War ja schon spät, aber nochmals für Dich, das Ganze soll mit WinServer umgesetzt werden, weil das anders gar nicht geht.
@Chris_S04 Mein Anwendung wäre erstes und zweites. Ich pack das Ding nicht auf einen eigenen Rechner, weil ich Geld sparen möchte und es vom Prinzip auch virtuell laufen sollte. Die Probleme, die ich momentan habe, kann sich keiner erklären (pfSense-Forum), daher mein Versuch mit der physikalischen NIC.
Was die Sicherheit betrifft, ich könnte wohl auch die WAN-Ports per DDA durchreichen und die LAN-Ports per SR-IOV realisieren? Wie schon mehrfach gesagt, es geht mir bei SR-IOV nicht um den möglichen Performancegewinn, sondern darum, dass die pfSence direkt die NICs sehen kann.
Ergänzung ()
PS: Aber eure Skepsis über die Sinnhaftigkeit meines Projektes ist mir natürlich nicht entgangen. Daher Zeit für einen erneuten Test:
Tatsächlich hatte ich mir für mein Vorhaben vor ein paar Tagen eine alte intel-quad-Port NIC bei ebay geschossen. Nun habe ich gerade das erste mal getestet, ob das Problem damit überhaupt noch auftritt und ... es tritt jetzt gerade nicht mehr auf. 😀
Das bedeutet, alleine der Wechsel von zwei Realtek NICs auf die intel-NIC, unter Verwendung von Hyper-V auf Win10, also nur vSwitches ohne SR-IOV, scheint das Problem gelöst zu haben.
Also kann ich das Projekt eigentlich sofort beerdigen. Werde aber noch über den Tag verteilt testen und das Ganze wahrscheinlich dennoch realisieren, wenn nun nicht der Stabilität halber, dann wegen der gesteigerten Sicherheit (mögliche Sicherheitslücken im vSwitch).
PPS: Ein Problem scheint immer noch da zu sein, unter Verwendung eines Software VPN-Clients in einer VM kommt es zu Packetloss am WAN in der pfSense. Mal sehen, was passiert, nachdem ich WinServer aufgesetzt habe.
Wenn du dir die Powershell Befehle alle in richtiger Reihenfolge notiert hast bist für den Worstcase jedoch gut vorbereitet und hast mehr über die Funktionen gelernt ggü. Knöpfchen in einer GUI drücken. Naja nicht unbedingt aber MS geht wie gesagt dazu über immer mehr Features & Infrastruktur as a Code auszuliefern.
Du hast echt Spaß daran, dir das Leben unnötig komplex zu machen, oder? So wie ich es heraus lese willst du die per DDA durchgereichte NVMe für die pfsense nutzen? Falls ja: Anleitung befolgt? Wenn du statt pfsense testweise ein aktuelles Linux oder Win10 booten und installieren willst: Wird da die NVMe erkannt? Nur um herauszufinden ob es ein generelles Problem ist oder an pfSense liegt...
Dir ist bewusst, dass das Thema Disk Passthrough und Performance ab Server 2016 quasi zu vernachlässigen ist? (Beispielhafte Quelle)
Du handelst dir wieder mehr Komplexität als notwendig ein anstatt dem Host die NVMe zu lassen, dort eine VHD/VHDX zu erstellen und diese der VM zu geben. Bei Gen2 VMs sollte die VM korrekt erkennen, dass die VHDX auf einer SSD liegen und entsprechen "trimmen". Wichtig: Bei Linux und *BSD VMs muss je nach Distribution oder Version SecureBoot deaktiviert werden. Auf der anderen Seite sind Gen2 VMs wohl zickig beim Boot from ISOs zur Installation je nach ISO 🤷♂️ Da ist man wieder froh, sich damit nicht (mehr) herum ärgern zu müssen und kämpft lieber mit anderen Problemen
Ansonsten wäre mir neu, dass pfSense so schnellen Storage voraus setzt bzw. davon überhaupt groß profitiert wenn man nicht Unmengen Daten cachen will aber meist gibt es dafür gute/bessere/modernere Alternativen je nach Use-Case.
Wie immer "problematisch" wenn man Technik und Kenntnisse aus der Consumerwelt mit Enterprise vermischt. Wenn ich selbst Hardware beruflich betreibe/bestelle klicke ich im Angebot auf "write intensive" SSDs, kümmere mich um Redundanzen per Raid-Controller oder software-defined-storage Lösungen und gebe Rechnung dem Kunden oder Chef und wenn etwas ausfällt kommt in definierter Zeit Ersatzhardware und/oder Techi und tauscht aus. Ja, das ist in gewissem Maße aktives Geldverbrennen aber wenn ich die Zeit dagegen rechne um mich mit so etwas beschäftigen zu müssen puh dann mache ich da lieber etwas anderes wenn ich es nicht unbedingt lernen will weil man passionierter Storage-Admin ist oder so^^
@snaxilian
Die nvme ist nicht für die pfSense, sondern für ein Windows. Da ich dort nun auch BitLocker eDrive nutzen möchte, muss schon der ganze Controller durchgereicht werden, mit vhdx möchte ich an der Stelle nicht arbeiten.
Und die Anleitung habe ich befolgt, mein Problem ist, dass die VM nicht vom durchgereichten nvme booten kann, vermutlich normal, aber man kann ja mal fragen.
Was die Generation betrifft, da hatte ich mit pfSense und DDA bei den NICs tatsächlich Probleme, ich musste auf Gen1 ausweichen. Gen2 konnte pfSense nicht vollständig booten, sowohl mit der Final, als auch mit der Development.
