Capture and Analyze Traffic with Wireshark

Capture real DNS, TCP, and HTTP/HTTPS packets and map them to the OSI model.

Introduction

30 Second Summary

Every time you open a website, your computer is having dozens of invisible conversations with servers around the world. These conversations follow strict rules, use specific addresses, and travel through layers of protocols.

In this project, you will capture and analyze your own computer's live network traffic using Wireshark. You'll decode real packets layer by layer to understand exactly how your machine communicates with the internet.

What You'll Build

You'll become a "Network Detective" by investigating your own machine's network traffic with Wireshark and Windows commands, building a complete picture of how networking protocols work together.

By the end of this project, you'll have:

A Network Identity Card documenting your machine's IP address, subnet mask, default gateway, and DNS server.
Live DNS, TCP, and HTTP/HTTPS traffic captured and decoded in Wireshark, with protocols identified by port number.
A packet dissection mapping real traffic layers directly to the OSI model.
Secret Mission: Capture a full DHCP handshake (Discover, Offer, Request, Acknowledge) by releasing and renewing your IP address while Wireshark is running.

Are there any prerequisites?

You just need a Windows PC and basic familiarity with what networking is. No hands-on networking experience is required. This project will guide you through installing Wireshark and running every command from scratch.

Before We Start

Before We Start...

Install and Verify Wireshark

Every network investigation starts with the right tools. Wireshark is the industry-standard packet analyzer used by cybersecurity professionals worldwide to inspect live network traffic.

In this step, you'll install Wireshark on your Windows machine and confirm it can see your network interfaces. You'll also verify your network adapter is connected using Command Prompt.

In this step, get ready to:

Install Wireshark 4.6.6 with Npcap for live packet capture.
Identify your active network interface in Wireshark's welcome screen.
Confirm your network connectivity using ipconfig in Command Prompt.

Download and install Wireshark

Wireshark needs a companion library called Npcap to capture live packets from your network card. The Windows installer bundles Npcap automatically, so you only need one download.

Press the Windows key to open your search bar.
Type Wireshark and look at the results.

✔️ I see Wireshark 4.6.6

Wireshark is already installed. Open it from your search results and skip ahead to the next substep.

How do I check my version?

Once Wireshark opens, click Help in the menu bar, then click About Wireshark. The version number appears at the top of the dialog. If you see 4.6.6 or higher, you're good to go.

ⓧ I see an older version of Wireshark

You need version 4.6.6 or higher for this project. Older versions may use deprecated display filters and lack current Npcap support.

Open your browser and go to https://www.wireshark.org/download.html.
Under Stable Release: 4.6.6, click the Windows x64 installer link.
Run the downloaded Wireshark-4.6.6-x64.exe file.
Accept all default settings throughout the installer.
When prompted about Npcap, leave the Install Npcap checkbox checked. This replaces any older capture library you may have.
Complete the installation and open Wireshark.

What about WinPcap?

WinPcap is a deprecated capture library that older Wireshark versions used. Wireshark 4.6.6 uses Npcap instead. If the installer detects WinPcap on your system, it will prompt you to uninstall it. Follow that prompt to avoid conflicts.

ⓧ Wireshark isn't installed

Open your browser and go to https://www.wireshark.org/download.html.
Under Stable Release: 4.6.6, click the Windows x64 installer link.
Run the downloaded Wireshark-4.6.6-x64.exe file.
Accept all default settings throughout the installer. The defaults are recommended for most users.
When the installer reaches the Npcap step, leave the Install Npcap checkbox checked. Npcap is required for live packet capture.
The Npcap installer will open as a separate window during the process. Accept its default settings too, then click Install.
Once both installers complete, click Finish.

What is Npcap?

Npcap is a Windows library that gives applications like Wireshark access to raw network packets flowing through your network card. Without it, Wireshark can open saved capture files but cannot capture live traffic.

Installer blocked by Windows?

If Windows SmartScreen blocks the installer, click More info, then click Run anyway. The official Wireshark installer is signed by the Wireshark Foundation.

help me get past the Windows SmartScreen warning for Wireshark

Identify your active network interface

When Wireshark opens for the first time (without a capture running), it displays a Welcome Screen listing all available network interfaces on your machine.

