May 05, 2023

2733

OpnSense Portweiterleitung in Kaskade

Hallo,
ich habe ein kleines Problem in meinem Netzwerk.
Aber zuerst mein Setup, da wir hier zur untermiete wohnen und das Haus keine zwei Internetanschlüsse unterstützt musste ich in den sauren Apfel beißen und die Internetverbindung der Hauptmieter mitbenutzen.
Da dort so gut wie kein Wert auf Absicherung des Netzweks gelegt wird und alle meine Angebote dies zu übernehmen verneit werden habe ich eine OpnSense eingerichtet um unser Heimnetz aktiv von dem Hauptnetzwerk abzutrennen.

Das hat auch alles wunderbar geklappt, mir ist natürlich bewusst das Doppel NAT bzw Kaskaden zu vermeiden sind, allerdings ist das hier nicht möglich da ich den Router leider nicht ersetzen darf.

Hier ein Netzwerkplan zur Illustration:

   WAN / Internet
            :
            : VDSL-/Telekom
            :
   .-----+-----.
   |  Router    | (T-Com Speedport Smart 3)
   '-----+-----'  
            |
            |           .-------------.
            +----+ LAN-Switch +---------------------------+
            |           '-------------'                                          |  
            |                                                                 .-----+-------.       .-------------.
            |                                                                 |  OPNsense +---+  WLAN AP  |  
            |                                                                 '-----+-------'       '-------------'  
            |                                                                          |
  LAN1 | 192.168.2.0/24                                        LAN2 | 192.168.10.0/24
            |                                                                          |
   .-----+-------.                                                     .-----+-------.
   | LAN-Switch |                                                    | LAN-Switch |
   '-----+-------'                                                     '-----+-------'  
            |                                                                          |
  ...-----+------...             (Clients/Server)             ...-----+------...

Nun zu meinem Problem:
Ich versuche einen Mediaserver der im LAN2 steht einem Gerät aus dem Koppelnetz LAN1 Zugriff zu geben.

Ich habe es bereits mehrfach mit eine Portweiterleitung versucht komme aber nicht weiter.
Ich habe ein Paar Bilder von meiner Regel und den Einstellungen gemacht. Vielleicht fällt ja jemandem etwas auf was helfen könnte.

Danke schonmal. Falls noch Infos gebraucht werden oder ich etwas vergessen habe einfach nachfragen.

Please also mark the comments that contributed to the solution of the article

Content-Key: 7026657783

Url: https://administrator.de/contentid/7026657783

Printed on: April 27, 2024 at 08:04 o'clock

43 Comments

Latest comment

Mist, ich sehe grade das mein ASCII Netzwerkplan nicht wirklich übernommen wurde. Ich hab mal nen Screenshot gemacht und lade den mal hoch.

Häng doch das OPNsense direkt nach den Router, behandle beide Wohnparteien als zwei Subnetze am OPNsense . Dann sparst du dir auch das Doppel-Nat.

In diesem Post geht es nicht darum ob oder wie ich das DoppelNat verhindere. Ich habe keine andere Möglichkeit.

Problem ist wenn ich mal eben etwas umstecken muss oder ich aus anderen gründen an die Hardware muss. Die beiden Parteien sind baulich voneinander getrennt und ich will nicht immer rüber und klingeln wenn ich an meine Geräte möchte. Außerdem läuft bei denen Magenta TV und Telefon über den Router was die sache zusätzlich erschwert.

Wenn ich das hätte verhindern können hätte ich es gemacht. Aber danke trotzdem.

Hallo,

das wird denke ich so nicht klappen, ohne dass du Zugriff auf den Router bekommst.
Du wirst dort nämlich eine Rückroute eintragen müssen in dein LAN2, sonst wird der Client in LAN1 immer sein Gateway fragen wohin er das Paket schicken soll und dieser wird das Paket verwerfen weil er keine Rückroute in dein LAN2 hat.

Bitte korrigiert mich wenn ich falsch liege.

Gruß

Zitat von @michi1983:

Hallo,

