TCP port 0 reserved for what purpose

1. It is non-standard (and in fact, counter-productive) for a firewall to not allow an ACK back through the Firewall if the original SYN or Data packet that caused the ACK was permitted through. TCP Requires ACKs to even form a connection. Your Network Manager is misinformed or confused. ACK's do not pose a security risk.

2. Your next step is to prove your Firewall is receiving the initial SYN, and returning the SYN ACK. If the packet capture in your picture is captured from your Firewall, then you have sufficient proof of this fact. Specially if this capture is from the outside interface of your Firewall (the one facing the Internet)

@Karyhead made a great point that something tricky is going on with the "SSL Handshake" (it will make sense why that is in quotes when you finish reading this post).

Almost every type of SSL Handshake will always start with a Client Hello (sent from the Client), followed immediately by a Server Hello (sent by the server). Instead, your packet capture is indicating that immediately following the Three Way Handshake (these are the packets labeled [SYN] [SYN,ACK] [ACK]) the Client is sending two packets. We can learn a few things from these two packets:

• Based on the Time Delta, the 2nd packet is sent .000002 seconds after the 1st, which tells us this is not a re-transmitted packet
• The next two packets in the capture from the server include an ACK# of 156 and 173. Which means the first packet was probably 155 bytes, and the 2nd packet was probably 17 bytes. I say probably because I don't have access to the PCAP to validate definitively, and there may be some other strangeness going on. Either way, the one thing we know for sure is these first two packets from the Client were 172 bytes combined
• These are not a Client Hello. I compared to a few sample captures on my laptop, most Client Hellos were around 200+~ bytes. I didn't see any less than 200. Moreover, if it were a Client Hello, Wireshark would have interpreted it as such. Additionally, you can see in the first and second packet that the MSS gets set to 1432, which means it isn't a case of the 172 byte Client Hello having to be fragmented into two packets.
• The server sends no data to the client. You can tell because when the server sends its FIN in the 2nd to last packet, the Sequence number is just 1. Which means the only item that was sent by the Server that required an acknowledgement was the Server's "SYN" from its original "SYN/ACK". What this tells us is this is definitely not a SSL/TLS handshake. Every SSL/TLS handshake requires information from both sides of the conversation. Even an abbreviated handshake requires confirmation from both parties that they still have the necessary authentication and keying material.

Note: For the sake of this post, SSL and TLS are completely identical and can be

In the end, you are probably looking at someone tunneling data through port 443. Its impossible to tell what data it might be from just what you sent, but if that conversation came across my Firewall that was supposedly only letting SSL-encrypted-HTTP over port 443 through (aka, HTTPS), I would definitely take a closer look at the content to figure out what that might be. It could be malicious, but it could be harmless. And even if its harmless, I would want to know what is ... and why they feel they need to tunnel their traffic over TCP/443 instead of request an another application port be opened through.

Will the passive closer resend the FIN and then the active closer knows the ACK was lost?

Yes. Quoting from TCP/IP Illustrated Volume 1, in the TCP Connection Management section:

3. To complete the close, the final segment contains an ACK for the last FIN. Note that if a FIN is lost, it is retransmitted until an ACK for it is received.

There is a timeout. When in LAST_ACK, the passive closer will resend FIN when there is a timeout, assuming that it was lost. If it was indeed lost, then the active closer will eventually receive the retransmitted FIN and enter TIME_WAIT. If the FIN was not lost but the final ACK was lost, then the active closer is in TIME_WAIT and receives FIN again. When this happens - receiving a FIN in TIME_WAIT - the ACK is retransmitted.

The timeout value in TIME_WAIT is NOT used for retransmission purposes. When there is a timeout in TIME_WAIT, it is assumed that the final ACK was successfully delivered because the passive closer didn't retransmit FIN packets. So, the timeout in TIME_WAIT is just an amount of time after which we can safely assume that if the other end didn't send anything, then it's because he received the final ACK and closed the connection.