Messages

Ich habs geschafft!

Das interne Zertifikat hab ich bekommen, weil das Admin UI der OpnSense auf Port 80/443 lauschte.
Hab ich nun geändert.

Nun funktioniert es.
Wobei ich nicht ganz sicher bin, warum...

Meinem Verständnis nach, hätte ich die NAT Regeln für 80 auf 8080 und 443 auf 8081 nun auch für LAN aktivieren müssen.
Es funktioniert aber auch, wenn sie weiterhin nur für WAN definiert sind...

*) Scheint mir ein Caching Problem im zu sein. NAT Regel muss sehr wohl für LAN und WAN definiert werden.

Die NAT Settings (Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection) habe ich auch wieder deaktiviert. Wozu braucht man diese?

Versteh die Antwort nicht ganz  ;)
Bedeutet das nun, dass dies der einzige Weg ist, wie man es lösen kann?
Warum hat es dann vorher ohne funktioniert?

Ich hab's nun mal (fast) zu Ende probiert:

Code Select Expand


❯ nslookup git.zuhause.net
Server: 192.168.1.3
Address: 192.168.1.3#53

git.zuhause.net canonical name = zuhause.net.
Name: zuhause.net
Address: 192.168.1.1

Zum einen kommt die Zertifikatswarnung.
Ich bekomme nicht das Zertifikat, welches ngnix ausliefern würde, sondern das interne Zertifikat der OpnSense.
Akzeptiere ich dieses, kommt:

Code Select Expand


A potential DNS Rebind attack has been detected.
Try to access the router by IP address instead of by hostname. You can disable this check if needed under System: Settings: Administration.


Frage: Wie komm ich zum korrekten Zertifikat und darf ich diesen Check deaktivieren?

Meinst Du, ich soll die lokale IP in meinem DNS für git.zuhause.net hinterlegen?
Das hab ich schon probiert.

Ich denke, es würde funktionieren. Bekomme dann aber eine Zertifikatswarnung.
Darum "denke". Ich habe das nämlich mal nicht akzeptiert und wieder bleiben lassen.
Immerhin, hat es hat ja schon mal komplett richtig funktioniert...

Hallo!
Ich habe wieder mal ein NAT Problem.
Ich habe einen GIT Dienst, welcher per Internet zugänglich ist.
Auf der OpnSense läuft Nginx mit Reverseproxy zum GIT-Service auf Port 50000.
Von extern funktioniert das auch.

Code Select Expand


   Internet
      |
+------------+
| DSL Modem  |
| 10.0.0.138 |
+------------+
      | DMZ
      |
      | 10.0.0.10
+-------------+
|   OpnSense  |
| 192.168.1.1 |
+-------------+
      |   
      |       
+------------+
|   Switch   |--------------+------------------+
+------------+              |                  |
      |                     |                  |
      |                     |                  |
+----------------+  +-------------------+  +--------+
|    DNS         |  |      Git          |  | Client |
| 192.168.1.3:53 |  | 192.168.1.3:50000 |  +--------+
+----------------+  +-------------------+


Bis vor kurzem hat das auch im Netzwerk funktioniert.
Da ich nicht so oft per LAN auf den Dienst zugreife, habe ich erst jetzt festgestellt, dass es nicht
mehr funktioniert.

Zuletzt habe ich ein Update auf der OpnSense durchgeführt. Hatte auch ein Backup. Leider hab ich
verabsäumt, zu prüfen, ob ich per LAN noch auf den Dienst hinkomme. Backup ist mittlerweile gelöscht.
Ich habe OpnSense nun neu installiert (mit alter Install-CD) und Config eingespielt. Funktioniert
trotzdem nicht mehr.

Im LAN kann ich den öffentlichen Namen auflösen:

Code Select Expand


❯ nslookup git.zuhause.net
Server: 192.168.1.3
Address: 192.168.1.3#53

Non-authoritative answer:
git.zuhause.net canonical name = zuhause.net.
Name: zuhause.net
Address: 193.154.xxx.xxx


Der Browser bekommt aber einen timeout.

Unter Firewall / Advanced habe ich die 3 NAT Settings aktiviert (waren, als es funktionierte, nicht
eingeschalten). Hilft aber nichts.