das wird denke ich so nicht klappen, ohne dass du Zugriff auf den Router bekommst.
Du wirst dort nämlich eine Rückroute eintragen müssen in dein LAN2, sonst wird der Client in LAN1 immer sein Gateway fragen wohin er das Paket schicken soll und dieser wird das Paket verwerfen weil er keine Rückroute in dein LAN2 hat.

Bitte korrigiert mich wenn ich falsch liege.

Gruß

Ich habe Zugriff auf die Weboberfläche des Routers, allerdings glaube ich nicht das ich da eine Rückroute eintragen kann, da diese Mistrouter von der Telekom funktionsmäßig extrem beschnitten sind und man quasi nichts einstellen kann. Falls du zufällig weißt wo ich das in diesem verdammten Ding einrichten kann bin ich für Tipps sehr dankbar.

Ich kenne das Gerät leider gar nicht.
Was noch eine Option wäre, ist dem Client im LAN1 eine statische Route zu setzen in Windows.
Das müsste dann eben der Hauptmieter am Gerät einrichten (aber schließlich ist er ja auch der, der auf deinen Mediaserver möchte)

route add 192.168.10.0 MASK 255.255.255.0 192.168.2.? (IP aus LAN1 der OPNSense)

Zitat von @michi1983:

Ich kenne das Gerät leider gar nicht.
Was noch eine Option wäre, ist dem Client im LAN1 eine statische Route zu setzen in Windows.
Das müsste dann eben der Hauptmieter am Gerät einrichten (aber schließlich ist er ja auch der, der auf deinen Mediaserver möchte)

route add 192.168.10.0 MASK 255.255.255.0 192.168.2.? (IP aus LAN1 der OPNSense)

Sei Froh! Die Router der Telekom kann man vergessen. Mit einer Fritte wäre man da besser bedient.

Das Gerät um das es sich handelt ist ein Chromecast mit AndroidTV welches die von uns zu Weihnachten bekommen haben. Ich weiß nicht ob ich eine solche Route da einstellen kann. Ich werde mal etwas rumsuchen.

Aber müsste wenn ich die Portweiterleitung von der Sense zum Mediaserver erstellt habe und in die ClientApp die IP von der Sense mit dem Port des Mediaservers eingebe nicht auch ohne Rückroute funktionieren? Oder habe ich da einen Denkfehler?

Ich hab mal nen Screenshot gemacht und lade den mal hoch.

Bitte benutze den Bearbeiten Knopf !! Damit kannst du es im Thread selber auch immer noch nachträglich machen!! Dann hättest du das überflüssige extra Bild vermeiden können. Gut, heute ist ja Freitag... 🐟

Bei deinem Problem ist es entscheidend WELCHE Protokolle bzw. Ports dein Medienserver verwendet, denn genau diese musst du im Port Forwarding einstellen. Sehr wahrscheinlich reicht nur der Port TCP 8086 nicht?!
Wenn du das nicht weisst, dann ist der Wireshark, wie immer, dein bester Freund.

Magenta TV und Telefon über den Router was die sache zusätzlich erschwert.

Da kannst du mit deiner pfSense dann auch fröhlich mitgucken!!

https://www.heise.de/ct/artikel/MagentaTV-auf-pfSense-Co-4698826.html
Magenta TV hinter pfSense und Cisco c3560cx

Zitat von @aqui:

Ich hab mal nen Screenshot gemacht und lade den mal hoch.

Danke für den Tipp mit Bearbeiten. Werde es mir merken.

Es handelt sich um einen Emby Mediaserver und soweit ich weiß verwendet der nur den TCP Port 8096 und noch einen für SSL wird aber nicht verwendet. Zumindest hatte es super geklappt als ich das Gerät direkt aus dem Internet erreichbar hatte und nur den einen Port Weitergeleitet hatte.

Vielleicht habe ich noch einen Denkfehler, aber wenn der Client aus LAN1 den Medienserver ansprechen möchte, dann schickt er doch den Request an sein Gateway, welches der T-Com Router ist. Dieser hat doch keinerlei Ahnung von dem LAN2, oder irre ich?

Aber wie @aqui schon sagte, am besten einfach mal Wireshark an der OPNSense anwerfen, dann bist du sicher schlauer als jetzt.