Open Wireshark if it is not already open. Press the Windows key, type Wireshark, and press Enter.
Look at the list of network interfaces on the Welcome Screen. Each interface has a small sparkline graph next to its name showing live network activity.
Find the interface with a moving sparkline. This is your active interface (usually named Wi-Fi or Ethernet).

You should see at least one interface with a moving sparkline graph indicating active network traffic. This confirms that Npcap installed correctly and Wireshark can see your network card.

Why do some interfaces have flat lines?

Interfaces with flat sparklines are either disconnected or unused adapters (like Bluetooth or virtual adapters). You only need to identify the one with active traffic for this project.

No interfaces listed at all?

This means Npcap did not install correctly. Close Wireshark, re-run the Wireshark installer, and ensure the Install Npcap checkbox is checked. You may also need to restart your computer after reinstalling Npcap.

help me fix Wireshark not showing any network interfaces on Windows

Confirm your network connection with ipconfig

Now you'll use Windows Command Prompt to verify that your network adapter has an IP address assigned. This confirms your machine is actually connected to a network.

Open Command Prompt by pressing Win+R, typing cmd, and pressing Enter.
Check your network configuration by running this command:

ipconfig

You should see output listing your active adapter (Wi-Fi or Ethernet) with three key fields: IPv4 Address, Subnet Mask, and Default Gateway.

What do these fields mean?

IPv4 Address is your machine's address on the local network (often starts with 192.168 or 10.).
Subnet Mask defines which addresses are on your same local network versus remote.
Default Gateway is your router's address. All traffic leaving your local network exits through here.

Don't see an IPv4 Address?

If your active adapter shows no IPv4 Address, your machine is not connected to a network. Check that your Wi-Fi is connected or your Ethernet cable is plugged in. Run ipconfig again after reconnecting.

help me understand why ipconfig shows no IPv4 address on my adapter

Your tools are ready. Wireshark can see your network interfaces, and your machine has a confirmed IP address. Next up, you'll dig deeper into what these network numbers actually mean by building your Network Identity Card.

Build Your Network Identity Card

In Step 1, you confirmed your machine has an active network adapter and can see it in Wireshark. Now it's time to go deeper into your machine's network configuration.

Every device on a network has an identity defined by a set of addresses and settings. In this step, you'll document these settings into a "Network Identity Card" that maps out how your computer communicates with the outside world.

In this step, get ready to:

Run ipconfig /all and document your machine's four critical network fields.
Understand what private IP addresses and subnet masks mean.
Test connectivity to the internet and your own machine.

Run ipconfig /all and document your network fields

The basic ipconfig command you ran earlier showed a quick summary. The /all flag reveals the full TCP/IP configuration for every adapter on your machine, including DNS servers and DHCP status.

In your Command Prompt from the previous step, display your full network configuration by running:

ipconfig /all

Find your active adapter in the output (the same Wi-Fi or Ethernet adapter you identified in Step 1).
Document these four critical fields from your active adapter:

IPv4 Address: your machine's address on the local network.
Subnet Mask: defines which addresses are "local" vs "remote."
Default Gateway: your router, the exit point to the internet.
DNS Servers: translates domain names to IP addresses.

Also note whether DHCP Enabled says Yes or No. This tells you if your IP address was assigned automatically by your router.

You should see values for all four fields listed under your active adapter. Most home networks show DHCP Enabled as Yes.

Not seeing all four fields?

Make sure you're looking at your active adapter (Wi-Fi or Ethernet), not a disconnected one. Disconnected adapters will show blank or missing values.

If your DNS Servers field is empty, your DNS settings may be provided through your Default Gateway instead. The gateway address often doubles as the DNS server on home networks.

Help me figure out why my ipconfig /all output is missing fields

What is DHCP?

DHCP (Dynamic Host Configuration Protocol) is the protocol that automatically assigns your IP address, subnet mask, gateway, and DNS servers. When DHCP Enabled says Yes, your router handed all four settings to your machine without any manual configuration.

You'll see DHCP in action during the Secret Mission later, where you'll capture the exact handshake between your machine and router.

Understand what your IP address means

Your IPv4 Address tells you a lot about where your machine sits on the network. Certain address ranges are reserved for private (local) use only.

Check whether your IPv4 Address starts with 192.168.x.x, 10.x.x.x, or 172.16-31.x.x. If it does, it's a private IP address. This address is only visible on your local network.

