Sophos SG115 blockiert Exchange auf einem WAN Port

[PEASANT KING]

Guten Tag,

ich habe ein Problem an dem ich langsam verzweifel, dabei sollte es doch so einfach sein.
Ich habe hier eine Sophos SG115 und nutze drei WAN Leitungen an der Sophos.

Es gibt ensprechende NAT Regeln, allerdings habe ich das Phänomen, das zwei Leitungen die Kommunikation mit dem Exchange Server zu lassen, die neue Leitung allerdings nicht. Ich stehe absolut auf dem Schlauch, leider gibt mit das Firewall Log auch nicht wirklich aufschluss.

Meiner Meinung nach sind alle drei Leitungen korrekt konfiguriert in der Sophos.

 

[d2boxSteve]

Dir ist hoffentlich bewusst dass ohne Screenshots keiner was dazu sagen kann außer: irgendwo in Firewall-/NAT-Regeln fehlt das dritte WAN Interface ...

 

[PEASANT KING]

Naja was sagen die NAT Regeln groß, aber Recht hast du!

Ich habe die IP des Exchange geprüft stimmt auch und der Port 443 in den NAT Regeln stimmt auch, es funktioniert ja auch beiden anderen Leitungen nur auf der neuen Glasfaser Leitung in der Sophos nicht.

 

[d2boxSteve]

Hm, sieht auf den ersten Blick richtig aus. Was genau passiert denn, wenn du aus dem Internet die Seite aufrufen willst?
Mein Problem hier ist, das ist noch die alte UTM Software, ich kenn eher die neue SFOS 18.x von den neuen XG-Firewalls (XG115).

 

[PEASANT KING]

Bekomme eine ganz normale Zeitüberschreitung im Firefox. Also für mich wird hier eindeutig von der Sophos geblockt.

Sry ich bin gerade dabei hier alles neu auf zu bauen und zu strukturieren neben, dem alltäglichen Wahnsinn ^^.
Dauert noch was, bis ich hier neuere Hardware bekomme.

Ich bin blöd, es liegt natürlich daran das ich ja aus dem gleichen Netz das Ganze versuche.
Gibt es denn hier nicht auch eine Möglichkeit, das es dennoch funktioniert? Denn wenn ich es von außerhalb versuche, sprich Smartphone z.B. dann gehts.

Schnellere Lösung wäre denke ich die interne IP des Exchange zu nutzen.

Nachtrag:

Denkfehler, ich habe eine externe IP XXX und rufe Adresse auf YYY beide IPs gehören mir, nur meine Anfrage von XXX wird an YYY abgeblockt. Wenn ich das Ganze von außerhalb mache, Smartphone mit ZZZ als Adresse an YYY geht es direkt.

 

[Kampfwurst Hugo]

https://www.google.com/url?sa=t&sou...MwDXoECAIQAg&usg=AOvVaw0fY3fJRwp1Vvu7yatjvhY6

 

[PEASANT KING]

Okay danke für den Google Eintrag, aber es funktioniert ja teilweise, denn ich habe drei externe WAN Adressen und über zwei von denen geht es ja nur über die dritte nicht.

 

[Raijin]

Ich kenne mich mit Sophos leider so gar nicht aus, aber bist du dir sicher, dass etwas geblockt wird? Woraus schließt du das?

Bei Multi-WAN kann es bei fehlerhafter Konfiguration schlimmstenfalls passieren, dass jeweils request und reply auf verschiedenen WANs reinkommen bzw. rausgehen. Das führt unweigerlich zu Problemen, die sich darin zeigen, dass keine Verbindung zustande kommt und man den Eindruck bekommen kann, dass irgendetwas geblockt wird.

In deinem Screenshot ist eine Option für "Initialisierungspakete protokollieren" zu sehen. Ich würde die mal einschalten. Dabei werden mutmaßlich die SYN bzw. SYN+ACK Pakete beim Verbindungsaufbau protokolliert. Ich vermute mal, dass man da sehen müsste ob beide über dasselbe WAN laufen oder nicht.

Falls diese Log-Funktion nicht ausreicht, kann man bei Sophos sicherlich auch tcpdump, o.ä. nutzen, um alle Pakete zu loggen.

 

[PEASANT KING]

