Learning Network Traffic Analysis with Wireshark: My First Practical Investigation

A hands-on networking exercise exploring DNS, TLS, TCP, IP addressing and network conversations.
Introduction
Understanding how devices communicate across a network is an important skill in networking and cybersecurity.
For my second practical technical challenge, I installed Wireshark, an open-source network protocol analyzer, and used it to inspect traffic generated by my own computer over Wi-Fi.
The objective was to move beyond networking theory and understand what happens when devices communicate.
This was a learning exercise involving ordinary network activity, not an investigation of a confirmed cyberattack.

Lab environment
Component Details
Operating system Windows 11
Tool Wireshark
Network interface Wi-Fi
Capture duration Approximately 30 seconds
Initial packets captured 145
I selected my active Wi-Fi interface and started a live packet capture.

1. Understanding DNS traffic
I began by applying the Wireshark display filter:
dns
The filter returned two packets representing a DNS query and response.
The query contained:
• A domain name being requested.
• Record type A.
• DNS class IN.
The response returned two IPv4 addresses.
This demonstrated how DNS translates domain names into IP addresses that devices can use to communicate.
What I learned: DNS analysis can help an analyst understand which domains a device attempts to resolve and correlate those domains with returned IP addresses.

2. Examining TLS traffic
Next, I applied:
tls
I observed 40 TLS packets:
TLS observation Packets
Client Hello 1
Server Hello 1
Application Data 34
Other TLS packets 4
Total 40
Client Hello begins the TLS handshake by communicating supported connection parameters.
Server Hello responds with the server's selected parameters.
Application Data represents encrypted application communication.
What I learned: Even when application data is encrypted, network analysts can still examine useful metadata and handshake information. Encryption protects content, but it does not make all network activity invisible.

3. Understanding TCP connection establishment
I used this display filter:
tcp.flags.syn == 1
I observed two packets:
• SYN
• SYN-ACK
These represent the first two stages of the TCP three-way handshake.
The normal sequence is:

1. SYN — the client requests a connection.
2. SYN-ACK — the server acknowledges the request.
3. ACK — the client acknowledges the server's response. This helped me understand how TCP establishes reliable connections before data exchange.

4. Distinguishing private and public IP addresses
I applied the filter:
ip
I examined several source and destination address pairs.
This helped me distinguish private IPv4 addressing from public IPv4 addressing.
The key lesson was that a packet's source and destination fields help establish the direction of communication and identify the network endpoints involved.
For privacy, I have not included the actual IP addresses from my local capture in this article.

5. Analyzing endpoints
I navigated to:
Statistics → Endpoints → IPv4
The endpoint statistics showed that my own computer's local IPv4 address had the highest observed packet count, with 45 packets.
An endpoint provides statistics about an individual network address.
This is useful when investigating which hosts are most active in a capture.

6. Analyzing TCP conversations
I then navigated to:
Statistics → Conversations → TCP
My capture contained 15 TCP conversations.
The conversation with the highest observed packet count involved my computer and an external IP address, with 28 packets.
This introduced an important distinction:
• Endpoints provide statistics about individual network addresses.
• Conversations provide statistics about communication between pairs of endpoints.
This distinction is useful when moving from individual packet inspection to understanding communication between devices.

7. Investigating TCP resets
Finally, I applied:
tcp.flags.reset == 1
Wireshark returned no packets.
This meant no TCP reset packets were observed in this capture.
It does not prove that resets never occur on the network or that the network is secure. It is simply an observation limited to the captured traffic.

Key lessons
Through this practical exercise, I developed an introductory understanding of:
• Live packet capture using Wireshark.
• DNS queries and responses.
• TLS handshakes and encrypted application data.
• TCP connection establishment.
• Private and public IPv4 addressing.
• Endpoint statistics.
• TCP conversation analysis.
• TCP reset investigation.
• Evidence-based network investigation.
One particularly important lesson was that unusual traffic does not automatically mean malicious activity. An analyst must examine the context, identify the source, understand the communication patterns and gather supporting evidence before drawing conclusions.

Limitations
This exercise used a short capture of approximately 30 seconds containing 145 packets.
It was not a full network security assessment, penetration test or confirmed incident investigation.
The absence of TCP reset packets does not establish that the network is secure. Similarly, packet counts alone cannot establish malicious behavior.
Further investigation using longer captures, traffic baselines and additional network monitoring tools would be necessary for deeper analysis.

Conclusion
This challenge gave me practical experience using Wireshark to understand network communication.
Rather than just learning what DNS, TLS and TCP mean theoretically, I was able to observe their behavior in actual network traffic.
I am continuing to build practical skills across networking, cybersecurity, artificial intelligence and software engineering.

Tools used: Wireshark, Windows 11.
GitHub portfolio: OJO Cybersecurity Journey

This article documents a personal educational exercise. No unauthorized network access or interception was performed.