Why can't the internet see my IP address?

Your router has a separate public IP address that the rest of the internet sees. Your private IP only works inside your home network. When your machine sends traffic to the internet, your router translates your private address to its public address before forwarding the packet.

This is why every device on your home network can have a 192.168.1.x address without conflicting with other networks around the world.

Now look at your Subnet Mask. If it shows 255.255.255.0, it means the first three groups of numbers (octets) identify your network, and the last octet identifies your specific device.

What does the subnet mask actually do?

Your machine uses the subnet mask to determine whether a destination address is on the local network or on a remote network. If the destination is local, the packet goes directly. If it's remote, the packet gets forwarded to the Default Gateway (your router) instead.

For example, with a subnet mask of 255.255.255.0 and your IP of 192.168.1.5, any address starting with 192.168.1.x is considered "local." Anything else gets routed through your gateway.

Test connectivity to the internet and your local machine

You've documented your network settings, but how do you know they actually work? The ping command sends a small packet to a destination and waits for a reply. It's the quickest way to confirm connectivity.

Test your internet connectivity by pinging Google's public DNS server:

ping 8.8.8.8

You should see four replies in the format Reply from 8.8.8.8: bytes=32 time=XXms TTL=XX. This confirms your machine can reach the internet through your Default Gateway.

Now test the loopback address by pinging your own machine:

ping localhost

You should see replies from 127.0.0.1 (or ::1 for IPv6). The loopback address always points to your own machine. It never leaves your network adapter.

Why ping two different targets?

Pinging 8.8.8.8 proves your traffic can leave your local network, pass through the gateway, and reach the internet. If this fails but ping localhost succeeds, you know your network adapter works but your internet connection is broken.

Security analysts use this exact layered approach to isolate where a network failure is occurring.

Seeing "Request timed out" or "Destination host unreachable"?

If ping 8.8.8.8 fails, check that your Wi-Fi or Ethernet is still connected. Look at the network icon in your Windows taskbar for a warning symbol.

Some corporate or school networks block ping traffic with a firewall. If you're on a restricted network, the rest of the project will still work because Wireshark captures packets regardless of whether ping is allowed.

Help me troubleshoot why my ping command is failing

Your Network Identity Card is complete. You now know exactly how your machine identifies itself on the network and have confirmed it can reach the internet. Next up, you'll use Wireshark to capture live DNS traffic and watch those DNS servers in action.

Investigate DNS Live

Your Network Identity Card documents the addresses your machine uses to communicate. One question remains: when you type a website name like google.com, how does your computer figure out which IP address to connect to?

That's the job of DNS (Domain Name System), which translates human-readable domain names into IP addresses. In this step, you'll use Wireshark to capture this translation happening live on your network.

In this step, get ready to:

Capture live DNS traffic using Wireshark's display filter.
Expand a DNS packet layer by layer to see the OSI model in action.
Generate multiple DNS queries and examine A and AAAA records in the responses.

Start a DNS capture

To see DNS in action, you need to tell Wireshark to start recording packets and then filter down to only DNS traffic. This keeps the display clean so you can focus on name resolution.

Switch back to Wireshark.
Double-click your active interface (the one with the moving waveform you identified in Step 1) to start capturing packets.
In the display filter bar (the green bar at the top of the window), type dns and press Enter.
The packet list should appear mostly empty or with a few background DNS requests. This filter shows only DNS traffic on port 53.

What is a display filter?

A display filter tells Wireshark to show only packets matching a specific protocol or condition. The capture is still recording everything, but your view is narrowed to just DNS packets. You can change or clear the filter at any time without losing captured data.

Now you'll generate a DNS query so Wireshark has something to show you.

Switch back to Command Prompt.
Run a DNS lookup by entering this command:

nslookup example.com

Switch back to Wireshark. You should see new DNS packets appear in the packet list.

You should see two key entries: a "Standard query" (your machine asking "what's the IP for example.com?") and a "Standard query response" (the DNS server answering with the IP address).

Not seeing any DNS packets?

Make sure you typed dns in the display filter bar (green bar), not the capture filter bar. The display filter bar is at the top of the main packet list area.
Confirm your capture is running. You should see a counter incrementing in the toolbar or title bar.
If you accidentally started the capture on the wrong interface, click the Stop toolbar button, then go back to the interface list and double-click the correct one.