Okay da habe ich schon einen Anhaltspunkt. Der Request läuft nicht über das gleiche WAN wie der Response,
was ich auch so im Betrieb nicht ändern kann zur Zeit, da die Dienste per DNS aufgelöst werden.
Ich hatte mal einen DNS Eintrag für zwei IPs hinterlegt, allerdings scheiterte das Ganze auch wieder daran, das die Hälfte nicht funktionierte.

 

[t-6]

Wie sehen die Multipathregeln aus?

Und: Irgendein spezieller Grund dass du nicht den Reverse Proxy/Webserver Protection für den Exchange-Zugriff nutzt? Dafür ist das Marketing-Blurb NGFW ja da.
Momentan stellst du halt einen Windows-Server direkt ins Internet... (abzüglich dessen was IPS wegfischen könnte)
Hier mal Franky's (afaik aktuellste) Anleitung dafür: https://www.frankysweb.de/sophos-utm-9-6-lets-encrypt-webserver-protection-und-exchange-2016-2019/
(Let's Encrypt kannst du überspringen wenn du bereits ein Zert hast das du hochladen kannst)

Und ich frag sicherheitshalber noch mal: Du nutzt auch schon wenigstens den Emailfilter, ja? Ansonsten kannst du auch gleich eine Fritzbox hinstellen.

 

[PEASANT KING]

Über Multipath Regeln umgehe ich im Moment das Problem, allerdings will ich in Zukunft nur noch eine Leitung und die restlichen Leitungen sind überflüssig theoretisch und sollen gekündigt werden.

 

[snaxilian]

Hast halt im Fehlerfall keine Redundanz wenn du alle bis auf eine Leitung kündigst.

 

[t-6]

Das hier:

Über Multipath Regeln umgehe ich im Moment das Problem,

Ist nicht die Antwort auf das hier:

Wie sehen die Multipathregeln aus?

Wir bräuchten einen Haufen mehr Infos bzw. Screenshots. Gerne können öffentliche IP-Adressen pseudonymiert werden.

allerdings will ich in Zukunft nur noch eine Leitung und die restlichen Leitungen sind überflüssig theoretisch und sollen gekündigt werden.

Keine WAN-Redundanz für einen Onpremise-Exchange bzw. generell keine WAN-Redundanz für - so sieht es zumindest aus - geschäftlichen Einsatz? Welche frische Verrücktheit ist das denn?
Bei Kosten-Nutzen-Rechnungen, besonders wenn man mal Erfahrungswerte hat, zeigt der Zeiger heutzutage immer Richtung zweiten Internetanschluss im Geschäftsbetrieb, selbst wenn deine Firma nur Gartentore zusammenschweißt. Und wenn deine Firma Gartentore zusammenschweißt, ist sie wahrscheinlich mit Exchange Online + LTE Hotspot als Coldspare besser bedient.

Das Gerenne und Geflenne (der Produktivätsverlust) bei ausgefallener Internetleitung ist immer mit einem Umsatzverlust behaftet, der erfahrungsgemäß die Kosten einer zweiten Internetleitung übersteigt. Ich würde niemals in einer Firma arbeiten wollen, die das nicht versteht.

 

[PEASANT KING]

Ich habe hier das totale Chaos übernommen und mir kann auch Keiner so wirklich sagen, was hier alles gemacht wurde was nicht gemacht wurde etc pp. ich muss mich hier halt rein fuchsen.

Ich habe jetzt eine Webserver Protection eingerichtet, für die Exchange Dienste habe ich DNS Einträge erstellt und habe das Ganze getestet, von extern funktioniert es auch wunderbar nur von intern nicht.
Wundert mich eigentlich, da es doch nun auch ohne Reverse Proxy bzw. Full NAT was auch gehen würde klappen sollte.

EDIT:

Hat sich erledigt, funktioniert, ich hatte die falsche Subdomain angesprochen ...

 

[PEASANT KING]

Ich hätte dennoch gern gewusst, warum das Ganze mit Full NAT bzw. Loopback NAT nicht funktioniert.
Theoretisch musste das doch auch gehen oder nicht?

 

[Raijin]

NAT-Loopback ist eine Funktion, die zum einen natürlich erstmal vom Router unterstützt und je nach GUI auch explizit aktiviert werden muss.

Dabei muss man bedenken, dass vermeintlich lokaler Traffic, also zwischen Client und Server, die ggfs sogar nebeneinander am selben Switch hängen, dabei vollständig über den Router und dessen WAN-Port geht (aber den WAN-Port nicht nach außen verlässt), um kurz vor dem Internet um 180° gedreht zu werden und die komplette NAT-Pipeline durchläuft bis zum lokalen Server. Das heißt auch, dass etwaige Portweiterleitungen, die speziell eingeschränkt werden (zB nur bestimmte Quell-IPs), unter Umständen nicht getriggert werden, wenn man beispielsweise auf die statischen IP-Adressen anderer Standorte triggert. Bei NAT-Loopback müsste man hier auch die lokale WAN-IP hinzufügen, weil NAT-Loopback-Traffic beim "wieder nach drinnen gehen" bereits die WAN-IP als Quell-IP bekommen hat (SNAT für outgoing traffic).

NAT-Loopback sollte daher nach Möglichkeit vermieden werden, weil ggfs auch die WAN<--NAT-->LAN Performance des Routers die Verbindung beeinträchtigen kann.

 

[PEASANT KING]

Ok, was ich durch tracert raus gefunden habe, ist das die Pakete von lokal nach draußen gehen an die externe IP dann an den Router dann wieder nach draußen zum Provider und bei mir an der external WAN enden.
Also logisch, das die Pakete nicht bei mir wieder am Client ankommen.

 

[Raijin]

Wenn die Ziel-Domain auf deine WAN-IP aufgelöst wird, sollte NAT-Loopback so laufen:

• Client will mit Domain verbinden
• DNS query von Domain ergibt eine öffentliche IP
• Client schickt Verbindung via Standardgateway (Router)
• Router sieht öffentliche Ziel-IP
• Router macht SNAT am WAN.
• Router merkt, dass er selbst das Ziel ist
• Router dreht die Verbindung im WAN-Port um 180°
• Router checkt seine Portweiterleitungen
• Router leitet bei einem Match an lokalen Server weiter
• Lokaler Server bekommt Verbindung von Quelle=WAN-IP des Routers
• Server antwortet auf dem umgekehrten Weg

Bei NAT-Loopback verlässt kein einziges Bit der Verbindung den WAN-Port nach außen. Ist das aber nachweislich der Fall, wird NAT-Loopback nicht unterstützt oder ist deaktiviert und die Verbindung dreht sich beim Providergateway.


Das bezieht sich jedoch in erster Linie auf Verbindungen, die über ein und denselben WAN-Port raus bzw. reingehen. Findet hier ein Transfer von WAN1 auf WAN2 statt, kann sich der Router anders verhalten. Das weiß ich offen gestanden nicht.

 

[PEASANT KING]

Wie du beschrieben hast, wenn ich über einen anderen WAN Port gehe, steht die Verbindung,
hatten hier andere meine ich auch schon erwähnt. Nun ist es so, das ich hier eine Glasfaster Leitung hinsetzen lassen habe, die alle anderen WAN Anbindungen überflüssig machen, da Ausfall vom Provider über Backup innherhalb des Hauses wohl sein sollte.

Daher sollen nächstes Jahr die restlichen Leitungen gekündigt werden und verschwinden.
Ich bin dabei gerade alles Stück für Stück umzustellen.
Jetzt habe ich genau das Problem, das ich eben aus dem eigenen Netzwerk unseren Exchange nicht erreiche bzw. um Outlook neu einzurichten etc. der Empfang von Mails funktioniert etc. nur, wenn ich hier Postfächer ändere etc. funktioniert das nicht, oder aber z.B. "Automatische Antworten" können nicht eingerichtet werden.

 

[Raijin]

Und wenn du einen lokalen DNS-Eintrag tätigst, der gar nicht erst die öffentliche IP zurückgibt, sondern direkt die lokale Server-IP? Das ist in der Regel der bessere Weg, weil man sich so den Umweg über den Router spart und zB Client und Server an ein und demselben Switch auch direkt miteinander reden. So wäre die ganze Multi-WAN-Geschichte bei der lokalen Nutzung irrelevant.

Ob und wie das geht, musst du natürlich der Doku des verwendeten lokalen DNS-Servers entnehmen.


Im worst case wäre natürlich ein Eintrag in der hosts-Datei der Clients möglich. Das ist aber sehr unschön würde ich nur als allerletzten Ausweg ansehen.