Mailrouting mit Exchange Hybridstellung

[mirrorrorrim]

Hallo zusammen,

wir haben Schwierigkeiten unsere Exchange Hybridstellung mit unserem lokalen No Spam Proxy zu verbinden. Vielleicht kann hier kurz jemand dazu eine Aussage treffen. Dazu mal ein paar Infos:

Ist-Zustand:
- lokaler NoSPamProxy Server (Version 15.2) für Encryption und Protection
- lokaler Exchange mit Hybridstellung
- Postfächer teilweise Online und teilweise auf dem lokalen Exchange

Soll-Zustand:
- alle ausgehenden E-Mails ins Internet sollen über den NSP gehen (egal, ob das Postfach lokal oder online liegt)
- eingehende E-Mails gehen per MX auf den lokalen Exchange, davor werden die E-Mails vom NSP geprüft (das klappt auch schon)

Wo ist das Problem? Beim Mailrouting, wie sind die Konnektoren richtig einzurichten? In der Doku habe ich leider nichts zu einer Hybridstellung gefunden, nur entweder rein O365 oder rein OnPremise.

Unsere Einstellungen:

E-Mail Server des Unternehmens
- der lokale Exchange ist hinterlegt
- O365 Mandant angelegt (als Clientzertifikat ist unser öffentliches Zertifikat hinterlegt)

Eingehende Sendekonnektoren
- SMTP Sendekonnektor an unseren lokalen Exchange (keine DNS Routing Einschränkungen) ; Kosten 30
- automatisch angelegter O365 Sendekonnektor; Kosten 50

Ausgehende Sendekonnektoren
- Direktzustellung per DNS, STARTTLS und unser Zertifikat hinterlegt, keine DNS Routingeinschränkungen

Empfangskonnektor
- Empfangskonnektor auf Port 25, etc. das sollte ja nicht weiter relevant sein

Wie muss ich die Konnektoren korrekt einrichten, damit der Mailfluss mit der Hybridstellung korrekt funktioniert? Auf dem Online Exchange existieren die Default Inbound/Outbound Konnektoren.

 

[JanJäschke]

Hey,

zeigt der Mixer nun auf den NSP oder auf den lokalen Exchange? (Nur um sicher zu sein)

So wie ich es verstehe ist dein Ziel:
MX: NSP
NSP Routet an den lokalen Exchange und dieser Teil nach Postfächern (eben hybrid) auf, korrekt?

In deinem Ist Zustand greift vermutlich der Inbound Konnektor vom O365 mit Prio 50?
Falls ja (hier wurde schon was verbessert): da er in dem vermeintlichen Soll erstmal nicht gebraucht wird, einfach deaktivieren

NSP selbst kann dir nicht entscheiden welcher User wohin geroutet werden soll wenn die gleiche Domäne genutzt wird.
Du musst dich also beim Empfsng auf EXO oder On-Prem festlegen und von dort an den jeweiligen anderen weiterleiten

LG
Jan

 

[mirrorrorrim]

Hallo Jan,

der MX zeigt auf den NSP bzw. im Endeffekt beide. Firewall macht NAT auf den NSP, der routet dann auf den Exchange.

Also deaktivieren lässt sich der O365 Konnektor nicht, ich kann nur die Zuordnung zur GW Rolle entfernen. Meinst du das?

Und beim Senden soll halt auch, egal, ob von Online oder lokalen Postfächern verschickt wird, die E-Mail über den NSP gehen. Dann sollte es hier doch reichen einen entsprechenden Outboundkonnektor und Transportregel im Exchange Online anzulegen? Und in dem Outbound Konnektor vom EXO stelle ich die Richtung: "Von O365 zu Partnerorganisation" und dann per Smarthost auf den NSP ein?

VG

 

[JanJäschke]

Jap, alle genannten Punkte sind korrekt.
Zuweisung entfernen, und dann die Konnektoren outbound anlegen.
Für EXO kannst du dir auch ein PowerShell Skript in der UI von uns generieren lassen und nur die notwendige Konfiguration davon rauskopieren.

 

[mirrorrorrim]

Guten Morgen Jan,

wir sind jetzt ein Stück weitergekommen, es funktioniert soweit alles, außer die Zustellung an Online Postfächer. Wenn wir von Extern an ein Online Postfach schicken, geht das erfolgreich durch den NSP (wird als Erfolgreich gekennzeichnet) und dann bekommt der externe Absender einen NDR vom lokalen Exchange "550. 5.4.4 Unable to Relay". Die Weiterleitung an den EXO klappt nicht. Schalten wir den NSP wieder aus und Mailfluss läuft wie bisher, dann klappt es fehlerfrei. Noch irgendeine Idee?

VG

 

[StefanCink]

"Unable to relay" sieht ganz nach NoSpamProxy aus, das ist unsere Standardfehlermeldung bei einer Abweisung. Ich kann mir vorstellen, dass auch der wieder ausgehende E-Mail-Traffic vom OnPrem-Exchange durch NSP geroutet wird. Bei einer Mail von Extern wäre das dann eine E-Mail mit einem externen Absender an einen internen Empfänger. Möglicherweise gibt es hierfür keine Regel.

 