Help me troubleshoot why Wireshark isn't showing DNS packets after I run nslookup.

Expand the DNS packet layers

Every packet captured by Wireshark contains multiple layers, like envelopes inside envelopes. Expanding them reveals how a DNS request travels from your network card all the way to the application level.

In the Wireshark packet list (top pane), click on one of the "Standard query" packets.
Look at the packet detail pane (the middle section of the window). You'll see a series of expandable rows, each representing a protocol layer.
Click the arrow next to Ethernet II to expand Layer 2. This shows the MAC addresses of your network card and your router.
Click the arrow next to Internet Protocol Version 4 to expand Layer 3. This shows the source IP (your machine) and destination IP (your DNS server).
Click the arrow next to User Datagram Protocol to expand Layer 4. Notice the destination port is 53.
Click the arrow next to Domain Name System (query) to expand Layer 7. This shows the actual domain name your machine asked about.

Why does DNS use UDP instead of TCP?

DNS uses UDP (User Datagram Protocol) because DNS lookups are short, simple question-and-answer exchanges. UDP skips the connection setup process that TCP requires, making it faster for quick requests.

Think of it like shouting a question across a room versus calling someone on the phone. Shouting (UDP) is faster for a single quick question. A phone call (TCP) is better when you need a long, reliable conversation.

You've just dissected a real DNS packet across four layers. Each layer adds its own addressing information to get the request from your machine to the DNS server and back.

Generate more DNS traffic and examine the responses

One DNS query is interesting, but looking at multiple queries reveals patterns. You'll see that every DNS response contains specific record types that map names to addresses.

Switch back to Command Prompt.
Run two more DNS lookups by entering these commands one at a time:

nslookup google.com

nslookup github.com

Switch back to Wireshark. You should see new DNS query and response pairs for each domain.
Click on one of the "Standard query response" packets.
In the packet detail pane, expand Domain Name System (response), then expand the Answers section.

Inside the Answers section, you'll see A records (IPv4 addresses) and possibly AAAA records (IPv6 addresses). These are the actual IP addresses that your browser would connect to when you visit that website.

What are A records and AAAA records?

An A record maps a domain name to an IPv4 address (like 142.250.80.46). An AAAA record maps a domain name to an IPv6 address (like 2607:f8b0:4004:800::200e).

Both record types serve the same purpose. They tell your machine where to find the server. IPv6 is the newer addressing system designed to handle the growing number of internet-connected devices.

Stop the capture by clicking the Stop toolbar button in Wireshark (the square icon in the toolbar), or press Ctrl+E.

Notice that every single DNS packet used port 53. This is the universally assigned port for DNS. Security analysts memorize common port numbers like this because spotting unexpected traffic on known ports is a key indicator of compromise.

Only seeing queries but no responses?

If you see query packets but no responses, your DNS server may be unreachable. Try running ping 8.8.8.8 in Command Prompt to check your internet connection.
If responses appear in Command Prompt from nslookup but not in Wireshark, confirm you're capturing on the correct interface. Your DNS traffic may be going through a different adapter.

Help me figure out why I'm seeing DNS queries but no responses in my Wireshark capture.

You've just watched DNS in action. You captured real queries leaving your machine, saw them travel over UDP on port 53, and confirmed the IP addresses that came back. Next up, you'll capture something even more interesting: the TCP 3-way handshake that establishes reliable connections.

Capture the TCP 3-Way Handshake

In the previous step, you watched DNS resolve domain names to IP addresses using quick, one-shot UDP packets. But what happens after your machine knows the IP address and needs to actually connect to a web server?

Before any real data can flow, TCP requires both sides to agree on a connection through a process called the "3-way handshake." In this step, you'll capture that handshake live and see exactly how TCP establishes a reliable connection that UDP skips entirely.

In this step, get ready to:

Capture SYN packets that start every TCP connection.
Identify the full 3-way handshake sequence (SYN, SYN-ACK, ACK) in HTTPS traffic.
Compare TCP's reliability handshake against UDP's connectionless speed.

Start a capture and filter for SYN packets

Every TCP connection begins with a SYN (synchronize) packet. By filtering for SYN packets only, you can watch connection attempts happen in real time as your browser reaches out to web servers.

