Verbindungsprobleme mit Exchange Online geloest

[Daniel Baumann]

Hallo zusammen

In den letzten Tagen gab es zunehmend Verbindungsprobleme aus dem BFH
Netzwerk zu den Exchange Mailservern in der Microsoft Cloud. Dies hat
sich von einzelnen Verbindungsproblemen bis hin zur vollstaendigen
Unbenutzbarkeit der E-Mail Dienste entwickelt.

Ursache war dass die Universitaet Bern, ueber welche wir ans schweizer
Hochschulnetz (SWITCH) und ans Internet angebunden sind, die Microsoft
Mailserver auf unserer Netzwerk-Anbindung gesperrt hat.

Seit gestern Dienstag, 11:45 Uhr ist diese Sperre wieder entfernt und
E-Mail ist uneingeschraenkt verfuegbar.

Im Folgenden die Hintergrund-Informationen und weiteren Massnahmen.


1. DNS Round Robin
==================

Wenn ein Mailclient (egal ob Thunderbird, Outlook oder was anderes;
betrifft alle die auf Exchange Online migriert worden sind) sich mit den
Microsoft Mailservern verbindet, so tut er das mit outlook.office356.com
und/oder outlook.office.com.

Diese DNS Eintraege sind sogenannte Round-Robin, d.h. es gibt mehre IP
Adressen die fuer diesen Eintrag zwecks Load Balancing zu Performance
und Redundanz hinterlegt sind:

---schnip---
$ kdig outlook.office365.com
outlook.ha.office365.com.	10	IN	A	52.97.201.194
outlook.ha.office365.com.	10	IN	A	52.97.201.242
outlook.ha.office365.com.	10	IN	A	52.97.186.146
outlook.ha.office365.com.	10	IN	A	52.97.201.210
outlook.ha.office365.com.	10	IN	A	52.98.168.178
outlook.ha.office365.com.	10	IN	A	52.98.163.18
outlook.ha.office365.com.	10	IN	A	52.97.232.194
outlook.ha.office365.com.	10	IN	A	52.97.201.226
---schnap---

Ein Client kann sich dann frei auswaehlen, welche der Adressen er
verwenden moechte, in der Regel wird einfach die erste Antwort genommen
(die in aller Regel von den antwortenden DNS Servern immer rotiert wird,
damit nicht immer die gleiche Adresse zuoberst steht).


2. Internet Anbindung via Universitaet Bern
===========================================

Die BFH verfuegt ueber keinen direkten Anschluss ans Internet, sondern
ueber eine redundante Anbindung (2x 10gbit) ans schweizer Hochschulnetz
(SWITCH) und damit ans Internet via die Universitaet Bern.

D.h. in unserem Rechenzentrum in Bern gehen zwei Glasfaserkabel zur
unibe, und von da weiter nach Zuerich. Der gesamte Traffic passiert
dabei den unibe Border-Router. Das ist fuer uns oekonomischer weil
dadurch die Anschlussgebuehren fuer SWITCH signifikant tiefer sind.

Als zusaetzlicher Service verhindert die Universitaet Bern so indirekt
einen Teil der Attacken (DoS, DDoS) aus dem Internet gegen unsere
Systeme weil wir denselben Uplink benutzen. Solche legitimen Sperrungen
von Adressen oder Adressbereichen sind nur jeweils kurzfristig fuer ein
paar Stunden notwendig und kommen insgesamt sehr selten vor (ein, zwei
mal pro Jahr). Das macht die unibe seit vielen Jahren unaufgefordert so
und dafuer sind wir sehr dankbar, das hat in den letzten 10 Jahren ein
paar mal groesseren Schaden/Ausfaelle auf unserer Seite verhindert.


3. Aktuelle Sperrung der Microsoft Server
=========================================

Die Netzwerkverantwortlichen der unibe haben in den letzten Tagen ein
erhoehtes Traffic-Aufkommen zu den Microsoft Mailservern bemerkt.

Das ist einerseits erklaerbar durch die weitere Migration unserer User
auf Exchange Online, andererseits durch Ende der Ferienzeit und
vermehrter Vorort-Praesenz der Mitarbeitenden.

Leider hat unibe selbststaendig entschieden, immer mehr Mailserver von
Microsoft zu blockieren. Schlussendlich waren gestern so 8 von den 10
verfuegbaren Mailservern geblockt.

Der Effekt war dass ein Client fuer jede Verbindung jeweils sich
"durchprobieren" musste, bis er einen der 2 noch funktionierenden Server
erwischt hat. Das aeusserte sich in extrem langsamem Zugriff oder keinem
Zugriff auf Mails, und ebenso eingeschraenkten Mailversand.

Allerdings war das Verhalten jederzeit diskret, d.h. wenn eine Mail
versendet werden konnte, wurde sie auch versendet. Ansonsten gab es auf
dem Client eine entsprechende Fehlermeldung dass der Mailserver nicht
erreicht werden kann und man konnte es nochmal probieren.

Verstaerkt wird der Effekt dadurch dass die DNS Records eine
Time-to-Life (TTL) von nur 5 Sekunden haben, d.h. ein Client fragt bei
praktisch jeder Verbindung nochmal neu nach Adressen an. Somit konnte
ein Client nicht davon profitieren, einmal einen funktionierenden
Mailserver erwischt zu haben, sondern das "2 aus 10"-Durchprobieren
faengt (spaetestens) alle 5 Sekunden wieder von vorne an.

Die Sperrung dieser Server wurde durch die unibe manuell (also nicht
aufgrund oder Teil eines automatischen Systems) und ohne Kommunikation
zur BFH vorgenommen. Wir haben darauf ensprechend reagiert, siehe unten.


4. Debugging (Drop vs. Reject, resp. Inbound vs. Outbound)
==========================================================

