Probleme mit Verbindung zu HTTPS Server
Hallo zusammen,
ich habe folgendes Problem. Bei einem Kunden kann ich im Extranet keine HTTPS Seiten aufrufen - Grund ist unklar. Ich vermute, das es evtl. am Routing liegt, aber vielleicht kann mir das jemand bestätigen.
Die Clients befinden sich im Privat Netz 192.168.1.0/24 und haben als Gateway einen Windows 2003 Server, der als Router fungiert. An dem sind zwei DSL Leitungen angeschlossen.
1. Leitung - T-DSL für Internet - hier wird die IP vom Provider zugewiesen
2. Extranet eines Automobilherstellers - hier hat der Kunden feste IPs vom Netzbetreiber bekommen.
Über RAS habe ich nun eine Routing erstellt, das alle IPs die Extranet stehen über die Extranet Leitung verbindet. Der Rest soll dann über die T-DSL Leitung verschwinden.
Das ganze klappt soweit auch ganz gut. FTP und HTTP Verbindungen stellen kein Problem da. Sobald ich aber eine HTTPS Seite aufrufe ich krieg ich nur die Zertifikatseite angezeit, wo ich die Verbindung mit Ja / Nein bestätigen kann (das typische IE Fenster eben).
Ich vermute einfach mal, warum es nicht klappt. Kann es sein, das nach der Bestätigung mit Ja die Verbindung zum HTTPS aufgebaut wird und der Server versucht die Verbindung zur anfragenden IP (also Extranet IP, die anfragt) aufzubauen. Da aber der Client im 192.168.1.0 Netz steht, bekommt dieser die Verbindung nicht mit, weil die Packete ja nicht für ihn sind ?
Muss ich im RAS evtl. noch dem Router sagen das der Port 443 auch natten soll ? Lohnt es ggf einen Proxy auf dem Windows 2003 Server aufzusetzen ?
Vielen Dank erstmal für Eure Hilfe.
Gruß Daniel
ich habe folgendes Problem. Bei einem Kunden kann ich im Extranet keine HTTPS Seiten aufrufen - Grund ist unklar. Ich vermute, das es evtl. am Routing liegt, aber vielleicht kann mir das jemand bestätigen.
Die Clients befinden sich im Privat Netz 192.168.1.0/24 und haben als Gateway einen Windows 2003 Server, der als Router fungiert. An dem sind zwei DSL Leitungen angeschlossen.
1. Leitung - T-DSL für Internet - hier wird die IP vom Provider zugewiesen
2. Extranet eines Automobilherstellers - hier hat der Kunden feste IPs vom Netzbetreiber bekommen.
Über RAS habe ich nun eine Routing erstellt, das alle IPs die Extranet stehen über die Extranet Leitung verbindet. Der Rest soll dann über die T-DSL Leitung verschwinden.
Das ganze klappt soweit auch ganz gut. FTP und HTTP Verbindungen stellen kein Problem da. Sobald ich aber eine HTTPS Seite aufrufe ich krieg ich nur die Zertifikatseite angezeit, wo ich die Verbindung mit Ja / Nein bestätigen kann (das typische IE Fenster eben).
Ich vermute einfach mal, warum es nicht klappt. Kann es sein, das nach der Bestätigung mit Ja die Verbindung zum HTTPS aufgebaut wird und der Server versucht die Verbindung zur anfragenden IP (also Extranet IP, die anfragt) aufzubauen. Da aber der Client im 192.168.1.0 Netz steht, bekommt dieser die Verbindung nicht mit, weil die Packete ja nicht für ihn sind ?
Muss ich im RAS evtl. noch dem Router sagen das der Port 443 auch natten soll ? Lohnt es ggf einen Proxy auf dem Windows 2003 Server aufzusetzen ?
Vielen Dank erstmal für Eure Hilfe.
Gruß Daniel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 62797
Url: https://administrator.de/forum/probleme-mit-verbindung-zu-https-server-62797.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
2 Kommentare
Neuester Kommentar
443 muss freilich auch genanntet werden, wenn von einer öffentlichen IP auf eine private IP zugegriffen werden soll.
Ansonsten scheint die Verbindung doch ok - wenn schon das Zertifikat angezeigt wird, dann hat man ja schon Verbindung zum Webserver.
Nach bestätigung des Zerttifikats springt er auf https und damit 443 um. Wenn dieser Port nicht erreichbar ist, kann auch keine Verbindung per ssl stattfinden.
Ansonsten scheint die Verbindung doch ok - wenn schon das Zertifikat angezeigt wird, dann hat man ja schon Verbindung zum Webserver.
Nach bestätigung des Zerttifikats springt er auf https und damit 443 um. Wenn dieser Port nicht erreichbar ist, kann auch keine Verbindung per ssl stattfinden.