Portforwarding 443 OWA nicht von Internem LAN erreichbar

[airdatec]

Hallo Zusammen,

nach einem Firwallwechsel von IPCOP (wieder eine) auf die Opensense klappt alles wunderbar.
Portforwarding von der Externen IP Adresse auf Port 443 klappt wunderbar via Alias und Portweiterleitung von außen (OWA). Jedoch fragen die Smartphones diese Externe WAN Adresse mit dem Port 443 auch aus dem Internen Wlan ab, da kommt jedoch keine Verbindung zustande.
Im Anhang 2 Bilder von der konfigurierten Forwarding Regel, die Firewall Regel wird ja automatisch erstellt.

Ich hoffe auf Hilfe Danke, denke es ist nur eine Kleinigkeit

Chris

[BeNe]

Vielleicht hilft Dir das ja weiter:

Wenn Du einen Microsoft Exchange Server betreibst (wovon ich jetzt mal aus gehe da es um OWA geht) kannst Du am Exchange Server selber einen internen und einen externen Pfad für OWA und alle anderen Dienste angeben.
Per Autodiscover werden denn jeweils die URL´s ermittelt. Ist der interne Pfad erreichbar, greift der auch, ansonsten fallback auf den externen.

Oder Du legst im internen DNS den selben Eintrag für dein OWA an, nur mit der internen IP anstatt der externen (DNS Splitting)

[airdatec]

Hallo naja, wir nutzten nur die WAN IP Adresse, es wäre schön das NAT 443 auch vom internen Netz (LAN/WLAN) auf die WAN Adresse zu nutzen, ging vorher mit IPCOP und anderen Routern ohne Probleme. Bin schön langsam am verzweifeln.

Müsste sonst ziemlich viele Handys umstellen da diese auf die WAN IP gebunden sind.

[JeGr]

> Hallo naja, wir nutzten nur die WAN IP Adresse, es wäre schön das NAT 443 auch vom internen Netz (LAN/WLAN) auf die WAN Adresse zu nutzen, ging vorher mit IPCOP und anderen Routern ohne Probleme. Bin schön langsam am verzweifeln.

Genau dafür gibt es ja die Exchange Einstellung für INTERNE Netze. Zudem du da m.W. nichts umstellen musst an den Telefonen, sondern das via Exchange Console und Autodiscover Anpassung geregelt wird.

Aber wenn man das unbedingt verbiegen muss, dann ist es am Einfachsten intern die URL einfach auf der internen Exchange IP aufzulösen und gut. Je nachdem wer den DNS stellt also entweder im DC oder in der Sense den Hostnamen überschreiben bzw. die komplette Domain, damit auch die Autodiscover Hits direkt an Exchange gehen.

Gruß

[airdatec]

Danke für die Antwort, habe ich verstanden, wenn ich das via DNS umbiege, dann passt evtl. das bereits akzeptierte Self Sign Zertifikat nicht.
Aber gehen wir mal weg vom Exchange.
 Ich möchte eigentlich nur das das Nat von außen (WAN) mit der selben WAN Adresse auch von innen (LAN) funktioniert.  Das ging bei IPCOP automatisch, auch bei anderen Routern. Diese Funktion würde ich gerne nachbauen, dann muss ich nix weiter anfassen.

Ist ein nicht von mir initiiertes Produktivsystem das nur noch ca. ein halbes Jahr halten muss (Office 365).

[JeGr]

> Das ging bei IPCOP automatisch, auch bei anderen Routern. Diese Funktion würde ich gerne nachbauen, dann muss ich nix weiter anfassen.

Was nicht heißt, dass es _sinnvoll_ ist. Ja das kann man machen. Stichwort NAT Reflection. Ist aber Murks aus NAT Gründen. Daher die sinnvollere Lösung: Entweder direkt via Exchange Policy oder per DNS, was mehr Sinn macht. Intern den DNS umschreiben und _direkte_ Verbindungen nutzen, ist für die Geräte sinnvoller, als erst eine angeblich externe Adresse aufrufen, auf die Firewall aufschlagen, merken, dass der Kram per NAT Redirectet wird und per Regeln umgebogen wieder nach innen geschickt werden, damit jede Verbindung unnötig quer durch die Firewall juckeln. Darum

Ja man kann alten Kram nachbauen - muss man aber nicht Intern den DNS überschreiben für die externe Domain und auf den Exchange zeigen lassen ist im Normalfall sinnvoller und für Debugging einfacher.

[fabian]

Es gibt auch eine andere Lösung: IPv6 - das macht solche Probleme wie NAT überflüssig, da alles ne public IP hat

Split DNS ist auf der OPNsense am einfachsten, da man einfach nur im unbound (DNS-Resolver) einen Host-Override setzen muss.

[airdatec]

Ich gebe euch ja allen Recht.
Bei allen Vorgängersystemen ging das halt automatisch, ob richtig oder falsch.
Danke erstmal für die Antworten.
Da demnächst auf Office 365 umgestellt wird (halbes Jahr), ist das ganze eh nicht mehr notwendig.
Wir wollten halt in der Zwischenzeit die alte Lösung weiterlaufen lassen (IPCOP Forwarding intern/extern auf den Exchange 443). 
Hier lösen die Handys gegen die WAN IP auf (OWA) (somit kein Namenseintrag), das klappt per NAT Forwarding auch von außen über die WAN IP, nur halt leider nicht im Internen LAN/Wlan.

Sobald Ich hier NAT Reflection aktiviere (mit der Option der bei Erweitert/Einstellungen) sie Anhang, klappt auch der Zugriff aus dem Internen LAN/WLAN, jedoch wird dann bei jeder Browseranfrage (internes LAN) 443 auf den Forwarding Server durchgestellt.

DNS Splitting ist aufgrund der genutzten IP somit nicht möglich, da das ja mW. nur via Namenseinträgen geht.

[fabian]

mit einem reverse proxy kannst du auch grundsätzlich mehrere services hinter einem Port betreiben, wenn es das Protokoll erlaubt.

[airdatec]

Vielen Dank !

ich konnte das ganze mit Lets Encrypt und HA Proxy umsetzten.
Diese Anleitung ist auch wirklich gut:

https://www.frankysweb.de/exchange-2016-opnsense-haproxy-und-lets-encrypt/

Jetzt würde ich gerne zusätzlich zur Benutzername/Login Thematik mit Clientzertifkaten arbeiten.
Das ist im Frontend auch Konfigurierbar.

Hier kann man auch die CA zur Verifkation auswählen, nach neustart des HA Proxys kommt auch im Chrome die Zertifkatsabfrage, jedoch werden alle Exportieren Zertifkate (incl. Benutzerschlüssel abgelehnt)

Geht das überhaupt und hat hier jemand ein How To ?. über die Öffentliche CA von Letsencrypt kann ich ja keine Userzertifkate erstellen (damit die CA Kette durchgereicht wird.)