If you are looking for practical, hands-on Wireshark training that takes you from installation to advanced troubleshooting, this guide is written for you. In this Wireshark training I walk you through how I use Wireshark day to day, explain the key concepts you must know, and provide step-by-step workflows and examples you can run immediately. Expect detailed explanations of capture filters, display filters, loopback captures, VPN troubleshooting, sessions and streams, TCP three-way handshakes, sequence number calculations, and best practices that save you time when working on real incidents. 

Outline 

• Why Wireshark matters and what libraries power it 

• Installation essentials and NPCAP: why the loopback matters 

• Choosing the right interface and using the interface graph 

• Capture filters versus display filters: when and how to use each 

• BPF capture examples and practical capture commands 

• Loopback interface explained with a practical Python example 

• VPN troubleshooting: what you can and cannot see 

• Proxy behavior and duplicated loopback packets 

• Sessions, conversations and how to analyze them 

• Stream IDs, following streams and filtering specific sessions 

• TCP flags, SYN packets and identifying first packets 

• Sequence numbers, raw vs relative sequence, and calculations 

• Importance of capturing the three-way handshake 

• Practical capture and analysis checklist 

• Common filters cheat sheet and examples 

• Advanced tips, pitfalls to avoid and interview tips 

Why Wireshark matters 

Wireshark is the industry standard open source packet analyzer. Many networking and security tools output PCAPs in formats compatible with Wireshark, and Wireshark uses libpcap and tcpdump libraries under the hood to interpret raw packet bytes. Because it is open source and widely accepted, Wireshark is integrated into a lot of vendor tools and workflows. In my Wireshark training I stress that the tool helps you turn hex output into human readable protocol conversations so you can answer questions like: 

• Is the client actually sending the packet? 

• What payload left the host and was it encrypted? 

• Did the TCP three-way handshake complete? 

• Which session is causing most of the traffic? 

These are the core questions you will learn to answer reliably when you practice packet capture and analysis. 

Installing Wireshark and configuring NPCAP 

Installation is straightforward, but there are two important options you must know: 

1. Install NPCAP: Essential if you want to capture loopback traffic (traffic generated and consumed on the same machine). If NPCAP is not installed, you will miss internal communications that never hit the physical NIC. 

2. USBPCAP: Optional. Useful if you need USB traffic capture, but not required for most network troubleshooting. 

When you run the Wireshark installer on Windows you will be prompted to install NPCAP. Make sure it is checked. Without NPCAP you will not capture 127.0.0.1 traffic and troubleshooting local services, VPN client behavior, or proxy behavior can become confusing. 

Installation steps I recommend during this Wireshark training: 

1. Download the latest stable Wireshark installer from the official site. 

2. Run the installer and ensure NPCAP is selected. 

3. Finish installation, then open Wireshark and confirm you see loopback and physical adapters in the interface list. 

Choosing the right interface and using the interface graph 

When you open Wireshark you are presented with a list of interfaces. Each interface has a small traffic graph so you can quickly identify which adapter is active. If your laptop is on Wi-Fi you will see packet flow on the Wi-Fi graph and little or no traffic on the wired LAN adapter. Capture on the interface that shows activity. 

Why this matters: capturing on the wrong interface will give you no useful packets, or a flood of irrelevant traffic. Use the graph as your hint and then confirm by taking a short capture. 

Capture filters vs display filters: master both 

Understanding the difference between capture filters and display filters is fundamental. I emphasize this early in my Wireshark training because using the wrong filter at the wrong time can either cause you to miss critical data or force you to sift through thousands of unrelated packets. 

• Capture filters: Applied before packets are written to disk. These use the libpcap/tcpdump syntax (BPF syntax). Example: host 192.168.1.12 or port 8080 or tcp port 443. Capture filters reduce the PCAP size and are essential when you need to limit captures on busy interfaces or when you must capture only traffic to/from a host or port. 

• Display filters: Applied after capture, inside Wireshark. These use Wireshark filter syntax like ip.addr == 192.168.1.12 or tcp.port == 80 or tcp.flags.syn == 1. Display filters are more expressive and allow you to inspect traffic interactively without discarding packets. 