Ich helfe mir aktuell so, indem ich einen Hotspot zum Mobiltelefon aufbaue. Dann kann ich den GIT
sync durchführen  :(

Ich habe noch die Screenshots zu NAT und WAN-Rules ergänzt.

Könntest du mir das bitte etwas genauer erklären. Wie laufen da die Pakte im Hintergrund und warum und wo kommt da dann NAT is Spiel. Aktuell hab ich hier null Durchblick, würde das aber gerne verstehen...

Eine Frage hätte ich zu den Port-Forward Regeln.

Komme ich vom Internet habe ich eine Regel für Interface WAN, Source *, Destination 192.168.1.254, Port 443 zu NAT IP und Port.

Intern im LAN löse ich meine Domäne jetzt direkt auf die IP 192.168.1.254 auf.
Dort ist auch die Port-Forward Regel notwendig. Ich komme ja auch intern über 443 daher und muss dann ganz woanders hin.
Nun dachte ich, dass ich bei der Port-Forward Regel auch das LAN interface angeben muss. Ist aber nicht so. Funktioniert auch, wenn dort WAN steht.

Warum? Das WAN Interface ist, wenn ich mich nur im LAN bewege, gar nicht im Spiel - oder doch?

Der TP-Link ist ein managed Switch.

Ich habe jetzt einen DNS Override erfasst. DNS läuft übrigens auf der OpnSense.
Nun wird *.test.privat zu 192.168.1.254 aufgelöst.

Es funktioniert  ;D

Aber: Ich brauch also gar kein NAT
Wozu braucht man das dann eigentlich?

Hallo,

ich hatte hier bereits vor kurzem einen ähnlichen Post bzgl. NAT. Nochmal ein neuer Thread, da ich an das Thema anders herangehen mag. Ich hab meinen Testaufbau vereinfacht - ich hatte gehofft (Reverse Proxy läuft nun direkt auf der Firewall) das das dann auf Anhieb funktioniert. Tut es aber nicht. Und ich verstehe noch weniger als vorher  ;)

     Internet
        |
  +------------+
  | DSL Modem  |
  | 10.0.0.138 |
  +------------+
        | DMZ
        | 
        | 10.0.0.10
+---------------+
|   OpnSense    |
| 192.168.1.254 |
+---------------+
        |   
        |       
+---------------+
|   TP-LINK     |
| 192.168.1.253 |-------+
+---------------+       |
        |               |
        |               |
+---------------+  +--------+
|    Gitea      |  | Client |
| 192.168.1.250 |  +--------+
| Port 50080    |
+---------------+


Auf 192.168.1.250 läuft Gitea am Port 50080
Vom Client aus kann ich über die interne IP+Port darauf zugreifen.

Auf der OpnSense ist DynDns eingerichtet. Bei meinem Provider gibt es noch CNAME Einträge. Nennen wir die Domain test.privat, dann gäbe es die git.test.privat (und später noch andere xxx.test.privat).

Auf der OpnSense habe ich nginx eingerichtet mit einem server namens git.test.privat. Dieser lauscht auf den port 8080 und link zum upstream server 192.168.1.250 auf Port 50080 (also meine Gitea instanz).

Auf der OpnSense habe ich dann noch eine Port-forward Regel eingerichtet, welche WAN address, port 80 auf 192.168.1.254 (also OpnSense), port 8080 (=nginx server für GIT) weiterletet.

Nehme ich mir mein Handy zur Hand, dann kann ich problemlos via git.test.privat auf Gitea zugreifen.

Mache ich das von meinem Client aus, dann passiert nichts...
In den Firewall:Settings:Advanced habe ich alle 3 NAT Optionen angekreuzt (auch schon div. andere Kombinationen ausprobiert).

Zum Verständnis: Wenn ich im Browser die URL git.test.tt eingebe, wird der DNS nach der IP befragt. Das ist externe IP. Wenn der Browser dann den HTTP request absetzt, erkennt OpnSense wegen der NAT Settings, dass die externe IP eigentlich die interne 192.168.1.250 ist? Und der Request wird direkt zum LAN interface und nicht ans WAN geroutet? Aber wie kommt die Firewall zu dieser Info? Ist das überhaupt irgendwie korrekt, was ich da schreibe?

Im Log der Firewall sehe ich:
wan  <-  10.0.0.10:8320     xxx.xxx.xxx.214:80 tcp let out anything from firewall host itself (force gw)   
LAN  ->  192.168.1.17:56538 xxx.xxx.xxx.214:80 tcp Default allow LAN to any rule

Und danach ist Funktstille, im Log und im Browser  :(

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.

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

Steht auf "Use system default" bzw. hab ich auch schon "Enable" versucht. Ändert nichts.

Was bedeutet Split DNS? Ein DNS Override anlegen?

Ich hab übrigens nochmal die Konfiguration bei Null gestartet (Neuinstallation). Hilft aber auch nicht...

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 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 :-(

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.