3
Windows-Server verliert Verbindung zu Subnetz der Aussenstelle
Guten Tag
Ausgangslage:
Virtualisierter Windows Server 2012 R2 (auf vmware ESXi 5.5) am Hauptsitz
Sehr stabiler IPSec Tunnel zwischen beiden Standorten (Fortigate 100D am Hauptsitz, FortiWiFi 30D bei Aussenstelle)
Subnetz Hauptsitz 192.168.20.0/24
Subnetz Aussenstelle 192.168.11.0/24
Der betroffene Server kann nach einem Neustart ohne Weiteres auf Geräte der Aussenstelle zugreifen und diese natürlich auch anpingen.
Erst nach einer Gewissen Laufzeit (i.d.R. 1-2 Wochen) funktioniert die Verbindung plötzlich nicht mehr. Im LAN der Hauptsitzes kann der betroffene Server nach wie vor auf alle Geräte zugreifen.
Sämtliche Server und Clients am Hauptsitz haben zu diesem Zeitpunkt immer noch eine stabile Verbindung zu den Geräte der Aussenstelle.
Bereits geprüft habe ich:
- Windows Firewall aus/ein am betroffenen Server (hat keinen Einfluss)
- Ping von Server Hauptsitz zu Server Aussenstelle nicht möglich
- Ping von Server Aussenstelle zu Server Hauptsitz fehlerfrei
- Netzwerk-Adapter in vmware (VMXNET3) entfernt und neu hinzu gefügt
- DNS geprüft, alles i.O.
Der Server am Hauptsitz loggt:
DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "192.168.11.200" kommunizieren; angefordert von PID 9e0 (C:\Program Files (x86)\PRTG Network Monitor\PRTG Probe.exe).
Dem oben genannten Ereignis geht kein anderes auswertbares Ereignis voraus, aufgrund dessen eine Analyse stattfinden könnte.
Natürlich habe ich auch schon im Internet gesucht, aber auch dort keine spezifische Antwort gefunden.
Kennt jemand dieses Verhalten?
Grüsse
Marc
Ausgangslage:
Virtualisierter Windows Server 2012 R2 (auf vmware ESXi 5.5) am Hauptsitz
Sehr stabiler IPSec Tunnel zwischen beiden Standorten (Fortigate 100D am Hauptsitz, FortiWiFi 30D bei Aussenstelle)
Subnetz Hauptsitz 192.168.20.0/24
Subnetz Aussenstelle 192.168.11.0/24
Der betroffene Server kann nach einem Neustart ohne Weiteres auf Geräte der Aussenstelle zugreifen und diese natürlich auch anpingen.
Erst nach einer Gewissen Laufzeit (i.d.R. 1-2 Wochen) funktioniert die Verbindung plötzlich nicht mehr. Im LAN der Hauptsitzes kann der betroffene Server nach wie vor auf alle Geräte zugreifen.
Sämtliche Server und Clients am Hauptsitz haben zu diesem Zeitpunkt immer noch eine stabile Verbindung zu den Geräte der Aussenstelle.
Bereits geprüft habe ich:
- Windows Firewall aus/ein am betroffenen Server (hat keinen Einfluss)
- Ping von Server Hauptsitz zu Server Aussenstelle nicht möglich
- Ping von Server Aussenstelle zu Server Hauptsitz fehlerfrei
- Netzwerk-Adapter in vmware (VMXNET3) entfernt und neu hinzu gefügt
- DNS geprüft, alles i.O.
Der Server am Hauptsitz loggt:
DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "192.168.11.200" kommunizieren; angefordert von PID 9e0 (C:\Program Files (x86)\PRTG Network Monitor\PRTG Probe.exe).
Dem oben genannten Ereignis geht kein anderes auswertbares Ereignis voraus, aufgrund dessen eine Analyse stattfinden könnte.
Natürlich habe ich auch schon im Internet gesucht, aber auch dort keine spezifische Antwort gefunden.
Kennt jemand dieses Verhalten?
Grüsse
Marc
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: 353827
Url: https://administrator.de/forum/windows-server-verliert-verbindung-zu-subnetz-der-aussenstelle-353827.html
Ausgedruckt am: 25.12.2024 um 17:12 Uhr
3 Kommentare
Neuester Kommentar
Hi
"geht nicht" heisst was? Der Ping per DNS löst nicht zur IP auf?
Wenn DNS nicht funktioniert: hat der Server eine Verbindung zum DNS Server? Was sagt das Log des DNS Servers?
Er löst auf, aber der Ping bekommt einen Timeout?
Wenn der DNS zwar funktioniert aber der Ping einen Timeout hat: Wie weit kommt der Ping denn, wenn du dir das Traceroute mal anschaust ?
"geht nicht" heisst was? Der Ping per DNS löst nicht zur IP auf?
Wenn DNS nicht funktioniert: hat der Server eine Verbindung zum DNS Server? Was sagt das Log des DNS Servers?
Er löst auf, aber der Ping bekommt einen Timeout?
Wenn der DNS zwar funktioniert aber der Ping einen Timeout hat: Wie weit kommt der Ping denn, wenn du dir das Traceroute mal anschaust ?
Hallo SeaStorm
DNS funktioniert. Die Auflösung des Servernamens beim Ping stimmt. Ping läuft.
Eben habe ich festgestellt, dass ich den Windows-Server der Aussenstelle anpingen und darauf zugreifen kann, andere Geräte (Firewall, NAS, usw.) aber nicht. Die Fehlersuche am Windows-Server kann ich abschliessen. Vermutlich ist am Tunnel etwas nicht koscher.
Ich habe vor ca. 2 Monaten beide Firewalls (Hauptsitz und Aussenstelle) updated.
Wenn ich die Fehler-Logs checke, fallen diese Updates zeitlich mit dem Auftreten dieses Fehler zusammen.
Danke trotzdem für Deine Bemühungen. Ich schliesse den Fall.
Grüsse
Marc
DNS funktioniert. Die Auflösung des Servernamens beim Ping stimmt. Ping läuft.
Eben habe ich festgestellt, dass ich den Windows-Server der Aussenstelle anpingen und darauf zugreifen kann, andere Geräte (Firewall, NAS, usw.) aber nicht. Die Fehlersuche am Windows-Server kann ich abschliessen. Vermutlich ist am Tunnel etwas nicht koscher.
Ich habe vor ca. 2 Monaten beide Firewalls (Hauptsitz und Aussenstelle) updated.
Wenn ich die Fehler-Logs checke, fallen diese Updates zeitlich mit dem Auftreten dieses Fehler zusammen.
Danke trotzdem für Deine Bemühungen. Ich schliesse den Fall.
Grüsse
Marc
Hallo alle
Ich makiere den Fall als gelöst.
Die Lösung war sichtlich einfach: Tatsächlich hat PRTG den Zugriff auf das "fremde" Subnetz verhindert. Das ist mir ein Rätsel. Aber was soll's. Wenn's nur wieder läuft. Nach einem Neustart der PRTG-Dienste funktioniert's wieder.
Künftig werden die PRTG.Dienste 1x wöchentlich automatisch neu gestartet.
Grüsse
Marc
Ich makiere den Fall als gelöst.
Die Lösung war sichtlich einfach: Tatsächlich hat PRTG den Zugriff auf das "fremde" Subnetz verhindert. Das ist mir ein Rätsel. Aber was soll's. Wenn's nur wieder läuft. Nach einem Neustart der PRTG-Dienste funktioniert's wieder.
Künftig werden die PRTG.Dienste 1x wöchentlich automatisch neu gestartet.
Grüsse
Marc
