Problem: VLAN Routing, bhyve & Server VM

naja cisco bedient halt noch FDDI und Tokenring was die meisten , vermutlich ,
nicht mehr kennen.

Holger
 
Moin ihr Lieben,

vielen Dank für eure Unterstützung und frohe Pfingsten erstmal...

Habe jetzt alle eure Hinweise befolgt und so weit wie es ging umgesetzt:
Cisco factory reset und diese Standard Konfig soweit belassen wie möglich --> ssh aktiviert und DHCP client gelöscht
VLAN1 ist default und kann nicht (so ohne Weiteres) gelöscht werden
Interface ist 192.168.1.254

Richte dir doch mit bhyve passthrough eines einzelnen Ports (geht problemlos bei Intel, bei anderem Hersteller muss man mal schauen/probieren) deiner NIC ein, dann sparst du dir den Umweg über den bhyve-vswitch sowie Latenz und dort aufprallende Pakete gehen direkt zu pfSense. In pfSense siehst du den Port dann mit der echten MAC und als Gegentest ist er auf dem Host verschwunden. Ich weiß nicht genau, wie sich das bei pfSense verhält, bei opnsense braucht man es nicht, aber schaden tut es auf keinen Fall: füge diesen Port als 'blanko'-Interface hinzu. Nur den Haken bei 'enable Interface' rein, IP auf none lassen, nichts weiter konfigurieren, als Name bietet sich 'trunkport_cisco' an. Das ist, damit das Interface auf jeden Fall 'up' kommt.
Nun setzt du darauf deine vlans in pfSense. Jedes einzelne VLAN fügst du nun in der Sense als Interface hinzu, für die Übersichtlichkeit als name v10, v20, v30. Der Einfachheit fürs Verständnis bietet sich jeweils 192.168.10.1/24, 192.168.20.1/24 und 192.168.30.1/24 an.
Zurück auf dem Cisco

... das funktioniert leider nicht / kann nicht funktionieren?
denn wenn ich dem LAN IF die IP wegnehme erreiche ich die pfSense gar nicht mehr, das mündet in eine Neuinstallation, schon zwei mal...

Auf der ersten bhyve Kiste ist irgendwas mit DMAR Kompatibilität nicht gegeben (vt-d der CPU nicht wirklich standardmäßig, darum hat das mit dem passthru nicht richtig funktioniert und hat mich einen ganzen Tag gekostet)

Also andere Kiste, ebenfalls 4 ethernet Ports und 4Core Celeron 16G RAM, FreeBSD 13.2 from the scratch und vm-bhyve installiert und soweit funzt es jetzt (auch genau in dieser Reihenfolge konfiguriert):
igc0 ist auf der Kiste für passthru maskiert (Das scheint bei mehr als einem IF übrigens nicht in der loader.conf zu gehen)
igc1 hat auf der Kiste 192.168.1.10 fest zugewiesen
igc2 hat auf der Kiste DHCP und ist direkt mit der fritzbox verbunden und funktioniert

2 virtuelle switches angelegt public und igc1 zugefügt, sowie custom mit igc2,

pfSense in neuer, entsprechend der igc* konfigurierten VM installiert.

Bei der Installation folgende Konfiguration angegeben:
igc2 wird als VTNET1 in die VM gereicht und wird als WAN Interface konfiguriert und bekommt von der fb eine passende IP zugewiesen
igc1 wird als VTNET0 in die VM gereicht und ist das LAN interface mit der Standard IP 192.168.1.1
igc0 ist durch passthru native in der VM und ist das OPT1 interface.
Auf dieses Interface habe ich die VLANs 10, 20 und 30 angelegt
Vom Client standardmäßig im VLAN1 des Cisco und fixer IP 192.168.1.101 habe ich sofort zugriff auf die FW und internet
Hier kann ich dann den VLANs auf dem nativ igc0 IF die IP Adressen zuweisen 192.168.10.1 (für VLAN10) *.20.1 für 20 etc

Auf der FW 2 any2any Regeln für Opt1 (VLAN10) und opt2 (VLAN20) angelegt

Auf dem CISCO ebenfalls die VLANs angelegt:
Port 24 ist Access Port im VLAN 1 und mit dem LAN IF (IP 192.168.1.1) der pfSense verbunden (Das ist der Notfallport über den ich auf jeden Fall die FW Erreiche)
Port 12 ist Trunk mit VLAN10 getagged

