5520 Dynamic NAT question

[jcarrabine1]

I've been tracking a conversation on my firewall. I have an inside device that is trying to communicate to a server outside to send data. The conversation is suppose to be all 443. I see that there is a TCP connection made and a dynamic NAT that translates my inside device to the public IP, and appears to change the port to 65415. The problem I'm having is that the conversation ends with reset-O, and I'm wondering if that port has something to do with it, or if it's just that their server is resetting the connection because of an issue they are having? The vendor says no firewall rules are needed for this device to communicate with their server.                

[Jouni Forss]

Hi,

What I assume you are seeing is that the local IP address is translated to the "outside" interface IP address of your ASA.

So you are doing Dynamic PAT translation.

While your connections original source port on the actual host might be something like 1025 the source port visible to the Internet might be something like 65000 after the Dynamic PAT translation.

To my understanding depending on the ASA software version there might have been changes to the above. For example currently wathching my own ASAs translations tell me that the original source port is kept even after the Dynamic PAT. I would imagine if there was already overlap (on the ASA) the source port would change after the Dynamic PAT was performed.

The fact that you are seeing a TCP Reset from the remote host would seem to me point to the fact that your host can reach the remote host. I am not sure however why the TCP Reset is sent.

I cant see the Dynamic PAT being a reason that the HTTPS connection would fail. There are some other applications that really dont like Dynamic PAT but rather require Static NAT or Dynamic NAT to work properly. But I dont see HTTPS having the same problem.

You can always take some traffic captures on the connecting host or ASA.

- Jouni

[jcarrabine1]

Thanks for the reply. I've done the packet trace, and it's the same deal.

In a packet trace I see

my device contacts the remote server with a SYN

their server responds back with SYN, ACK

My device send an ACK

The window is setup

my device sends a client hello

their device sends an ACK and immediately sends a FIN, ACK in the next packet

Seem to me the lines of communication work, but maybe a certificate/PKI mismatch is happening and the server might be rejecting based on that. At any rate I'm feeling like this is an issue on their end not mine.

Thoughts?

Thanks again

[Jouni Forss]

Sadly I have very little understanding on the server/IT side of things.

After detecting what you yourself mention above I would probably already be passing the case to someone else who could confirm what was actually happening between the host and the server.

At what point does the server send the TCP Reset? Could this be that the connecting host doesnt terminate the TCP connection from its part and because of that the server eventually sends a TCP Reset?

Wouldnt the server sending FIN,ACK mean that there is indeed something wrong with the host and the server and not the connection between them?

- Jouni

[jcarrabine1]

At what point does the server send the TCP Reset? Could this be that the connecting host doesnt terminate the TCP connection from its part and because of that the server eventually sends a TCP Reset?

I believe the message on the firewall is represented as reset-O and the message in the packet trace is FIN, ACK essentially they are the same thing.

Wouldnt the server sending FIN,ACK mean that there is indeed something wrong with the host and the server and not the connection between them?

Absolutly my friend!

Sorry for wasting time. I guess my last comment is just me venting steam.

Thanks again.