wie funktioniert NAT

[macalloy]

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 

[kosta]

Eine Sache verstehe ich aus deinem Posting nicht: was/wer ist TP-Link? Ist das ein einfacher unmanaged Switch?

Ich werde nicht so tun ob ich mich da jetzt weiß ich nicht wie gut auskenne, aber für mich klingt es nach einem DNS Thema? Wer löst wo auf und auf welche IP? Wird der FQDN git.test.privat intern oder extern aufgelöst, und welche IP springt dabei raus? Wenn man intern abfragt, sollte eigentlich am Unbound landen, und dort sollte ja die IP 192.168.1.250 rauskommen... dann gibt's auch kein NAT mehr...

[macalloy]

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 

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

[kosta]

Na wunderbar.
Mit NAT (=Translation) übersetzt du üblicherweise eine IP in eine andere (bzw. ein ganzes Netzwerk). Meistens wird's verwendet um interne IP (LAN) in eine öffentliche (WAN) zu verwandeln. Wobei "WAN" muss nicht zwingend Internet sein. Man kann auch zwischen zwei privaten Netzen (oder auch einzelnen IPs) NATen. In deinem Fall brauchst du aber kein NAT, da du innerhalb eines Netzes ja nichts umwandeln musst.

[macalloy]

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?

[lfirewall1243]

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?

Ist normal und richtig wenn NAT Refelection aktiv ist.

[macalloy]

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...

[lfirewall1243]

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...

https://forum.opnsense.org/index.php?topic=7627.0

Da hatte @JeGr das ganz gut beschrieben

[kosta]

Übrigens, ein bisschen eine andere Anwendung vom NAT, als klassisch LAN->WAN und Webserver.
Hab daheim ein VOIP Firmentelefon, der bei mir zu Hause eine LAN-Adresse bekommt. Dieser muss aber in die Firma zum 3CX Telefonie-Server (IPsec Tunnel) und weiter nach Deutschland auch per IPsec Tunnel zur RDS-Farm, wo sich ein 3CX Client auch befindet. Und der Haken dabei ist: mein LAN-Netz zu Hause wird auf der RDS-Farm in DE nicht akzeptiert, sondern nur ein bestimmter Bereich in der Firma. Daher habe ich nur eine Möglichkeit: in der Firma eine virtuelle IP im akzeptierten Bereich erstellen, und dann die IP von zu Hause auf die virtuelle IP NAT'en. Und das natürlich auch in beiden Richtungen.