Port 6 ist als Access auf VLAN 10 untagged gelegt
Alle andern VLAN1 untagged (standard)
Stöpsel ich den Client irgendwohin (VLAN1) komme ich auf die FW, habe Internet und kann die Kiste, den CISCO anpingen, sowie die VLAN IF *10.1 ,*20.1 und *30.1 auf der FW anpingen
Das ist schon verwunderlich, da im Trunk des Port 12 nur VLAN10 angegeben ist nicht aber 20 oder 30 und VLAN1 sollte er auch nicht mehr kennen, trotzdem kann ich sie anpingen

--> Ende der guten Nachricht

Stöpsel ich den Client auf Port 6 mit VLAN10, ändere seine IP auf 192.168.10.101 kann ich nur noch das eigene IF anpingen sonst nix mehr

Das Fehlerbild ist jetzt ein anderes, bin aber eigentlich keinen Schritt weiter (Außer das ich viel gelernt habe)

Habe mich jetzt bei den Konfigs auf das Wesentlich beschränkt um den Beitrag nicht zu lang werden zu lassen. Ich kann aber asap Konfigs vom Cisco, bhyve Kiste oder pfSense hier posten

Vielen Dank & Gruß

Thorsten
 
.. das funktioniert leider nicht / kann nicht funktionieren?
denn wenn ich dem LAN IF die IP wegnehme erreiche ich die pfSense gar nicht mehr, das mündet in eine Neuinstallation, schon zwei mal...
Beim Wegnehmen klar, aber der Unterschied ist wo sie aufgelegt ist. Liegt sie auf einem vtnet von einem vswitch mit oder ohne physischem port auf oder auf einem port, der via passthrough drinhängt? Und dann noch, ob das seitens pfsense tagged oder untagged 'rauskommt'. Ich weiß, das ist initial verwirrend und das LAN IF ist der Ast auf dem man sitzt während der Einrichtung.
Es verwirrt und erschwert auch noch mehr, wenn man das remote einrichtet und im gleichen Netz des Hosts bleiben will, damit SSH nicht abreißt.

Stells dir vielleicht sorum erstmal vor, auch aus Clientsicht: angenommen passthrough läuft, igc0 und igc1 sind in der vm und du hast noch nichts angestöpselt. igc0 ist dein WAN, igc1 ist dein LAN. Bis hier eine ganz normale Basis-Einrichtung von pfsense.
Der Unterschied ist aber: du hast erstmal keinerlei Verbindung auf den Host. Weder in pfsense (weiß davon gar nichts) noch physisch außen. Der Trick ist hier durch Hinzufügen von weiteren Netzen Zugang zum Rest zu bekommen, quasi Ausgangspunkt immer das LANIF der sense. Da die Überlegungen also wie komme ich nun via LANIF zum Host, zum vlan$, zur fritzbox...?
Die andere Variante wo die physischen ports einfach nur dazugehängt werden, find ich sicherheits-/performancetechnisch weniger pralle, aber wenn passthrough nicht geht, gehts nicht anders.
Gleicher Aufbau, zwei vswitche, noch kein einziges Kabel gesteckt. Gedankliche Erinnerung: ab hier hat dein physischer Host noch keine IP und du bist nicht via SSH drauf. Du erstellst vswitch0, der bekommt igc0 hinzugefügt. Das mündet in pfsense als vtnet0 und gibt dein WAN. Vswitch1 bekommt igc1 und mündet in vtnet1 als LAN. Die defaultIP von sense 192.168.1.1 liegt auf vtnet1 an, aber du erreichst diese (untagged) jetzt auf dem physischen igc1 (...und der host aber auch durch die mangelnde Trennung).
Ab hier macht man dann die weiteren Überlegungen, wie man weiter ausbauen möchte. Immer im Hinterkopf: Falsche/unüberlegte Änderungen, die die Kette vtnet1/igc1/vswitch1 betreffen können den Zugang zur sense abreißen lassen.


Auf der ersten bhyve Kiste ist irgendwas mit DMAR Kompatibilität nicht gegeben (vt-d der CPU nicht wirklich standardmäßig, darum hat das mit dem passthru nicht richtig funktioniert und hat mich einen ganzen Tag gekostet)
Jep, man braucht eine funktionierende IOMMU und vt-d bzw. amd-vi. Es reicht nicht, wenn die CPU das kann, das Mainboard und dessen BIOS müssen das unterstützen/freigeschaltet haben. Ggf. muss man die IOMMU von auto auf enabled wechseln, sowie SVM, wenn vorhanden. Dann sollte das klappen. Das 'geht problemlos bei Intel mit Einzelports' war auf den Netzwerkchip bezogen, nicht auf die CPU. ;)

