2

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

enter image description here

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.

2
  • 1
    Some observations. TCP handshake completes successfully. The next thing that should happen is an SSL handshake. The client sends its Hello, which I will assume are pkts 4 and 5. The server's TCP ACKs this data and then should send its Hello. Instead it closes the connection with a FIN. Considering that there's no real delay (deltas are sub-millisecond), I doubt packets are getting dropped and the connection is closed due to timeout. Either the client isn't sending a proper SSL Hello or the server doesn't like the Hello. Either way the server closes the connection. – karyhead Mar 7 '15 at 0:10
  • @karyhead brings up great points. A bit more info: Typically the first two messages in the SSL Handshake are a Client Hello and a Server Hello. These two messages typically don't contain much data, so its very rare that you would need to packets to send the same set of data. After the Win7 box sends two packets, the RemoteSupport backs "ACKs" 156 and 173, which means the initial two packets were only 172 bytes. Most Client Hellos are around 200~ -- this was definitely not a Client Hello so large that it must have been sent in two packets. Your capture is not a regular TLS handshake. – Eddie Mar 9 '15 at 5:29
2
  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.

2
  • To this end, perhaps he could provide more details about those two packets by expanding the Secure Socket Layer session. New handshakes have sizes of 268 bytes or less - probably because they do not have a session ID. I think the resumed sessions are larger. The traffic does get identified by Wireshark as SSL, which is interesting. – James Shewey Mar 10 '15 at 4:20
  • After diving into it further, I think it is an XMPP request over port 443. There is no XMPP response from the server that I can tell. I believe SSL traffic is supposed be taking place at some point but is hard to say without a packet capture on the other side of the firewall. One of the things I forgot to add, the capture was taken using a tap on the cable coming out of the Windows 7 computer. It is very difficult for me to get approval for a packet capture outside of the firewall. So, I don't know if the response is getting blocked. – Rafe Mar 11 '15 at 17:51
1

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.

0

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.

7
  • Hi James, welcome to Network Engineering SE. Just wanted to point out that Selective ACK (SACK) would not come in to play here. SACK allows a speaker to selectively acknowledge what data it has received (in order to communicate the data it has not received). TCP without SACK would mean I could only Acknowledge the last continuous sequence# that I have received. To put simplified numbers to it, if I receive 0-100, don't receive 101, then receive 102-200, regular TCP would "ACK 101" and the sender would resend 101-200. Whereas SACK would allow me to communicate that I only missed 101. – Eddie Mar 9 '15 at 5:22
  • Eddie, you are right! I was mixing SACKs with TCP window scaling, which are two very distinct topics. I have updated my answer to reflect this. – James Shewey Mar 9 '15 at 6:00
  • Hi James. I actually think you were confusing it with Delayed Acknowledgements. =) – Eddie Mar 9 '15 at 6:55
  • Good info Eddie, thanks! Am I mistaken, or is that not a component of Window scaling? (From your link - "Delayed ACKs can give the application the opportunity to update the TCP receive window and also possibly to send an immediate response along with the ACK.") – James Shewey Mar 9 '15 at 7:12
  • The TCP Window size can be updated in any/every ACK packet. Whether I'm sending an ACK after every received packet or every other packet (which Delayed Acknowledgement does), in both cases I have "the opportunity to updated the TCP receive window". The point the link is probably trying to make is that delayed Acknowledgement sends an ACK every two packets so that the window can still be updated relatively "quickly" -- as compared to every 20 or 30 packets. Window Scaling itself simply identifies that the window size can change dynamically mid conversation. – Eddie Mar 9 '15 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.