Rule of thumb from this Wireshark training: use capture filters to reduce noise when you are confident about source/destination/port; use display filters to explore a full capture. 

BPF capture examples and practical capture commands 

Capture filters use BPF syntax. Here are practical examples you will rely on during real troubleshooting and in this Wireshark training: 

• Capture traffic to or from a host: host 192.168.1.12 

• Capture traffic for a specific TCP or UDP port: tcp port 80 or udp port 53 

• Capture traffic between two hosts: host 192.168.1.12 and host 10.0.0.5 

• Capture traffic from a single source: src host 10.0.0.5 

• Capture traffic to a single destination: dst host 10.0.0.5 

Use these capture filters when you want a BPF or directed capture. If you need bi-directional capture for a host, simply use host X and it will capture both incoming and outgoing packets for that address. 

Loopback interface: what it is and why it matters 

The loopback interface is the internal software interface with IP 127.0.0.1. Applications communicate with the loopback first before the packets are handed to the physical network adapter. If your application and server are running on the same host, the packets never reach the physical interface unless specifically configured to do so. 

Why you need loopback captures in your Wireshark training toolkit: 

• To confirm the application created the packet before encryption or tunneling by a VPN client. 

• To debug local server-client issues when both are on the same machine (for example when testing an HTTP server on port 8080). 

• To understand proxy behavior and why you may see duplicate packets in captures. 

Practical example: local HTTP server and loopback capture 

Try this quick exercise to see loopback behavior: 

1. Start a simple HTTP server on your machine. For example, on a machine with Python installed run: python -m http.server 8080 

2. Open Wireshark and capture on the Wi-Fi interface with capture filter port 8080. Now connect to 127.0.0.1:8080 using a browser. You will see the request succeed, but you will not see the packets on the Wi-Fi capture because they never hit the physical adapter. 

3. Stop the Wi-Fi capture and start a new capture on the loopback interface (requires NPCAP on Windows). 

4. Repeat the request to 127.0.0.1:8080 and observe the HTTP GET and response on the loopback capture. 

This demonstrates clearly why NPCAP and loopback captures are required for internal communications and VPN troubleshooting scenarios. 

Using loopback captures for VPN troubleshooting 

VPNs (SSL VPN, IPsec, GRE, etc.) encrypt traffic before leaving the host. If a user reports that they are connected to the VPN but cannot reach a server, the troubleshooting path is: 

1. Confirm the application actually sent the packet by capturing on loopback. If no packet exists on loopback, the problem is the application itself or local configuration. 

2. If loopback shows the packet, capture on the VPN interface to see the encrypted payload and encapsulation (you will typically see ESP or SSL encapsulated packets). You will not be able to see the inner application payload unless you decrypt the tunnel. 

3. Capture on the physical interface and on upstream devices like routers or firewalls to confirm whether the encrypted packets left the host and whether the remote peer replied. 

If you capture on the firewall and do not see the encrypted packets from the client, but you see them on loopback and VPN interface, then the issue might be on the host or locally on the NIC. If you see the packets on the client and on the firewall but no reply from the remote peer, the issue is upstream. Also keep in mind some packet loss may occur due to interface drops or buffer overflow; this is why capturing at multiple places is required. 

Proxy servers and duplicated loopback packets 

When a proxy is involved, you may see the same session represented twice in captures: once on the loopback (internal application to proxy) and once between the proxy and the destination. For example, explicit or implicit proxies often accept an application request on loopback and then make a separate connection to the external server. This duplication is normal: 

• Loopback shows internal traffic between the app and proxy (127.0.0.1 source/destination). 

• Physical interface shows traffic between the proxy and the external server. 

Do not be confused by this. When analyzing proxy-related problems, focus on the correct leg of the communication you intend to troubleshoot and ignore the loopback leg if your interest is the external connection. 

Encrypted VPN traffic: what you will and will not see 

When a packet is encrypted, you will still see protocol headers of the encapsulating protocol, such as ESP or SSL, but not the inner application payload. Example: 

• Client sends HTTP to 10.0.0.5; the VPN client encrypts that and sends ESP packets to the VPN gateway. You will see ESP packets on the physical and VPN interface but you will not see the original HTTP content unless you decrypt the tunnel. 