In Wireshark, start a new capture on your active interface by double-clicking it in the interface list (the one with the moving waveform graph).
Click on the display filter bar (the green bar at the top of the packet list).
Type the following filter and press Enter:

tcp.flags.syn==1

What does this filter do?

This display filter tells Wireshark to show only packets that have the SYN flag set. The SYN flag is the very first signal a machine sends when it wants to open a TCP connection.

Open your web browser and navigate to https://www.example.com.
Switch back to Wireshark. You should see SYN packets appearing in the packet list.

Each SYN packet represents the first step of TCP's 3-way handshake. Your machine is saying "I want to connect" to the web server.

Not seeing any SYN packets?

Make sure the capture is running (the shark fin icon at the top left should be grayed out, and the red stop button should be active). If no packets appear, try refreshing the browser page or navigating to a different website.

Double-check your display filter is typed exactly as tcp.flags.syn==1 with no spaces around the equals signs.

Help me troubleshoot why my SYN filter isn't showing packets in Wireshark.

Identify the full 3-way handshake

The SYN filter shows only the opening move. To see the complete handshake, you need to view all TCP traffic on the HTTPS port so you can spot the SYN, SYN-ACK, and ACK sequence together.

Clear the current display filter by clicking the X button on the right side of the filter bar.
Type the following filter in the display filter bar and press Enter:

tcp.port==443

This shows all TCP traffic to and from port 443 (the HTTPS port).

Look at the very beginning of a connection in the packet list. Find three consecutive packets that form the handshake:

SYN - Your machine says "I want to connect."
SYN-ACK - The server says "OK, I acknowledge."
ACK - Your machine says "Great, we're connected."

Click on each of the three packets and look at the Info column to see the TCP flags listed (e.g., [SYN], [SYN, ACK], [ACK]).

Why does TCP need a handshake?

The 3-way handshake is what makes TCP "reliable." Both sides confirm they can send and receive before any real data flows. This means if a packet gets lost later, TCP knows to resend it.

UDP skips this process entirely. It just sends data immediately without checking if the other side is ready. That's faster, but there's no guarantee the data arrives.

Can't find the three handshake packets together?

There may be many packets in the list. Scroll to the very top of the capture to find the earliest connections. The SYN packet will have your machine's IP as the source, and the SYN-ACK will have the server's IP as the source.

You can also sort by the Time column to see packets in chronological order.

Help me find the TCP 3-way handshake in my Wireshark capture.

Compare UDP traffic to TCP

You've seen how TCP sets up a careful, reliable connection. Now look at UDP to see the opposite approach. UDP packets just go out the door with no introduction and no confirmation.

Clear the current filter by clicking the X button on the filter bar.
Type the following display filter and press Enter:

udp

Look at the UDP packets in the list. Notice there is no handshake. No SYN, no SYN-ACK, no ACK. Packets are sent immediately without establishing a connection first.
Look for DNS traffic on port 53 in the list. This is the same DNS traffic you captured in the previous step. DNS uses UDP because it's a quick question-and-answer that doesn't need reliability guarantees.

When is UDP used instead of TCP?

UDP is chosen when speed matters more than guaranteed delivery. DNS (port 53), video streaming, and online gaming all use UDP. Dropping one packet is acceptable because the next one arrives immediately.

TCP is used when every byte must arrive intact. HTTP/HTTPS (ports 80/443) and SSH (port 22) use TCP because missing data would corrupt a web page or break a remote session.

This is the core difference a cybersecurity analyst needs to understand. Attackers exploit both protocols differently.

Stop the capture by clicking the red square Stop button in the toolbar.

You should now be able to clearly see the difference between TCP and UDP. TCP has the handshake setup (SYN, SYN-ACK, ACK) before data flows. UDP has no setup at all.

Not seeing UDP packets?

Make sure the capture was still running when you applied the udp filter. If you stopped the capture earlier, the filter only searches existing packets. Try generating some DNS traffic by running nslookup example.com in Command Prompt while a new capture is running.

Help me see UDP traffic in my Wireshark capture.

You've now seen TCP's careful connection setup and UDP's speed-first approach in live traffic. Next up, you'll see why this reliability difference matters for security by comparing what HTTP exposes in plaintext versus what HTTPS encrypts.

Compare HTTP vs HTTPS

You now know how TCP builds a reliable connection with its 3-way handshake, while UDP skips straight to sending data.

