I have an odd problem that so far Cisco has not been able to resolve. We are in the process of migrating from AT&T fiber to Comcast Business Fiber. All DNS records have been moved over. We currently have both links up. The ASA configuration is setup for tracking (redundancy). All of our outbound traffic is going through the Comcast link (default route) and most of our incoming traffic via DNS has been setup to the new external IP configured on the secondary up-link for Comcast.
Here is the problem: When I change our MX records from AT&T to Comcast; messages are delayed. Often times 5-10 times longer than using the AT&T link. On several occasions, the messages are delayed so much, that the sender server drops the connection. We have a 15 minute timeout configured on the IronPort (ESA C170). but that is the same configuration used by AT&T.
At first, the thought was a config problem on our ASA (55xx series). However, after hours of support from the ASA team, it was determined not to be a problem with the ASA. Later as a confirmation, I changed the Comcast IP route to bypass the C170 and emails flow as expected (omit spam detection).
The ESA simply listens to port 25 traffic, checks for spam and viruses and then pass that information to Exchange 2010.
Been working with the ESA team for nearly 2 weeks and they cannot seem to find a problem. But again, if I bypass the ESA, there are no issues. The ASA has been configured so that SMTP traffic has priority and confirmed that Port 25 is open.
What I have done currently is leave our production SMTP (MX) records pointing to our AT&T IP, and configured a temporary domain (xxxxxx.COM) to point to our Comcast IP. I configured both Exchange and the Ironport to accept messages from that domain. I have followed message tracking over and over again, tried and review packet captures and provide every possible log to Cisco. What I am seeing is that the message(s) stop at the point where it is retrieving the message header. For example, I have one message that the connection was accepted at 1333hours, it matched SBRS, was accepted via the TLS Protocol. The message connection continues and the last line before the delay is the incoming connection added the recipients email address. After that, there is nearly a 12 minutes delay until the next item which is the message ID header. With my test domain, the message will eventually be received and forwarded on to our exchange server. The later steps taking just seconds.
If I used one of our production domains, messages are dropped. Those same messages, the message tracking does not record a subject line (by way of the message headers).
Can anyone shine a light on why this is occurring? I can provide any logs, captures or message tracking details you may need. I just need to get this resolved.
Email sent from say Live.com (Microsoft Hotmail Servers) to our ATT IP through our ASA firewall then through the IronPort; that email arrives on time.
Email sent with an attachment from Live.com (Microsoft Hotmail Servers) to our ATT IP through our ASA firewall then through the IronPort; that email arrives on time.
Email sent from Live.com (Microsoft Hotmail Servers) to our Comcast IP through our ASA firewall then through the IronPort; that email arrives on time.
Email sent with an attachment from Live.com (Microsoft Hotmail Servers) to our Comcast IP through our ASA firewall then through the IronPort; that email is delayed.
Email sent with an attachment from Live.com (Microsoft Hotmail Servers) to our Comcast IP through our ASA firewall bypassing the IronPort; that email arrives on time.
The tests messages with attachments vary from 1MB-3MB. The Max message size is 50MB. Our ATT connection is 15Mbps. Our Comcast connection is 50Mbs. Other than the ESA, there is no other gear between the ASA and our Exchange servers.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...