Zitat von @michi1983:

Vielleicht habe ich noch einen Denkfehler, aber wenn der Client aus LAN1 den Medienserver ansprechen möchte, dann schickt er doch den Request an sein Gateway, welches der T-Com Router ist. Dieser hat doch keinerlei Ahnung von dem LAN2, oder irre ich?

Aber wie @aqui schon sagte, am besten einfach mal Wireshark an der OPNSense anwerfen, dann bist du sicher schlauer als jetzt.

Also die Verbindung kommt an der Sense an und wird auch in den Logs als PASS markiert es passiert aber nichts weiter. Ich werde mal prüfen ob die Verbindung an den Mediaserver weitergeleitet wird weil in seinen Logs taucht nichts auf.

hatte es super geklappt als ich das Gerät direkt aus dem Internet erreichbar hatte und nur den einen Port Weitergeleitet hatte.

OK, dann sollte es natürlich auch problem los mit der OPNsense klappen.

Ja das dachte ich auch als ich das vor ein paar Tagen in Angriff genommen hatte.
Habe auch alles so eingerichtet wie ich es damals hatte. Wie gesagt es kommt eine anfrage an der Sense an, nur was dann damit passiert muss ich noch rausfinden.

Zitat von @Cylestat:

OK, dann sollte es natürlich auch problem los mit der OPNsense klappen.

Und was sagen die Logs des Medienservers? Kommt da auch was an?

Sieht nicht so aus, bisher konnte ich noch nichts finden.

Also am Mediaserver scheint nichts anzukommen.
Warum auch immer.
Die Sense zeigt mir bei Verbindungsversuchen zwei Logeinträge an. Für mich sieht das so aus als wenn die Umleitung funktioniert.

Demnach muss das Problem in unserem Teil vom Netzwerk liegen.

Ich habe mal Screenshots gemacht. Was meint ihr?

Hier ein funktionierendes Beispiel für das Port Forwarding von TCP 80 (HTTP) auf einen internen Webserver im LAN (192.168.111.222).
Es ist lediglich eine Port Forwarding Regel einzurichten und mehr NICHT! Deine zusätzliche Frickelei oben ist unnötig und kontraproduktiv und zudem ist es unnötig den Port überflüssigerweise unter "Zielport weiterleiten" einzutragen wenn du wie in deinem Falle keine Port Translation verwendest!
Wenn, dann also das Port Forwarding Setup auch richtig machen!

Achte darauf das du entweder am Ende das automatische Erstellen der WAN Regel auf die WAN IP Adresse akzeptierst oder manuell eine WAN Port Regel erstellst!

Desweiteren muss in einer Kaskade das Blocking der RFC 1918 privaten Netze am WAN Port (Interfaces -> WAN) deaktiviert sein!

Dann sähe es richtig so aus mit dem Beispiel TCP 80:

Bzw. hier die Klick ToDos

Mehr "Silbertablett" geht an einem Freitag nicht mehr!

Fazit:
Finde deinen Fehler!

Achte darauf das du entweder am Ende das automatische Erstellen der WAN Regel auf die WAN IP Adresse akzeptierst oder manuell eine WAN Port Regel erstellst!

Ist Angehakt.

Desweiteren muss in einer Kaskade das Blocking der RFC 1918 privaten Netze am WAN Port (Interfaces -> WAN) deaktiviert sein!

Ist auch abgeschaltet, da sonst keine Kommunikation mit dem Koppelnetz möglich.

Mehr "Silbertablett" geht an einem Freitag nicht mehr!

Tut mir wirklich leid aber scheinbar bin ich heute schwer von Begriff.
Wo hast du den Fehler gefunden?

Hab hier noch einmal Screenshots von meiner NAT Regel und der dazugehörigen FW Regel gemacht:

Srry den ersten Part habe ich wohl überlesen.

Es ist lediglich eine Port Forwarding Regel einzurichten und mehr NICHT! Deine zusätzliche Frickelei oben ist unnötig und kontraproduktiv und zudem ist es unnötig den Port überflüssigerweise unter "Zielport weiterleiten" einzutragen wenn du wie in deinem Falle keine Port Translation verwendest!

