Netzwerkanalyse und Optimierung - Bericht für IT-Management
Datum: 17. Februar 2026 Betreff: Analyse und Behebung von Performance-Problemen bei Microsoft 365 Cloud-Diensten
Zusammenfassung
Es wurden zwei wesentliche Ursachen für langsame Antwortzeiten bei Microsoft 365 Diensten (Business Central, Outlook, Teams) identifiziert und behoben:
-
DNS-Fehlkonfiguration auf Firewall XGS-30 (30er-Netz): Die Firewall hatte sich selbst als DNS-Server eingetragen, was zu 3 Sekunden Verzögerung bei jeder Namensauflösung führte. Behoben durch Korrektur der DNS-Upstream-Server.
-
Unnötige Security-Inspection für Microsoft-Traffic: Alle Verbindungen zu Microsoft 365 durchliefen vollständige Sicherheitsprüfungen (Virenscanner, Intrusion Prevention, Sandboxing). Für vertrauenswürdigen Microsoft-Traffic wurde eine Bypass-Regel (FastPath) eingerichtet.
Zusätzlich wurde ein dauerhaftes Monitoring-System aufgebaut, das Netzwerk- und Cloud-Performance kontinuierlich überwacht und bei Problemen automatisch alarmiert.
1. Identifizierte Probleme
Problem A: DNS-Selbstverweis (30er-Netz) — BEHOBEN
| Kategorie | Detail |
|---|---|
| Betroffener Standort | 30er-Netz (XGS-30, 10.128.30.1) |
| Symptom | Jede DNS-Auflösung dauerte ~3 Sekunden statt <50ms |
| Auswirkung | Alle Webzugriffe im 30er-Netz waren um 3+ Sekunden verzögert |
| Ursache | Die Firewall XGS-30 hatte ihre eigene IP als primären DNS-Server konfiguriert, was eine Schleife erzeugte |
| Behebung | DNS-Upstream geändert auf Google DNS (8.8.8.8 / 8.8.4.4) via Sophos API |
| Verbesserung | DNS-Auflösung von ~3000ms auf ~20ms (Faktor 150x schneller) |
Problem B: Firewall Deep Packet Inspection für M365 — BEHOBEN
| Kategorie | Detail |
|---|---|
| Betroffene Standorte | Beide (40er-Netz und 30er-Netz) |
| Symptom | Gelegentlich langsame Antwortzeiten bei M365-Diensten |
| Auswirkung | HTTP-Antwortzeiten 100-500ms höher als nötig |
| Ursache | Webfilter, Virenscanner, IPS und Sandstorm-Sandboxing waren aktiv für M365-Traffic |
| Behebung | FastPath-Firewall-Regel erstellt, die M365-Traffic von Security-Scanning ausnimmt |
| Verbesserung | Geschätzt 100-500ms Reduktion pro Anfrage, geringere CPU-Last |
Problem C: Microsoft-seitige Verarbeitungszeiten — NICHT LOKAL LÖSBAR
| Kategorie | Detail |
|---|---|
| Betroffene Standorte | Alle (auch Referenznetz ohne Firewall) |
| Symptom | Sporadische Antwortzeiten von 5-14 Sekunden bei Business Central |
| Ursache | Serverseitige Verarbeitungszeit bei Microsoft (Azure-Backend) |
| Maßnahme | Keine lokale Lösung möglich. Dokumentiert und im Monitoring erfasst. |
2. Aufgebaute Monitoring-Infrastruktur
Architektur
Ein dauerhaftes Monitoring-System wurde auf Basis von Open-Source-Technologien aufgebaut:
| Komponente | Funktion | Standort |
|---|---|---|
| Prometheus | Zentrale Metrik-Datenbank | Raspberry Pi (Referenznetz) |
| Grafana | Dashboard-Visualisierung | Raspberry Pi, erreichbar via Browser |
| Blackbox Exporter (Pi) | Messung vom Referenznetz | Raspberry Pi |
| Blackbox Exporter (Salto) | Messung vom Hauptstandort | Windows Server Salto |
| SNMP Exporter | Firewall-Performance-Daten | Windows Server Salto |
| Sophos Central API | Cloud-Management-Daten | Raspberry Pi |
Was wird gemessen?
| Messung | Frequenz | Zweck |
|---|---|---|
| HTTP-Antwortzeiten zu 5 Microsoft-Endpunkten | Alle 15s | Cloud-Performance |
| Ping zu Internet-Zielen und MS Cloud | Alle 15s | Netzwerklatenz |
| DNS-Auflösung für 4 Microsoft-Domains | Alle 30s | DNS-Performance pro Resolver |
| Firewall CPU, RAM, Disk | Alle 30s | Firewall-Auslastung |
| Interface-Traffic und Fehler | Alle 30s | Bandbreite und Hardwareprobleme |
| 13 WLAN Access Points (Ping) | Alle 15s | AP-Erreichbarkeit |
Automatische Alarmierung
| Alert | Schwelle | Severity |
|---|---|---|
| DNS-Auflösung > 500ms | 1 Minute anhaltend | Warning |
| DNS-Auflösung > 3s | 30 Sekunden | Critical |
| DNS nicht auflösbar | 1 Minute | Critical |
| HTTP-Antwort > 3s | 1 Minute | Critical |
| DNS-Lookup > 1s | 1 Minute | Warning |
| Paketverlust > 2% | 2 Minuten | Warning |
| Ziel nicht erreichbar (ICMP) | 2 Minuten | Critical |
3. Grafana Dashboards
Dashboard 1: Netzwerk- und Cloud-Latenzmonitoring CK (Hauptdashboard)
5 Sektionen mit insgesamt 30 Panels:
| Sektion | Panels | Zweck |
|---|---|---|
| Standortvergleich | 4 | ICMP-Latenz, Paketverlust, HTTP-Antwortzeiten — Hauptstandort vs. Referenz |
| HTTP Detailanalyse | 7 | Aufschlüsselung der HTTP-Antwortzeit in DNS, TCP, TLS, Server-Verarbeitung, Transfer |
| Firewall-Performance | 7 | CPU/RAM/Disk, Interface-Traffic, Errors, HTTP Hits |
| Jitter-Analyse | 4 | Schwankungen in Latenz und Antwortzeiten |
| DNS-Analyse | 6 | MS-spezifische DNS-Auflösung pro Resolver, Erfolgsrate, Spikes |
| Alerts | 1 | Aktive Alarme |
Standort-Filter: Das Dashboard unterstützt einen Standort-Filter (Hauptstandort / Referenz / Alle), um gezielt einen Standort zu analysieren oder beide zu vergleichen.
Dashboard 2: Sophos XGS Firewall
- Detailansicht einer einzelnen Firewall: Ressourcen, Dienste, Interfaces, Lizenzen
Dashboard 3: Sophos XGS - Vergleich
- Beide Firewalls nebeneinander: WAN-Durchsatz, VPN-Traffic, Ressourcen im direkten Vergleich
Dashboard 4: Sophos WLAN Access Points
- AP-Erreichbarkeit, Latenz, Verfügbarkeit-Timeline, Sophos Central Alerts
4. Firewall-Konfigurationsänderungen
Auf beiden Firewalls (XGS-40 und XGS-30):
Neue FQDN Host Group "Microsoft 365 FastPath"
12 Wildcard-Domains, die den gesamten Microsoft-365-Traffic abdecken: - .dynamics.com, .office365.com, .microsoftonline.com, .office.com - .msauth.net, .msftauth.net, .windows.net, .microsoftonline-p.com - .office.net, .outlook.com, .msocdn.com, .azure.com
Neue Firewall-Regel "MS Claude" (Position 1)
- Quell-Zonen: LAN, WiFi
- Ziel: Microsoft 365 FastPath (FQDN-Gruppe)
- Dienste: HTTP, HTTPS
- Aktion: Accept (ohne Inspection)
- Deaktiviert: WebFilter, IPS, Antivirus, Sandstorm, HTTPS-Decrypt
Sicherheitshinweis: Microsoft-365-Traffic ist bereits durch Microsoft-eigene Sicherheitsmaßnahmen geschützt (Defender, Safe Links, Safe Attachments). Die lokale Firewall-Inspection für diesen Traffic ist redundant und verursacht unnötige Latenz. Diese Konfiguration entspricht der offiziellen Microsoft-Empfehlung für Netzwerkoptimierung.
Nur auf XGS-30:
DNS-Konfiguration korrigiert
- Vorher: DNS1=10.128.30.1 (Selbstverweis!), DNS2=8.8.8.8, DNS3=8.8.7.7
- Nachher: DNS1=8.8.8.8, DNS2=8.8.4.4
5. Ergebnisse und Metriken
DNS-Verbesserung (30er-Netz)
| Metrik | Vorher | Nachher | Verbesserung |
|---|---|---|---|
| DNS login.microsoftonline.com | 3067ms | 22ms | 99.3% |
| DNS businesscentral.dynamics.com | 3015ms | 20ms | 99.3% |
| DNS outlook.office365.com | 3042ms | 48ms | 98.4% |
| DNS graph.microsoft.com | 3089ms | 27ms | 99.1% |
| Active DNS Alerts | 9 | 0 | Alle behoben |
Erwartete Gesamtverbesserung
- 30er-Netz: 3-4 Sekunden schnellere Ladezeiten bei allen Webzugriffen
- Beide Netze: 100-500ms Verbesserung durch FastPath-Bypass
- Geringere CPU-Last auf Firewalls durch weniger DPI-Verarbeitung
- Dauerhaftes Monitoring verhindert unbemerkte Rückfälle
6. Empfehlungen
- Monitoring-Dashboards regelmäßig prüfen — mindestens wöchentlicher Blick auf die Alert-Übersicht
- Alerts ernst nehmen — neue Alerts sollten zeitnah untersucht werden
- DNS-Konfiguration bei Änderungen prüfen — bei Firewall-Updates sicherstellen, dass kein Selbstverweis entsteht
- Processing-Spikes dokumentieren — wenn Benutzer über Business Central Langsamkeit klagen, im Dashboard prüfen, ob die Processing-Phase betroffen ist (= Microsoft-seitig, kein lokales Problem)
- FastPath-Regel pflegen — bei neuen Microsoft-Domains die FQDN-Gruppe erweitern
Erstellt: 17.02.2026