Port Forwarding - bekomme es nicht auf die Kette

[MCMarcel]

Hi,

folgendes Problem, ich hab jetzt stunden verbracht und komme gefühlt keinen schritt weiter.

Ich will eigentlich nur ne Portweiterleitung auf meinen Unraid Server.
Ich hab unter Firewall: NAT: Port Forward also eine Regel erstellt, alles was auf 443 reinkommt soll auf 1443 raus gehen (Reverse Proxy)
geht nicht...

Spaßeshalber wollte ich nur die Weboberfläche von dem Server weiterreichen, selbst das geht nicht, Online Port Checker sagen ist noch zu und in der Live Ansicht kommt geblocked weil gematched mit rule 13?
Finde auch nirgends die Regel 13 - oder überhaupt eine liste der Regeln^^

Bin kein Netzwerkprofi, dachte aber kenn mich ein wenig aus... und dann kam Opnsense xD

Grüße und Danke vorab

=)

[JeGr]

Hi!

Erste Frage: Hast du das WebUI der Sense noch auf 80/443? Wenn ja leg das mal sicherheitshalber auf einen anderen Port. Wir empfehlen in Workshops gerne sowas wie 4443 o.ä. da 8443 und Co gerne für andere Sachen gebraucht werden. Zudem gibts ne automatische Weiterleitung, die bitte auch abschalten:

System / Settings / Administration
-> TCP Port: 4443
-> Disable Web GUI redirect rule

ansonsten werden 80/443 nämlich auf den neuen Port mit umgeschrieben, was eher ungeil ist. Das aber nur sicherheitshalber, denn du bastelst da mit den Standard Web Ports auf der Sense und Weiterleitungen, und da hat es sich dann schnell mal, dass der Port Forward nicht greift und du plötzlich die UI der Sense im Netz hast statt deinem Unraid :/

* Davon weitergehend: sind das alle Port Forward Regeln oder gibts noch mehr als diese?
* Ich vermute die Regel auf dem WAN ist dann die verlinkte Regel, das sollte passen. Sind da noch mehr oder ist das die einzige?
* Hast du irgendwelche (schrägen) Floating Regeln angelegt die noch mit reingrätschen?
* Kannst du den 1443 Port auf dem Unraid von der Sense aus erreichen? Hast du das mit Test Port oder via SSH/Console mal getestet? :)

Cheers

[MCMarcel]

Hi :)

TCP Port von OPNsense hab ich schon umgestellt und die Weiterleitungsregel deaktiviert (checked)

Port Forwarding Regeln gibts nur die 2, also die 2 WAN regeln und die Systemvoreingestellten AntiLockout regeln.

Genau, die auf der Schnittstelle WAN ist die verlinkte die Automatisch erzeugt wurde beim erstellen der Portweiterleitung

Bei Floating sind nur Standart Regeln aktiv.

Port Probe von WAN:
# /usr/bin/nc -v -w 10 -z  -4 -s '**.220.189.***'  '10.100.10.100' '1443'
nc: connect to 10.100.10.100 port 1443 (tcp) failed: Operation timed out