Mit Frickelei meinst du warscheinlich die Reflection Settings. Habe die jetzt wieder deaktiviert. Bringt aber leider auch nichts. Hatte hier im Forum gelesen das diese Settings in einer Kaskade helfen.

Es ist gar nicht möglich den Zielport anders festzulegen als über "Zielport weiterleiten". Wenn ich das Feld lösche oder auf any stelle spuckt mir die Sense Fehler aus. Dieses Feld wurde automatisch ausgefüllt als ich den Zielportbereich festgelegt habe. In deinem Beispiel wird übrigens auch der "Redirect Target Port" gesetzt.

Es ist gar nicht möglich den Zielport anders festzulegen als über "Zielport weiterleiten".

Nachts ist kälter als draußen... Was bedeutet dieser verschwurbelte Satz??
Wenn du Port Translation machen willst um deinen internen Zielport zu verschleiern, also das du z.B. mit dem Client von außen mit Port TCP 58086 reinkommst und die Firewall den Port dann intern auf TCP 8086 umsetzt. Dafür ist das gedacht, wie gesagt "Port Translation".
Laut deiner Port Forwarding Regel oben machst du das aber nicht, denn bei dir sind Eingangsport und Weiterleitungsport identisch! Folglich ist es dann auch sinnfrei und kontraproduktiv hier etwas einzutragen wenn kein Port Translation gemacht wird. Das Feld bleibt dann sinnvollerweise bzw. wird automatisiert gesetzt.
Das mit dem Target Port ist richtig. Wenn man kein Redirect macht wird der automatisch ausgefüllt.

Du solltest mit einem Wireshark einmal generell prüfen ob Port Forwarding TCP 8086 Traffic überhaupt am Medienserver ankommt. Dazu einmal den Medienserver abziehen und stattdessen einen Wireshark PC mit gleicher IP Adresse aufstecken. Dann von außen einen Zugriff initiieren und checken ob dort TCP 8086 Traffic ankommt.
So weisst du sicher ob die PFW Regel in der FW sauber funktioniert oder ob du da noch einen Kinken reinfabriziert hast!

Dazu ggf. auch nochmal das LAN Regelwerk querchecken. Nicht das du dort etwas wegfilterst?!
Generell rennt das Port Forwarding auf der OPNsense absolut fehlerfrei und problemlos.

Nachts ist kälter als draußen... Was bedeutet dieser verschwurbelte Satz??

Nur das mir die OpnSense nicht gestattet das Feld frei zu lassen.

Du solltest mit einem Wireshark einmal generell prüfen ob Port Forwarding TCP 8086 Traffic überhaupt am Medienserver ankommt. Dazu einmal den Medienserver abziehen und stattdessen einen Wireshark PC mit gleicher IP Adresse aufstecken. Dann von außen einen Zugriff initiieren und checken ob dort TCP 8086 Traffic ankommt.
So weisst du sicher ob die PFW Regel in der FW sauber funktioniert oder ob du da noch einen Kinken reinfabriziert hast!

Also Wireguard empfängt definitiv etwas vom richtigen Klienten.
Kenne mich mit Wireguard nicht gut aus und wie man bestimmt merkt bin ich eher ein Anfänger wenn es um Netzwerktechnik geht. Mir sagen diese Pakete nicht viel. Allerdings sieht man das da irgendwas nicht korrekt zu sein scheint. Mir fehlt nur die Expertise dazu.

Dazu ggf. auch nochmal das LAN Regelwerk querchecken. Nicht das du dort etwas wegfilterst?!

Dort habe ich jeweils Regeln gesetzt die alles erlauben, also sollte es dort keine Probleme geben. Steht aber auf der Liste noch zu checkender sachen.

Generell rennt das Port Forwarding auf der OPNsense absolut fehlerfrei und problemlos.

Ja die Erfahrung habe ich auch gemacht, darum bin ich ja auch so Verlohren. XDD

Also Wireguard empfängt definitiv etwas vom richtigen Klienten.

Wireguard?? 🤔

Kenne mich mit Wireguard nicht gut aus

