Traffic Capture Lab
[Link] & Network Overview
For this lab, I designed and deployed a segmented network environment using Cisco CML.
The core backbone consists of a Cisco ASAv Firewall acting as the central gateway, DHCP
server, and NAT device. A Layer 2 switch handles the segmentation, splitting the network
into three VLANs:
VLAN 10 (Client 1): General access client
VLAN 20 (Client 2): General access client in a separate subnet
VLAN 30 (Client 3): Traffic capture VLAN
To ensure connectivity between VLAN 10 and VLAN 20 (which sit at the same security level
on the firewall, VLAN 30 is configured with a higher security level of 70), I configured the
same-security-traffic permit inter-interface command. Finally, I configured a SPAN (Switched
Port Analyzer) session on the switch to mirror traffic from the uplink trunk to the traffic
capture machine in VLAN 30.
[Link] Configuration
Layer 2 Segmentation (Switch Configuration)
My first step was creating separate VLANs on this switch. I then configured SW1 to tag
frames for the different VLANs on trunk port.
Trunking: I configured interface e0/0 (connected to the Firewall) as a trunk to carry
traffic for all VLANS 10, 20 and 30.
Access Ports:
o e0/1 assigned to VLAN 10.
o e0/2 assigned to VLAN 20.
o e0/3 assigned to VLAN 30.
SPAN (Port Mirroring) Configuration
To capture all traffic on the trunk link, I configured a local SPAN session on Switch 1. As
verified by the show monitor session all command above, the source interface is set to
Et0/0, which is the uplink trunk connecting the switch to the ASAv firewall. I configured the
session to monitor traffic in both directions (incoming and outgoing) to capture all traffic on
this trunk link.
The destination interface is Et0/3, which connects directly to the monitoring VM (Kali-30). I
also configured the Encapsulation: Replicate setting. Since Et0/0 is a trunk link carrying
traffic for different VLANs, this setting tells the switch to preserve the 802.1Q VLAN tags in
the mirrored packets. This allows me to easily distinguish between VLAN 10 and VLAN 20
traffic when analysing the traffic capture in Wireshark.
Firewall Interfaces & Routing (Inter-VLAN)
Instead of using a physical router, I used the ASAv for "Router on a Stick" functionality. I
created sub-interfaces on the firewall's GigabitEthernet0/0 interface.
Interface G0/0.10: Assigned IP [Link] (Gateway for VLAN 10)
Interface G0/0.20: Assigned IP [Link] (Gateway for VLAN20)
Interface G0/0.30: Assigned IP [Link] (Gateway for VLAN30)
Interface G0/1: Connected to our NAT node to allow internet connectivity to our end
points
DHCP Services
To automate IP assignment, I configured the ASAv as a DHCP server. I created three distinct
pools so devices would automatically pick up an IP in their respective subnets.
NAT Configuration
To allow the VMs to reach the internet, I configured Dynamic Network Object NAT. This
translates the private internal IPs (192.168.x.x) to the single public IP of the firewall's outside
interface.
3. Packet Analysis
A. TCP Three-Way Handshake
To ensure reliable communication, TCP uses a three-step process to establish a connection
before any data is sent. I captured a standard ssh connection request to identify this process.
The Process:
1. SYN (Synchronize): The client (Kali-10) sends the initial packet with the SYN flag set.
This tells the server, "I want to talk, and here is my Initial Sequence Number (ISN)."
2. SYN/ACK (Synchronize + Acknowledge): The destination (Kali-20) replies. It sets the
ACK flag to acknowledge the client's sequence number and sets the SYN flag to
provide its own sequence number.
3. ACK (Acknowledge): The client replies one last time with the ACK flag, confirming it
received the server's sequence number. The connection is now "ESTABLISHED"
Identification: I identified these packets as belonging to the same conversation by filtering
for the specific TCP Stream index in Wireshark. You can clearly see the Sequence numbers
incrementing logically (Relative Seq: 0 -> 1)
TCP Options Observed:
In the screenshot above, I captured the initial SYN packet (Frame 8) of the conversation. This
is the most critical packet for option negotiation, as the client proposes its capabilities to the
server.
By expanding the Options field in Wireshark (20 bytes total), I identified the following
negotiated parameters:
1. Maximum Segment Size (MSS): 1460 bytes The client is requesting an MSS of 1460
bytes. This is the standard configuration for Ethernet networks, calculated by taking
the standard MTU (1500 bytes) and subtracting the IP header (20 bytes) and TCP
header (20 bytes).
2. SACK Permitted (Selective Acknowledgment): The SACK Permitted flag is present,
indicating that this client supports selective acknowledgments. This allows the
receiver to acknowledge non-contiguous blocks of data, which significantly improves
performance if packets are lost during transmission.
3. Window Scale: 7 (Multiply by 128): This option allows the TCP window size to
exceed the traditional 65,535-byte limit. A shift count of 7 means the actual window
size will be the header value multiplied by 2^7 (128). This is essential for modern
high-speed networks to maximize throughput.
4. Timestamps: The timestamp option is active (TSval is set, TSecr is 0 because this is
the first packet). This enables the hosts to calculate Round Trip Time (RTT) accurately
for every packet and protects against wrapped sequence numbers (PAWS).
B. TCP Four-Way Teardown
In the screenshot above, I captured the termination of an SSH session (Port 22) between the
client ([Link]) and the server ([Link]). Because TCP is a full-duplex protocol,
meaning data can flow in both directions independently, each side must close its
transmission path separately. This results in a four-step process known as the 'Four-Way
Handshake' or 'Teardown.'
Detailed Packet Breakdown:
1. Step 1: Initiation (Packet 123)
o Source: [Link]
o Flags: FIN, ACK
o Analysis: The client decides it has no more data to send. It sends a packet
with the FIN (Finish) flag set. Note that it also keeps the ACK flag set to
acknowledge the last bit of data it received. This initiates the 'Active Close'
2. Step 2: Acknowledgment (Packet 124)
o Source: [Link]
o Flags: ACK
o Analysis: The server receives the termination request and immediately sends
an ACK. At this specific moment, the connection is in a state known as Half-
Closed. The client (.10.11) cannot send any more payload data, but it can still
receive data if the server (.20.10) had anything left to say.
3. Step 3: Server Closure (Packet 125)
o Source: [Link]
o Flags: FIN, ACK
o Analysis: Once the server finishes its own tasks, it sends its own FIN flag to
the client. This is the server saying, 'I am also done sending data now.'
4. Step 4: Final Closure (Packet 126)
o Source: [Link]
o Flags: ACK
o Analysis: The client acknowledges the server's FIN request. Once this final
ACK is sent, the connection is fully dismantled, and the socket resources on
both VMs are released.
Observation on Sequence Numbers: It is worth noting that a FIN flag consumes one logical
sequence number. In Packet 123, the Sequence number is 1933. In the reply (Packet 125),
the Acknowledgement number is 1934. This confirms that the receiver processed the FIN
correctly.
C. TTL and MAC Address Analysis
This section demonstrates how packet headers change as traffic moves through a routed
network. I traced ICMP packets traveling from Kali-10 (Source) to Kali-20 (Destination),
passing through the ASAv (Gateway).
The Capture Points
Capture 1: Source (Kali-10)
TTL: 64
Source MAC: 52:54:00:b2:1d:3c (Kali-10's actual MAC)
Dest MAC: 52:54:00:19:c1:94 (ASAv Gateway MAC)
Display Filter Used: [Link]==1
Capture 2: Destination (Kali-20)
TTL: 64
Source MAC: 52:54:00:19:c1:94 (ASAv Gateway Interface for VLAN 20)
Dest MAC: 52:54:00:01:46:75 (Kali-20's actual MAC)
Display Filter Used: [Link]==1
Capture 3: SPAN (Mirror) Port
Analysis of the Trunk Link Traffic: The capture taken from the SPAN port on the trunk link
provides the most technical insight into how the ASAv handles traffic between zones. Unlike
the individual client captures, this view allows us to see the routing process happen in real-
time.
As shown in the two screenshots above, I captured the exact same ICMP Echo Request
(Sequence 1) twice. This occurred because the traffic had to travel up to the firewall to be
routed, and then down back to the switch to reach the destination.
1. The 802.1Q VLAN Tags: This capture validates that the trunking configuration is working
correctly.
In the first screenshot (Frame 164): We see the packet arriving from the source
client. The 802.1Q Virtual LAN header clearly identifies this traffic as belonging to ID:
10.
In the second screenshot (Frame 165): We see the packet immediately after the
firewall has processed it. The firewall has re-tagged the frame with ID: 20 so the
switch knows to forward it to the destination VLAN.
2. MAC Address Rewrite (Layer 2 Routing): These images also illustrate why MAC addresses
differ between capture points. The MAC address is a Layer 2 header, which is stripped and
rewritten at every hop (router/firewall).
Incoming (VLAN 10): The Destination MAC ends in c1:94. This is the firewall's
physical interface. The client is addressing the gateway.
Outgoing (VLAN 20): The Source MAC is now c1:94. The firewall has now become the
sender. It has rewritten the Layer 2 header, placing its own MAC as the source and
the target Kali-20's MAC as the destination.
TTL (Time-To-Live) Analysis
Explanation of the Field: In the capture above, I monitored an ICMP traffic exchange
between my internal client ([Link]) and an external server ([Link]). This allows us to
analyze the Time-To-Live (TTL) field in the IP header, which serves as a safety mechanism to
prevent packets from circulating endlessly in a network loop.
Each time a packet passes through a router (or Layer 3 hop), the router decreases the TTL
value by 1. If the TTL reaches 0, the packet is discarded, and an ICMP 'Time Exceeded'
message is sent back to the source. This mechanism exists to prevent packets from looping
endlessly in a network; if the TTL hits 0, the packet is discarded.
Observation of Values: By comparing the Request (Frame 258) and the Reply (Frame 259),
we can see that the TTL is determined by the sending device's operating system default, not
the network path itself.
1. Outbound Packet (Frame 258):
o Source: Kali Linux ([Link])
o TTL Value: 64
o Analysis: My local VM generated this packet. Linux-based operating systems
typically default their initial TTL to 64. Since this packet was captured at the
source (or the very first switch hop), the value remains at its maximum
default.
2. Inbound Packet (Frame 259):
o Source: External Server ([Link])
o TTL Value: 128
o Analysis: This is the reply coming from the remote destination. The fact that
the TTL is different (128) confirms that the remote device is using a different
OS or configuration (Windows systems and many Cisco devices often default
to 128).