6
Route in ein weiteres (bekanntes) Netzwerk klappt vom DC aus nicht
Hallo zusammen,
folgende Ausgangslage:
Aus unserem Netz (172.16.1.0) soll der Zugang auf ein weiteres Netz (172.32.11.0) möglich sein. In dem entfernten Netz läuft u.a. die Netzsecurity von einem Dienstleister.
Die Route habe ich entsprechend auf unserer Firewall (= Standardgateway) eingetragen, die Route funktioniert von allen Clients aus unserem Netz einwandfrei. Lediglich der 1. Domänencontroller kommt nicht durch (weder per Ping, Telnet, ...). Hier kommt ständig die Zeitüberschreitung.
Ich habe mal die Unterschiede zwischen 1. und 2. Domänencontroller auf der Firewall verglichen. Der 1. Domänencontroller ist im Vergleich nur in zwei NAT-Regeln und Server-SSL (für DPI) veränkert..
Staatische Routen direkt auf dem 1. DC sind nicht eingetragen. Der Dienstleister hat ein Routingproblem seinerseits ausgeschlossen.
Hat jemand eine Idee, woran das liegen könnte?
folgende Ausgangslage:
Aus unserem Netz (172.16.1.0) soll der Zugang auf ein weiteres Netz (172.32.11.0) möglich sein. In dem entfernten Netz läuft u.a. die Netzsecurity von einem Dienstleister.
Die Route habe ich entsprechend auf unserer Firewall (= Standardgateway) eingetragen, die Route funktioniert von allen Clients aus unserem Netz einwandfrei. Lediglich der 1. Domänencontroller kommt nicht durch (weder per Ping, Telnet, ...). Hier kommt ständig die Zeitüberschreitung.
Ich habe mal die Unterschiede zwischen 1. und 2. Domänencontroller auf der Firewall verglichen. Der 1. Domänencontroller ist im Vergleich nur in zwei NAT-Regeln und Server-SSL (für DPI) veränkert..
Staatische Routen direkt auf dem 1. DC sind nicht eingetragen. Der Dienstleister hat ein Routingproblem seinerseits ausgeschlossen.
Hat jemand eine Idee, woran das liegen könnte?
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: 511824
Url: https://administrator.de/contentid/511824
Ausgedruckt am: 26.11.2024 um 05:11 Uhr
6 Kommentare
Neuester Kommentar
Hi,
ich hoffe, das ist ein Schreibfehler deinerseits, denn 172.32.x.x ist kein privater IP-Adressraum mehr, dieser endet bei 172.31.255.255
Und falls es doch so ist -> Dienstleister wechseln
Ping ist irrelevant, was sagt tracert?
ein weiteres Netz (172.32.11.0)
ich hoffe, das ist ein Schreibfehler deinerseits, denn 172.32.x.x ist kein privater IP-Adressraum mehr, dieser endet bei 172.31.255.255
Und falls es doch so ist -> Dienstleister wechseln
Lediglich der 1. Domänencontroller kommt nicht durch (weder per Ping, Telnet, ...). Hier kommt ständig die Zeitüberschreitung.
Ping ist irrelevant, was sagt tracert?
Mal abgesehen von dem (hoffentlich) vermutlichen Tippfehler in der Adressierung oben ist die Kardinalsfrage WER dieses Netz routet bzw. WO es direkt angeschlossen ist ?
Ist das ebenfalls die Firewall ??
Dann wäre eine statische Route dort natürlich völlig falsch, denn direkt angeschlossenen Netze "kennt" die Firewall logischerweise auch ohne Routen. Eine zusätzliche Route wäre da ziemlich kontraproduktiv !
Hilfreich wäre mal eine kleine Skizze WIE das gesamte Netz aussieht bzw. WO die Routing Pfade sind.
In der Regel ist die Ursache von sowas falsche oder fehlende Gateways oder falsche oder fehlende Firewall Regeln. Routen braucht der DC logischerweise nicht.
Was er aber zwingend braucht ist ein Default Gateway und dieses Gateway (Firewall ?) sollte dann den Weg ins Zielnetz kennen.
Traceroute (tracert) oder Pathping (Windows) sind hier wie immer deine besten Freunde, denn sie zeigen alle Routerhops einzeln an.
Grundlagen dazu findest du sonst hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Ist das ebenfalls die Firewall ??
Dann wäre eine statische Route dort natürlich völlig falsch, denn direkt angeschlossenen Netze "kennt" die Firewall logischerweise auch ohne Routen. Eine zusätzliche Route wäre da ziemlich kontraproduktiv !
Hilfreich wäre mal eine kleine Skizze WIE das gesamte Netz aussieht bzw. WO die Routing Pfade sind.
In der Regel ist die Ursache von sowas falsche oder fehlende Gateways oder falsche oder fehlende Firewall Regeln. Routen braucht der DC logischerweise nicht.
Was er aber zwingend braucht ist ein Default Gateway und dieses Gateway (Firewall ?) sollte dann den Weg ins Zielnetz kennen.
Traceroute (tracert) oder Pathping (Windows) sind hier wie immer deine besten Freunde, denn sie zeigen alle Routerhops einzeln an.
Grundlagen dazu findest du sonst hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Zitat von @phartmann:
... der Zugang auf ein weiteres Netz (172.32.11.0) möglich sein. In dem entfernten Netz läuft u.a. die Netzsecurity von einem Dienstleister.
... der Zugang auf ein weiteres Netz (172.32.11.0) möglich sein. In dem entfernten Netz läuft u.a. die Netzsecurity von einem Dienstleister.
Tippfehler? Ansonsten ist das der Fehler. Es ist nur 172.16.0.0/12 (=172.16.0.0 ... 172.31.255.255) laut RFC1918 für die Private Nutzung freigegeben.
lks
Ich denke wir drei haben ein Beben ausgelöst
Vermutlich, denn vom TO kommt ja keinerlei Feedback mehr. Wohl das Interesse an einer zielführenden Lösung verloren ?!
Hoffentlich reichts dann wenigstens noch für ein
Wie kann ich einen Beitrag als gelöst markieren?
Hoffentlich reichts dann wenigstens noch für ein
Wie kann ich einen Beitrag als gelöst markieren?
Sorry, war natürlich ein Tippfehler. Den Fehler habe ich gefunden, der DC ist wegen einer unglücklichen Regel falsch ins andere Netz gegangen.
@aqui: Warum sollte ich das Interesse an einer zielführenden Lösung verloren haben; im Jahresendgeschäft fehlt manchmal der Blick für Foren...
@aqui: Warum sollte ich das Interesse an einer zielführenden Lösung verloren haben; im Jahresendgeschäft fehlt manchmal der Blick für Foren...