Das ist ja kein Problem dafür gibt es hier ein Tutorial was das ändert:
Merkzettel: VPN Installation mit Wireguard
Falls du den Wireshark meinst gibt es auch eins dafür um das zu ändern:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html

sieht man das da irgendwas nicht korrekt zu sein scheint.

Ja, es gibt heftige TCP Retransmissions auf der Verbindung was zeigt das da physisch vermutlich was defekt ist. Transceiver, Kabel, Stecker oder Switch der dazwischensteckt usw.
Ggf. auch das eingerichtete Bridge Interface was vermutlich falsch konfiguriert ist?! (geraten). Wozu nutzt du die Bridge?

darum bin ich ja auch so Verlohren

Sicher ohne Ohren.

Wireguard?? 🤔

Srry meinte natürlich Wireshark, Autokomplettierung hat dazwichen gefunkt. XDD

Die Bridge habe ich eingerichtet um alle Ports meiner OpnSense zu zu einem "switch" zusammenzufassen Damit ich nicht für jeden Port ein eigenes Subnetz einrichten muss und der DHCP nicht meckert das er auf mehreren Ports läuft aber den Selben Adressbereich benutzt.

um alle Ports meiner OpnSense zu zu einem "Switch" zusammenzufassen

Du meinst damit hoffentlich nur das lokale LAN, richtig? Der WAN Port gehört niemals auf eine Bridge.

Bedenke das bei einem Bridge Setup das LAN IP Interface immer auf das virtuelle Bridge Interface gebunden sein MUSS!! Es darf niemals auf einem Memberport der Bridge gebunden sein.
Das wird sehr häufig falsch gemacht und führt dann zu solchen Problemen wie oben.

Du meinst damit hoffentlich nur das lokale LAN, richtig? Der WAN Port gehört niemals auf eine Bridge.

Natürlich, der WAN Port ist nicht in der Bridge.

Bedenke das bei einem Bridge Setup das LAN IP Interface immer auf das virtuelle Bridge Interface gebunden sein MUSS!! Es darf niemals auf einem Memberport der Bridge gebunden sein.
Das wird sehr häufig falsch gemacht und führt dann zu solchen Problemen wie oben.

Ich verstehe ehrlich gesagt nicht ganz was du damit meinst. Ich habe aus dem Lan Interface die Bridge erstellt und alle andere Ports zu dieser hinzugefügt. War das das falsche vorgehen?

War das das falsche vorgehen?

Das kommt drauf an an welches Interface du die IP Adresse gebunden hast. Die MUSS immer auf dem virtuellen Bridge Interface liegen!

Table of contents

Bridge Interface erstellen

IP Adressierung dem Bridge Interface zuweisen

Bridge Interface erstellen

Hier als Beispiel mit den Memberports OPT2 (igb2) und OPT3 (igb3)
Beachte das diese Memberports zwar "enabled" sind aber keine IP Konfig haben (IP Konfiguration Type none)!
Sicherheitshalber sollte man IMMER Spanning Tree auf den Bridge Memberports aktivieren (hier das moderne RSTP) um der Gefahr von Loops auf den Bridgeport vorzubeugen was ein Netzausfall bedeuten würde.

IP Adressierung dem Bridge Interface zuweisen

Nach dem Setup der Bridge taucht diese als neues Interface auf im "Interface Assignment". Mit Klick auf + aktiviert man das Bridge Interface (Enable), gibt ihm ggf. einen sinnvollen Namen wie z.B. "LAN2" und definiert hier die Segment IP Adresse (Konfig Type Static).

Das kommt drauf an an welches Interface du die IP Adresse gebunden hast. Die MUSS immer auf dem virtuellen Bridge Interface liegen!

IP ist auf der Bridge und sonst auf keinem Interface. Alle Interfaces sind aktiviert haben aber keine IP hinterlegt.

Bridge Interface erstellen

Ich danke dir für die tolle Anleitung. Damit konnte ich kleinere Fehler in meiner Konfig finden und lösen.
Ich hatte z.B. das Spanning Tree Protocol nicht eingeschaltet. Seit dem das gefixt ist funktioniert die Übertragung in unserem Netzwerk besser.

