3
Probleme mit Wan-Verbindung zu Webmail von Exchange 2003 via HTTPS
Wan Webmail Access
Ich habe folgendes Problem:
Firewall Cisco Pix 501
SBS 2003 mit Exchange
Ich habe folgende Konfiguration am Mailserver vorgenommen:
IIS antwortet für SSL Verbindungen an Port 8443
128 Bit Verschlüsselung ist aktiviert
Am Firewall habe ich Port 8443 publiziert und eine dementsprechende Filterregel erstellt.
Der Seite Exchange im IIS habe ich erlaubt Anfragen von jeglichen IP-Adressen zu antworten.
Nun sollte bei Internetanfragen via SSL an Port 8443 eine SSL-Verbindung aufgebaut werden, die es erlaubt auf das eigene Mail-Postfach zuzugreifen. Im localen Netzwerk funktioniert dies auch tadellos; bspw. mit Eingabe im Browser von https://lan-ip-server:8443/exchange. Browser wie Internet Explorer, Firefox und Netscape bauen eine fehlerfreie Seite auf. Versucht man nun dasselbe über Wan mit https://wan-ip-firewall:8443/exchange wird eine Verbindung aufgebaut, aber der IE 6.0 gibt einen Fehler auf der Seite an (Objekt erwartet - wogmöglich ein Problem mit ASP?) und Firefox präsentiert die Seite und ladet auch die einzelnen Seiten, aber für alle Bilder werden nur Platzhalter geladen.
Was habe ich übersehen. Firewall? Muss ich für ein besonderes Protokoll eine Regel erstellen. Oder streikt nur der IIS bei Wan-Verbindungen; oder besteht ein Fehler bei den Zertifikaten, da ich jedoch über Lan ohne Probleme zugreifen kann, glaube ich nicht das dies der Fall ist. Verbinde ich mich via VPN an den Firewall, also wie wenn ich mich im Lan befände, funktioniert alles einwandfrei. Also ist es auch kein Fehler an den Einstellugen der Browser.
Für jegliche Vorschläge wäre ich sehr dankbar.
Ich habe folgendes Problem:
Firewall Cisco Pix 501
SBS 2003 mit Exchange
Ich habe folgende Konfiguration am Mailserver vorgenommen:
IIS antwortet für SSL Verbindungen an Port 8443
128 Bit Verschlüsselung ist aktiviert
Am Firewall habe ich Port 8443 publiziert und eine dementsprechende Filterregel erstellt.
Der Seite Exchange im IIS habe ich erlaubt Anfragen von jeglichen IP-Adressen zu antworten.
Nun sollte bei Internetanfragen via SSL an Port 8443 eine SSL-Verbindung aufgebaut werden, die es erlaubt auf das eigene Mail-Postfach zuzugreifen. Im localen Netzwerk funktioniert dies auch tadellos; bspw. mit Eingabe im Browser von https://lan-ip-server:8443/exchange. Browser wie Internet Explorer, Firefox und Netscape bauen eine fehlerfreie Seite auf. Versucht man nun dasselbe über Wan mit https://wan-ip-firewall:8443/exchange wird eine Verbindung aufgebaut, aber der IE 6.0 gibt einen Fehler auf der Seite an (Objekt erwartet - wogmöglich ein Problem mit ASP?) und Firefox präsentiert die Seite und ladet auch die einzelnen Seiten, aber für alle Bilder werden nur Platzhalter geladen.
Was habe ich übersehen. Firewall? Muss ich für ein besonderes Protokoll eine Regel erstellen. Oder streikt nur der IIS bei Wan-Verbindungen; oder besteht ein Fehler bei den Zertifikaten, da ich jedoch über Lan ohne Probleme zugreifen kann, glaube ich nicht das dies der Fall ist. Verbinde ich mich via VPN an den Firewall, also wie wenn ich mich im Lan befände, funktioniert alles einwandfrei. Also ist es auch kein Fehler an den Einstellugen der Browser.
Für jegliche Vorschläge wäre ich sehr dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7449
Url: https://administrator.de/contentid/7449
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
3 Kommentare
Neuester Kommentar
also ich würde so ad hoc, die Firewall vermuten.
Zeig die Pix in ihrem Syslog-Protokoll nichts an?
Zeig die Pix in ihrem Syslog-Protokoll nichts an?
Hallo, danke für dein Interesse:
Hier die Syslog für die entsprechenden Ports,
x.x.x.x ist unsere Wan-Ip, die ich nicht freizügig angeben möchte
Die 80.104.12.152 ist eine Ip meines privaten Providers (Dial In).
Auch ich dachte anfangs es könnte am Pix liegen. Aber ich habe keine denies oder errors im syslog, und wenn dann nur einige die durch meine Tests hervorgerufen wurden. Diese Logs besagen, daß Verbindungen an Port 8443 aufgebaut wurden, Fehler keine vorhanden sind, also sitzt der Fehler vielleicht doch im IIS? Vielleicht kannst Du etwas erkennen, das ich nicht sehe, danke im voraus.
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-106100: access-list outside_access_in permitted tcp outside/80.104.12.152(1729) -> <010><009>inside/x.x.x.x(8443) hit-cnt 1 (first hit)
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-302013: Built inbound TCP connection 16781 for outside:80.104.12.152/1729 (80.104.12.152/1729) to inside:192.168.17.10/8443 (x.x.x.x/8443)
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16780 for outside:80.104.12.152/1728 to inside:192.168.17.10/8443 duration 0:00:10 bytes 42960 TCP FINs
2005-02-27 12.09.19 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16779 for outside:80.104.12.152/1727 to inside:192.168.17.10/8443 duration 0:01:20 bytes 88455 TCP Reset-O
2005-02-27 12.09.24 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16781 for outside:80.104.12.152/1729 to inside:192.168.17.10/8443 duration 0:01:14 bytes 38127 TCP Reset-O
2005-02-27 12.09.55 Local0.Info 192.168.17.1 %PIX-6-305012: Teardown static TCP translation from inside:192.168.17.10/8443 to outside:x.x.x.x/8443 duration 0:21:36
Hier die Syslog für die entsprechenden Ports,
x.x.x.x ist unsere Wan-Ip, die ich nicht freizügig angeben möchte
Die 80.104.12.152 ist eine Ip meines privaten Providers (Dial In).Auch ich dachte anfangs es könnte am Pix liegen. Aber ich habe keine denies oder errors im syslog, und wenn dann nur einige die durch meine Tests hervorgerufen wurden. Diese Logs besagen, daß Verbindungen an Port 8443 aufgebaut wurden, Fehler keine vorhanden sind, also sitzt der Fehler vielleicht doch im IIS? Vielleicht kannst Du etwas erkennen, das ich nicht sehe, danke im voraus.
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-106100: access-list outside_access_in permitted tcp outside/80.104.12.152(1729) -> <010><009>inside/x.x.x.x(8443) hit-cnt 1 (first hit)
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-302013: Built inbound TCP connection 16781 for outside:80.104.12.152/1729 (80.104.12.152/1729) to inside:192.168.17.10/8443 (x.x.x.x/8443)
2005-02-27 12.08.10 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16780 for outside:80.104.12.152/1728 to inside:192.168.17.10/8443 duration 0:00:10 bytes 42960 TCP FINs
2005-02-27 12.09.19 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16779 for outside:80.104.12.152/1727 to inside:192.168.17.10/8443 duration 0:01:20 bytes 88455 TCP Reset-O
2005-02-27 12.09.24 Local0.Info 192.168.17.1 %PIX-6-302014: Teardown TCP connection 16781 for outside:80.104.12.152/1729 to inside:192.168.17.10/8443 duration 0:01:14 bytes 38127 TCP Reset-O
2005-02-27 12.09.55 Local0.Info 192.168.17.1 %PIX-6-305012: Teardown static TCP translation from inside:192.168.17.10/8443 to outside:x.x.x.x/8443 duration 0:21:36
Hallo,
habe das Problem gelöst. Lag nicht am Firewall.
Ich hatte die externen Zugangsrechte auf die Seite im IIS von Exchange nur für die Seite Exchange gesetzt. Dachte mir das müsste reichen. Leider nicht. Musste externe Zugänge auch auf die Site ExchWeb setzen. Dies habe ich übersehen, da der Browser keine Links auf ExchWeb benutze sondern immer nur Exchange aufrief.
Wie meistens nur eine Kleinigkeit, die aber dazu führte, daß ich WE-Arbeit machen musste .... na ja, wenigstens funktionierts jetzt, kann man nichts machen, selber schuld.
habe das Problem gelöst. Lag nicht am Firewall.
Ich hatte die externen Zugangsrechte auf die Seite im IIS von Exchange nur für die Seite Exchange gesetzt. Dachte mir das müsste reichen. Leider nicht. Musste externe Zugänge auch auf die Site ExchWeb setzen. Dies habe ich übersehen, da der Browser keine Links auf ExchWeb benutze sondern immer nur Exchange aufrief.
Wie meistens nur eine Kleinigkeit, die aber dazu führte, daß ich WE-Arbeit machen musste ....
na ja, wenigstens funktionierts jetzt, kann man nichts machen, selber schuld.