Port Probe von LAN:
# /usr/bin/nc -v -w 10 -z  -4 -s '10.100.10.1'  '10.100.10.100' '1443'
Connection to 10.100.10.100 1443 port [tcp/*] succeeded!

[JeGr]

> TCP Port von OPNsense hab ich schon umgestellt und die Weiterleitungsregel deaktiviert (checked)

Superb :)

> Port Forwarding Regeln gibts nur die 2, also die 2 WAN regeln und die Systemvoreingestellten AntiLockout regeln.

Das klingt gut :)

OK dann wird das etwas rätselhafter. Wie kommt denn Internet an dein WAN ran? Ich habe im ersten Bild "pppoe0" gelesen, also vermute ich einmal, dass du dich direkt via PPPoE und ein Modem einwählst?

Kannst du bei der automatisch erstellten Regel für das Unraid einmal das Logging anschalten? Sollte möglich sein.
Du prüfst von extern übrigens auf "1443" - das ist falsch, denn du mappst ja via NAT die 443 auf die 1443, somit ist Port 1443 nach extern natürlich geschlossen und es sollte ledglich 443 offen sein :) Kannst du das nochmal prüfen?

Das ist in Regelform etwas verwirrend, aber die Reihenfolge der Abarbeitung ist "NAT Regeln zuerst, dann Firewallregeln" und da ein ankommendes Paket dann zuerst durch NAT transformiert wird (aka Zieladresse und Port werden umgeschrieben), muss die Firewallregel auf dem WAN natürlich so "seltsam" aussehen, dass die int. IP und der int. Port freigegeben werden müssen (da das Paket ja schon transformiert am Regel-Filter ankommt). Darum von extern nochmal mit der normalen HTTPS/443 testen :)

Cheers
\jens

[Patrick M. Hausen]

Das ist in Regelform etwas verwirrend, aber die Reihenfolge der Abarbeitung ist "NAT Regeln zuerst, dann Firewallregeln" und da ein ankommendes Paket dann zuerst durch NAT transformiert wird (aka Zieladresse und Port werden umgeschrieben), muss die Firewallregel auf dem WAN natürlich so "seltsam" aussehen, dass die int. IP und der int. Port freigegeben werden müssen (da das Paket ja schon transformiert am Regel-Filter ankommt). Darum von extern nochmal mit der normalen HTTPS/443 testen :)

Oder man stellt in der Port Forwarding NAT Rule einfach die "Filter rule association" auf "Pass". Wenn man sich ein eingehendes Port Forwarding baut, dann will man in der Regel auch Services erlauben. Und einfache Quell-/Zieladress-Einschränkungen kann man ebenfalls direkt in der NAT Rule machen.

Just my 2 ct. Ich hab überall "Pass" auf allen meinen Firewalls.

[MCMarcel]

> TCP Port von OPNsense hab ich schon umgestellt und die Weiterleitungsregel deaktiviert (checked)

Superb :)

> Port Forwarding Regeln gibts nur die 2, also die 2 WAN regeln und die Systemvoreingestellten AntiLockout regeln.

Das klingt gut :)


OK dann wird das etwas rätselhafter. Wie kommt denn Internet an dein WAN ran? Ich habe im ersten Bild "pppoe0" gelesen, also vermute ich einmal, dass du dich direkt via PPPoE und ein Modem einwählst?

Exakt, vorgelagert hab ich ein Modem und Opnsense meldet sich an via PPPoE.

Kannst du bei der automatisch erstellten Regel für das Unraid einmal das Logging anschalten? Sollte möglich sein.

Ja, kann ich machen, weiß nur nicht wo ich die logs einsehen kann^^

Du prüfst von extern übrigens auf "1443" - das ist falsch, denn du mappst ja via NAT die 443 auf die 1443, somit ist Port 1443 nach extern natürlich geschlossen und es sollte ledglich 443 offen sein :) Kannst du das nochmal prüfen?

Klar - mein Fehler^^:
# /usr/bin/nc -v -w 10 -z  -4 -s '**.220.189.***'  '10.100.10.100' '443'
nc: connect to 10.100.10.100 port 443 (tcp) failed: Operation timed out

Das ist in Regelform etwas verwirrend, aber die Reihenfolge der Abarbeitung ist "NAT Regeln zuerst, dann Firewallregeln" und da ein ankommendes Paket dann zuerst durch NAT transformiert wird (aka Zieladresse und Port werden umgeschrieben), muss die Firewallregel auf dem WAN natürlich so "seltsam" aussehen, dass die int. IP und der int. Port freigegeben werden müssen (da das Paket ja schon transformiert am Regel-Filter ankommt). Darum von extern nochmal mit der normalen HTTPS/443 testen :)

Cheers
\jens

Nutze sonst immer externe tools um die Ports zu checken, bin das nicht gewohnt das es schon eingebaut ist :)

Hab jetzt mal das Loggin für die Portweiterleitung und für die Regel der WAN Schnittstelle aktiviert.

=)

[JeGr]

> Ja, kann ich machen, weiß nur nicht wo ich die logs einsehen kann^^

Firewall: Log Files: Live View

> nc: connect to 10.100.10.100 port 443 (tcp) failed: Operation timed out

Meh, das wollte ich natürlich nicht lesen :D Schade, aber das wäre auch zu einfach gewesen...
Aber dann wirds langsam richtig interessant. Hmm.

Wenn das Logging für die Unraid Regel drin ist, versuch nochmal von extern auf die WAN IP via tcp/443 draufzukommen und vorher vielleicht von innen nochmal ne IP Testseite aufrufen (also sowas wie http://checkip.dyndns.org oder https://ip.qwertiko.io) um zu testen, dass die IP die du aufrufst auch wirklich deine ist, die du in der UI siehst - nicht dass der Provider da noch mogelt ;)

Wenn das passt, solltest du eigentlich nen grünen Eintrag in der Live-View zu deinem Zugriff haben mit Destionation <interneUnraidIP>:1443 und kein Block gegen <externerWANIP>:443 aber genau das müssen wir mal rausfinden.

:)

[MCMarcel]

Achsoo, dachte ich kann das evtl. einzeln ansehen welche Regel was blockt..

Die IP stimmt überein.

Im Anhang ein ausschnitt wie es aussieht wenn ich vom handy (mobil) auf den port 443 zugreifen möchte..


Teste ich es mit Port Probe, bekomme ich nur ausgehend von LAN eine Grüne Meldung (2. Bild)
nix eingehend?

:-/

[JeGr]

So nach einigem Hirnschmalz-Einsatz und schlußendlich einer kurzen "Look-at-me" Session bei der ich mal direkt aufs System schauen konnte, hat sich das Problem als kurioser herausgestellt als gedacht :D

Problem war hier tatsächlich ... das verwendete Alias für die Destination des Port Forwards. Hier war zwar die IP hinterlegt aber versehentlich der Typ statt auf "Host" auf "URL (IP)" gestellt! Damit hat die Sense versucht, die angegebene URI/IP abzurufen und eine Liste oder einzelne IP abzurufen, die zurückgegeben wird (also im Prinzip ähnlich wie Firehol Blocklisten abzurufen). Da es hier natürlich keine IPs als Antwort gab - war das Alias schlicht leer.

Und ein Port Forward / Redirect auf eine leere Zieladresse führt PF nicht aus, womit dann der ganze Redirect geskippt wurde. Eine Änderung auf eine manuell eingegebene IP hatte dann nach einigen Versuchen und Debugging im temp-rule file gezeigt, dass die Regel plötzlich ausgeführt wurde. Dadurch auf das Alias gestoßen und korrigiert -> und zack geht auch der Redirect von extern sauber durch :)

Also: Ggf. auch mal die verwendeten Aliase überprüfen, vielleicht hat sich da auch einfach mal ein kleiner Fehler eingeschlichen. Alles andere - Forward, Regel etc. - haben nämlich eigentlich gepasst ;)

Cheers
\jens