O365 Migration

shaazaminator

Hey Community,

M470 12.10.4

I'm in the process of migrating my on prem Exchange server to O365 but I keep running into connectivity issues with the send/receive connectors on both sides along with the Outlook client not connecting due to my firebox causing havoc in the middle.

Has anyone been through this before, or is there a guide explaining how to configure your firebox policies & proxies for O365?

I have incoming and outgoing SMTP proxies, along with HTTPS proxies running DPI.

Sample FB deny:

2024-08-29 09:40:31 Deny 104.47.74.42 xxx.xxx.xxx.xxx smtp/tcp 21825 25 Zayo Fiber Trusted IBEW48 ProxyDeny: SMTP AUTH (SMTP-Exchange-Inbound-00) Incoming Exchange Proxy proc_id="smtp-proxy" rc="595" msg_id="1BFF-0002" proxy_act="Incoming Exchange Proxy" rule_name="Default" authtype="NTLM" geo_src="USA" geo_dst="USA" Traffic

Sample O365 Deny:

Detailed log
450 4.4.317 Cannot connect to remote server [Message=SubjectMismatch Expected Subject: WORK.com. Presented Subject: CN=https.proxy.nul, OU=Fireware, O=WatchGuard_Technologies. Thumbprint: 727EFD5D51D5A8A304938E659BCEB677E5E64B83.] [LastAttemptedServerName=mail.mydomain.com] [LastAttemptedIP=xxx.xxx.xxx.xxx:25] [SmtpSecurity=-1;-1] [DM6NAM12FT111.eop-nam12.prod.protection.outlook.com 2024-08-29T16:52:25.667Z 08DCC77C54BDD053]

I really don't want the whole O365 world access to SMTP port 25 & 465 inbound to my Exchange server. Presently our inbound mail runs through a remote mail gateway and I just allow the IP's of that gateway access. That being said, I did allow *.protection.outook.com along with the other O365 fqdn's in for testing but still had connection issues. My guess is my proxy settings.

Thoughts or ideas appreciated.

• Doug

PhilT_VIT

Not that I have any Fireboxes with inbound SMTP to deal with any more (all the clients I deal with use hosted mail servers like Microsoft 365), but for outbound SMTP I've found even for scan to email we needed to bypass the SMTP proxy and just use a SMTP packet filter as it didn't like some of the extended SMTP commands being used (from memory the default SMTP proxy drops sessions if it uses a command not in its list).

Try having a SMTP packet filter instead of the proxy for the inbound connection (restricted to the Microsoft 365 servers) and see if that makes a difference.
May need to do the same for outbound SMTP connections from the on-premise Exchange server as well.

james.carson

@shaazaminator

The specific log you're seeing suggests that the proxy is denying the traffic due to the authentication type being used by the remote server does not match the list in your ESMTP -> Authentication section of your proxy action.

If you're unsure what they're using, it may help to change your none matched action to allow, with logging turned on so you can note what they're specifically using, and add it to that list.

I wouldn't suggest using a packet filter unless you have no other option, as a packet filter will leave out most security services that the proxy provides.

shaazaminator

Hey James,
I didn't think of changing the "none matched" to "allow". Let me try it.

The thought of using packet filters instead of proxies for email scares me to death.
Something I may have to do to get by since this is only temporary.

Thanks,

• Doug