SF21VUS Case Study – PacketBomb

SF21VUS Case Study

Now let's put it all together and apply what you've learned to a real life case study.

Problem statement:

A remote desktop user gets disconnected from the server. The server is hosted and not in our control.

First, we need to Define the Problem and narrow down the issue

  1. Is this the only application with the problem?

    Yes

  2. What are the specifics of the issue - just broken or is it slow sometimes?

    Just broken. Randomly disconnects

  3. Is there an error message?

    No error message

  4. When did the problem start?

    Issue was first reported 3 weeks ago

  5. Has anything changed?

    Not that we're aware of, either on the client machine or network. The client machine was a new install but that was 6 months before the issue was reported

  6. Last patch update?

    2 weeks ago but problem was happening before that

  7. When does it happen?

    Randomly. Could happen 4 times in an hour or twice over two days

  8. Does it affect multiple people?

    Three people are connecting to the server via RDC, but only one person has the problem

  9. What are the differences in the work flow or behavior in these 3 people?

    The one with the problem uses RDC much more often than the other two.

  10. Client OS?

    Windows 7 x64 Professional

  11. Server OS?

    Windows 7 x64 Professional

  12. What devices are in our network path?

    Client -> Netgear GS724T-> HP ProCurve 1800-24G -> Cisco ASA 5510 -> Comcast modem

  13. What are the client and server IPs?

    Client: 192.168.108.186     Server: 13.181.233.82

Capturing the data - In this case, you have run Wireshark on the problematic client's machine until there was a disconnect. You did not use a capture filter. The disconnect occurred about 2:50pmEDT

Download the pcap

Verify the data - Make sure the data captured covers the time of the disconnect and that you see traffic between the client and server. Hint (highlight the following text with your mouse): Go to Statistics -> Summary. Make sure the captured time range covers the issue at 2:50pmET a

Wireshark Setup - Make sure you've configured Wireshark to your liking. Refer to the Wireshark Setup lesson.

Analysis - Highlight the hidden text after the word "Hint" to see a hint

  1. Find the beginning of the connections between the client and server. Hint: Add filter for SYN packets to the client and server filter: (ip.addr eq 192.168.108.186 and ip.addr eq 13.181.233.82) and tcp.flags==2 
  2. Look at each connection to see if you can find a problem. Hint: Apply a TCP conversation filter on each SYN packet one by one to look at each conversation. Right click -> Conversation filter -> TCP. Look at the end of each connection to see how it closes
  3. What looks like a problem and what might be a normal window close? Hint: Most connections have no outstanding data in flight and the client closes the connection with a RST. The problematic connection appears to have packet loss and the client gives up and RSTs the connection. Does this problem correspond with the time of the issue? Problem connection: (ip.addr eq 192.168.108.186 and ip.addr eq 13.181.233.82) and (tcp.port eq 56770 and tcp.port eq 3389)
  4. What do you notice about when the retransmissions start? Hint: Look at delay of the original segment that gets retransmitted later - frame 34997. It appears there's a long delay just before the data is lost. Since this is RDC, it could be the user doing something else e.g. using another application outside the RDC connection, getting coffee, talking with someone, etc
  5. What's another test you could do to determine if the host is unresponsive or these packets are just not getting through? Hint: Run a continuous ping to see if the host also stops responding to ping. Add icmp as a display filter to the filter string and see if the host stopped responding to pings during the retransmissions. Filter: ((ip.addr eq 192.168.108.186 and ip.addr eq 13.181.233.82) and (tcp.port eq 56770 and tcp.port eq 3389)) or icmp
  6. What's a possible next step? Hint: Look at the logs of the ASA for dropped packets for this traffic. Take a capture either on the ASA or on the outside interface to see if the packets are getting dropped there. If the traffic is getting through, then need to follow up with the hosting provider

My Analysis - Before you watch this video, do the analysis yourself. Answer the questions above. Once you do that, follow along with the video