• To prove whether the app sent the packet, use loopback capture to inspect the unencrypted local traffic before encryption. 

So the sequence is always: inspect loopback to confirm generation, inspect VPN interface to confirm encapsulation, inspect physical/remote devices to confirm delivery. 

Sessions and conversations: identifying unique streams 

Wireshark groups traffic into sessions or conversations based on tuple values. A session is uniquely identified by: 

• Source IP 

• Source port 

• Destination IP 

• Destination port 

• Protocol number (for example TCP protocol number 6, UDP 17, ICMP 1) 

Understanding sessions is important because a single session can contain thousands of packets. In Wireshark go to Statistics -> Conversations to see all conversation entries at layer 2, layer 3, and layer 4. Conversations shows you the number of packets and bytes for each session and lets you sort by packet count or bytes to quickly find the top talkers in a capture. 

When I run Wireshark in a lab and get 20,000 packets, the first thing I do is open Conversations and sort by packet or byte count. This quickly reveals which session is responsible for the majority of traffic and narrows the scope for analysis. 

Stream IDs, following streams, and applying filters 

Each TCP session will have a stream ID in Wireshark. You can use that stream ID to filter all packets belonging to the same session. Right-click a packet and choose "Follow" -> "TCP Stream" or "Apply as Filter" to build a display filter such as tcp.stream == 0. Alternatives include building filters manually like ip.addr == X and tcp.port == Y. 

When you follow a TCP stream, Wireshark can display the payload in a human readable format showing the full request and response sequence for the stream. This is invaluable for application-level troubleshooting. 

Display filter examples you will use every day in this Wireshark training 

• ip.addr == 192.168.1.12  (show packets where either source or destination match) 

• tcp.port == 443  (show packets where source or destination port is 443) 

• tcp.stream == 0  (show all packets in stream 0) 

• tcp.flags.syn == 1  (show SYN packets) 

• tcp.flags.ack == 1 && tcp.flags.syn == 0  (show ACKs that are not SYN) 

• http  (show HTTP protocol packets) 

Tip: Right-click a field in the packet details pane and choose "Apply as Filter" or "Apply as Column" to build filters without memorizing syntax. This is one of the fastest ways to learn filters and save time in production troubleshooting. 

TCP flags, SYN packets and identifying the first packet of a session 

To find the first packet of a TCP session, look for the SYN packet that has only the SYN flag set and not the ACK flag. The SYN packet is usually the first packet initiated by the client. Use a display filter like tcp.flags.syn == 1 and tcp.flags.ack == 0 to isolate SYN-only packets. Those represent session initiations. 

When a PCB does not contain the three-way handshake, it can make the capture unreliable for some types of analysis. For example, initial TCP options such as window size and MSS (maximum segment size) are negotiated during handshake. Without that handshake you cannot reliably calculate relative windows and do some congestion diagnostics. 

Sequence numbers: relative vs raw and how to calculate the next sequence

Wireshark displays two kinds of sequence numbers: 

• Relative sequence numbers: starts at 0 for each stream, useful for simple arithmetic when calculating bytes transmitted during a session. 

• Raw sequence numbers: actual 32-bit sequence numbers used on the wire. These are large and not convenient for quick math, but necessary when correlating packets across captures or when working with retransmissions that reference raw values. 

Best practice: enable both sequence and acknowledgement columns in Wireshark. To do this right-click the sequence number field and choose "Apply as Column", then do the same for the acknowledgement field. This helps you compute bytes sent and received without guessing. 

How to calculate the next sequence number 

The next expected sequence number = current sequence number + payload length (number of data bytes carried in the TCP segment). For example, if you see sequence number 1000 and the packet contains 150 bytes of TCP payload, the next expected sequence will be 1150. Wireshark can compute this for you and shows sequence and next sequence values where needed. 

When you see gaps in sequence numbers, it usually indicates missing packets in your capture or that you started capturing mid-session and therefore missed earlier bytes. That is why I stress capturing the three-way handshake in Wireshark training: it anchors the stream and avoids raw sequence confusion. 

The three-way handshake and why capturing it matters 

TCP connection establishment uses a three-way handshake: SYN, SYN-ACK, ACK. During this handshake the following are negotiated or established: 