Aber leider hatte das keinen Effekt bei meinem ursprünglichem Problem. Ich werde im laufe des Tages die Bridge einmal auflösen und diese dann nach deinem Tut noch einmal erstellen. Vllt behebt das ja einen Fehler der bei der Einrichtung gemacht wurde. Ich melde mich wenn ich mehr weiß.

Danke erstmal.

Wenn du in deinem Netzwerk (Switch) RSTP Spanning Tree aktiv hast solltest du in jedem Fall darauf achten das der Haupt Switch (Root Switch) global immer eine höher Spanning Tree Priority konfiguriert bekommt!!
Damit gibt der Root Switch bei redundanten Pfaden dann immer zwingend vor welcher Port im Forwarding Mode ist. Ist immer ein Mus sbei einer sauberen Spanning Tree Konfig.
Siehe zu der Thematik u.a. auch HIER.

Hab dem Root Switch (Bei mir die Sense) jetzt einfach die höchste Prio gegeben, da meine Managed Switches von Netgear mir keine Möglichkeit geben da etwas zu verändern. Ich habe sicherheitshalber auf das STP Protokoll umgestellt, da ich vermute das diese günstigen Netgear Switches nicht mehr haben werden. So ist die Kompatibilität zumindest gegeben.

Habe jetzt auch alle Regeln aller Ports und der Bridge noch einmal gegengecheckt. Da wird gar nichts gefiltert. Ich habe da nur Regeln drin die alles erlauben.

Das neuerstellen des Bridgeinterfaces hat leider auch nichts gebracht.

Clent App neu installiert, hat auch nichts gebracht. (Einen Versuch war es Wert)

Es ist zum Mäusemelken. Die Sense zeigt mir weiterhin bei Verbindungsversuchen an das der rdr und die FW Regel alles durchlassen.
Ist die Farbe des rdr Eintrags im Log richtig? Ich hatte angenommen das diese blaue Hinterlegung einfach nur anzeigen soll das es sich um keine FW Regel handelt, die sind ja Grün oder Rot je nach dem ob sie blocken oder erlauben.

da meine Managed Switches von Netgear mir keine Möglichkeit geben da etwas zu verändern.

Sehr ungewöhnlich und kann eigentlich nicht sein. Welches Model ist das?? Die RSTP Prio über ein Endgerät zu setzen ist keine optimale Idee...

Ich habe sicherheitshalber auf das STP Protokoll umgestellt

Eine ganz ganz schlechte Idee!! Das Protokoll ist eigentlich sei den letzten 20 Jahren tot denn die Welt macht ausschliesslich RSTP. Die Konvergenzzeiten sind tödlich bei klassischem STP deshalb nutzt es kein Mensch mehr.

da ich vermute das diese günstigen Netgear Switches nicht mehr haben werden.

Das wäre sehr sehr ungewöhnlich und bedeutet das sie die letzten 20 Jahren nichts an den Produkten gemacht haben was natürlich Unsinn ist. Das sie einen Standard den 98% aller Netze nutzen nicht supporten ist höchst unglaubwürdig...aber nundenn. Wenn du das Modell postest können wir für dich das Admin Handbuch lesen um zu verifizieren was du behauptest.

Ist die Farbe des rdr Eintrags im Log richtig?

Ohne einen aktuellen Screenshot des Regelwerkes zu sehen ist das Raten im freien Fall!

Sehr ungewöhnlich und kann eigentlich nicht sein. Welches Model ist das?? Die RSTP Prio über ein Endgerät zu setzen ist keine optimale Idee...

1x GS308E - 8-Port Gigabit Ethernet Smart Managed Plus Switch
2x GS305E – 5-Port Gigabit Ethernet Smart Managed Plus Switch

OK steht wieder auf RSTP.

Konnte in der Weboberfläche und im Handbuch nichts dazu finden.
Aber Warscheinlich habe ich nicht richtig oder nach den falschen Sachen gesucht.

Ohne einen aktuellen Screenshot des Regelwerkes zu sehen ist das Raten im freien Fall!

