4.1 Starting a capture

1. Open Wireshark.
2. Select the network interface that carries internet/VPN traffic (e.g. Ethernet, Wi-Fi, or eth0).
3. Click Start capturing packets.

4.2 Capture filters (optional but recommended)

Set these before clicking Start, to limit capture to RDP traffic:

• Default RDP port with no specific IP:
  • $tcp port 3389$
• Between customer and a specific RDP server:
  • $host X.X.X.X and host Y.Y.Y.Y and tcp port 3389$
• Custom RDP port:
  • $tcp port <custom_port>$

You can set this in Capture → Options → Capture Filter or in the capture filter box on the main screen.

6.1 Check that SYN packets leave the client

On the customer machine:

1. Filter:
   • $ip.dst == Y.Y.Y.Y and tcp.port == 3389$
2. Attempt to connect via RDP.
3. Look for TCP handshake:
   • Client sends SYN: $tcp.flags.syn == 1 and tcp.flags.ack == 0$
   • Server should respond with SYN/ACK: $tcp.flags.syn == 1 and tcp.flags.ack == 1$
   • Client completes with ACK.

Interpretation:

• No SYN from client at all:

  • RDP client misconfigured (wrong IP/port).
  • Local firewall blocking outbound RDP.
  • Routing issue on customer LAN/VPN.

• SYN sent, no SYN/ACK from server:

  • Likely firewall or routing block between customer and our hosting.
  • RDP service may not be listening on the expected IP/port.

6.2 Check from server side

On the RDP server (or closest host):

1. Filter:
   • $ip.src == X.X.X.X and ip.dst == Y.Y.Y.Y and tcp.port == 3389$
   • Or simply $tcp.port == 3389$ and look for sessions from customer IP.
2. Attempt to connect from customer.
3. See whether server receives the SYN:
   • If server never sees the SYN:
     • Routing/firewall between customer and server is blocking traffic.
   • If server sees SYN but immediately sends RST:
     • Filter: $tcp.flags.reset == 1$.
     • RDP service may be disabled or port not open.
     • Local firewall on server may be configured to reject.

6.3 ICMP errors (blocked / unreachable)

On either side, filter:

• $icmp$

Look for:

• $icmp.type == 3$ (Destination Unreachable)
• Codes:
  • Port unreachable: likely RDP service not listening.
  • Host/network unreachable: routing issue.
  • Admin prohibited: firewall policy blocking RDP.

7.1 Look for TCP resets

Filter:

• $ip.addr == X.X.X.X and ip.addr == Y.Y.Y.Y and tcp.port == 3389$
• $tcp.flags.reset == 1$

Interpretation:

• Reset from server to client:

  • Server-side firewall/IPS closing the connection.
  • Idle timeout on VPN/firewall.
  • Server OS terminating session (resource issues or policy).

• Reset from client to server:

  • Local client firewall/AV closing connection.
  • Client network stack issues (VPN drops, interface reset).

Check packet timing:

• If the RST appears after a period of inactivity:
  • Likely timeout on a security device or VPN.
• If RST appears immediately after some error:
  • Look at previous packets for TLS or network errors.

7.2 Check for packet loss and retransmissions

Filter:

• $ip.addr == X.X.X.X and ip.addr == Y.Y.Y.Y and tcp.port == 3389 and (tcp.analysis.retransmission or tcp.analysis.lost_segment)$

Frequent retransmissions indicate:

• Packet loss on path (ISP, VPN, Wi-Fi).
• Congestion causing drops.
• Problem on customer’s local network (especially Wi-Fi).

When retransmissions are severe, the TCP session can stall and may eventually be reset, causing RDP to drop.

8.1 Check latency (RTT)

1. Filter:
   • $ip.addr == X.X.X.X and ip.addr == Y.Y.Y.Y and tcp.port == 3389$
2. Use:
   • “Statistics → TCP Stream Graphs → Round Trip Time Graph”
3. Select the RDP TCP stream between customer and server.

Interpretation:

• Consistently high RTT (e.g. more than 150150–200200 ms):
  • Expected latency if customer is geographically distant or on a slow link.
• Spikes in RTT (variable latency):
  • Network instability (flapping connection, Wi-Fi interference, VPN issues).

8.2 Check retransmissions and throughput

Filter:

• $tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.lost_segment$

High retransmissions plus high RTT produce visible lag in RDP.

Additionally, examine:

• “Statistics → Conversations → TCP”
  • Look at bytes transferred, packets, and duration.
• If throughput is very low despite good RTT:
  • Possible bandwidth shaping or QoS restrictions.
  • Check if other traffic is saturating the link.

9.1 Expected sequence for a healthy connection

From client:

1. SYN (to Y.Y.Y.Y:3389Y.Y.Y.Y:3389).
2. SYN/ACK from server.
3. ACK from client.
4. RDP negotiation packets (Client Hello, etc.).

If you never see SYN/ACK, or see ICMP “admin prohibited”:

• Customer firewall or ISP blocking outbound RDP.
• Our perimeter firewall blocking inbound RDP.
• Wrong NAT/VPN configuration.

9.2 Asymmetric behavior between sides

Compare captures:

• On client side: SYNs sent, no responses.
• On server side: no incoming SYN from that customer IP.

Conclusion:

• Traffic is being dropped somewhere in between (usually firewall or routing).
• Provide capture evidence for network team:
  • Client pcap: shows SYN leaving.
  • Server pcap: shows no corresponding SYN arriving.