• Initial sequence numbers 

• MSS (maximum segment size) 

• Window scaling options 

• Other TCP options like selective acknowledgment

If your capture misses the handshake you will not see the negotiated values. This can make subsequent window size and retransmission analysis unreliable because you do not know the initial window scaling factor or MSS. In my Wireshark training I always ask students to ensure they capture from before the handshake begins whenever possible. 

Practical workflow: how I approach a troubleshooting capture 

When I get a packet capture problem, I follow a repeatable workflow. You can use this checklist during live incidents: 

1. Ask the user for the context: which machine, which time window, what action they were performing, service or port numbers. 

2. Confirm whether the issue is local or remote. If local, ask for a loopback capture on the affected host. If remote, ask for captures on the host and on the next-hop device (router/firewall). 

3. Collect captures with NPCAP enabled where appropriate and ensure the three-way handshake is captured. If necessary, reproduce the issue while capturing to ensure completeness. 

4. Start with a broad capture then narrow down using capture filters where you are confident. For initial exploration use a full capture and then use display filters (ip.addr, tcp.port, tcp.stream) to narrow your view. 

5. Open Statistics -> Conversations and sort by packet and byte counts to find top talkers and the most active session IDs. 

6. Right-click a packet from an interesting session and choose Follow -> TCP Stream to inspect the full exchange for that session. 

7. Verify handshake, sequence numbers, retransmissions, and TCP window scaling. Apply filters like tcp.flags.syn == 1 to find SYN packets or tcp.analysis.retransmission to reveal retransmits. 

8. If a VPN is involved, capture on loopback and on the VPN interface to verify application behavior and encapsulation, then capture on physical interfaces and upstream devices to verify delivery. 

9. When you need to prove the application generated a packet, use loopback. When you need to prove the packet left the machine, use the physical or VPN interface capture. 

Common filters and a cheat sheet you will use in interviews 

Below is a compact cheat sheet that I use in Wireshark training and when mentoring engineers who are preparing for interviews. Memorize these examples and understand the difference between the two filter syntaxes. 

• Capture filter syntax (BPF/tcpdump): 

• host 192.168.1.12 

• tcp port 80 

• udp port 53 

• src host 10.0.0.1 and dst host 10.0.0.2 

• Display filter syntax (Wireshark): 

• ip.addr == 192.168.1.12 

• tcp.port == 443 

• tcp.flags.syn == 1 

• tcp.stream == 3 

• tcp.analysis.retransmission 

Examples you will get asked to write on the fly in interviews: 

• Show only HTTP traffic from a host: ip.addr == 192.168.1.12 and http 

• Show only SYN packets initiating connections: tcp.flags.syn == 1 and tcp.flags.ack == 0 

• Filter by stream: tcp.stream == 5 

• Show only encrypted tunnel traffic types: esp or ssl 

Advanced tips and common pitfalls 

Here are practical tips that I teach in my Wireshark training sessions to avoid common mistakes: 

• Always check you captured the three-way handshake. If not, request another capture or reproduce the issue. 

• Install NPCAP on Windows when you need loopback captures. Forgetting NPCAP is the most common installation mistake. 

• Use capture filters when you cannot afford a large PCAP. Use display filters when you need full context and can store the capture. 

• Right-click fields and use “Apply as Filter” and “Apply as Column” to build filters fast and avoid syntax errors. 

• When seeing duplicate packets in a capture, confirm whether one of the duplicates is loopback traffic or proxy-mediated traffic. 127.0.0.1 packets can often be ignored when analyzing external connectivity. 

• If you suspect interface drops, capture on both sides of the interface and compare. If packet disappears on an upstream device, you might be seeing an interface buffer drop, route issues or ACL drops. 

• When dealing with encrypted VPN traffic, remember you will see ESP or SSL packets on the wire. Use loopback captures to verify the inner payload before encryption. 

Troubleshooting examples you will practice in this Wireshark training 

Here are two concrete scenarios I walk students through that illustrate the concepts above. 

Scenario 1: User connected to VPN but cannot reach the internal server 

1. Ask the user to reproduce the issue and capture on loopback. If no packet appears on the loopback, the problem is at the application level. 

