On 7/15/2012 9:53 AM, Ryan Pugatch wrote: > There is an ASA firewall in the office > and an ASA firewall in the new datacenter.
Upon seeing this I thought "Aha!" Then I read: > No esmtp fixup though. That "fixup" is often the cause of such goofy problems. Nonetheless, it is a good idea to eliminate any other ASA special sauce as the problem. To do this create a 1:1 TCP 25 PAT mapping between the public and RFC1918 IP addresses on both ASAs. This should allow SMTP packets in both directions to pass unmolested by all other ASA features, including the SPI engine, SMTP proxy, rate limiters, etc, etc. It's been a few years since I worked with PIX/ASA, so some things may have changed. I.e. creating a 1:1 PAT/NAT may not automatically bypass other features. Read you ASA documentation. > We run the network all the way up to the border routers talking BGP with > our providers so we have a good level of control. IME, CPE end point routers typically don't exchange BGP updates with upstream routers as this can be a recipe for disaster. Static routes are typical, and reliable. Even if you have 2 links to two providers for redundancy, BGP usually isn't used. BGP may or may not be part of the problem, but I wouldn't assume it's not. For instance, if your local routing table is FUBAR'd due to a BGP problem, and say you're doing real-time round-robin fanning of outbound packets from the office router across both provider links, half your packets may go to an upstream router which simply drops the packets due to having no route to the destination or an intermediate router in the packet header. If this occurs, the kernel TCP stack on your MX server in the datacenter will never be able to reassemble the TCP packet sequence. This may explain why you see packets arriving at the MX host but Postfix never responding. Although, an initial SMTP connection packet should be easily contained within a single TCP packet, so the scenario above may not be applicable. Still, given the apparent complexity of this network setup, I'd leave no stone unturned in the packet path. Work with your providers and do and end-to-end trace of an SMTP session from source workstation doing the submitting to the MX/outbound in the datacenter. If the same systems worked fine before the switchover, logic would dictate the source of the problem is in the parts that have changed or been added. > I am just uncertain of > what could be doing this at this point. It seems clear the problem lay somewhere in or between the ASAs/routers. > Thank you for your response. You're welcome. Sorry I can't give you a pinpoint answer. If I could, simply based on this email exchange, I'd be much in demand, and wealthy. ;) -- Stan
