office 365 emails not coming out

Good morning, we are developing a web application, where it is required to use an office 365 email account to send the emails, however they do not appear.

What are the parameters that must be enabled correctly?

Thank you.

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @AlfonsoPC
    Without knowing how you're sending those emails, it's difficult to say what is required.

    -What protocol are you using? (SMTP, MAPI?)
    -Do you have an outbound rule set up to allow that traffic?
    -Do you see any errors for that traffic in traffic monitor on the firewall, or from where you are trying to send the email in your logs?

    -James Carson
    WatchGuard Customer Support

  • edited August 2023

    Good afternoon, SMTP is being used, port 25, and the smtp.office365.com server for sending mail, an smtp proxy with starttls was enabled in the watchguard and when doing the test sending an error is generated both in the language virus as in the SSL whatchguard FSM which is as follows:

    2023-08-15 13:24:28 UIAMember1 pxy 0x75e220-15302162 5767: 192.168.8.240:58555 -> 52.96.173.178:25 [A t] {B}: Accept SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/tlsv1 alert unknown ca] Domain: outlook.com PFS: ALLOWED | ALLOWED Debug

  • I have an application doing the same thing with O365.
    You need port 587 and TLS.
    I just created a custom packet filter instead of a proxy as the application just sends plain text acknowledgements. Easier that way.

    It's usually something simple.

  • thanks, it worked.

    Good job.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @AlfonsoPC If you are using TLS encryption and want the firewall to proxy that traffic, your server's SSL cert needs to be uploaded to the firewall.

    See:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/smtp/proxy_smtp_tls_encryption_c.html

    A packet filter will also work as it does not touch the certificate at all, but will not decrypt the traffic (and therefore won't scan the unencrypted traffic.

    James Carson | Support Engineer
    WatchGuard Technologies, Inc. | www.watchguard.com
    Office Hours: 9:00 AM to 6:00 PM Pacific (GMT-8), Sun - Thurs
    Contact us: https://www.watchguard.com/wgrd-support/support-by-phone/all
    Tech Search: https://techsearch.watchguard.com/
    Feedback: https://www.watchguard.com/wgrd-support/feedback

    -James Carson
    WatchGuard Customer Support

  • I have a similar issue to AlfonsoPC, plus I'm new to managing a Firebox. I've read the documentation and watched a few vids, and I think I created a custom packet filter and policy for 587 properly, however, when I test I see in traffic monitor that the traffic is blocked with a 'Unhandled internal packet-00' error.
    I've tested connections over TCP 25 & 465 and both work, but the 587 just doesn't. I even included UDP 587 to see but no luck, and all other settings of the policy were left at default.
    I'm wondering if order policy is an issue or did I configure incorrectly? If not, I certainly need help.

  • @868Noob said:
    I have a similar issue to AlfonsoPC, plus I'm new to managing a Firebox. I've read the documentation and watched a few vids, and I think I created a custom packet filter and policy for 587 properly, however, when I test I see in traffic monitor that the traffic is blocked with a 'Unhandled internal packet-00' error.

    Whenever you see an "Unhandled Internal Packet-00" type log, that generally means it didn't match any of the policies you have defined.
    Your screenshot shows the "587" policy matching traffic from "Any-Trusted" to "Any-External" - I am wondering if the internal system is not directly on a trusted interface (the only way that is going to match), in which case you'd need to specify that internal system IP address/subnet in the "from" rule.

  • Please post a sample deny log message with 'Unhandled internal packet-00' as the reason

  • @PhilT_VIT said:

    @868Noob said:
    I have a similar issue to AlfonsoPC, plus I'm new to managing a Firebox. I've read the documentation and watched a few vids, and I think I created a custom packet filter and policy for 587 properly, however, when I test I see in traffic monitor that the traffic is blocked with a 'Unhandled internal packet-00' error.

    Whenever you see an "Unhandled Internal Packet-00" type log, that generally means it didn't match any of the policies you have defined.
    Your screenshot shows the "587" policy matching traffic from "Any-Trusted" to "Any-External" - I am wondering if the internal system is not directly on a trusted interface (the only way that is going to match), in which case you'd need to specify that internal system IP address/subnet in the "from" rule.

    Hi Phil,

    The server is part of a specified VLAN for all servers and its connected on a Trusted Interface. I've tried using the system IP, the system FQDN and the IP range but no luck.
    Connections to ports 25 and 465 work without any issue.

  • @Bruce_Briggs said:
    Please post a sample deny log message with 'Unhandled internal packet-00' as the reason

    Bruce,

    I tried the policy with 1 outgoing link at a time, then with both (as seen in graphic) but same result.

  • edited May 19

    The deny log message indicates that there is no policy allowing that port for that user or that source interface name - Servers.
    It appears that the Servers interface is not a Trusted interface and ths not allowed by an Any-trusted policy.
    Add Servers to the From: of your policy & test again.

    FYI - no need to blank out private IP addrs or interface names...
    Showing them to us does not incur any security exposure to you.

  • @Bruce_Briggs said:
    The deny log message indicates that there is no policy allowing that port for that user or that source interface name - Servers.
    It appears that the Servers interface is not a Trusted interface and ths not allowed by an Any-trusted policy.
    Add Servers to the From: of your policy & test again.

    FYI - no need to blank out private IP addrs or interface names...
    Showing them to us does not incur any security exposure to you.

    I recreated a new packet filter and policy as seen in image 1 & 2, but still being denied as seen in image 3.

  • FYI - the source IP addr being denied is not a private one, it is a public one, listed as being in Dortmund Germany.
    Best to not show any full public IP addrs here.

    Is your goal to have private ones on this subnet, and have it NATed incoming and outgoing?

    Is the DIGICEL interface of the External type?

  • james.carsonjames.carson Moderator, WatchGuard Representative

    I would suggest opening a support case so one of our support team can take a look at your config and assist. You can open a support case via the support center link at the top right of this page.

    -James Carson
    WatchGuard Customer Support

  • @Bruce_Briggs said:
    FYI - the source IP addr being denied is not a private one, it is a public one, listed as being in Dortmund Germany.

    That's actually being used as an internal private address (previous person's doing, but no clue why), working on a plan to change.

    Best to not show any full public IP addrs here.

    Is your goal to have private ones on this subnet, and have it NATed incoming and outgoing?

    Is the DIGICEL interface of the External type?

    Finally got through! So it seems the Firebox had not been restarted in a while... before I even came, and it took a power outage to cycle it last night. Now traffic is passing and the box appears to be updated as well.

    Thanks again for the assistance!

  • Since it has been a long time since this firewall was rebooted, it may be running an older version of Fireware.

    For the record, what version of Fireware is on it and what firewall model do you have?
    The most recent Fireware version is V12.10.3.
    Many older Firebox models do not support the latest version of Fireware.
    Knowing your firewall model allows us to tell you what the newest versions that can run on your firewall.

    Normally a reboot is not needed for config changes to work. Odd.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    My guess would be one of two things here:

    -The mail server was leaving the connection open (or what it thought was a connection.) Rebooting the firewall would have closed whatever connection you had open and froced it to re-start.

    -The mail server failed to submit messages, and timed itself out. Rebooting the firewall caused the connection to up/down, or it naturally tried again after timing out.

    Or the firewall was just still denying the traffic for some reason.

    If you do run into that issue again, I'd suggest opening a support case. All I can really do is speculate with the info I have here.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.