2. If the loopback capture has the unencrypted request, capture on the VPN interface. You should see encrypted traffic such as SSL or ESP. That shows encapsulation is happening. 

3. Capture on the physical interface or firewall to verify the encrypted packets reach the VPN gateway. If the firewall capture shows the encrypted packets, but the gateway does not reply, escalate to the VPN gateway team. 

4. If you see the encrypted packets on the client but not on the firewall, check routing, interface configuration, or hardware buffer drops on the client machine NIC. 

Scenario 2: Slow uploads but downloads are fine 

1. Capture the session and open Statistics -> Conversations. Sort by bytes per second or packet count to identify asymmetric throughput. 

2. Follow the TCP stream to observe one-way throughput. Use TCP graph tools in Wireshark or compute through the bits per second statistics shown in Conversations to confirm the asymmetry. 

3. Check for retransmissions (tcp.analysis.retransmission), window size issues (tcp.window_size), and mismatched MSS values negotiated during handshake. 

4. Verify you captured the three-way handshake for window scale and MSS negotiation. If handshake is missing, ask for a new capture capturing from the start of the session. 

Interview tips and real-world expectations 

For mid-level roles (five to seven years), expect to be asked about capture techniques, filters, and real troubleshooting scenarios. Interviewers often test whether you: 

• Know the difference between capture filters and display filters 

• Understand when to capture loopback traffic and why NPCAP is required 

• Can interpret TCP three-way handshake, window size, MSS, and sequence numbers 

• Can use Statistics -> Conversations to find top talkers and analyze sessions 

• Can calculate next sequence numbers and explain retransmission causes 

Practice is the key. Use small labs to generate traffic, run Python simple HTTP server, or spin up containers to reproduce issues and capture traffic. Hands-on practice solving real problems is the best preparation for both interviews and production troubleshooting. 

Common filter examples to memorize 

Here is a compact list to memorize as part of your Wireshark training routine. These will be helpful in exams, interviews, and production: 

• Capture filter: host 192.168.1.12 

• Capture filter: tcp port 443 

• Display filter: ip.addr == 192.168.1.12 

• Display filter: tcp.port == 80 

• Display filter: tcp.flags.syn == 1 and tcp.flags.ack == 0 

• Display filter: tcp.stream == X 

• Display filter: tcp.analysis.retransmission 

• Display filter: http or dns or ssl or esp 

Wrap up and final recommendations 

In this Wireshark training I have tried to condense years of practical experience into a clear, repeatable workflow. The key takeaways are: 

• Install NPCAP for loopback captures and always confirm you are on the correct interface. 

• Use capture filters to limit PCAP size and display filters to analyze captured data. 

• Always try to capture the three-way handshake for reliable TCP analysis. 

• Use Statistics -> Conversations and stream follow to quickly identify problem sessions. 

• For VPN and proxy issues, use loopback captures to verify the application generated packets and then trace the packet through the VPN and physical interfaces. 

If you follow the workflows outlined here and practice the examples I gave, your ability to troubleshoot network issues using Wireshark will improve dramatically. Keep practicing, build a set of reproducible lab scenarios, and use the cheat sheet of filters until the syntax becomes second nature. 

Next steps for continued learning 

Practice these exercises to build confidence after you finish this Wireshark training: 

1. Set up a simple HTTP server with Python and capture loopback and physical interface traffic to see the difference. 

2. Configure a local proxy and observe duplicated sessions on loopback and external interfaces. 

3. Create a small VPN lab or use a client VPN to observe encrypted packets and practice correlating loopback, VPN interface, and firewall captures. 

4. Capture long sessions and use Conversations to find the top talker and analyze throughput. 

5. Practice identifying SYN packets, calculating next sequence numbers, and analyzing retransmissions and window scaling. 

Use this guide as a reference during your daily troubleshooting and as a study companion for interviews. The more hands-on captures you analyze, the faster you will become comfortable with the tools and patterns. Keep capturing, keep filtering, and keep practicing. 

Good luck with your Wireshark training and real-world troubleshooting. If you follow the techniques outlined here you will be able to diagnose and resolve network and application problems faster and with more confidence.