An der Regel hat sich nur verändert das ich dort keinen Zielportbereich mehr angebe, sonst ist alles identisch zu den Screenshots oben. Ich habe noch einmal Screenshots meiner aktuellen Regel und des Logs gemacht.

Du hast leider Recht und auch richtig gesucht bzw. konntest nichts finden.
Diese primitiven Teile können generell gar kein Spanning Tree sondern nur eine proprietäre Loop Detection.
Dann kann man sich letztlich auch das gut gemeinte Spanning Tree, RSTP Setup komplett sparen.

Wenigstens etwas das ich richtig gemacht habe. XDD
Aber gut zu wissen. Dann schalte ich das wieder ab.

Ich glaube auch den Hauptfehler für diese ganzen kaputten Datenpakete gefunden zu haben. Vor einiger Zeit hatte ein Kollege meine Proxmox Server etwas "Verbessert". Er hat jeder VM eine neue Virtuelle Netzwerkkarte zugeteilt, ein Netzwerk im Netzwerkmanager angelegt und alles so eingestellt das es über einen eigenen IP Bereich miteinander Kommunizieren kann.
Ich vermute das das etwas mit den ganzen Fehlern zu tun hat. Ich werde mich mal dran setzen und alles wieder auf des Standard den ich gesetzt hatte zurücksetzen und niemanden mehr uneingeschränkten Zugriff auf meine Dienste geben. Wenn ich das erledigt habe Probiere ich es noch einmal und melde mich noch einmal ob das jetzt den entscheidenen Durchbruch bringt.

Ansonsten noch irgendeine Idee was hier falsch laufen könnte und wieso Trotz RDR und FW Regel der Client aus dem Koppelnetz keine Verbindung in Unser Heimnetz aufbauen kann?

Er hat jeder VM eine neue Virtuelle Netzwerkkarte zugeteilt, ein Netzwerk im Netzwerkmanager angelegt

Das könnte natürlich sein. Vielleicht hilft das hier noch zur Übersicht:
Pfsense in Proxmox als Router
Die NIC Adapter der VMs sind aber von vmxnet3 auf die deutlich performanteren VirtIO (paravirtualized) umgestellt worden!
Mit der Konfig kommt es zu keinerlei Fehlern was man auch problemlos im iPerf3 und dem Kabelhai testen kann. Keep it simple...

noch irgendeine Idee was hier falsch laufen könnte

Hab das Port Forwarding hier mit HTTP, HTTPS und SMB/CIFS (TCP 445) und mit Last via iPerf3 getestet auf einem aktuellen Proxmox 7.4 und das rennt völlig fehlerlos ohne jegliche Retransmissions etc.

Ich glaube da habe ich mich falsch ausgedrückt. Proxmox und die OpnSense laufen auf zwei unterschiedlichen Barebones. Protectli Vault für die Sense und einen von MinisForum für Proxmox.

Ich wollte OpnSense nicht Virtualisieren, ich habe es liebe wenn kritische Systeme Bare Metal installiert sind.

Hab das Port Forwarding hier mit HTTP, HTTPS und SMB/CIFS (TCP 445) und mit Last via iPerf3 getestet auf einem aktuellen Proxmox 7.4 und das rennt völlig fehlerlos ohne jegliche Retransmissions etc.

Hast du das auch aus einem Kaskadierendem Netz versucht? Ich vermute den Fehler oder das Problem, wenn es nicht an der Fehlkonfiguration von Proxmox liegt irgendwo da.

ich habe es liebe wenn kritische Systeme Bare Metal installiert sind.

Ist auch absolut richtig! Sorry, für das Missverständnis.

Hast du das auch aus einem Kaskadierendem Netz versucht?

Über eine virtualsierte OPNsense (nur Testbed

) auf eine VM.
Also Engerät -> physische Nic -> Proxmox vSwitch -> virt. NIC WAN Port -> virt. NIC LAN Port -> virt. NIC der VM und vice versa. Mehr virtuelles Netz geht fast nicht mehr...

Ist auch absolut richtig! Sorry, für das Missverständnis.

Alles gut.

