Owa von extern per Portumleitung funktioniert nicht korrekt

[_Nemo 10]

Hallo Wissende,

 

ich habe folgende Umgebung:

1x Securepoint Firewall V11 dahinter  mehrere Kunden mit je einem Exchangeserver 2013 oder Exchange 2010

 

die externe Anbindung funktioniert über umgeleitete Ports

Z.B. Kunde1 - feste-IP:44329 > Firewall Portumleitung auf 443 > Kunde1-Exchange

       Kunde2 - fetse-IP:44330 > Firewall Portumleitung auf 443 > Kunde2-Exchange

       Kunde3 - feste-IP:44331 > Firewall Portumleitung auf 443 > Kunde3-Exchange

Smartphones funktionieren bei allen Kunden ohne Probleme.

Jetzt wollte ein Kunde die Owa von extern nutzen und dabei ist aufgefallen, dass bei keinem Exchange-Server 2013 die Anbindung der Owa von extern funktioniert, intern funktioniert sie. Dieses Problem scheint nur mit dem Exchange 2013 zusammenzuhängen, 2010 funktioniert einwandfrei.

 

Das Problem stellt sich wie folgt da:

Webbrowser https://feste-ip:44329/owa > Seite wird mit einem Zertifikatsfehler (wegen selbstsigniertem) aufgerufen > man sagt lade trotzdem, ist die nächste Meldung "Seite kann nicht gefunden werden Error 404". In der Adressleite wird die Logonseite ohne Port aufgerufen.

 

Route ich von extern den 443, was standardmäßig nicht gewollt ist, auf einen der Kunden-Exchangeserver z.B. Kunde1 funktioniert die Owa bei diesem Kunden. Rufe ich bei dieser Konstellation bei einen Kunden mit Portumleitung z.B. Kunde2 die Owa auf, startet die Owa von Kunde1 > siehe Problem Beschreibung > Logonseite wird ohne Port aufgerufen.

 

Jetzt meine Fragen:

Wenn im virtuellen Verz. der Owa die externe URL mir einem Port eingetragen wird, wertet der Exchange diesen korrekt aus? Oder ist das falsch?

Ist der Reverse-Proxy eine Lösung dafür?

 

Da für mich das nach einem grundsätzlichen Problem ausschaut, habe ich erstmal auf weitere Details verzichtet.

 

Ich bedanke mich für Eure Mühen und Denkansätze.

 

Manuel

 

 

[testperson 1.680]

Hi,

 

das grundsätzliche Problem ist eher, dass man sowas richtig macht und nicht so (Meiner Meinung nach insbesondere im Hosting).

Eine Lösung dafür wäre, wie von dir erwähnt, ein Reverse Proxy. Alternativ müsstest du für jeden Kunden eine eigene (statische) öffentliche IP Adresse (und Port 443 / https) nutzen. Die selbstsignierten Zertifikate solltet Ihr auch ASAP entsorgen.

 

Gruß

Jan

[mwiederkehr 373]

Soweit ich weiss, ist das Ändern des Ports bei OWA, ActiveSync etc. nicht unterstützt. Es wird irgendwo im OWA einen absoluten Link haben, weshalb der Zugriff scheitert.

 

Die beste Lösung ist eine IP-Adresse pro Kunde. Ist das nicht möglich, könnte man es mit URL Rewriting oder einem Reverse Proxy lösen. Dafür sollte Application Request Routing (ARR) vom IIS schon reichen.

 

Variante 1 (unterschiedlicher Port): Auf dem Exchange des Kunden im IIS URL Rewrite konfigurieren, dass es bei Antworten https://ip durch https://ip:port ersetzt.

 

Variante 2 (alle Kunden auf Port 443): Einen Server mit IIS und ARR installieren und je nach Hostnamen die Anfragen auf die Exchange-Server dahinter verteilen. Dies ist sicher die schönste Lösung, bedingt aber einen zusätzlichen Server und etwas Konfigurationsaufwand.

[NorbertFe 2.035]

Spätestens Outlook wird bei sowas ja in sich zusammenfallen. Ich würde auch eher dazu tendieren "es richtig zu machen". ;)

[_Nemo 10]

Vielen Dank für die schnellen Antworten.

Die akute Aufgabenstellung konnte ich estmal mit dem Standardport erfüllen.

Ich werde mir in den nächsten Tagen, wozu macht man Urlaub, einen Kopf machen wie ich dies bei uns dann händeln kann.

 

Ich würde mich dann gerne mit meinen Ideen oder Lösungsansätzen an euch wenden.

 

Herzlich Dank

 

Manuel