17
OPNsense mit 2xWAN und einem Ports
Hallo.
Ich habe die KI schon befragt, gab mir auch recht gute Anleitungen, aber irgendwie klappte das nicht.
Daher die Frage an die Runde
Ein bestimmter Port nennen wir einfach mal 1111 soll ungleitet werden auf einen bestimmten Rechner.
Das kann ich auch bestätigen, man sieht es im Liveprotokoll.
Nun ist es leider so, dass dier besagte Rechner standardmäßig, wie alle im LAN 192.168.188.0 über den WAN rausgehen der auch keine öffentliche IP hat.
Nun soll die Firewall so Programmiert werden, das wenn eine Anfrage über den Port 1111 an den Rechner 192.168.188.3 geht. dieser bei Beantwortung über den frei zugängliche WAN geht.
Nennen wir die WANS mal Telekom (öffentliche IP) und Starlink (keine öffentliche ip)
Ich hoffe ich habe mich nicht so blöd ausdrückt.
Ich habe die KI schon befragt, gab mir auch recht gute Anleitungen, aber irgendwie klappte das nicht.
Daher die Frage an die Runde
Ein bestimmter Port nennen wir einfach mal 1111 soll ungleitet werden auf einen bestimmten Rechner.
Das kann ich auch bestätigen, man sieht es im Liveprotokoll.
Nun ist es leider so, dass dier besagte Rechner standardmäßig, wie alle im LAN 192.168.188.0 über den WAN rausgehen der auch keine öffentliche IP hat.
Nun soll die Firewall so Programmiert werden, das wenn eine Anfrage über den Port 1111 an den Rechner 192.168.188.3 geht. dieser bei Beantwortung über den frei zugängliche WAN geht.
Nennen wir die WANS mal Telekom (öffentliche IP) und Starlink (keine öffentliche ip)
Ich hoffe ich habe mich nicht so blöd ausdrückt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670758
Url: https://administrator.de/forum/opnsense-mit-2xwan-und-einem-ports-670758.html
Ausgedruckt am: 21.02.2025 um 18:02 Uhr
17 Kommentare
Neuester Kommentar
In der DST-NAT Regel eine Markierung für die Firewall vergeben (Set local tag). Firewall-Regel auf dem WAN Interface anlegen welche auf die gerade vergebene Markierung matcht (Match local tag) und das GW dieser Regel auf das gewünschte WAN-GW festlegen (reply-to), fertsch.
Gruß gastric
Gruß gastric
1
@151183 sorry, stehe ein wenig auf dem schlauch.
Habe die Tags eingetragen.
Wie kann ich sie mir in der Liveansicht nun anzeigen lassen. Hab die opnsense in deutsch
Habe die Tags eingetragen.
Wie kann ich sie mir in der Liveansicht nun anzeigen lassen. Hab die opnsense in deutsch
🙃
Hab die opnsense in deutsch
Naja, ein Admin sollte beides beherrschen ....1
sorry, ich bin nicht der nerd in dem bereich. lerne gerne dazu. sorry für meine DAUart im Moment
Werde das eben anhaken und gucken
Werde das eben anhaken und gucken
@151183
So, und wo soll ich das nun genau sehen können ?
Ich konnte soweit filtern in der Liveansicht, dass ich sehe wie der Port rein kommt.
Nun wie und wo muss ich nach diesem Tag ausschau halten.
Sei mir nicht böse, dass ich so blöd nachfrage.
Doch Fachenglisch geht. Aber ich pers. mags lieber in deutsch. Bin da einfach schneller
So, und wo soll ich das nun genau sehen können ?
Ich konnte soweit filtern in der Liveansicht, dass ich sehe wie der Port rein kommt.
Nun wie und wo muss ich nach diesem Tag ausschau halten.
Sei mir nicht böse, dass ich so blöd nachfrage.
Doch Fachenglisch geht. Aber ich pers. mags lieber in deutsch. Bin da einfach schneller
Deine Beschreibung ist auch echt wirr und dadurch schwer veständlich, zumal auch eine kurze Skizze fehlt. Ein typischer Freitags Thread... 🐟 ☹️
Versteht man dich richtig hast du ein klassisches Dual WAN Design mit der Firewall und ein lokales LAN.
Dein Ziel ist es lokalen LAN Traffic ins Internet der als Zielport 1111 (ob TCP oder UDP hast du auch nicht gesagt!
) hat immer fest über den "frei zugänglichen" WAN Port schicken. Simples Policy based Routing also.
Jetzt fragt man sich natürlich WAS meinst du jetzt genau mit "frei zugänglichem" WAN?? Vermutlich (geraten) wohl den Telekom Anschluss mit der öffentlichen WAN IP?! Auf einer Firewall ist bekanntlich nichts "frei zugänglich" deshalb nutzt man ja gerade eine Firewall?!
Leider machst du auch keinerlei hilfreich Aussagen WELCHE Balancing Policy du derzeit bei den 2 WAN Anschlüssen konfiguriert hast. Ob Round Robin, Weighted usw. all das ist unklar. Nach deiner Schilderung gehen wir mal (geraten) von klassischem Round Robin aus also einer fiftyfifty Verteilung nach Session.
Für eine Lösung musst du also ein Policy Routing konfigurieren das allen 192.168.188.x Traffic mit UDP oder TCP 1111 Zielport an den Telekom WAN Port schickt.
Wie oben schon gesagt musst du dafür über eine Firewall Regel den entsprechenden Traffic klassifizieren und diesen so gekennzeichneten Traffic dann an den Telekom WAN Port forwarden. Genau das ist oben gemeint.
Siehe Step 4 in:
https://docs.opnsense.org/manual/how-tos/multiwan.html
Versteht man dich richtig hast du ein klassisches Dual WAN Design mit der Firewall und ein lokales LAN.
Dein Ziel ist es lokalen LAN Traffic ins Internet der als Zielport 1111 (ob TCP oder UDP hast du auch nicht gesagt!
) hat immer fest über den "frei zugänglichen" WAN Port schicken. Simples Policy based Routing also.Jetzt fragt man sich natürlich WAS meinst du jetzt genau mit "frei zugänglichem" WAN?? Vermutlich (geraten) wohl den Telekom Anschluss mit der öffentlichen WAN IP?! Auf einer Firewall ist bekanntlich nichts "frei zugänglich" deshalb nutzt man ja gerade eine Firewall?!
Leider machst du auch keinerlei hilfreich Aussagen WELCHE Balancing Policy du derzeit bei den 2 WAN Anschlüssen konfiguriert hast. Ob Round Robin, Weighted usw. all das ist unklar. Nach deiner Schilderung gehen wir mal (geraten) von klassischem Round Robin aus also einer fiftyfifty Verteilung nach Session.
Für eine Lösung musst du also ein Policy Routing konfigurieren das allen 192.168.188.x Traffic mit UDP oder TCP 1111 Zielport an den Telekom WAN Port schickt.
Wie oben schon gesagt musst du dafür über eine Firewall Regel den entsprechenden Traffic klassifizieren und diesen so gekennzeichneten Traffic dann an den Telekom WAN Port forwarden. Genau das ist oben gemeint.
Siehe Step 4 in:
https://docs.opnsense.org/manual/how-tos/multiwan.html
@aqui
Ja, du hast ja recht, ich rede immer ein wenig Wirr, im Kopf schon wörter gesagt und vergessen aufzuschreiben oder umgekehrt. Liegt vermutlich an meinem Authismus.
Skizze ist nun aktuell nciht meins. Ich erkläre es eben noch mal ganz Detailiert.
Wir haben 2 WAN Zugänge Einer (TelekomDSL) ist von außen erreichbar, so das man wie hier im Beispiel ohne Probleme den besagten Port auf einen Rechner weiterleiten kann. Das wird auch pass mäßig in der Liveprotokoll angezeigt.
Der andere WAN ist ein typischer Starlink Zugang wo die öffentliche ip der Privaten IP nicht entspricht. Quasi wie bei Mobilfunk.
Nun wollte ich gerne dass wenn z.b. der Port 1111 auf z.b. der 192.168.188.3 weitergeleitet wird und der Rechner den Port beantworten will, dieses nicht über die Standardgateway beantwortet, sondern nur bei diesen speziellen Port 1111 über die TelekomDSL beantwortet.
Ja, du hast ja recht, ich rede immer ein wenig Wirr, im Kopf schon wörter gesagt und vergessen aufzuschreiben oder umgekehrt. Liegt vermutlich an meinem Authismus.
Skizze ist nun aktuell nciht meins. Ich erkläre es eben noch mal ganz Detailiert.
Wir haben 2 WAN Zugänge Einer (TelekomDSL) ist von außen erreichbar, so das man wie hier im Beispiel ohne Probleme den besagten Port auf einen Rechner weiterleiten kann. Das wird auch pass mäßig in der Liveprotokoll angezeigt.
Der andere WAN ist ein typischer Starlink Zugang wo die öffentliche ip der Privaten IP nicht entspricht. Quasi wie bei Mobilfunk.
Nun wollte ich gerne dass wenn z.b. der Port 1111 auf z.b. der 192.168.188.3 weitergeleitet wird und der Rechner den Port beantworten will, dieses nicht über die Standardgateway beantwortet, sondern nur bei diesen speziellen Port 1111 über die TelekomDSL beantwortet.
Das haben wir wohl missverstanden. OK.
Das ist Standard und benötigt keine weitere Regel bei einem Port-Forwarding, denn beim Portforwarding existiert ja bereits ein Eintrag in der States-Table für die Verbindung die geNATed wird, und auf dem Weg zurück vom LAN-Host in Richtung Internet-Client wird ja die Quell-Adresse wieder auf ihr Original (WAN-Adresse) umgeschrieben. Und die OPNSense verwendet bei Multi-WAN automatisch ein reply-to um das richtige WAN-Interface zu selektieren von dem der Traffic kam, da ist es egal welches GW für den Client sonst eingerichtet es denn die Sense wählt automatisch das richtige für die existierende eingehende Verbindung in der States-Tabelle. "reply-to" ist per Default aktiviert es ist also nichts weiter erforderlich!
Kannst du auch in den erweiterten Firewall Einstellungen nachlesen
Klappt hier im Testlab auch einwandfrei.
Das ist Standard und benötigt keine weitere Regel bei einem Port-Forwarding, denn beim Portforwarding existiert ja bereits ein Eintrag in der States-Table für die Verbindung die geNATed wird, und auf dem Weg zurück vom LAN-Host in Richtung Internet-Client wird ja die Quell-Adresse wieder auf ihr Original (WAN-Adresse) umgeschrieben. Und die OPNSense verwendet bei Multi-WAN automatisch ein reply-to um das richtige WAN-Interface zu selektieren von dem der Traffic kam, da ist es egal welches GW für den Client sonst eingerichtet es denn die Sense wählt automatisch das richtige für die existierende eingehende Verbindung in der States-Tabelle. "reply-to" ist per Default aktiviert es ist also nichts weiter erforderlich!
Kannst du auch in den erweiterten Firewall Einstellungen nachlesen
Klappt hier im Testlab auch einwandfrei.
2wo die öffentliche ip der Privaten IP nicht entspricht. Quasi wie bei Mobilfunk.
Das nennt sich übrigens CG-NAT (Carrier grade NAT). Siehe auch hier.
@aqui Danke für die Info, hoffentlich kann ich mir das mal merken.
@151183
Also du sagst, dass es eigentlich autmatisch geregelt wird. D.H. wenn einer von außen über einen feigegebenen Port rein kommt auf einen Rechner, es autmatisch geregelt wird, dass die Antwort über den selben WAN zurückkommt.
Ok, dann hat es wohl eine andere Ursache. Leider bin ich nicht so drin, wie einige von euch, daher habe ich, so denke ich, was entscheidenes Vergessen. Dieser PC, der von außen erreichbar ist, ist Teil eine Domäne, und der DC macht in dem Falle die DNS, die Gateway ist die Firewall. Damit wird dich Sache sicherlich schwieriger oder ?
Sorry, wenn ich so blöd frage.
Also du sagst, dass es eigentlich autmatisch geregelt wird. D.H. wenn einer von außen über einen feigegebenen Port rein kommt auf einen Rechner, es autmatisch geregelt wird, dass die Antwort über den selben WAN zurückkommt.
Ok, dann hat es wohl eine andere Ursache. Leider bin ich nicht so drin, wie einige von euch, daher habe ich, so denke ich, was entscheidenes Vergessen. Dieser PC, der von außen erreichbar ist, ist Teil eine Domäne, und der DC macht in dem Falle die DNS, die Gateway ist die Firewall. Damit wird dich Sache sicherlich schwieriger oder ?
Sorry, wenn ich so blöd frage.
Zitat von @Decker2022:
@151183
Also du sagst, dass es eigentlich autmatisch geregelt wird. D.H. wenn einer von außen über einen feigegebenen Port rein kommt auf einen Rechner, es autmatisch geregelt wird, dass die Antwort über den selben WAN zurückkommt.
Korrekt.@151183
Also du sagst, dass es eigentlich autmatisch geregelt wird. D.H. wenn einer von außen über einen feigegebenen Port rein kommt auf einen Rechner, es autmatisch geregelt wird, dass die Antwort über den selben WAN zurückkommt.
Ok, dann hat es wohl eine andere Ursache. Leider bin ich nicht so drin, wie einige von euch, daher habe ich, so denke ich, was entscheidenes Vergessen. Dieser PC, der von außen erreichbar ist, ist Teil eine Domäne, und der DC macht in dem Falle die DNS, die Gateway ist die Firewall. Damit wird dich Sache sicherlich schwieriger oder ?
Nein. Ob das Ding nun Teil einer Domäne ist oder nicht ist dabei irrelevant für das Forwarding der Firewall. Du setzt damit aber deine gesamte Domäne mit dem Port-Forwarding einem nicht kalkulierbaren Risiko aus. Solche Geräte gehören immer in eine DMZ und benötigen besonderen Schutz vor dem Rest des Netzwerks.1
Also dieser Rechner ist nur offen für einen einzigen Port. Ansonsten ist diese Maschine nur über dire Firewall per VPN erreichbar.
Aber bitte erstmal zurück. Also wenn ich z.B den Port 1111 (nur Beispiel) auf 192.168.188.3 Weiterleite, dieses auch sehe im Liveprotokoll. Warum kommt dann keine Antwort zurück.
Die Firewall des PC's ist jedenfalls für den Port 1111 freigegeben.
Aber bitte erstmal zurück. Also wenn ich z.B den Port 1111 (nur Beispiel) auf 192.168.188.3 Weiterleite, dieses auch sehe im Liveprotokoll. Warum kommt dann keine Antwort zurück.
Die Firewall des PC's ist jedenfalls für den Port 1111 freigegeben.
Zitat von @Decker2022:
Also dieser Rechner ist nur offen für einen einzigen Port. Ansonsten ist diese Maschine nur über dire Firewall per VPN erreichbar.
Ist irrelevant , ein einziger Port reicht für den Angreifer vollkommen aus ...Also dieser Rechner ist nur offen für einen einzigen Port. Ansonsten ist diese Maschine nur über dire Firewall per VPN erreichbar.
Aber bitte erstmal zurück. Also wenn ich z.B den Port 1111 (nur Beispiel) auf 192.168.188.3 Weiterleite, dieses auch sehe im Liveprotokoll. Warum kommt dann keine Antwort zurück.
Die Firewall des PC's ist jedenfalls für den Port 1111 freigegeben.
Schmeiß TCPDump oder Wireshark an dann siehst du wo das Paket falsch abbiegt oder gefiltert wird.Die Firewall des PC's ist jedenfalls für den Port 1111 freigegeben.
1
@151183
So, habe es geklärt. Der Fehler liegt nicht bei mir, also ich habe mal nstat -ano ausgeführt.
Anders als vom Softwarebetreuer behauptet, war der besagte Port nicht da
Habe dann ein kleines Powershellscript geöffnet mit besagten Port und siehe da, der Port ist zugänglich.
Da muss die Softwarebetreuung nochmal ran.
Danke für Alles
So, habe es geklärt. Der Fehler liegt nicht bei mir, also ich habe mal nstat -ano ausgeführt.
Anders als vom Softwarebetreuer behauptet, war der besagte Port nicht da
Habe dann ein kleines Powershellscript geöffnet mit besagten Port und siehe da, der Port ist zugänglich.
Da muss die Softwarebetreuung nochmal ran.
Danke für Alles
1war der besagte Port nicht da
Echt jetzt? Und dann hier extra nen Fred für aufmachen, das ist doch das erste was man checkt...🤔2
@151183
Na ja, so ganz war es nicht.
Ich habe natürlich geschaut mit netstat -ano vorher
Da war er auch da.
Danach habe ich Firewall etc geprüft, und dachte ich habe nen Fehler.
Dann dachte ich guck nochmal sicherheitshalber nach und dann war der Port weg.
Daher habe ich dann ein Powershell Script laufen lassen und siehe da Port war offen und zugänglich.
Ich kann dir leider nicht sagen warum das nun plötzlich so war. Sonst hätte ich hier nicht reingeschrieben
Danke für deine Mühe, und sorry dafür
Na ja, so ganz war es nicht.
Ich habe natürlich geschaut mit netstat -ano vorher
Da war er auch da.
Danach habe ich Firewall etc geprüft, und dachte ich habe nen Fehler.
Dann dachte ich guck nochmal sicherheitshalber nach und dann war der Port weg.
Daher habe ich dann ein Powershell Script laufen lassen und siehe da Port war offen und zugänglich.
Ich kann dir leider nicht sagen warum das nun plötzlich so war. Sonst hätte ich hier nicht reingeschrieben
Danke für deine Mühe, und sorry dafür