[mirrorrorrim]

Hallo Stefan,

ich kann gerade keine Screenshots anfertigen, ich erklärs mal so:

Externer Absender schickt Mail an internen Empfänger (Postfach liegt OnPremise): Mail--Firewall--NoSpamProxy--Exchange 2019 -> funktioniert

Externer Absender schick Mail an internen Empfänger (Postfach liegt im Exchange Online): Mail--Firewall--NoSpamProxy--Exchange 2019--Exchange Online -> funktioniert nicht. In der Nachrichtenverfolgung vom NoSpamProxy steht die E-Mail als erfolgreich zugestellt. Der Exchange schickt eine E-Mail an den Absender, dass die Mail nicht zugestellt werden kann (Unable to Releay). Der Absender ist in dem Fall auch nicht der NoSpamProxy, sondern direkt der Exchange. Der lokale Exchange hat Probleme die E-Mail an den Online Exchange zuzustellen. Es gibt dort zwei Sendekonnektoren (der durch den Hybridassistenten angelegte Konnektor mit Adressraum xyz.onmicrosoft.com und den Sendekonnektor Richtung NoSpamProxy mit Adressraum *.

VG

 

[Fabian]

Wir haben unseren EX 2016 leider schon lange weg, aber die Frage die es zu klären gilt:

Wie muss der Mailflow korrekterweise sein:

Internet <-> NSP <-> EX <-> EXO (hatten wir damals erfolgreich mit unserer Cisco ESA am laufen während der Migration der Postfächer zu Office 365)
oder
Internet <-> NSP <-> EXO <-> EX (So schreibt es MS, siehe Quelle)

Wenn es keine Präferenz gibt ggf. NSP auf EXO zeigen lassen und was dieser nicht kennt via Connector nach Onprem zurück schieben?

Ich würde darauf tippen das der EX die E-Mail von NSP falsch interpretiert (Berechtigung, Connector etc.) und nicht auf die TargetAddress auflöst und an EXO weiterleitet.

Wird der gleiche Konnektor beim EX für die IP vom NSP und der Internet-FW genutzt?

Wenn es direkt auf den EX klappt, jedoch nicht mit dem NSP davor ....

Quelle: https://learn.microsoft.com/en-us/e...es/manage-mail-flow-on-office-365-and-on-prem

LG
Fabian

 

[mirrorrorrim]

Guten Morgen,

der Mailfluss soll so aussehen:

Internet <-> NSP <-> EX <-> EXO

Wir haben zwei Sendekonnektoren:

Outbound O365:




Outbound NSP: (aktuell steht dort wieder die IP der Firewall, damit klappt es problemlos)






Im EXO:




VG

 

[Fabian]

Deine Screenshots zeigen nur den Ausgang aus Sicht des Exchange Onpremises Servers (ins Internet zum NSP/ FW für die Domain "*" bzw. zu EXO nach Office 365 mit domain.mail.onmicrosoft.com), diese passen meines Erachtens. Die wichtigere Frage ist der Eingang - letztlich leitet der EX die E-Mails an migrierte Konten ja nicht weiter, sondern bounced diese.

Hier müsste es auch Zuweisungen geben, welche IP an welchen Konnektor geht und welche Berechtigung somit greift.

 

[mirrorrorrim]

Okay, also ich dacht der Sendekonnektor Outbound 365 leitet die E-Mails weiter. Das ist schonmal ein anderer Ansatz. Ich habe mal in die Empfangskonnektoren geschaut, dort ist aber in keinem der vorhandenen Konnektoren die Firewall hinterlegt.

 

[MichiH]

Okay, also ich dacht der Sendekonnektor Outbound 365 leitet die E-Mails weiter. Das ist schonmal ein anderer Ansatz. Ich habe mal in die Empfangskonnektoren geschaut, dort ist aber in keinem der vorhandenen Konnektoren die Firewall hinterlegt.

Moin,

nur mal ganz dumm gefragt: Darf der Exchange denn direkt per Port 25 in's Internet und stimmt das an den Sendekonnektor gebundene Zertifikat mit der Einstellung im EXO Inbound Konnektor?
Ich habe schon häufiger Stress an dieser Stelle gehabt, vor allen Dingen wenn mit Wildcard Zertifikaten gearbeitet wird. Mitunter hat es geholfen, die Konnektoren auf die externe IP Adresse umzustellen.

 

[mirrorrorrim]

Hallo Michi,

der Exchange darf per SMTP ins Internet. Zertifikat ist überall *.domain.de - das mit dem Konnektor auf die öffentliche IP wäre auch noch ein Ansatz, das werden wir beim nächsten Versuch mal testen.

VG

 

[Sören]

Zertifikat ist überall *.domain.de

dem entnehme ich, dass ihr ein wildcard Zertifikat nutzt und weil du "überall" schreibst: gehe ich davon aus, dass dieses Zert an mehreren Konnektoren gebunden ist...richtig?

Wenn ja: MS macht "first match wins" die nehmen dann einfach den ersten Konnektor den sie finden auf den das Zert gebunden ist...egal ob das der richtige oder falsche ist. Niemals ein wildcard an Konnektoren im EXO binden