Grundsaetzlich kann man Traffic auf zwei Arten sperren - man kann
entweder still die Netzwerkpakete verwerfen (drop) oder aktiv
zurueckweisen (reject).

In konventionellen Netzen wird haeufig noch gedropt, was dazufuehrt dass
Netzwerk-Clients in (lange) Timeouts laufen. Dafuer werden die
Netzwerkgeraete minimal weniger belastet weil ein Verwerfen weniger
Prozessierungs-Aufwand generiert als ein aktives Zurueckweisen.

In der heutigen Zeit ist ein drop, ausser in Nischenfaellen von sehr
grossen Distributed-Denial-of-Service (DDoS) Attacken, nicht mehr
empfehlenswert und auch nicht mehr noetig. Aktuelle Systeme koennen
Rejects problemlos abarbeiten. Ein aktives Reject ist daher immer zu
bevorzugen, weil dadurch unmittelbar die Netzwerkteilnehmer die
Verbindung abbrechen und Fehler sich sofort bemerkbar machen. Dies
insbesondere dann wenn mehrere Systeme hintereinander arbeiten, so dass
sich keine langen Timeout-Ketten bilden koennen.

Wuerden alle "reject statt drop" machen, waere das Internet (oder das
jeweilige Teilnetz) fuer alle besser/schneller. Im neuen BFH Netzwerk
machen wir grundsaetzlich ueberall reject, im alten Netzwerk haben wirs
seit der Uebernahme im Mai 2020 ueberall dort wo sinnvoll moeglich und
an den neuralgischen Punkten ebenfalls auf reject umgestellt.

Analog zu "reject statt drop" wird konventionell leider haeufig auch nur
eingehender Traffic (inbound) gesperrt, statt beide Richtungen zu
sperren. Weil dadurch ausgehender Traffic (outbound) zu den gesperrten
Adressen immer noch moeglich ist, verhaelt es sich fuer alle
Netzwerkteilnehmer wie bei einem Drop: sie laufen in ein Timeout rein
weil sie auf die (nicht eintreffende) Antwort warten muessen.

Wuerden Sperrungen auf Router-Ebene auf inbound und outbound Traffic
gemacht (auch hier sind heutigen Systeme mehr als nur performant genug,
Traffic in beide Richtungen sperren zu koennen), waere der Effekt der
Sperrung der Mailserver gewesen, dass gar kein Mail mehr funktioniert
haette.

Das waere zum Debuggen wesentlich einfacher gewesen. Zusammen mit der
Erwartungshaltung dass wir komplett ungefiltertes Internet von der unibe
erhalten, haben wir zuerst doppelt-und-dreifach unsere eigenen Systeme
ausgeschlossen (Firewall, Border, etc.), ein "Rueckwaertskanal"-Problem
im Peering zwischen Microsoft und SWITCH vermutet (das ist auch das was
man per traceroute sieht: traffic hin zu MS funktioniert, aber zwischen
MS und SWITCH kommt nichts mehr zurueck weil MS via SWITCH nicht
zustellen kann weil unibe nicht annimmt).

Dashalb haben wir erst als Letztes mit der unibe im Verlauf des Dienstag
Vormittags Kontakt aufgenommen. Diese haben dann schlussendlich schnell
reagiert und die Sperrung ensprechend wieder entfernt.


5. Massnahmen
=============

  * Wir haben der unibe unsere Erwartungshaltung zu ungefiltertem
    Internet kommuniziert, ebenso die Anforderung nach zeitnaher
    Kommunikation bei Eingriffen und dem Wunsch nach mehr Feingefuehl
    bei (vermeintlich legitimen) Sperrungen - die gesperrten Adressen
    waren klar ersichtlich aus dem Microsoft SaaS Bereich.

    Wir haben gleichzeitig der unibe auch unseren Dank ausgesprochen
    fuer die legitimen, temporaeren Sperrung in Notfall-Situationen in
    den letzten Jahren (DoS, DDoS) und den ansonsten bisher immer sehr
    guten Service und Zusammenarbeit.

    unibe wird nun die internen Prozesse ueberarbeiten und uns
    informieren.

  * Wir haben die vollstaendige Liste aller gesperrten Adressen und
    Ports verlangt und erhalten. Wir werden diese in den naechsten Tagen
    bereinigen (d.h. alles entsperren lassen was nicht gesperrt sein
    muss; wir haben bereits einige weitere illegitime Sperrungen von
    Systemen gefunden).

  * Langfristig: in Hinblick auf den Campus Biel ist eine
    Diversifizierung der Internet-Anbindung durch einen eigenen,
    separaten Internet-Aufgang im dort neu aufzubauenden Rechenzentrum
    in Biel vorgesehen.

    Dadurch kann nicht nur eine Performance-Verbesserung fuer die
    Standorte in Biel erreicht werden, sondern auch eine Verbesserung
    fuer die Gesamt-BFH durch Provider-Unabhaengigkeit und oertliche
    Redundanz geschaffen werden.


6. Fun Fact
===========

Die Sperrung der Microsoft Mailserver hat nich nur die BFH betroffen,
sondern neben der unibe (definitiv) selbst auch (vermutlich) alle der
unibe Internet-anbindungstechnisch angehaengten Institutionen wie PH
Bern und das Insel Spital.

Die Einschraenkung war fuer alle Teilnehmenden gleichermassen
verheerend. Trotzdem waren wir offenbar die ersten die den Effekt der
Sperrung bemerkt haben. Ob wir die Ersten sind die grossflaechig auf
Exchange Online setzen, oder ob alle in den Ferien oder im Homeoffice
sind, oder einfach keine E-Mails lesen/verschicken.. wissen wir
natuerlich nicht :)


Wir danken fuer euer Verstaendnis.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science