6
Unstabile Verbindung über OPNsense-HAproxy zu Exchange
Moin zusammen,
Ich stelle im Outlook Verbindungsstatus fest, dass die Verbindungen zum Exchange Server ab und trennen und sich danach gleich wieder verbinden.
Aufbau:
Windows 10 mit Outlook 2016
OPNsense mit HAproxy
Exchange 2016
Als Test habe ich die Verbindung über den HAproxy weg gelassen und den Client direkt zum Exchange Server verbinden lassen. Hier kommen keine Fehler mehr zustande. Also muss es am HAproxy liegen.
Hier sieht man, wie er gerade wieder die Verbindung herstellt (in der dritten Zeile), was nach ein paar Sekunden dann auch klappt:
Das Interesante ist, dass dieses erst ca 25 Sekunden nach öffnen von Outlook passiert, in den ersten 25 Sekunden gibt es keine Fehler. Es gibt auch keine Fehler, wenn ich alle 10 Sekunden unten links auf "Verbindung wiederherstellen" klicke, oder wie ein Weltmeister 3x pro Sekunde darauf drücke, um mal etwas höheren Traffic zu verursachen. Erst 25 Sekunden danach geht es wieder los, mal mit der obersten Verbindung im Bild und auch mal mit denen darunter, nach Zufallsprinzip - man beachte den Fehlerzähler.
Im HAproxy habe ich die Verbindung wahlweise über HTTP Layer 4 und HTTP Layer 7 versucht, bei beiden kommt das gleiche Fehlerbild. Ich habe es auch wahlweise mit SSL Offloading und auch ohne versucht. Eingerichtet ist es nach dieser Anleitung:
https://www.frankysweb.de/exchange-2016-opnsense-haproxy-und-lets-encryp ...
Outlook zeigt in den paar Logs, die es menschenlesbar erzeugt, nichts an. Auch auf dem Exchange Server bleibt die Ereignisanzeige dabei ruhig. Ich weiss nicht, wo ich weiter eingrenzen soll.
Danke euch in Voraus and keep rockin'
Der Mike
Ich stelle im Outlook Verbindungsstatus fest, dass die Verbindungen zum Exchange Server ab und trennen und sich danach gleich wieder verbinden.
Aufbau:
Windows 10 mit Outlook 2016
OPNsense mit HAproxy
Exchange 2016
Als Test habe ich die Verbindung über den HAproxy weg gelassen und den Client direkt zum Exchange Server verbinden lassen. Hier kommen keine Fehler mehr zustande. Also muss es am HAproxy liegen.
Hier sieht man, wie er gerade wieder die Verbindung herstellt (in der dritten Zeile), was nach ein paar Sekunden dann auch klappt:
Das Interesante ist, dass dieses erst ca 25 Sekunden nach öffnen von Outlook passiert, in den ersten 25 Sekunden gibt es keine Fehler. Es gibt auch keine Fehler, wenn ich alle 10 Sekunden unten links auf "Verbindung wiederherstellen" klicke, oder wie ein Weltmeister 3x pro Sekunde darauf drücke, um mal etwas höheren Traffic zu verursachen. Erst 25 Sekunden danach geht es wieder los, mal mit der obersten Verbindung im Bild und auch mal mit denen darunter, nach Zufallsprinzip - man beachte den Fehlerzähler.
Im HAproxy habe ich die Verbindung wahlweise über HTTP Layer 4 und HTTP Layer 7 versucht, bei beiden kommt das gleiche Fehlerbild. Ich habe es auch wahlweise mit SSL Offloading und auch ohne versucht. Eingerichtet ist es nach dieser Anleitung:
https://www.frankysweb.de/exchange-2016-opnsense-haproxy-und-lets-encryp ...
Outlook zeigt in den paar Logs, die es menschenlesbar erzeugt, nichts an. Auch auf dem Exchange Server bleibt die Ereignisanzeige dabei ruhig. Ich weiss nicht, wo ich weiter eingrenzen soll.
Danke euch in Voraus and keep rockin'
Der Mike
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: 4322850676
Url: https://administrator.de/contentid/4322850676
Ausgedruckt am: 17.11.2024 um 21:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Was ich nach wie vor nicht verstehe, wenn du Split-DNS betreibst (so habe ich es im anderen Beitrag von dir verstanden), sollten die Anfragen intern doch gar nicht zum HAproxy kommen.
Gruß,
Dani
Das Interesante ist, dass dieses erst ca 25 Sekunden nach öffnen von Outlook passiert, in den ersten 25 Sekunden gibt es keine Fehler.
es gibt in der Konfiguration von HAproxy eine paar Parameter die alle mit timeout beginnen. Könnte hierdurch das beschriebene Verhalten enstehen? Dazu noch eine Referenz Konfiguration, die wohl funktioniert.Was ich nach wie vor nicht verstehe, wenn du Split-DNS betreibst (so habe ich es im anderen Beitrag von dir verstanden), sollten die Anfragen intern doch gar nicht zum HAproxy kommen.
Gruß,
Dani
Moin,
das sehe ich auch so!
Frank
Was ich nach wie vor nicht verstehe, wenn du Split-DNS betreibst (so habe ich es im anderen Beitrag von dir verstanden), sollten die Anfragen intern doch gar nicht zum HAproxy kommen.
das sehe ich auch so!
Frank
Doch, weil ich im gesplitteten (internen) DNS als Zieladresse die IP des HAproxys eingetragen habe. Er hat HA für intern und für extern gemacht.
Ich habe mich bereits mit ein paar Timeouts herum gespielt, jedoch ohne Erfolg. Ich habe jedoch 60 Sekunden als Timeout eingestellt, da der erste Fehler immer schon nach 25 Sekunden kam. Ich werde mal die Werte im Referenzlink eintragen und probieren.
Ich habe mich bereits mit ein paar Timeouts herum gespielt, jedoch ohne Erfolg. Ich habe jedoch 60 Sekunden als Timeout eingestellt, da der erste Fehler immer schon nach 25 Sekunden kam. Ich werde mal die Werte im Referenzlink eintragen und probieren.
Boah, tatsächlich hat die Timeout Einstellung bewirkt, dass die Fehler ausbleiben (oder vielleicht erst viel später kommen, das muss ich noch beobachten)
Standard war 30s bei beiden.
Was mir nicht in den Kopf geht:
Ich hatte dieses bereits anfangs von 30s auf 60s erhöht, ohne, dass der Fehler verschwand. Warum kamen die ersten Fehler bereits nach 25s, obwohl die Timeouts auf 60s eingestellt waren?
timeout client 15m # this value should be rather high with Exchange
timeout server 15m # this value should be rather high with ExchangeStandard war 30s bei beiden.
Was mir nicht in den Kopf geht:
Ich hatte dieses bereits anfangs von 30s auf 60s erhöht, ohne, dass der Fehler verschwand. Warum kamen die ersten Fehler bereits nach 25s, obwohl die Timeouts auf 60s eingestellt waren?
Stichwort TCP-Keepalive / TCP Session Timeout / TCP Idle Timeout
https://support.microsoft.com/en-us/topic/troubleshooting-long-running-m ...
https://www.msxfaq.de/netzwerk/grundlagen/tcp_session_timeout.htm
https://support.microsoft.com/en-us/topic/troubleshooting-long-running-m ...
https://www.msxfaq.de/netzwerk/grundlagen/tcp_session_timeout.htm
Hmmm. Ich erkenne in den Beschreibungen darin keine Begründung, warum ein Fehler erscheint noch bevor ein Timeout die Session trennt. Eigentich dürfte es innerhalb dieser 60 Sekunden keine einzige Trennung geben.
