Technische Analyse: Netzwerkprobleme und Lösungen
Inhaltsverzeichnis
- Ausgangslage und Symptome
- Aufbau der Monitoring-Infrastruktur
- Problem 1: DNS-Selbstverweis auf XGS-30
- Problem 2: Latenz durch Firewall-Inspection
- Problem 3: Microsoft-seitige Processing-Spikes
- Umgesetzte Lösungen
- Verifizierung und Ergebnisse
- Offene Punkte
1. Ausgangslage und Symptome
Beschriebenes Problem
Benutzer an beiden Standorten (40er-Netz und 30er-Netz) meldeten langsame Antwortzeiten bei der Nutzung von Microsoft 365 Cloud-Diensten, insbesondere: - Microsoft Business Central (businesscentral.dynamics.com) - Microsoft 365 Login (login.microsoftonline.com) - Outlook / Exchange Online (outlook.office365.com)
Erste Beobachtungen
- Probleme traten unregelmäßig auf
- Kein offensichtlicher Zusammenhang mit Tageszeit oder Benutzeranzahl
- Betroffen waren Webanwendungen im Browser, nicht VPN oder interne Dienste
2. Aufbau der Monitoring-Infrastruktur
Zur systematischen Analyse wurde ein umfassendes Monitoring aufgebaut:
Messpunkte
- Hauptstandort (10.128.40.x): Blackbox Exporter auf Windows Server "Salto", misst vom gleichen Netzwerk wie die Benutzer
- Referenznetz (192.168.178.x): Blackbox Exporter auf Raspberry Pi, misst vom Heimnetz über einen anderen Internetanschluss (Fritz!Box)
Messmethoden
- ICMP Ping: Netzwerklatenz und Paketverlust zu Internetzielen und Microsoft-Servern
- HTTP Probes: Komplette HTTP-Transaktionen zu Microsoft-Endpunkten mit Phasen-Zerlegung (DNS, TCP, TLS, Processing, Transfer)
- DNS Probes: Dedizierte DNS-Auflösungstests für Microsoft-Domains über alle verfügbaren Resolver
- SNMP: Firewall-Performance-Daten (CPU, RAM, Interface-Statistiken)
Messergebnisse vor der Behebung
| Messwert | XGS-40 (40er-Netz) | XGS-30 (30er-Netz) | Referenz |
|---|---|---|---|
| DNS login.microsoftonline.com | ~12ms | ~3000ms | ~15ms |
| DNS businesscentral.dynamics.com | ~20ms | ~3000ms | ~20ms |
| DNS outlook.office365.com | ~25ms | ~3000ms | ~12ms |
| HTTP Gesamtzeit (BC) | 800-3000ms | 4000-8000ms | 600-2000ms |
| ICMP 8.8.8.8 | ~15ms | ~15ms | ~12ms |
3. Problem 1: DNS-Selbstverweis auf XGS-30
Symptom
Alle DNS-Auflösungen über die XGS-30 (10.128.30.1) dauerten exakt ~3 Sekunden oder ein Vielfaches davon.
Analysemethodik
Schritt 1: DNS-Vergleichstest
PowerShell-Skript auf dem Salto-Server, das denselben DNS-Lookup über verschiedene Resolver durchführt:
Resolve-DnsName -Name "login.microsoftonline.com" -Server 10.128.30.1 -Type A
Resolve-DnsName -Name "login.microsoftonline.com" -Server 10.128.40.1 -Type A
Ergebnis: XGS-30 konsistent ~3000ms, XGS-40 konsistent ~12ms
Schritt 2: Domainkategorien testen
Tests mit verschiedenen Domain-Kategorien (Microsoft Auth, Apps, CDN, Google, allgemein): - Alle Domains waren auf XGS-30 langsam → kein domainspezifisches Problem - XGS-40 war bei allen Domains normal
Schritt 3: TCP vs. UDP DNS
# UDP (Standard)
Resolve-DnsName -Name "test123.google.com" -Server 10.128.30.1 -Type A
# → 3067ms
# TCP
Resolve-DnsName -Name "test123.google.com" -Server 10.128.30.1 -Type A -TcpOnly
# → 61ms
Schlüsselerkenntnis: TCP DNS funktionierte (61ms), UDP DNS war broken (3067ms). Die 3 Sekunden entsprechen dem Standard-UDP-DNS-Retry-Timeout.
Schritt 4: Cache-Bypass mit zufälligen Subdomains
$random = "test-$(Get-Random -Max 999999).google.com"
Resolve-DnsName -Name $random -Server 10.128.30.1 -Type A
Auch zufällige (nicht-gecachte) Domains zeigten das gleiche Verhalten → kein Cache-Problem
Schritt 5: DNS-Konfiguration prüfen (via XGS API)
<Request>
<Login>...</Login>
<Get><DNS></DNS></Get>
</Request>
Ergebnis (Root Cause):
DNS1: 10.128.30.1 ← DIE FIREWALL SELBST!
DNS2: 8.8.8.8
DNS3: 8.8.7.7
Root Cause
Die XGS-30 hatte sich selbst (10.128.30.1) als primären DNS-Upstream-Server konfiguriert. Dies erzeugte eine rekursive Schleife:
Client → XGS-30 DNS-Proxy → XGS-30 als Upstream → Timeout (3s) → Fallback auf 8.8.8.8
- Client fragt XGS-30 DNS-Proxy (10.128.30.1:53)
- DNS-Proxy leitet an konfigurierten DNS1 weiter: 10.128.30.1 (sich selbst)
- Dies erzeugt eine Schleife, die nach ~3s mit UDP-Timeout abgebrochen wird
- Erst dann wird DNS2 (8.8.8.8) versucht, der antwortet
- Gesamtzeit: ~3s Timeout + ~15ms Google DNS = ~3015ms
TCP DNS funktionierte, weil TCP-Verbindungen zur Loopback-Adresse anders gehandhabt werden als UDP-Pakete.
Auswirkung
- Jede DNS-Auflösung im 30er-Netz dauerte mindestens 3 Sekunden zusätzlich
- Jede HTTP-Verbindung zu einem neuen Host wurde um 3s verzögert
- Bei ungecachten DNS-Einträgen (TTL abgelaufen) trat das Problem erneut auf
- Betroffen: Alle Geräte im 30er-Netz, die die XGS-30 als DNS nutzen
4. Problem 2: Latenz durch Firewall-Inspection
Symptom
Auch im 40er-Netz (XGS-40) wurden zeitweise langsame Antwortzeiten bei Microsoft-Diensten beobachtet, obwohl DNS dort korrekt funktionierte.
Analyse
Vergleich der Firewall-Regeln beider XGS-Firewalls via API:
<Get><FirewallRule></FirewallRule></Get>
Regel "CKOffice LAN / WLAN nach extern" (beide XGS):
| Feature | Status | Auswirkung |
|---|---|---|
| WebFilter | Aktiv | URL-Kategorisierung, SSL-Inspection |
| IPS (Intrusion Prevention) | Aktiv | Deep Packet Inspection |
| ScanVirus | Aktiv | Antivirus-Scanning aller Downloads |
| ZeroDayProtection (Sandstorm) | Aktiv | Dateien werden zur Sandbox-Analyse an sandbox.sophos.com gesendet |
| DecryptHTTPS | Aktiv | TLS-Interception für alle HTTPS-Verbindungen |
Root Cause
Alle HTTPS-Verbindungen zu Microsoft-Cloud-Diensten durchliefen: 1. TLS-Interception: Die Firewall bricht die TLS-Verbindung auf, entschlüsselt den Traffic, scannt ihn, und baut eine neue TLS-Verbindung zum Client auf (Man-in-the-Middle) 2. Web Filter: Jede URL wird kategorisiert und gegen Richtlinien geprüft 3. IPS: Deep Packet Inspection auf bekannte Angriffsmuster 4. Antivirus: Heruntergeladene Inhalte werden gescannt 5. Sandstorm: Unbekannte Dateien werden an die Sophos-Sandbox gesendet und dort analysiert — dies kann mehrere Sekunden dauern
Besonders ZeroDayProtection (Sandstorm) verursacht Verzögerungen, weil Dateien vor der Zustellung an den Client erst an sandbox.sophos.com gesendet und dort analysiert werden müssen.
Ergänzende Erkenntnis: Office365Enabled
Bei Prüfung der WebFilter-Konfiguration wurde festgestellt:
Office365Enabled = 0
Auf allen WebFilter-Policies. Dies bedeutet, dass die Sophos-eigene M365-Optimierung (die Microsoft-Traffic von der Interception ausnimmt) nicht aktiviert war.
5. Problem 3: Microsoft-seitige Processing-Spikes
Symptom
Selbst nach DNS-Fix und FastPath-Optimierung zeigten die HTTP-Probes gelegentlich hohe Antwortzeiten von > 5 Sekunden für Business Central.
Analyse
Die HTTP-Phasen-Analyse zeigte: - DNS: 0ms (gefixt) - TCP Connect: ~20ms (normal) - TLS: ~40ms (normal) - Processing: bis zu 14.500ms (14,5 Sekunden!) - Transfer: < 10ms (normal)
Entscheidender Test: Dieselben Processing-Spikes traten auch vom Referenznetz auf — also über einen komplett anderen Internetanschluss und ohne XGS-Firewall.
Root Cause
Business Central (businesscentral.dynamics.com) hat serverseitige Verarbeitungsspitzen, die von Microsoft verursacht werden. Diese können bis zu 14,5 Sekunden dauern und betreffen alle Benutzer weltweit. Mögliche Microsoft-seitige Ursachen: - Server Scaling / Cold Start bei Tenant-Zugriff - Datenbankabfragen auf Azure-Backend - Microsoft-interne Wartung oder Lastspitzen
Bewertung
Dies ist kein lokales Netzwerkproblem und kann nicht durch lokale Maßnahmen behoben werden. Es handelt sich um das erwartete Verhalten einer Multi-Tenant-Cloud-Anwendung.
6. Umgesetzte Lösungen
Lösung 1: DNS-Konfiguration XGS-30 korrigiert
Methode: Sophos XGS REST API (Port 4444)
<Request>
<Login><Username>admin</Username><Password>***</Password></Login>
<Set operation="update">
<DNS>
<IPv4Settings>
<ObtainDNSFrom>Static</ObtainDNSFrom>
<DNSIPList>
<DNS1>8.8.8.8</DNS1>
<DNS2>8.8.4.4</DNS2>
<DNS3></DNS3>
</DNSIPList>
</IPv4Settings>
</DNS>
</Set>
</Request>
Vorher: DNS1=10.128.30.1 (selbst), DNS2=8.8.8.8, DNS3=8.8.7.7 Nachher: DNS1=8.8.8.8, DNS2=8.8.4.4
Sofortige Verbesserung: DNS-Auflösung von ~3000ms auf ~0ms (gecacht) / ~20ms (ungecacht)
Lösung 2: Microsoft 365 FastPath-Regel
Auf beiden Firewalls (XGS-40 und XGS-30) wurde eine FastPath-Regel erstellt, die Microsoft-365-Traffic von der Deep Packet Inspection ausnimmt.
Schritt 1: FQDN Host Group erstellt (via API)
<Set operation="add">
<FQDNHostGroup>
<Name>Microsoft 365 FastPath</Name>
<Description>Microsoft 365 Domains für FastPath Acceleration</Description>
</FQDNHostGroup>
</Set>
Schritt 2: 12 FQDN Hosts erstellt (via API)
| Name | FQDN |
|---|---|
| ms365-dynamics | *.dynamics.com |
| ms365-office365 | *.office365.com |
| ms365-microsoftonline | *.microsoftonline.com |
| ms365-office | *.office.com |
| ms365-msauth | *.msauth.net |
| ms365-msftauth | *.msftauth.net |
| ms365-windows-net | *.windows.net |
| ms365-microsoftonline-p | *.microsoftonline-p.com |
| ms365-office-net | *.office.net |
| ms365-outlook | *.outlook.com |
| ms365-msocdn | *.msocdn.com |
| ms365-azure | *.azure.com |
Schritt 3: Firewall-Regel manuell erstellt (WebAdmin)
Die XGS API unterstützt keine Erstellung von Firewall-Regeln (API Code 500). Die Regel wurde manuell über das WebAdmin-Interface erstellt.
Regel "MS Claude" (Position 1 auf beiden XGS):
| Einstellung | Wert |
|---|---|
| Position | 1 (oberste Regel) |
| Source Zones | LAN, WiFi |
| Source Networks | Any |
| Destination Zones | WAN |
| Destination Networks | Microsoft 365 FastPath (FQDN-Gruppe) |
| Services | HTTP, HTTPS |
| Action | Accept |
| Web Filter | None |
| IPS | None |
| Scan Virus | Disable |
| Zero Day Protection | Disable |
| Decrypt HTTPS | Disable |
| Application Control | None |
| Log Traffic | Enable |
Wirkung: Traffic zu Microsoft-365-Domains durchläuft den Xstream FastPath der Sophos XGS. Dieser umgeht die DPI-Engine vollständig: - Kein TLS-Aufbrechen - Kein Antivirus-Scan - Keine Sandstorm-Analyse - Kein IPS - Ergebnis: Minimale Latenz, Hardware-beschleunigte Weiterleitung
Lösung 3: XGS-30 Neustart
Nach dem DNS-Fix wurde die XGS-30 neu gestartet, um DNS-Caches und bestehende Verbindungen zurückzusetzen.
7. Verifizierung und Ergebnisse
DNS-Verbesserung (sofort messbar)
| Domain | Vorher (XGS-30) | Nachher (XGS-30) | Verbesserung |
|---|---|---|---|
| login.microsoftonline.com | 3067ms | 21.6ms | 99.3% |
| businesscentral.dynamics.com | 3015ms | 123.8ms* | 95.9% |
| outlook.office365.com | 3042ms | 48.0ms | 98.4% |
| graph.microsoft.com | 3089ms | 26.5ms | 99.1% |
*BC initial höher wegen erstem Resolve nach Reboot, normalisiert sich auf ~20ms.
Prometheus Alerts
- Vorher: 9 Alerts firing (alle XGS-30 DNS-bezogen)
- Nachher: Alle XGS-30 DNS-Alerts cleared
Erwartete Langzeitverbesserung (FastPath)
- HTTP-Gesamtantwortzeit zu Microsoft-Diensten: Reduktion um geschätzt 100-500ms pro Anfrage
- Elimination der Sandstorm-Verzögerungen für M365-Traffic
- Geringere CPU-Last auf beiden Firewalls durch weniger DPI-Verarbeitung
8. Offene Punkte
- Langzeitmonitoring: Die FastPath-Wirkung über mehrere Tage beobachten
- BC Processing-Spikes: Microsoft-seitig, keine lokale Lösung. Dokumentation für Benutzer erstellen.
- 8.8.8.8 Remote DNS-Probe: Feuert dauerhaft als Alert (DNS-Probe zu Google DNS über Salto schlägt fehl, vermutlich Firewall-Regel). Kann bereinigt oder als known-issue dokumentiert werden.
- Office365Enabled auf WebFilter: Könnte zusätzlich aktiviert werden für verbleibenden M365-Traffic, der nicht durch die FastPath-Regel abgedeckt wird.
- DNS auf XGS-40: Aktuell DNS1=8.8.8.8, DNS2=8.8.4.4 — korrekt konfiguriert, kein Selbstverweis.
Erstellt: 17.02.2026 Analyse durchgeführt mit: Prometheus, Blackbox Exporter, Sophos XGS REST API, PowerShell