But reliability is only part of the picture. What about the actual content of those packets? In this step, you'll see the critical security difference between HTTP and HTTPS. You'll observe how plaintext traffic exposes everything to anyone watching your network, while encrypted traffic hides the payload completely.

In this step, get ready to:

Capture plaintext HTTP traffic and read its contents in Wireshark.
Observe encrypted HTTPS/TLS traffic and confirm the payload is unreadable.
Use netstat -an to see all active connections and their port numbers.

Capture plaintext HTTP traffic

Most modern websites use HTTPS, which encrypts your data in transit. But some sites still serve content over plain HTTP with no encryption at all. You're about to see exactly what that means for security.

Switch back to Wireshark and start a new capture on your active interface by clicking the blue shark fin button (or pressing Ctrl+E).
In the display filter bar (the green bar at the top), type http and press Enter.
Switch to your web browser and type http://neverssl.com in the URL bar, then press Enter.

Why neverssl.com?

This site deliberately serves content over unencrypted HTTP so you can test what plaintext traffic looks like. Almost every other website now uses HTTPS by default, which would make this demonstration impossible.

Switch back to Wireshark. You should see HTTP GET requests appear in the packet list.
Click on one of the HTTP packets in the list.
In the packet detail pane (middle section), expand the Hypertext Transfer Protocol layer.
Read through the details. You can see the full URL, headers, host name, and potentially page content in plain text.

What does this show you?

Everything in this HTTP packet is completely readable. The URL you visited, the browser you used, and any data exchanged is all visible as plain text.

This is exactly what an attacker on your network could see if you browsed websites over HTTP. Anyone with Wireshark on the same network could read this traffic.

Not seeing any HTTP packets?

Make sure you typed http:// explicitly in the URL bar. Some browsers automatically upgrade to HTTPS. If your browser redirects to HTTPS, try typing the full URL http://neverssl.com/online/ instead.

Also confirm your display filter says http (not https) and the filter bar is green, not red.

Help me see HTTP packets in Wireshark

Observe encrypted TLS traffic

Now you'll see what happens when a site uses encryption. The contrast with what you just saw will be dramatic.

In Wireshark's display filter bar, clear the current filter by clicking the X button on the right side of the bar.
Type tls in the display filter bar and press Enter.
Switch to your browser and navigate to https://www.google.com.
Switch back to Wireshark. You should see TLS packets appear, including "Client Hello" and "Server Hello" messages.
Click on a TLS packet and look at the packet detail pane.

Unlike the HTTP packet you examined earlier, you cannot read the actual content. The data payload is encrypted and appears as meaningless bytes.

What is the TLS handshake?

The "Client Hello" and "Server Hello" packets are the TLS handshake. Your browser and the server are agreeing on encryption settings before any real data is sent. After this handshake, all communication is encrypted.

HTTPS uses port 443 while HTTP uses port 80. This is why firewalls and security tools monitor both ports. Traffic on port 80 is exposed. Traffic on port 443 is protected.

Not seeing TLS packets?

Make sure the display filter says tls (not ssl). Wireshark replaced the ssl filter with tls in version 3.0. Also confirm your capture is still running (the stop button should be active).

Help me find TLS packets in Wireshark

Inspect active connections with netstat

You've seen packets in Wireshark, but there's another way to check what your machine is connected to right now. The netstat command shows all active network connections and the ports they use.

Switch back to Command Prompt and run this command:

netstat -an

What does this command do?

The -a flag shows all connections and listening ports. The -n flag displays addresses and port numbers in numerical form instead of resolving hostnames.

