Hello All,

We upgraded our esa's from 11.0-128 towards 12.5-066

Immediately after the upgrade we started to see TLS error ( for mails which come in from internet and gets routed over ESA towards our O365 tenant )

The errors are :

Tue Sep 17 09:08:25 2019 Info: ICID 43627580 TLS error: [Errno 54] Connection reset by peer
Tue Sep 17 09:08:31 2019 Info: ICID 43627587 TLS error: [Errno 32] Broken pipe
Tue Sep 17 09:08:35 2019 Info: ICID 43627596 TLS error: [Errno 32] Broken pipe
Tue Sep 17 09:08:41 2019 Info: ICID 43627607 TLS error: [Errno 54] Connection reset by peer
Tue Sep 17 09:08:42 2019 Info: ICID 43627609 TLS error: [Errno 32] Broken pipe
Tue Sep 17 09:08:47 2019 Info: ICID 43627618 TLS error: [Errno 32] Broken pipe

So almost for every message coming in from the internet.... If we look deeper in the mail traces, the mail is received & transferred fine within the same session. So no queueing at all.

It might seems cosmetic, sure..but we didn't have those errors in 11.0-128.. Must be something changed in 12.5-066 .

We also have a case open with Ciso TAC, but seems to be stuck... ( result : I cannot confirm the source of the reset packet since it doesn't generate from the ESA ) --> they see a RST comming from O365 ( but the issue occurs with accepting the incomming connection :-) ) so imho the result has nothing to to with it ...

note:

smtp conv logs show the error also :

Tue Sep 17 09:27:24 2019 Info: ICID 43630119 >> 250 ok: Message 50409463 accepted

Tue Sep 17 09:27:24 2019 Info: ICID 43630119 - Connection unexpectedly closed by peer.

Tue Sep 17 09:27:24 2019 Info: ICID 43630119 close

Anybody else having the same issues ?

Regs

Rob

Please try to enable a packet capture in the ESA using the sending host IP address and port 25 as filter. Then attempt the SMTP conversation. That will help gather captures and know if the TLS issue occurs due to cipher negotiations or TLS versions in use.

If the sender expects only high end ciphers to be negotiated with ESA, you may add to existing Inbound SMTP Ciphers

MEDIUM:HIGH : @STRENGTH along with the existing ciphers.

Hello

I did a packet trace , but no TLS negotiations are going wrong... It seems and that's very strange .. the errors only occurs from mails that come from an O365 environment on the internet towards our ESA's

For every mail that gives that error ( and connection lost ) we are seeing this in the trace :

SOURCE                  DESTINATION                        PROTOCOL                         INFO

O365 IP                   OUR ESA IP                           TCP                                     PORT X-> 25 [ RST, ACK]

O365IP                    OUR ESA IP                           TCP                                     PORT X-> 25 [ RST, ACK ]

So two RST's in a row and then the connection is lost

..… Any idea ?

Just a heads up to this thread, We are looking into it within the Cisco TAC cases opened.
If and when we get to an update on the issue, we'll share it forward on this thread as well due to the concerns noted.

I would recommend anyone having this issue to let us know on Cisco TAC via a ticket.

Regards,
mathew

This issue depending on when it occurs is handled differently.

In the case of the original request and some other tickets I looked into, the issue was more of a cosmetic type issue; where the email has been completely delivered and the ESA gets a RST packet to end the connection instead of a FIN packet, so we end up logging the TLS error due to improper TLS connection closure.

If your mail_logs or tracking is showing it happening at the beginning of an ICID, then it could be a different underlying issue.

Regards,

Mathew