Port-Forward funktioniert nicht

Started by ChrisVH1982, February 23, 2021, 11:14:34 PM

Previous topic - Next topic
Hallo Community,

Firewalls sind für mich Neuland, daher verzeiht bitte, sollte die Lösung meines Problems zu einfach sein :-).

Ich habe opnsense als virtuelle Appliance auf meinem Hyper-v Server installiert und stelle zwei Interfaces WAN/LAN bereit. In meinem Testszenario soll eine Webseite im LAN vom WAN aus erreichbar sein. Dazu habe ich eine Port-Forward Regel erstellt, die aber nicht funktioniert.

In der vereinfachten Darstellung anbei sieht man links mein Test Szenario und rechts die von mir an opnsense vorgenommenen Einstellungen. Im Live Log der Firewall lese ich aber immer, dass meine Verbindung wegen der "default deny rule" geblockt wurde. Diese Regel finde ich aber nicht.


Hallo Chris,
in der NAT-Regel als Destination die IP-Adresse Deiner WAN-Schnittstelle, also 192.168.1.10, eintragen. Hintergrund: die Anfrage vom Client (Source) kommt auf der WAN-Schnittstelle an und soll von dieser "Destination" weitergeleitet werden an Deinen Web-Server.

Hi!

Erst einmal herzlichen Dank für die Erklärung, was die "Destination" ist. Das war mir aus der Doku nicht ganz klar, aber Du hast es mir mit nur einem Satz erklärt!

Ich habe mal folgende Einstellungen probiert... Scheint den gleichen Effekt zu haben:
Destination = Single Host or Network (IP)
Destination = WAN address

Der Effekt ist nun, dass ich im Log "grün" sehe und als Label "let out anything from firewall host itself" sehe. Auch wird mein Host unter korrekter IP und Port als "Destination" angezeigt. Dennoch wird die Webseite im Browser nicht angezeigt. Muss der Weg zurück, also die Antwort, auch noch freigegeben werden?

Okay Korrektur, also ich sehe leider immer noch Meldungen von der "Deny Rule".


Hi,

Mich verwirrt deine Zeichnung etwas.
Welche IP hat denn dein Laptop jetzt? Die rote oder die grüne?

Die rote wäre ok, die grüne kann meiner Meinung nach nicht funktionieren da sie im selben Netz wie der Webserver wäre und die FW damit nicht klar käme.

Neben der NAT von außen nach innen musst du natürlich auch auf dem WAN Port den Traffic auf Port 80 erlauben.

Erlaube was auf Port 80 der WAN Schnittstelle ankommt. Dann forwarding des Portes auf den Webserver.

Gruß

Sven

Gesendet von meinem SM-N960F mit Tapatalk pro


Hallo Sven,

die Rote soll WAN und die Grüne LAN darstellen. Das Laptop hat auch im Test Szenario auch eine LAN IP. Die kannst Du im Prinzip ignorieren.

Wo mache ich das?
Neben der NAT von außen nach innen musst du natürlich auch auf dem WAN Port den Traffic auf Port 80 erlauben.
Erlaube was auf Port 80 der WAN Schnittstelle ankommt. Dann forwarding des Portes auf den Webserver.


Der Port-Forward erstellte automatisch eine Regel:
Source * Port * Destination <MeinServer> Port 80 Gateway * Schedule *

Hallo Chris,
mit welcher IP rufst Du die Webseite auf Deinem Client auf - diese muss natürlich die IP der WAN-Schnittstelle, also 192.168.1.10 sein. Kannst Du das Firewall Log mal in "lesbar" einstellen - mann erkennt auf Deiner Graphik nichts.

Ah sorry, habe nicht bemerkt, dass die Thumbnails nicht anklickbar sind!

Also die IPs bei mir in Netz sind andere, daher bitte nicht verwirrt sein. Ich rufe über meinen Client (192.168.19.10) die Webseite http://192.168.19.67:8080 auf... Diese IP ist die IP des WAN Interfaces. Laut Nat-Regel, sollte 8080 vom WAN interface auf 192.168.20.51:80 weitergeleitet werden. Dies erzeugt dank Deiner ersten Empfehlung auch "grüne Einträge"... Aber funktioniert trotzdem nicht.


Schalt mal das Logging für die relevanten Regeln ein. Bisher sehen wir da nur die Pakete, die die Firewall Richtung Webserver schickt.
,,The S in IoT stands for Security!" :)

Öhm, also ich sehe in den Firewall-Logs nur IPs, die in der Grafik im ersten Post garnicht vorkommen.

Ist denn am WAN "deny private IPs" deaktiviert?
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Quote from: chemlud on February 24, 2021, 02:38:16 PM
Öhm, also ich sehe in den Firewall-Logs nur IPs, die in der Grafik im ersten Post garnicht vorkommen.

Ist denn am WAN "deny private IPs" deaktiviert?
Stimmt, evtl. ist der Filter für Bogon Netzwerke aktiv. Der würde dann natürlich am WAN Interface die den von dir genutzten IP Bereich, welcher für private LANs definiert wurde blockieren.

Gesendet mit Tapatalk pro


Die oben genannten IPs waren nur ein Beispiel. In den Screenshots sieht man die von mir genutzten "echten" IPs.

Das Aktivieren des Logging bringt auch nicht mehr Infos im Live Log.
Firewall > NAT > Port Forward > Mein Eintrag > Log = YES
Firewall > NAT > Rules > WAN > Autom. erstellter Eintrag > Fragezeichen angeklickt um Logging zu aktivieren



Es muss doch eine FW Regel auf dem WAN Interface geben, die den Traffic zulassen soll. Dort mal logging einschalten. Du solltest dann definitiv Pakete im Log sehen. Wenn nicht, klemmt es noch anderweitig.
,,The S in IoT stands for Security!" :)

Wenn du das ganze in Laborumgebung ohne Internet testest, dann gib deinem Laptop sowie dem WAN Interface eine IP außerhalb der für privat reservierten IP Adressen oder schau nach ob du die Filterung für Bogon Netzwerke ausgeschaltet hast. Sonst wirst du nie mit einer 192.168.X.X IP durch das WAN kommen.

Gesendet mit Tapatalk pro


Quote from: Gauss23 on February 24, 2021, 04:24:04 PM
Es muss doch eine FW Regel auf dem WAN Interface geben, die den Traffic zulassen soll. Dort mal logging einschalten. Du solltest dann definitiv Pakete im Log sehen. Wenn nicht, klemmt es noch anderweitig.
Nicht wenn du in der NAT Regel unten "erlauben" auswählst
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support