cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2529
Views
15
Helpful
10
Replies

Multiple hosts show as down, TLS?

ozorgnax1
Level 1
Level 1

I am having a problem with multiple hosts being marked as down, with more coming approximately once a week.

It is very annoying for my users and reflects badly upon me, as an admin and advocate for us needing this product.

 

What will happen is:

1. Sent mails will stay in the queue and not get sent. If I don't do anything, users will get a mail after 3 days with message too old.

Looking in the ESA I see the hosts as down. (screenshot 1)

Cli tells me this:

hoststatus tinsillo.com

Host mail status for: 'tinsillo.com'
Status as of: Mon Mar 30 10:43:06 2020 -02
Host up/down: down

Counters:
Queue
Soft Bounced Events 0
Completion
Completed Recipients 0
Hard Bounced Recipients 0
DNS Hard Bounces 0
5XX Hard Bounces 0
Filter Hard Bounces 0
Expired Hard Bounces 0
Other Hard Bounces 0
Delivered Recipients 0
Deleted Recipients 0

Gauges:
Queue
Active Recipients 1
Unattempted Recipients 1
Attempted Recipients 0
Connections
Current Outbound Connections 0
Pending Outbound Connections 0

Oldest Message 10 hours 42 mins 53 secs
Last Activity Mon Mar 30 10:21:36 2020 -02
Ordered IP addresses: (expiring at Mon Mar 30 17:03:20 2020 -02)
Preference IPs
5 23.106.125.178

MX Records:
Preference TTL Hostname
5 6h20m13s mail.tinsillo.com

 

I have allowed all encryption algorithms in ssl settings, as I suspect a mismatch in algorithms.

 

If I go to ESA -> Mail policies -> destination controls -> and set TLS to none

The hoststatus changes to UP and mails go through.

 

I do not think it is optimal to manually whitelist domains like this, and having to disable TLS is even worse.

 

Can you please help me to diagnose and fix this? 

1 Accepted Solution

Accepted Solutions

Not everyone supports TLS on inbound mail



1. Go back and set your ciphers to something sane...

I use MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:!IDEA:@STRENGTH

With TLS 1.0, 1.1 and 1.2 enabled.

2. In Destination controls set the default TLS support to PREFERRED. It will TRY TLS, but if it can't do it, the mail will go unencrypted.

3. If you have sites that MUST be encrypted, set those up as required.





The other way you could do it, I set your default to Requried, and then set entries for sites like this one where it set to preferred...



But I think you'll go a little crazy chasing down all of the sites that don't do TLS.






View solution in original post

10 Replies 10

ppreenja
Cisco Employee
Cisco Employee
Hello ozorgnax1,

If the status for any domain is shown as "down" which can be due to any network issue and upon changing the option in destination control of TLS to None resolves the same then the issue can be due to TLS.

Firstly, I would request you to change the option of TLS from "Required" to "Preferred" so that in case the TLS connection is not formed then the connection is made to the destination on the plain text instead (similar to None).

Secondly, to troubleshoot any issue with the destination, the best method will be to take a packet capture on the ESA appliance towards the destination mx records IP.

You can run a packet capture on the appliance during communication to show the complete connection and handshake, and associated issues that may be causing the connection to be interrupted.
++++++++++++++++++++++++++
If you need help getting the packet capture, kindly follow these steps (GUI):
Go to "Help and Support " >> Packet Capture.
Click on "edit settings."
Under "Filters" choose "Predefined Filters".
Type the sender's ip address in the "server ip" field.
Click "submit".
Click "start capture".
Ask the sender to send a test email
After finishing click "finish".
Select the capture and click "download file".
++++++++++++++++++++++++++

I hope the above helps.

Cheers,
Pratham


My default action is preferred, so nothing is tls required.

 

I sadly can't easily packet capture as I am on CES.

 

If your default is preferred and it keeps seeing this site down on connection to this site until you turn TLS off, you will have to get TAC involved.




Not everyone supports TLS on inbound mail



1. Go back and set your ciphers to something sane...

I use MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:!IDEA:@STRENGTH

With TLS 1.0, 1.1 and 1.2 enabled.

2. In Destination controls set the default TLS support to PREFERRED. It will TRY TLS, but if it can't do it, the mail will go unencrypted.

3. If you have sites that MUST be encrypted, set those up as required.





The other way you could do it, I set your default to Requried, and then set entries for sites like this one where it set to preferred...



But I think you'll go a little crazy chasing down all of the sites that don't do TLS.






but will the algos matter if it set to default preferred?

I mean if they dont agree shouldnt it just go to no tls?

Yes... Which is why at TAC call is probably warranted. Assuming you can try that site and see that their mail server is up (telnet to it on port 25), but the cloud ESAs see it as down, you need TAC to get into your boxes and figure out why.




do you know which log to grep for tls negotiations?

It's in the mail log.

I'm not sure what you can do in CES, but more detail would be in the SMTP conversation logs, if you can turn it on.




After setting algos to your suggestion, testing one of the hosts succeded with prefer.

I am now suspecting it to be one of those problems where one algo will fail and the parts are unable to renegotiate and standoff instead.

I will test further later.

Yes all of my problem domains are now at hoststatus up and receiving mail.

Until further I hope this has resolved my problem, though I hate having to implement a workaround without a smoking gun.