Wenn du jetzt wohin pingen kannst, obwohl es nicht möglich sein sollte, dann ist da was zuviel gebridget und so leid mir das jetzt tut: nochmal zurück auf Los.

igc0 ist auf der Kiste für passthru maskiert (Das scheint bei mehr als einem IF übrigens nicht in der loader.conf zu gehen)
Doch, so: pptdevs="1/5/0 1/5/1"
Was ich da meinte war, dass es darauf ankommt, wie der jeweilige NICChip verdrahtet ist. Im dummen Fall geht nur die komplette deviceid (1/5/0 als Beispiel) inkl. aller Ports, bei Intel einzelne Ports eigentlich immer. Mit pciconf -lv sollte man das alles aufgelistet bekommen.
Dazu sei noch zur zusätzlichen Verwirrung erwähnt, dass z.B. ein für passthrough definierter port4 der NIC oft die 3 als devid hat und in der VM dann als igc0 erscheint, weil die Aufzählung immer bei 0 beginnt. Daher besser die Augen auf die MAC richten.

Noch ein Tip: mittels vm console $meinvmname kommt man vom Host aus auf pfsense und kann den Resetmodus auslösen, bei opnsense ist das die "4". Spart eine Neuinstallation. :)

Zum Trost: aller Anfang ist schwer, ich hab auch einige viele Resets in meinem Leben gemacht...aber das Gelernte sitzt dann.
 
das ist nix verwunderlich ,

vlan1 = nativ vlan per default .... von daher ist vlan1 nicht loeschbar.

Holger
 
Ich hab jetzt weder für opnsense noch für pfsense ein ausführliches Tutorial gefunden, aber diese Blogbeiträge kommen nahe ran inkl. weitere genaue Erklärungen zur Ergänzung:
 
Doch, so: pptdevs="1/5/0 1/5/1"
nä, dann nimmt er IMMER igc3, EGAL ob ich "1/0/0" für igc0, "2/0/0" für igc1, "3/0/0" für igc2 oder "4/0/0" für igc3 angebe, es ist immer igc3
Das ist auf beiden Kisten so igc* für realtec oder em* für intel auf der anderen Kiste...
... egal man kann es auch nachher mit "devctl set driver -f pci0:1:0:0 ppt" machen, dann wird igc0 abgehängt und in der pciconf -v -l erscheint ppt0:0:1:0:0, die ich dann mit passthru0="1/0/0" in die VM übergebe. Auf der Kiste ist es komplett weg und ich kann dem übergeben icg0 (heißt wirklich so) in der VM eine IP geben (Ausprobiert mit eine TestVM und nur dieses IF angestöpselt)

Bei der pfSense kommt man da nur auf einen Terminal, der "quasi" abgestürzt ist, da steht sowas wie "Boot up complete" und es regt sich nix mehr.
Einzige Lösung mit ssh, aber ohne IF kein Zugang!

so sieht das dann aus:
1685379727587.png


Abgesehen von den IP Adressen bei OPT2 & OPT3 ist das bis dahin alles durch die CLI bei der Installation konfiguriert, nirgends ein Kabel angestöpselt

WAN auf vtnet1 funktioniert und ist NUR über die Firewall oder Internet mit der Firewall erreichbar lässt sich nicht anpingen von nirgends --> funktioniert also wie es sein sollte, optional kann man nachher noch das IF der Kiste in die pfSense passthrun um noch mehr Isolation zu bekommen

Nach dem factory reset des Cisco, den Client und die die Kiste angestöpselt und dank VLAN1 und der Cisco IP 192.168.1.254 aus der Standard Konfig hatte ich sofort Internet.
Dann vlan 10 und vlan 20 angelegt, Port 24 als Trunk mit den VLANs 1U , 10 & 20 jeweils T konfiguriert --> noch gehts!
Port 6 als access ins vlan10 gejoint, Client IP auf 192.168.10.101 geändert, kein Ping mehr nirgends wohin!
Port 6 ind Client IP wieder zurück: Ping & Internet geht!
Aus dem Trunk das vlan 1 entfernt --> wieder alles dunkel

Das ist der aktuelle Status (vlan1 wieder in den trunk, sonst könnte ich das hier nicht schreiben)

Ich kann jetzt nicht behaupten, dass unerlaubt irgendwo hingepingt werden kann und ds trunking zumindest mit vlan1 scheint irgendwie zu funktionieren

Den Stöpsel zum igc0, dass ist das passthrute, kann man übrigens getrost abziehen, es geht ALLES über das vtnet0 mit der Standard IP 192.168.1.1, die anderen IF der vlans erreiche ich über diesen Port.

Andersherum habe ich spasseshalber mal eine IP auf das vtnet0 (192.168.2.1) gelegt und das igc0 direkt mit einem anderen Client (192.168.2.101) direkt verbunden und ich kann die pfSense anpingen, passthru funktioniert also

@Holger: und wie du schon sagst: Man lernt sehr viele Dinge (Was bei mir übrigens der Hauptzweck ist, das nachher funktionierende Netzwerk nehme ich billigend in kauf!
Aber ohne euch wäre ich aufgeschmissen - danke & Gruß

Thorsten
 

Anhänge

  • 1685377719553.png
    1685377719553.png
    371 KB · Aufrufe: 56
Vielen Dank, diese Blogs und noch mehr hatte ich auch schon gefunden

Gaelan D'costa - PCI passthru in bhyve

The blog of Gaelan D'costa
robotdisco.github.io
robotdisco.github.io
... er hat das gleiche Problem:
  • MINI-NOTE: Some addon cards have multiple devices, which would show up as like two triplets, 9/0/0 and 9/0/1 or whatever. An example of this would be a network card with two or four thernet ports. Some devices are unhappy if you only pass through a subset of triplets … I don’t really understand it.
 
AUWEIA, böser Fehler:

1685383408640.png


als ich eben noch mal durch den Thread gescrollt habe, ist es mir zufällig im ersten Screenshot oben aufgefallen
Der Bit Count der subnet mask war fälschlicherweise auf 32 (Standard bei pfSense) gestellt,

Habs jetzt auf 24 korrigiert und zack: GEHT!

noch nicht ganz so wie ich will, aber immerhin ich komme mit einem PC aus dem vlan10 ins internet und NUR dort hin!
Habe noch flugs einen DHCP auf das IF konfiguriert und die Clients aus vlan10 bekommen eine IP, Gateway & DNS...
MANN, ich mach mir jetzt erstmal 'n Bier auf, wollt ihr auch eins?

Morgen gehts dann darum den Cisco irgendwie auch aus den vlan10 & 20 zu erreichen ohne umzustöpsel, steht aber ja weiter oben im Thread beschrieben

Vielen Dank noch mal an euch für eure Unterstützung

Thorsten
 
Habs jetzt auf 24 korrigiert und zack: GEHT!
Äh ja, das stach auf dem screenshot hervor...(passiert mir aber heute immer noch, so Flüchtigkeitskrams!) :)

'n Bier auf, wollt ihr auch eins?
Immer! :D

Schade, dass das mit dem passthrough so buggy reagiert. Normalerweise klappt das und wenn du sagst, dass das mit beiden NICs so ist, dann liegt das wohl an der Implementierung vom Mainboard. Hat das schon die letzte firmware drauf?
Wenn ja, dann würde ich nochmal genau alle Optionen im BIOS durchforsten.

Edit, was vergessen:
Durch den Erfolg bist du ja jetzt befeuert und weißt grob wie alles nun zusammenspielt, aber ein weiterer guter Tip ist das LAN-IF auch für die Übergangsphase zu sattelfest als Notfallport 'in die Kiste rein' anzusehen. ;)
 
naja, diese Kisten sind so billige China Böller, der eine aus 2017 mit J1900 CPU und der andere, auf dem es jetzt läuft ist vor zwei Monaten gekauft, aber ne ältere Version noch mit nem J4125 mit dem Erfolg dass ich Win11 nicht drauf zum Laufen bekommen habe - nun denn, jetzt hat er ja noch eine "vernünftige" Funktion bekommen, vor allem weil er AES HW Verschlüsselung kann, für VPN Gedöns.. Der andere kann das auch nicht.
Muss mal schauen, ob es ein Neures AMI gibt, die Einstellungen im BIOS habe ich durch, das müsste passen.

Erstmal alle Grundfunktionen, eben auch den Emergency Path fixieren und dann noch mal alles auf NULL und von vorne, dabei aber peinlichst genau dokumentieren und einen Notfallplan erstellen - In 5 Jahren blicke ich garantiert nicht mehr dadurch...
... ist wie damals beim Programmieren: //Kommentare sind was für Langweiler... ich habe auch in Perl programmiert und da kann man so richtig schmutzig sein, von wegen der $_ und @_ Standard Variablen, die, wenn man sie nicht angibt, als Pointer auf den CPU Stack zeigen und so rattenschnell ist das man es manchmal nicht glauben kann...
Muss man auch nur zwei Jahre später an so einem Code was ändern steht man mit vielen Fragezeichen auf der Stirn vor seinem eigenen Erzeugnis!

Gruß
 
Zurück
Oben