cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1846
Views
0
Helpful
2
Replies

Proper TLS Config for IronPort C170

kmartin472
Level 1
Level 1

I inherited an infrastructure a little bit ago that uses an IronPort C170 cluster for email security. I have been tasked with configuring TLS connections with our new medical benefits provider and have some issues doing so. We have 3 MX records, let's call them mail1, mail2 and mail3. Mail1 and mail2 are configured normally on our firewall to pass SMTP traffic on port 25 to the MailListener port on the IronPort which is 25. Mail3, however, is configured on the firewall to translate SMTP traffic on port 25 to port 3600 which is sent to the TLS Listener port 3600 on the IronPort. The IronPort MailInterfaces are configured as such (25,3600) Reverse configuration on the firewall takes any port 3600 traffic from the IronPort and translates it to port 25 traffic for the rest of the world.

I configured the IronPort with a new Sender Group named TLS_ACCEPT,  added all the medical provider domain names/IPs to it and assigned it to  the ACCEPTED Mail Flow Policy where TLS is set to Required. Likewise,  for outgoing, I specified the same domain names/IPs within the  Destination Controls to require TLS for sending purposes.

I replaced the guy who originally configured this so I am not too sure how it is setup on the other end for TLS connections already established. We do have a few in place that are active. I am assuming that the other end is configured to send email only to the mail3 MX record. This configuration, however, is not possible with our medical provider so I need an alternative. They have verified that they cannot contact us on mail1 or mail2 via TLS but can with mail3.

The obvious problem is if a sender from these new domains tries to send TLS_required emails to us over the mail1 and mail2 MX IPs, they will receive an NDR. If I configure the firewall to translate mail1 and mail2 incoming connections from port 25 to 3600, any email sent with TLS not prefered/required will get an NDR. This was actually tested and domains like Yahoo and Hotmail could not send to us.

Are there any options for me on the IronPort to allow these connections to be sent from all our MX IPs without having to translate the ports? If not, what would happen if I changed the TLS Listener port on the IronPort to 25 instead of 3600 and disabled all the NAT rules on the firewall for mail3? I am only to assume this translation was another security step added by the previous admin here but am not too sure what would happen if I eliminated it.

Any advice, help, questions, assistance or fun-poking would be greatly appreciated!! Thank you in advance!

2 Replies 2

Kevin,

OMG there's so much unneeded complication here...You can totally ditch the port translation

Here's what I did:

Under Network/IP interfaces, I have 3 interfaces:  managment, Public, Private.

     Public is exposed to the net, only port 25 allowed in/out, with 1 A  record for a Domain1 which I have a certificate for.

Under Network/Listener I have 2 Listeners: 

     Outbound on the Private interface not really relavent for the rest of this discussion

     Inbound on the Public interface

          listening on port 25

          using an Accept query pointed at my Active Directory (all the various email domains in 1 AD)

          using a cert that matches the hostname on the Public interface

          Mail flow polices in HAT all set to TLS preferred with an address list configed for the "required" ones

Mail Policies/Destination Controls to force sending as TLS

In my external DNS

     Domain1

          A  mail.domain1.com  x.x.x.

          mx domain1.com  mail.domain1.com pref 10 weight 10 TTL 86400

     Domain2-10

          mx domain2.com mail.domain1.com

          mx domain3.com mail.domain1.com

     etc....

Hope that helps...

Ken    

Thank you, Ken. I would consider this config if it was a new deployment. This situation, however, has been resolved by having the other party configure their end to send to our 3rd MX record only.