Firewalls and ACKs

Question

We have a system using Windows 7 that connects to a piece of equipment directly using a crossover cable on NIC1 and it connects to the network on NIC2. It seems to communicate with everything it is supposed to just fine with the exception of one thing. The problem is a support program on the computer is supposed to communicate with the company that supports that piece of equipment over the internet. It uses three services:

1. An XMPP Service - Netstat shows it connecting
2. An RDP Service - Not connecting. I think this is initiated by the support end.
3. A Telemetry service - I don't know if this has to be initiated by support.

The support company says they can't see the computer on our end. After a lot of troubleshooting they say, it is our firewall because it isn't allowing ACK packets to come back through. This worked when it was running on Windows XP so, I really don't think that is the issue. I did try this with the Windows firewall disabled with no luck. My understanding with the following output is, ACKs are coming back through. According to our network manager ACKs aren't allowed to come back through. I can't get a packet capture on the other side of the firewall.

I get the following output (sanitized) in wireshark

I am looking for two things:

1. Firewalls are a week area for me, can someone explain to me about ACK's not being allow back through and how that works or why that is a security risk if allowed?
2. What do you suggest the next step to be?

The support company has the following in their documentation: Equipment requires outbound communication on port 443 TLS. Incoming ports don't need to be opened. IP ACK messages much be allowed back through the firewall. No VPN Required due to TSL over 443.

Addendum: I forgot to mention a couple of things. All of the packets look like they are appropriately ACK'ed in order. I think Wireshark is just calling it SSL traffic because it is using port 443. It looks more like unencrypted jabber (XMPP) traffic, so I am really confused by that. I was going to upload another screen capture of the wireshark output with all three streams in it but I think the frame numbers might confuse things. There are three streams in this capture and they all have the same data in them. There aren't any retransmits. I did a 20 minute capture that has a few in them but that was probably due to bandwidth congestion on our internet connection (time of day thing). I am going to get with the Support Company tomorrow and get them to look at what you all said. I think it will be very useful.

Answer 1

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.

Answer 2

When you say "The support company says they can't see the computer on our end" do you mean the support company is initiating traffic from their end (possibly for the RDP connection you mention earlier)? If this is the case I'm curious if the IP on the server is the same. If it has changed, the required access may need to be adjusted on the firewall to allow the connection from support to the new server IP. I still have to dive into Wireshark so I wouldn't be able to give you suggestions there. If you can browse to an HTTPS website from the server or telnet to the support IP on port 443, that would be easy confirmation that HTTPS outbound is allowed (though not exact).

By the way, for port 443, most firewalls (stateful) would allow the return traffic as long as the initiating traffic was allowed via access list rules.

Answer 3

In the pcap you provide a screenshot of, you establish a connection and then send 2 packets. Only 1 ACK is recieved. This is not abnormal as TCP uses window scaling, but in the 6th frame, it might be helpful to know what frame this is an ACK to. If you click on this frame, Wireshark has a SEQ/ACK analysis section. If this is an ACK to frame 5, then the support company has no leg to stand on. If it is an ACK to frame 4, the you might be missing the ACK to frame 5, but it is doubtful that you are blocking ACKs as you received an ACK to frame 4.

It looks like the telemetry service is HTTPS based. Based on this, it looks like a failed SSL handshake.