TCP Reset issue, possibly with ASA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-26-2017 07:26 AM - edited 03-12-2019 02:25 AM
Community,
I am experiencing a strange issue that I will do my best to explain. Our company is moving to using Mailgun as our email relay provider. Mailgun has given us a FQDN of api.mailgun.net to send the emails to. This FQDN has a "revolving" DNS where when the FQDN is queried, DNS can return a dozen or more different public IP addresses. The issue were seeing is that randomly, the TCP connection between our internal Mail Transfer Agent (MTA) and the Mailgun servers will fail. This causes our MTA to query again for the next address, which will also fail. Eventually it will reach a Mailgun server that will pick up the connection.
Where the process is failing is during the TCP 3 way handshake. Running a packet capture on the ASA (5545x), I found that when our MTA (10.120.113.233) sends a [SYN] packet, a [RST,ACK] packet is getting immediately sent back to our MTA with a source address of the Mailgun servers public IP address. This failure can occur many times in a row from different mailgun servers. Its not just the same servers either, in one round the TCP connection can fail and the next it will work going to the same Mailgun server. Ive attached for reference some screen captures of the wireshark pcap file taken from the ASA that was snooping this transaction. Mailgun states that we are the only customer having this issue.
My question is this: Can the ASA send TCP reset commands on behalf of the destination? That would be spoofing right? Im not aware of a situation where the ASA would spoof the destination address like that, making it look like the Reset came from the destination when in reality it came from the ASA. I have read that the ASA can send TCP resets, but not with the source address of the original destination address.
I have asked Mailgun whether or not they can confirm that their servers are actually sourcing the Reset commands but they state that they run everything out of AWS and don't have that kind of visibility.
Any help insights you can lend on this would be helpful. Ive attahced a couple of PNG files for reference. Thanks!
Chris.
- Labels:
-
NGFW Firewalls
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-05-2017 12:58 PM
It was found that this was the issue:
https://supportforums.cisco.com/document/66011/using-hostnames-dns-access-lists-configuration-steps-caveats-and-troubleshooting
Namely the section "Sites returning DNS responses with low TTL cause unpredictable access"
Im still not sure why the wireshark was showing the TCP Reset being sent but its possible the ASA was sending this as a means of killing the connection after it dropped the traffic.
