OPNsense Forum
International Forums => German - Deutsch => Topic started by: macalloy on February 19, 2021, 09:20:39 pm
-
Hallo,
ich habe mir vor kurzem OpnSense eingerichtet. Auf einem Server im LAN betreibe ich eine Gitea Installation. Per Port-forward ist dieser auch im Internet erreichbar. Vom LAN aus konnte ich bis vor kurzem ohne Probleme mit dem DynDNS Namen ansprechen.
Vor kurzem hab ich OpnSense auf die neue Version aktuallisiert. Und ich vermute, dass es seit diesem Zeitpunkt nicht mehr funktioniert. D.h. Zugriff mit dem DynDNS Namen; es funktioniert nur noch direkt die IP adresse (bzw. LAN interner Name).
Internet
|
+------------+
| DSL Modem |
| 10.0.0.138 |
+------------+
| DMZ
| 10.0.0.10
|
+---------------+
| OpnSense |------------- DHCP clients
| 192.168.1.254 | 192.168.1.60 - 99
+---------------+
|
|
+----------------+
| Dienste Server |
| 192.168.1.250 |
+----------------+
Welche Einstellungen sind hier nicht korrekt?
Ich habe die hoffentlich relevanten Screenshots beigelegt.
Schon mal Danke für die Hilfe!
-
Was sagt denn ein nslookup von Client?
Und was ein tracert?
-
nslookup liefert die Internet-Adresse (19x.1xx.20x.100)
traceroute to test.it (19x.1xx.20x.100), 64 hops max, 52 byte packets
1 192.168.1.254 (192.168.1.254) 9.324 ms 2.186 ms 2.605 ms
2 * * *
-
Dann schau Mal im Live Log während du es versuchst
Wird da was geblockt?
-
Ich bin erst am lernen, wie das alles funktioniert...
Ich hoffe, ich hab den log Filter korrekt gesetzt. Siehe Screenshot.
Ich würde mal sagen, da wird nichts geblockt.
-
Ich bin jetzt auf die ursprüngliche Version von OpnSense zurückgestiegen. Funktioniert auch nicht mehr.
Keine Ahnung was ich da wo verstellt habe. Ich bekomm's nicht mehr zum Laufen.
Hätte schon DNS override versucht. Aber da funktioniert dann der Reverse-Proxy am "Dienste Server" nicht.
Meine Domain lautet z.B. test.xy
Dann gibt es cname Einträge, z.b. für git.text.xy
Mit der Port forward Regel kommt https://git.text.xy zum "Dienste Server" auf Port 30443
Dort läuft ein Reverseproxy welcher git.text.xy:30443 zum richtigen gitea-server leitet.
Funktioniert vom Internet aus wunderbar. Mit DNS override funktioniert wie gesagt der Reverse Proxy nicht.
Und NAT funktioniert leider auch nicht mehr :-(
-
Spiel mal mit den Einstellungen unter Firewall --> Advanced, Reflection.
Ich benutze die nicht, aber ich habe den Verdacht, da könnte es bei Dir klemmen.
-
D.h. Zugriff mit dem DynDNS Namen; es funktioniert nur noch direkt die IP adresse (bzw. LAN interner Name).
Nur zur Sicherheit. Der DynDNS Name wird aber noch mit der richtigen IP aktualisiert? Das hast Du überprüft?
Und mit welcher IP Adresse funktioniert es? Die interne oder kannst Du auch die WAN IP nehmen?
-
Vom Internet kommend funktioniert die Port-Weiterleitung perfekt.
D.h. Aufruf von https://git.text.xy funktioniert.
Im LAN kommt ich auf meinen gitea-server nur per IP (oder seinem LAN namen):
http://192.168.1.250:50080
(Der Portforward gibt 443 an den Dienste Server Port 30443 wo ein Reverseproxy dann auf 50080 geht).
Verwende ich im LAN die externe URL, dann kommt irgendwann ein Timeout.
Ich glaub ich hab die 3 NAT Optionen nun schon in allen Kombinationen durch. Ändert aber nichts.
Eigenartig ist ja, dass es bis vor kurzem funktioniert hat.
Kann es noch am DSL Modem liegen? Aber dort kann ich gar keine Einstellungen vornehmen.
-
Ich hab übrigens nochmal die Konfiguration bei Null gestartet (Neuinstallation). Hilft aber auch nicht...
-
Ich hab übrigens nochmal die Konfiguration bei Null gestartet (Neuinstallation). Hilft aber auch nicht...
Hast du NAT Reflection für die Regel aktiviert ?
Sauberer wäre aber generell Split DNS
-
Steht auf "Use system default" bzw. hab ich auch schon "Enable" versucht. Ändert nichts.
Was bedeutet Split DNS? Ein DNS Override anlegen?
-
Den override hab ich schon versucht. Aber irgendwie funktioniert dann der Reverseproxy nicht.
Ich habe folgende Rev-Proxy Einträge:
https://test.xy:30443 --> 192.168.1.250:50081
https://git.test.xy:30443 --> 192.168.1.250:50080
ich komm dann immer auf den ersten Eintrag
-
Den Hintergrund warum das nicht funktioniert, verstehst Du aber? Die Anfragen kommen aus dem LAN und gehen wieder ins selbe LAN. Die OPNsense muss also die Source Adresse umschreiben, damit der Gitea Server seine Antwort an die OPNsense sendet. Du könntest mal schauen, ob Du die Requests am Gitea Server siehst. Du solltest die Source Adresse von der OPNsense sehen. Wenn da die IP vom LAN Gerät drin ist, ist es falsch. Wäre ein erster Schritt, um zu erfahren, was die OPNsense da mit dem Paket so anstellt. Oder mal ein TCPdump auf der OPNsense während eines solchen Zugriffs mitschneiden.
Als härteste Maßnahme: Du könntest den Gitea Server in ein eigenes VLAN packen. Dann braucht es kein Reflection Zeug.
-
Den Hintergrund warum das nicht funktioniert, verstehst Du aber? Die Anfragen kommen aus dem LAN und gehen wieder ins selbe LAN. Die OPNsense muss also die Source Adresse umschreiben, damit der Gitea Server seine Antwort an die OPNsense sendet. Du könntest mal schauen, ob Du die Requests am Gitea Server siehst. Du solltest die Source Adresse von der OPNsense sehen. Wenn da die IP vom LAN Gerät drin ist, ist es falsch. Wäre ein erster Schritt, um zu erfahren, was die OPNsense da mit dem Paket so anstellt. Oder mal ein TCPdump auf der OPNsense während eines solchen Zugriffs mitschneiden.
Als härteste Maßnahme: Du könntest den Gitea Server in ein eigenes VLAN packen. Dann braucht es kein Reflection Zeug.
Und falls die falsche IP als Source gesetzt wird musst du Outbound NAT auf deinem LAN Interface setzen
Dennoch wäre ein getrenntes Netz, gerade bei Diensten die aus dem Internet erreichbar sind der bessere Weg
-
Der Hinweis mit den getrennten Netzen hat mich zum Nachdenken gebracht...
Ich habe auf meiner Firewall und am Dienste Server noch eine Netzwerk-Karte frei.
Die beiden habe ich auch schon direkt verkabelt.
Internet
|
+------------+
| DSL Modem |
| 10.0.0.138 |
+------------+
| DMZ
|
| 10.0.0.10
| eth1
+----------------------------------+
| OpnSense |
| 192.168.1.254 192.168.10.254 |
+----------------------------------+
| eth0 | eth2
| |
+---------------+ |
| TP-LINK | |
| 192.168.1.253 | |
+---------------+ |
| |
| eth0 | eth1
+---------------------------------------+
| Dienste Server |
| 192.168.1.250 192.168.10.250 |
| Fileserver,... Docker |
+---------------------------------------+
Damit könnte ich mir ja das VLAN sparen - oder?
Nur was ich da dann wie konfigurieren muss ist mir noch nicht ganz klar. Vor allem, warum da kein Reflection mehr notwendig ist.
-
Der Hinweis mit den getrennten Netzen hat mich zum Nachdenken gebracht...
Ich habe auf meiner Firewall und am Dienste Server noch eine Netzwerk-Karte frei.
Die beiden habe ich auch schon direkt verkabelt.
Internet
|
+------------+
| DSL Modem |
| 10.0.0.138 |
+------------+
| DMZ
|
| 10.0.0.10
| eth1
+----------------------------------+
| OpnSense |
| 192.168.1.254 192.168.10.254 |
+----------------------------------+
| eth0 | eth2
| |
+---------------+ |
| TP-LINK | |
| 192.168.1.253 | |
+---------------+ |
| |
| eth0 | eth1
+---------------------------------------+
| Dienste Server |
| 192.168.1.250 192.168.10.250 |
| Fileserver,... Docker |
+---------------------------------------+
Damit könnte ich mir ja das VLAN sparen - oder?
Nur was ich da dann wie konfigurieren muss ist mir noch nicht ganz klar. Vor allem, warum da kein Reflection mehr notwendig ist.
Genau entweder getrennt verkabeln oder halt mit VLans.
Wenn du diese 2 getrennten Netzwerke hast, wird einfach auf dem LAN eine ALLOW Regel zu deiner DMZ angelegt, das wars eigentlich.