The output has four columns: Proto (TCP or UDP), Local Address (your IP and port), Foreign Address (the remote server's IP and port), and State (the connection status).

Look through the output for entries with port 443 in the Foreign Address column. These are your active HTTPS connections.
Look for port 53 entries. These are DNS connections.
Look for port 80 entries. If you see any, those are unencrypted HTTP connections.
Check the State column for these common values:

ESTABLISHED means an active, open connection.
LISTENING means your machine is waiting for incoming connections on that port.
TIME_WAIT means a connection is in the process of closing.

Why does this matter for security?

Security analysts use netstat to check what a machine is connected to right now. Unexpected connections to unknown IP addresses on unusual ports can indicate malware or unauthorized access.

If you see connections on port 80 to addresses you don't recognize, that traffic is unencrypted and could be intercepted. Connections on port 443 are at least encrypted in transit.

Return to Wireshark and stop the capture by clicking the red square button.

Seeing too much output from netstat?

The output can be very long. Scroll through it and focus on the Foreign Address column. Look for :443, :53, or :80 at the end of addresses.

Help me read my netstat output

You've now seen the most important lesson in network security firsthand. Unencrypted HTTP exposes everything, while HTTPS keeps your data hidden from prying eyes. Next up, you'll tie all of these layers together by mapping them to the OSI model.

Map Everything to the OSI Model

You've now seen how DNS resolves names, how TCP handshakes establish connections, and how encryption protects HTTPS traffic. Each of these observations revealed different layers of network communication.

The OSI model is the framework that organizes all of these layers into a single mental map. In this step, you'll select a real packet in Wireshark and walk through each layer from physical bits to application data.

In this step, get ready to:

Map the lower four OSI layers (Physical through Transport) in a real HTTPS packet.
Identify the upper layers (Session, Presentation, Application) and where encryption fits in.
Build a common ports cheat sheet that maps ports to protocols and OSI layers.

Map the lower layers of an HTTPS packet

Every packet Wireshark captures is structured as layers stacked on top of each other. The packet detail pane (the middle section of the Wireshark window) shows you these layers from bottom to top, matching the OSI model almost perfectly.

In Wireshark, look at your most recent capture (the one from the HTTP vs HTTPS step).
Click on any packet that shows port 443 in the Info column (these are your HTTPS packets).
In the packet detail pane (middle section), you'll see a stack of expandable rows. Click the arrow next to each row to expand it.
Expand Frame at the top. This is Layer 1 (Physical). It shows raw information about the bits on the wire.
Expand Ethernet II. This is Layer 2 (Data Link). It shows the MAC addresses of your network card (NIC) and your router.
Expand Internet Protocol Version 4. This is Layer 3 (Network). It shows the source and destination IP addresses that handle routing.
Expand Transmission Control Protocol. This is Layer 4 (Transport). It shows port numbers, sequence numbers, and flags that provide reliable delivery.

What is the OSI model?

The OSI (Open Systems Interconnection) model splits network communication into 7 layers, each with a specific job. Layer 1 deals with raw electrical signals. Layer 7 deals with the application you're using.

The key insight is that Wireshark shows you the OSI model visually. Every packet is layers within layers, and you're reading them right now.

What do these layers mean?

Frame (Layer 1, Physical): The raw bits transmitted on the wire or wireless signal.
Ethernet II (Layer 2, Data Link): MAC addresses that identify your NIC talking directly to your router.
Internet Protocol v4 (Layer 3, Network): Source and destination IP addresses that handle routing across networks.
Transmission Control Protocol (Layer 4, Transport): Ports, reliable delivery through acknowledgments, and sequencing.

Identify the upper layers and encryption

The upper layers of the OSI model (5 through 7) are where your application data lives. For encrypted traffic, TLS adds a security layer before the application data reaches the other side.

In the same HTTPS packet, look below the Transmission Control Protocol row.
If you selected a TLS handshake packet (Client Hello or Server Hello), expand Transport Layer Security. This operates between Layers 5 and 6, providing encryption before application data.
Notice that you cannot read the actual payload. The data is encrypted. Compare this to what you saw with HTTP traffic at neverssl.com earlier, where you could read the full content.
For an unencrypted HTTP packet, you would see Hypertext Transfer Protocol as the top layer (Layer 7, Application). This shows readable URLs, headers, and content.

Where do Layers 5, 6, and 7 fit?

In the real world, Layers 5 (Session), 6 (Presentation), and 7 (Application) often blend together. TLS handles encryption at what maps roughly to Layers 5-6. The application protocol (HTTP, DNS, SSH) sits at Layer 7.

Wireshark shows you this visually. Each row in the packet detail pane is one layer of the OSI model, stacked from bottom (Physical) to top (Application).

You should now see a clear mapping between the rows in Wireshark's packet detail pane and the OSI model layers. Frame at the top corresponds to Layer 1, and each row below adds a higher layer.

Don't see Transport Layer Security in the packet?

Not every HTTPS packet shows the TLS layer expanded. Try clicking on a packet that says "Client Hello" or "Server Hello" in the Info column. These are the TLS handshake packets where the layer is most visible.

If your capture doesn't have any TLS packets, you may need to look at the capture from the previous step when you visited https://www.google.com.

Still stuck? Help me find a TLS handshake packet in my Wireshark capture so I can see the Transport Layer Security row in the packet detail pane.

Build your common ports cheat sheet

Every security tool, firewall rule, and intrusion detection system relies on knowing which port numbers map to which protocols. You've already seen several of these ports in action throughout this project.

Review the common ports you've encountered. Match each one to what you observed in your captures:

Port 22: SSH (Layer 7). Encrypted remote access to servers.
Port 53: DNS (Layer 7). Name resolution. Uses UDP because it's a quick question-and-answer.
Port 80: HTTP (Layer 7). Unencrypted web traffic. You saw readable content at neverssl.com.
Port 443: HTTPS (Layer 7). Encrypted web traffic via TLS. You saw unreadable payloads.
Port 67/68: DHCP (Layer 7). Automatic IP address assignment. Uses UDP.

Why do these ports matter for cybersecurity?

Firewalls block or allow traffic based on port numbers. Intrusion detection systems flag unusual activity on specific ports. If you see traffic on port 22 from an unknown source, that could be an unauthorized SSH attempt.

Knowing these port-to-protocol mappings lets you read firewall rules, understand network logs, and spot suspicious connections instantly.

TCP vs UDP at the port level

Notice that ports 80 and 443 use TCP (reliable delivery matters for web pages), while port 53 (DNS) and ports 67/68 (DHCP) use UDP (speed matters more than guaranteed delivery). The protocol choice at Layer 4 depends on what the application at Layer 7 needs.

Secret mission

Capture a DHCP Handshake (DORA)

Ever wonder how your computer magically gets an IP address when you connect to Wi-Fi? There's a 4-step conversation happening behind the scenes between your machine and your router. In this secret mission, you'll capture that entire conversation live.

Clean Up Your Resources

This project runs entirely locally on your machine, so there are no ongoing costs or cloud resources to worry about. Decide whether to keep Wireshark installed for future projects, or remove it entirely.

Resources you used:

Wireshark 4.6.6 (packet capture application).
Npcap (network capture driver installed with Wireshark).
Any saved capture files (.pcapng) from your sessions.

Keep everything running

No action needed. Choose this if you plan to continue learning packet analysis or want Wireshark available for future cybersecurity projects.

Wireshark stays installed and ready to capture at any time.
Npcap remains active as a network driver. It uses negligible system resources when not capturing.
Your capture files remain wherever Wireshark saved them (check your Documents folder or the last directory you saved to).

Pause - I'll come back to this later

Close Wireshark to free up memory. Your installation stays in place for next time.

Close Wireshark if it is still open.
Close any open Command Prompt windows.
Your saved capture files and Wireshark settings will remain intact for when you return.

Delete - I don't want to use this again

Remove all project resources from your machine. Follow these steps to uninstall everything cleanly.

Close Wireshark completely before uninstalling.
Open Settings on your Windows machine.
Select Apps, then Installed Apps (Windows 11) or Apps & features (Windows 10).
Find Wireshark in the list, click it, and select Uninstall.
In the uninstaller, check the boxes to also remove plugins and personal settings if you want a clean removal.
After Wireshark is removed, return to the apps list and find Npcap. Select it and click Uninstall to remove the network capture driver.
Delete any saved capture files (.pcapng) from your Documents folder or wherever you saved them during the project.

Nice Work!

Congratulations, Network Detective. You've completed a hands-on investigation of real network traffic using the same tool that cybersecurity professionals rely on every day.

You've learned how to:

Captured live DNS queries, TCP handshakes, and HTTP/HTTPS traffic in Wireshark, identifying protocols by their port numbers (53, 80, 443).
Built a Network Identity Card documenting your IP address, subnet mask, default gateway, and DNS server.
Mapped Wireshark's packet layers directly to the OSI model, seeing how each layer (Ethernet, IP, TCP/UDP, Application) stacks together in real traffic.
Captured a full DHCP DORA handshake (Discover, Offer, Request, Acknowledge) showing how your machine gets its IP configuration automatically.

Ready to quiz yourself?