Über eine virtualsierte OPNsense (nur Testbed

) auf eine VM.
Also Engerät -> physische Nic -> Proxmox vSwitch -> virt. NIC WAN Port -> virt. NIC LAN Port -> virt. NIC der VM und vice versa. Mehr virtuelles Netz geht fast nicht mehr...

Ja da hast du recht. Viel mehr geht da nicht. XDD
Wie gesagt ich kümmere mich hier erstmal um den ganzen falsch konfigurierten Kram und melde mich ob es geholfen hat.

Wenn es das denn nun war, bitte deinen Thread hier dann auch als erledigt schliessen!!

Nein, das war es leider auch nicht.
Entschuldigt bitte das lange nichts passiert ist, extrem viel Stress auf der Arbeit und unser WLAN AP hat sich zwischenzeitlich verabschiedet (wenn dann kommt alles auf einmal) und das hatte Vorrang.

Welche Einstellungen in Opnsense könnten denn aktiv verhindern das mein Vorhaben klappt, dann schaue ich die mal durch.

Sonst habe ich keine Idee mehr was ich da noch versuchen soll. 😭

Die Portweiterleitung an sich funktioniert fehlerlos. Habs hier mit einer OPNsense und TCP 8082 und 8096 getestet das auf einen Wireshark Sniffer terminiert und der zeigt fehlerlos diese Frames an. Grundsätzlich kann man also davon ausgehen das Port Forwarding an sich in der OPNsense ohne jeden Fehler funktioniert!
Diesen Test solltest du in jedem Falle auch machen um sicher zu verifizieren das Frames mit diesem Port geforwardet werden.
Du kannst dazu z.B. das Terminalprogramm [ PuTTY] nutzen, machst eine Telnet Verbindung auf und gibst Port 8092 bzw. 8096 an was dir dann TCP 8092 oder 8096 Traffic generiert. Diesen Traffic solltest du dann auf dem forgewardeten Host (Wireshark PC) im lokalen OPNsense LAN sehen.
Das verifiziert dann das die PFW Regel sauber arbeitet.

Wenn es dennoch nicht klappt ist es möglich das der Medienserver ggf. noch zusätzliche Ports benötigt um eine Verbindung aufzubauen. Auch das kann man im Handumdrehen mit dem Wireshark herausfinden wenn man sich einmal einen funktionierenden Verbindungsaufbau ansieht und den mitschneidet.

Die Portweiterleitung an sich funktioniert fehlerlos. Habs hier mit einer OPNsense und TCP 8081 getestet das auf einen Wireshark Sniffer terminiert und der zeigt fehlerlos diese Frames an. Grundsätzlich kann man also davon ausgehen das Port Forwarding an sich in der OPNsense ohne jeden Fehler funktioniert!
Diesen Test solltest du in jedem Falle auch machen um sicher zu verifizieren das Frames mit diesem Port geforwardet werden.

Das werde ich machen. Kann allerdings etwas dauern bis ich dazu die zeit Finde, will das ja nicht irgendwie hinrotzen.

Wenn es dennoch nicht klappt ist es möglich das der Medienserver ggf. noch zusätzliche Ports benötigt um eine Verbindung aufzubauen. Auch das kann man im Handumdrehen mit dem Wireshark herausfinden wenn man sich einmal einen funktionierenden Verbindungsaufbau ansieht und den mitschneidet.

Das können wir direkt ausschließen. Es handelt sich um Emby bei dem Meidaserver und der nutzt zwei Ports 8096 für HTTP Traffic im LAN und 8920 für HTTPS und dieser wird, wenn die Funktion aktiviert ist nur bei Externen Verbindungen sprich bei Verbindungen direkt aus dem Internet genutzt.

Wenn es das denn war bitte deinen Thread dann auch als erledigt schliessen!

Nein das war es nicht.
Ich versuche es jetzt über eine Wireguard VPN Verbindung. Die geht komischerweise bei identischen Einstellungen durch.

Ich markiere den Artikel trotzdem als gelöst. Falls noch jemandem etwas einfallen sollte kann es ja hier rein geschrieben werden.

Danke trotzdem für eure Hilfe.

German solved Question Networks LAN, WAN, Wireless Networking Basics