cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9387
Views
11
Helpful
8
Replies

TLS errors after upgrading to 12.5-066 ( TLS error: [Errno 54] Connection reset by peer & [Errno 32] Broken pipe )

rolelael
Level 1
Level 1

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

 

8 Replies 8

pchakra2
Cisco Employee
Cisco Employee

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 ?  

Hi there,

you are not alone. The issue started to happen after the upgrade to 12.5 and seems to mainly impact communication to and from MS domains. 

 

Please open a ticket with TAC

 

 

Marc

Hello

I have a case open with cisco tac.... but we are not getting anywhere


This is happening to our environment as well for emails from O365 eversince we upgraded to 12.5.x. Cisco points to O365 but I doubt it. 

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

Did anyone manage to resolve this ?

 

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: