DEV Community: Khalif AL Mahmud

Building a Personal Cybersecurity Lab: Kali Linux + Metasploitable2 on VirtualBox

Khalif AL Mahmud — Thu, 18 Jun 2026 06:56:49 +0000

I've been wanting a safe, isolated environment where I could actually practice security concepts instead of just reading about them. Reading about vulnerabilities and exploits only gets you so far — at some point you need a sandbox where you can break things, fix things, and see how attacks and defenses actually behave on a network.

So I set out to build a small virtual lab on my own machine: a Kali Linux box as my "attacker" workstation, and Metasploitable2 as an intentionally vulnerable target to practice against. This post walks through exactly how I set it up, the mistakes I ran into, and how I verified everything was working before moving on to actual testing.

Problem Statement

Running security tools on a live network — or worse, on your host OS — is a bad idea for two reasons: it's risky (you could accidentally affect real systems), and it's messy (cleaning up after a misconfigured test is a pain). The fix is virtualization: spin up isolated VMs, connect them through a private virtual network, and keep everything contained on your own laptop or desktop.

The goal here was simple: get Kali and Metasploitable2 running side by side, talking to each other on an isolated virtual network, without touching my host system or any real network.

Step-by-Step Setup

1. Install VirtualBox

Grab VirtualBox from the official site: https://www.virtualbox.org/wiki/Downloads. Pick the build that matches your host OS and install it normally.

2. Create and Install the Kali Linux VM

Download the Kali installer image — "Installer Images → 64-bit → Everything" is the right choice (skip the Weekly and NetInstaller builds).

When creating the VM in VirtualBox, I used these specs:

Setting	Value
Disk space	60 GB
RAM	4 GB
CPU cores	3
OS Type	Linux → Debian 10.x (64-bit)
Boot firmware	UEFI

A note on disk size: the default 20GB is too small once you start running heavier tools like Nessus or OpenVAS later on, so I gave it more room upfront.

Boot the VM, choose "Graphical Install" from the menu, and walk through it like a normal Linux install. When it asks where to put the GRUB bootloader, point it at /dev/sda (or /dev/nvme0n1 if that's what shows up). Let it reboot when it's done, then log in.

Once you're in, update everything:

sudo apt update
sudo apt -y upgrade

Check your version to confirm everything's current:

lsb_release -a

3. Install VirtualBox Guest Additions

This step makes the VM way more pleasant to use — proper window resizing, better mouse integration, etc.

sudo apt update
sudo apt install -y virtualbox-guest-x11
sudo reboot

After the reboot, also go into your VM's Settings → General → Advanced and set both Shared Clipboard and Drag'n'Drop to "Bidirectional" instead of the default "Disabled." Small thing, but it makes copy-pasting commands between host and VM much easier.

4. Set Up Metasploitable2 as the Target

Metasploitable2 is distributed as a ready-made VMware disk (.vmdk), not an ISO, so the install process looks a little different. Download it from Sourceforge and unzip it somewhere convenient.

In VirtualBox, create a new VM with:

Type: Linux
Version: Ubuntu (64-bit)
RAM: 512 MB is plenty

The key difference from the Kali setup: when it asks about the virtual disk, don't create a new one — point it at the existing .vmdk file you extracted. No install step needed; it boots straight up.

Default credentials are msfadmin / msfadmin.

⚠️ Important: This VM is intentionally riddled with vulnerabilities. Never connect it to anything beyond your isolated lab network — NAT or host-only mode only.

Once you've confirmed you can log in, shut it down and take a snapshot (something like "Clean Metasploitable2 state" works fine as a name). That way, no matter how badly you break it later, you can roll back instantly.

5. Configure the Virtual Network

By default, VirtualBox's plain "NAT" mode doesn't let VMs talk to each other — you need "NAT Network" mode instead.

Go to File → Preferences → Network, click the "+" icon, and add a new NAT Network. The default name (NatNetwork) and default subnet (10.0.2.0/24 with DHCP enabled) are fine as-is.

Then, for each VM (Kali and Metasploitable2), go to Settings → Network → Adapter 1, and change "Attached to" from "NAT" to NAT Network, making sure the Name field points to your new network.

How to Verify

Once both VMs were up, I checked a few things to confirm the lab was actually working:

Kali boots to a usable desktop — no install errors, guest additions working, window resizes properly.
Metasploitable2 boots and accepts login — confirms the .vmdk was mounted correctly and the NAT Network adapter is active.
Resource usage looks sane with both VMs running — I kept an eye on RAM and CPU through the host's system monitor to make sure I wasn't overcommitting resources.
(Memory usage sitting around 80% with two VMs plus the host running gave me a good sense of how much headroom I actually have for heavier tools later.)
Basic ping test between the two VMs to confirm they can actually see each other on the NAT Network — this is the real proof the network config worked, since both VMs booting independently doesn't guarantee they can talk to each other.

What I Learned

A few things stood out while doing this:

VirtualBox's "NAT" and "NAT Network" modes are easy to confuse but behave very differently. Plain NAT isolates each VM from the others; NAT Network lets them share a private subnet and actually communicate — which is exactly what you need for any kind of attacker/target setup.
Snapshots aren't optional when working with intentionally vulnerable systems. The first time I messed up a config on Metasploitable2, having a clean snapshot to revert to saved me from a full reinstall.
Resource planning matters more than I expected. Running two VMs plus a host OS at once means watching RAM and CPU closely — giving Kali too much disk/RAM upfront just steals resources you'll want when running heavier tools later.
Isolation is the whole point. Keeping a deliberately vulnerable machine off any real network isn't just good practice — it's the difference between a safe learning environment and an actual security incident.

Common Mistakes Table

Mistake	Why It Happens	Fix
VMs can't ping each other	Using default "NAT" mode instead of "NAT Network"	Switch both VMs' Adapter 1 to "NAT Network"
Metasploitable2 won't boot	Trying to create a new virtual disk instead of using the existing `.vmdk`	Point the VM at the existing disk file during creation, don't create a new one
Kali window won't resize	Guest Additions not installed	Install `virtualbox-guest-x11` and reboot
Clipboard/drag-drop doesn't work between host and VM	Shared Clipboard / Drag'n'Drop left on "Disabled"	Set both to "Bidirectional" in VM Settings → General → Advanced
Running out of disk space mid-lab	Allocated the default 20GB to Kali	Allocate at least 60GB upfront if you plan to run scanners like Nessus/OpenVAS later

Conclusion

This was a pretty satisfying first step into building out a proper home lab. Nothing here is advanced yet — it's just plumbing — but plumbing matters. Having an isolated, repeatable environment means I can now move on to actually practicing scanning, enumeration, and exploitation techniques without worrying about breaking anything real.

Python Cryptography Basics: Building ASCII & Alphabet Tables from Scratch

Khalif AL Mahmud — Sat, 13 Jun 2026 18:00:25 +0000

When I first started digging into cryptography, I realized something quickly — before you can understand ciphers, encryption, or any real crypto concept, you need a solid grip on how computers actually represent characters. Numbers, binary, hex — it all starts there.

So I wrote two small Python programs that build these tables from scratch. Sounds simple, but honestly it clicked a lot of things into place for me. Let me walk you through both.

What We're Building

Program 1 — A table of uppercase letters (A–Z) with their decimal values (0–25), plus an arithmetic operation that adds 3 to each value.

Program 2 — A full ASCII table (characters 0–127) showing each character in Binary, Octal, Decimal, and Hexadecimal.

Program 1: Uppercase Alphabet Table with Arithmetic

The Problem

Map every uppercase letter A–Z to a number (A=0, B=1, ... Z=25), display the original table, then add 3 to every value and display an updated table.

This is actually the foundation of the Caesar cipher — shifting letters by a fixed number. That "add 3" operation? That's exactly what Caesar did.

The Code

print("Original Table:")
print("Letter\tDecimal")

letters = []
values = []

# A-Z Loop
for i in range(26):
    letter = chr(65 + i)   # ASCII of A = 65
    value = i
    letters.append(letter)
    values.append(value)
    print(f"{letter}\t{value}")

print("\nAfter Adding 3:")
print("Letter\tNew Value")

for i in range(26):
    new_value = values[i] + 3
    print(f"{letters[i]}\t{new_value}")

Step-by-Step Breakdown

1. chr(65 + i) — How we get letters from numbers

In Python, chr() converts an integer to its ASCII character. Since A has ASCII value 65, chr(65) gives 'A', chr(66) gives 'B', and so on up to chr(90) which is 'Z'.

print(chr(65))  # Output: A
print(chr(90))  # Output: Z

2. Storing letters and values in lists

We build two parallel lists — letters and values — so we can loop over them separately for the updated table.

3. Adding 3 to each value

new_value = values[i] + 3

This shifts every letter's number by 3. In cryptography terms, this is a Caesar cipher with shift=3. A (0) becomes 3, B (1) becomes 4, and so on.

4. Tab-separated output with \t

Using \t gives clean columnar output in the terminal without needing any external libraries.

Screenshot

How to Run

python alphabet_table.py

Expected Output (partial)

Original Table:
Letter  Decimal
A       0
B       1
C       2
...
Z       25

After Adding 3:
Letter  New Value
A       3
B       4
C       5
...

Program 2: Full ASCII Table — Binary, Octal, Decimal, Hex

The Problem

Print all 128 standard ASCII characters with their representations in four number systems: Binary, Octal, Decimal, and Hexadecimal — all in a clean tabular format.

The Code

print("Char\tDecimal\tBinary\t\tOctal\tHex")

for i in range(128):   # standard ASCII
    char    = chr(i)
    decimal = ord(char)
    binary  = bin(i)
    octal   = oct(i)
    hexa    = hex(i)

    print(f"{char}\t{decimal}\t{binary}\t{octal}\t{hexa}")

Step-by-Step Breakdown

1. range(128) — Standard ASCII range

ASCII defines 128 characters (0–127). The first 32 are control characters (non-printable), the rest are printable symbols, digits, and letters.

2. chr(i) — Integer to character

Converts each number to its corresponding ASCII character.

3. ord(char) — Character back to integer

ord() is the reverse of chr(). It takes a character and returns its ASCII decimal value. Useful to verify the round-trip conversion.

print(ord('A'))   # 65
print(chr(65))    # A

4. bin(), oct(), hex() — Python's built-in converters

Function	What it does	Example output
`bin(i)`	Converts to binary string	`0b1000001`
`oct(i)`	Converts to octal string	`0o101`
`hex(i)`	Converts to hexadecimal string	`0x41`

Python automatically adds prefixes (0b, 0o, 0x) so you always know which base you're looking at.

5. f-string formatting with \t

The \t tabs keep all columns aligned in the terminal without needing format() or any padding library.

Screenshot

How to Run

python ascii_table.py

Expected Output (partial)

Char    Decimal Binary          Octal   Hex
A       65      0b1000001       0o101   0x41
B       66      0b1000010       0o102   0x42
C       67      0b1000011       0o103   0x43
...
a       97      0b1100001       0o141   0x61
b       98      0b1100010       0o142   0x62

How to Verify Your Output

For Program 1:

Check that A maps to 0 and Z maps to 25
After adding 3: A should show 3, Z should show 28
Total rows: exactly 26 in each table

For Program 2:

A → decimal 65, binary 0b1000001, octal 0o101, hex 0x41
a → decimal 97 (lowercase is always 32 more than uppercase)
Total rows: 128 (0–127)

Quick sanity check in Python:

# Verify a few values manually
print(bin(65))   # 0b1000001
print(oct(65))   # 0o101
print(hex(65))   # 0x41
print(ord('A'))  # 65

What I Learned

Going through this exercise, a few things clicked that I hadn't fully internalized before:

Every character is just a number. The letter A and the number 65 are the same thing from the machine's perspective. Encryption at its core is just math on these numbers.
The Caesar cipher is literally just addition. Adding 3 to each letter's value and the cipher is done. Subtracting 3 decrypts it. That's it.
Number bases aren't scary. Binary, octal, hex — they're just different ways to write the same value. Python's bin(), oct(), and hex() make conversion trivial, but understanding why they exist (hardware efficiency, readability) matters more than memorizing conversions.
chr() and ord() are the gateway to text-based cryptography. Every classical cipher — Caesar, Vigenere, ROT13 — uses this same idea of converting text to numbers, operating on them, and converting back.

Common Mistakes

Mistake	Why it happens	Fix
`chr(i)` starting from 0 gives weird symbols	ASCII 0–31 are control characters	Start from `range(32, 128)` if you only want printable chars
Forgetting `chr(65 + i)` and using `chr(i)` directly	Off-by-one thinking	A = 65 in ASCII, not 0
Values after adding 3 going past Z (25→28)	Letters only go 0–25	Use modulo: `(value + 3) % 26` for wrapping
Binary output looking messy in columns	Binary strings have variable length	Use `format(i, '08b')` for fixed 8-bit width
`ord()` and `chr()` confused	Their names aren't obvious	`ord` = ordinal (number), `chr` = character

Conclusion

These two programs are small, but they sit right at the foundation of everything in cryptography. Before you can implement any cipher — even the simplest one — you need to understand how characters map to numbers and how those numbers can be represented in different bases.

If you're starting your cryptography journey, I'd recommend running both of these, playing with the shift value in Program 1 (try 13 for ROT13), and spending a few minutes reading the ASCII table output carefully. It makes a lot of later concepts much easier to grasp.

Lab Task 14 - How I Built a Real-Time Admin Login Attack Detector Using Snort3 and Apache on Ubuntu

Khalif AL Mahmud — Sat, 13 Jun 2026 12:48:36 +0000

Brute-force login attacks on web admin panels happen constantly in the wild. What if you could catch them in real time — watching the exact moment someone hammers your login page? That's exactly what I set up here.

In this walkthrough, I'll show you how to deploy a password-protected Apache web server on Ubuntu, simulate failed login attempts from a Kali Linux machine, and write custom Snort3 rules that fire alerts the moment those attempts hit your network. You'll see both the fast log and full log format outputs — side by side.

This is a hands-on, practical setup. Every command here was actually run and verified.

Problem Statement

Default web servers expose their admin pages with zero intrusion visibility. An attacker can keep hammering /admin with wrong credentials for hours, and without a detection layer, you'd never know. The goal here is to:

Set up a realistic web server with a password-protected /admin endpoint
Simulate unauthorized access from a separate attacker machine
Write Snort3 detection rules that catch those attempts in real time

Lab Environment

Machine	OS	Role
Ubuntu (Server)	Ubuntu 24.x	Web server + Snort3 IDS
Kali Linux (Attacker)	Kali 2025/2026	Attack simulation
Network	Host-only / NAT	VirtualBox

Step 1 — Install and Verify Apache2

On the Ubuntu machine, start by installing the Apache web server and the utilities package needed for password protection:

sudo apt update
sudo apt install apache2 -y
sudo apt install apache2-utils -y

Verify Apache is running:

sudo systemctl status apache2

You should see Active: active (running) in the output.

Step 2 — Create the Admin Web Page

Apache serves files from /var/www/html/. Create a new directory for the admin area and set up a basic HTML page:

sudo mkdir /var/www/html/admin
sudo nano /var/www/html/admin/index.html

Paste this minimal HTML:

<!DOCTYPE html>
<html>
<body>
    Welcome to Admin Page
</body>
</html>

Save and exit. Then remove the default Apache index page to keep things clean:

sudo rm /var/www/html/index.html

Step 3 — Password-Protect the Admin Directory

Create an admin user with a password. The -c flag creates a new password file:

sudo htpasswd -c /etc/apache2/.htpasswd adminuser

You'll be prompted to enter and confirm a password (e.g., 1234). Then set the correct permissions on the admin folder:

sudo chmod -R 755 /var/www/html/admin

Step 4 — Configure Apache to Protect the Admin Route

Edit the default Apache virtual host config:

sudo nano /etc/apache2/sites-available/000-default.conf

Add the following block inside the <VirtualHost *:80> section:

<Directory "/var/www/html/admin">
    AuthType Basic
    AuthName "Restricted Admin Area"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
</Directory>

Enable the headers module and restart Apache:

sudo a2enmod headers
sudo systemctl restart apache2
sudo systemctl status apache2

Step 5 — Confirm the Admin Page is Live

Check Ubuntu's IP address:

ip a

Note the IP (e.g., 192.168.1.104). Then from the Kali machine, open a browser and navigate to:

http://<UBUNTU_IP>/admin

You should see a browser login prompt asking for username and password.

Step 6 — Write the Custom Snort3 Detection Rule

Back on Ubuntu, open the local Snort rules file:

sudo nano /usr/local/etc/rules/local-rules/local.rules

Add this rule to detect HTTP traffic to port 80 that contains an Authorization header — which is what HTTP Basic Auth sends on every login attempt:

alert tcp any any -> any 80 (
    msg:"Unauthorized Access to admin page";
    content:"Authorization";
    sid:1000011;
    rev:2;
)

What this rule does:

alert tcp any any -> any 80 — watches all TCP traffic heading to port 80
content:"Authorization" — matches the HTTP header browsers send during Basic Auth login attempts
msg — the label you'll see in the alert log
sid — unique Snort rule ID

Step 7 — Validate the Snort3 Configuration

Before running Snort live, always test the config:

snort -c /usr/local/etc/snort/snort.lua -T

Look for this at the end of the output:

Snort successfully validated the configuration (with 0 warnings).

Step 8 — Start Snort3 in Alert Fast Mode

Run Snort on the active network interface (check yours with ip a — commonly enp0s3):

sudo snort -A alert_fast -i enp0s3 -c /usr/local/etc/snort/snort.lua

Leave this running in one terminal window.

Step 9 — Simulate the Attack (More Than 3 Failed Logins)

On the Kali machine, open the browser and go to http://<UBUNTU_IP>/admin. Click Sign in with wrong credentials at least 4–5 times (all attempts should fail).

Step 10 — Generate Alerts in Full Log Format

Stop the previous Snort instance (Ctrl+C) and restart with the full log format:

sudo snort -A full -i enp0s3 -c /usr/local/etc/snort/snort.lua

Repeat the failed login attempts from Kali. The full format gives you detailed packet-level information including TCP flags, sequence numbers, TTL, and more — useful for deeper analysis.

How to Verify Everything is Working

Apache is up: sudo systemctl status apache2 shows active (running)
Admin page is protected: Visiting http://<UBUNTU_IP>/admin shows a login popup
Snort is detecting: After login attempts, alerts appear in the terminal with the message "Unauthorized Access to admin page"
Snort config is valid: snort -c /usr/local/etc/snort/snort.lua -T returns 0 warnings
Full log works: Switching to -A full shows packet-level detail per alert

What I Learned

Working through this setup gave me a much clearer picture of how network-level detection actually works in practice. A few things stood out:

HTTP Basic Auth is surprisingly transparent to Snort. Every login attempt sends an Authorization header in cleartext (over HTTP), which makes it trivially detectable with a content-match rule. This reinforces why HTTPS is non-negotiable for anything sensitive.

Snort rules are very literal. The rule fires on every connection that contains the Authorization header — not just failed ones. To detect only failures, you'd need to correlate the server's 401 response, which requires stateful detection or threshold rules. This is a good next step to explore.

Fast vs. Full log formats serve different purposes. The fast format is great for real-time monitoring — clean, one-line-per-alert. The full format is better for post-incident forensics where you need packet details.

Configuration validation saves time. Running snort -T before going live catches rule syntax errors before they silently fail in production.

Common Mistakes

Mistake	What Happens	Fix
Not running `sudo a2enmod headers`	Apache fails to restart after config edit	Run `sudo a2enmod headers` then restart
Wrong network interface in `-i` flag	Snort captures nothing	Use `ip a` to confirm interface name (e.g., `enp0s3`)
Rule content keyword mismatch	No alerts fire	Check the exact string sent in HTTP headers using Wireshark
Using `sid` that already exists	Snort config validation fails	Use a unique SID (10000000+ range is safe for custom rules)
Forgetting to clear browser cache	Old auth cookies auto-login without triggering alerts	Clear cache or use incognito/private mode
Not testing with `snort -T` first	Errors only appear after launching live capture	Always validate config before live run

Conclusion

This setup takes under 30 minutes and gives you a fully functional intrusion detection demo for web admin brute-force attempts. The combination of Apache's Basic Auth, a targeted Snort3 content rule, and live packet capture on the interface creates a pipeline you can actually watch in action.

From here, there's a lot to build on — threshold rules to alert only after N attempts, suppression rules to reduce noise, or integrating with a SIEM to store and query alerts. But this foundation shows exactly how the detection layer works at the network level.

If you set this up or tweak the rules, let me know how it went in the comments.

Lab Task 13 - How I Built a Network Intrusion Detection System with Snort 3 on Ubuntu — and Caught Every Scan

Khalif AL Mahmud — Sat, 13 Jun 2026 12:23:41 +0000

Network security monitoring always looked intimidating to me — until I actually sat down, set up Snort 3 from scratch on Ubuntu, wrote my own detection rules, and watched it flag every single nmap scan in real time. This post walks through everything: installation, configuration, custom rules, and simulating real attacks to prove it works.

If you have ever wondered how intrusion detection systems actually work under the hood, this is a solid hands-on way to find out.

What We Are Building

A working Snort 3 IDS running on Ubuntu inside a virtual machine, monitored by a Kali Linux attacker VM. Snort will sit on the network interface, watch all traffic, and alert when it detects:

ICMP Ping Sweep
XMAS Scan
FIN Scan
NULL Scan
SYN Scan
TCP Connect Scan
UDP Scan

Both VMs are connected via Bridged Adapter in VirtualBox, so they share the same subnet.

Environment Setup

Machine	OS	Role	IP (example)
Defender	Ubuntu 22.04	Snort 3 IDS	192.168.1.104
Attacker	Kali Linux 2026.1	nmap scan source	192.168.1.106

Both adapters set to Bridged Adapter in VirtualBox settings so they can reach each other.

Step 1 — Update Ubuntu and Install Dependencies

Open a terminal on the Ubuntu VM and run:

sudo apt update

Then install all required build tools and libraries in one command:

sudo apt install -y build-essential \
  libpcap-dev \
  libpcre2-dev \
  libnet1-dev \
  zlib1g-dev \
  luajit \
  hwloc \
  libdumbnet-dev \
  bison \
  flex \
  liblzma-dev \
  openssl \
  libssl-dev \
  pkg-config \
  libhwloc-dev \
  cmake \
  cpputest \
  libsqlite3-dev \
  uuid-dev \
  libcmocka-dev \
  libnetfilter-queue-dev \
  libmnl-dev \
  autotools-dev \
  libluajit-5.1-dev \
  libunwind-dev \
  git \
  wget \
  ethtool

Step 2 — Create a Working Directory

mkdir snort-source-files
cd snort-source-files

Step 3 — Install LibDAQ (Snort's Data Acquisition Library)

LibDAQ is what allows Snort to capture packets from the network interface.

git clone https://github.com/snort3/libdaq.git
cd libdaq
sudo ./bootstrap
sudo ./configure
sudo make
sudo make install
cd ..

Step 4 — Install Tcmalloc (Memory Optimization)

Tcmalloc is a memory allocator from Google that reduces fragmentation and speeds up Snort under load.

wget https://github.com/gperftools/gperftools/releases/download/gperftools-2.10/gperftools-2.10.tar.gz
tar xzf gperftools-2.10.tar.gz
cd gperftools-2.10
sudo ./configure
sudo make
sudo make install
cd ..

Step 5 — Install Snort 3

Now the main event — clone and build Snort 3 from source:

git clone https://github.com/snort3/snort3.git
cd snort3
sudo ./configure_cmake.sh --prefix=/usr/local --enable-tcmalloc
cd build
sudo make
sudo make install

The sudo make step takes several minutes — this is normal. You will see progress climb from 0% to 100%.

After install, create a symlink and verify the version:

sudo ldconfig
sudo ln -s /usr/local/bin/snort /usr/sbin/snort
snort -V

Expected output:

-*> Snort++ <*-
   Version 3.12.2.0
   By Martin Roesch & The Snort Team

Step 6 — Configure the Network Interface

Find your interface name (mine was enp0s3):

ip a

Set it to promiscuous mode so Snort can capture all traffic:

sudo ip link set dev enp0s3 promisc on
sudo ethtool -K enp0s3 gro off lro off

Create a systemd service to persist this across reboots:

sudo nano /etc/systemd/system/snort3-nic.service

Paste this content:

[Unit]
Description=Set Snort3 NIC in promiscuous mode

[Service]
Type=oneshot
ExecStart=/sbin/ip link set dev enp0s3 promisc on
ExecStart=/sbin/ethtool -K enp0s3 gro off lro off

[Install]
WantedBy=multi-user.target

Enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now snort3-nic.service
sudo systemctl status snort3-nic.service

Step 7 — Create the Rules Directory and Configure snort.lua

sudo mkdir -p /usr/local/etc/rules/local-rules
cd /usr/local/etc/snort
sudo nano snort.lua

Make the following changes in snort.lua:

-- Set your network
HOME_NET = '192.168.0.0/24'
EXTERNAL_NET = '!$HOME_NET'

include 'snort_defaults.lua'

Scroll to the detection section and add the IPS block:

ips =
{
    include = '/usr/local/etc/rules/local-rules/local.rules',

    variables =
    {
        nets =
        {
            HOME_NET = HOME_NET,
            EXTERNAL_NET = EXTERNAL_NET
        }
    }
}

Save and exit with Ctrl+X → Y → Enter.

Step 8 — Write the Detection Rules

sudo nano /usr/local/etc/rules/local-rules/local.rules

Add these seven rules:

alert icmp any any -> $HOME_NET any (msg:"NMAP Ping Sweep Scan"; dsize:0; sid:1000001; rev:1;)

alert tcp any any -> $HOME_NET 22 (msg:"NMAP XMAS Scan"; flags:FPU; sid:1000002; rev:1;)

alert tcp any any -> $HOME_NET 22 (msg:"NMAP FIN Scan"; flags:F; sid:1000003; rev:1;)

alert tcp any any -> $HOME_NET 22 (msg:"NMAP NULL Scan"; flags:0; sid:1000004; rev:1;)

alert tcp any any -> $HOME_NET 22 (msg:"NMAP SYN Scan"; flags:S; sid:1000005; rev:1;)

alert tcp any any -> $HOME_NET 22 (msg:"NMAP TCP Connect Scan"; sid:1000006; rev:1;)

alert udp any any -> $HOME_NET any (msg:"NMAP UDP Scan"; sid:1000007; rev:1;)

Step 9 — Validate the Configuration

Before running Snort live, test that the config file loads without errors:

snort -c /usr/local/etc/snort/snort.lua -T

You should see at the end:

Snort successfully validated the configuration (with 0 warnings).
o")~   Snort exiting

Step 10 — Start Snort in Alert Mode

sudo snort -c /usr/local/etc/snort/snort.lua -i enp0s3 -A alert_fast

Snort is now running and watching enp0s3 for any traffic that matches the rules.

Step 11 — Simulate Attacks from Kali Linux

On the Kali VM, run each scan against the Ubuntu IP:

1. Ping Sweep

nmap -sn 192.168.1.104

2. XMAS Scan

sudo nmap -sX 192.168.1.104

3. FIN Scan

sudo nmap -sF 192.168.1.104

4. NULL Scan

sudo nmap -sN 192.168.1.104

5. SYN Scan

sudo nmap -sS 192.168.1.104

6. TCP Connect Scan

nmap -sT 192.168.1.104

7. UDP Scan

sudo nmap -sU 192.168.1.104

How to Verify

Watch the Snort terminal on Ubuntu while each nmap command runs on Kali. You will see live alert lines like this:

05/14-18:13:07.004392 [**] [1:1000001:1] "NMAP Ping Sweep" [**] [Priority: 0] {ICMP} 192.168.1.106 -> 192.168.1.104
05/14-18:15:21.301976 [**] [1:1000002:1] "NMAP XMAS Scan" [**] [Priority: 0] {TCP} 192.168.1.106:34107 -> 192.168.1.104:22
05/14-18:16:03.900911 [**] [1:1000003:1] "NMAP FIN Scan" [**] [Priority: 0] {TCP} 192.168.1.106:41928 -> 192.168.1.104:22
05/14-18:16:53.770290 [**] [1:1000004:1] "NMAP NULL Scan" [**] [Priority: 0] {TCP} 192.168.1.106:52411 -> 192.168.1.104:22
05/14-18:17:26.976133 [**] [1:1000005:1] "NMAP SYN Scan" [**] [Priority: 0] {TCP} 192.168.1.106:40209 -> 192.168.1.104:22
05/14-18:15:21.301976 [**] [1:1000006:1] "NMAP TCP Connect Scan" [**] [Priority: 0] {TCP} 192.168.1.106:34107 -> 192.168.1.104:22
05/14-18:12:48.402112 [**] [1:1000007:1] "NMAP UDP Scan" [**] [Priority: 0] {UDP} 192.168.1.1:1900 -> 239.255.255.250:1900

Each attack type triggers its corresponding rule — that means the IDS is working exactly as expected.

What I Learned

Working through this end to end taught me several things that documentation alone does not convey:

Snort rules are just pattern matchers. At their core, each rule is a protocol + direction + match condition. Once you understand that structure, writing new rules feels natural.

Promiscuous mode matters. Without promisc on, Snort only sees traffic addressed directly to the host. Flipping that one flag is what makes it a proper network monitor.

Building from source builds understanding. Watching each dependency compile, seeing LibDAQ slot into place, and then seeing Snort start up — it makes the whole stack tangible rather than abstract.

nmap flag combinations map to Snort flags directly. The -sX XMAS scan sets FIN, PSH, and URG flags — which maps to flags:FPU in the rule. That connection between the attacker's tooling and the defender's signature clicked during this lab.

Alert mode is just the beginning. Snort can also run in inline IPS mode and actively drop packets. This setup is the foundation for that.

Common Mistakes

Mistake	What Goes Wrong	Fix
Using Snort 2 instead of Snort 3	Config file format is completely different	Always clone from `github.com/snort3/snort3`
Wrong `HOME_NET` subnet	Rules never fire because traffic is not matched	Check your actual subnet with `ip a` and set it exactly
Not setting promiscuous mode	Snort misses traffic not destined for the host	`sudo ip link set dev enp0s3 promisc on`
Interface name mismatch in command	Snort starts but captures nothing	Confirm with `ip a` — may be `ens33`, `eth0`, or `enp0s3`
Rules path typo in snort.lua	Snort validates but fires no alerts	Double-check the exact path including subdirectories
Skipping `sudo ldconfig` after install	Snort binary cannot find shared libraries	Always run `sudo ldconfig` before testing
`flags:0` for NULL scan	May vary between Snort versions	Test with `snort -c snort.lua -T` and verify rule loads

Conclusion

Snort 3 is not the simplest tool to set up from scratch, but going through the full build process is worth it. You end up with a real understanding of how each piece fits together — LibDAQ capturing packets, the rules engine pattern matching, and the alert output confirming what the attacker is doing.

The combination of Snort writing alerts in one window while nmap runs in another makes the whole thing feel live and real. Each scan lights up the terminal on the defender side, which is a genuinely satisfying moment.

If you set this up yourself and run into issues, drop a comment below — happy to help debug.

Lab 12 - Telnet and SSH ( I Captured My Own Password in Wireshark — Here's What Telnet Taught Me About Network Security )

Khalif AL Mahmud — Sat, 13 Jun 2026 12:22:06 +0000

There's a moment in networking that changes how you think about protocols forever.

You type a password into a terminal. Then you open Wireshark, follow a TCP stream, and there it is — your password, sitting in plain text, completely readable by anyone on the network.

That's Telnet. And that's exactly why this experiment is worth doing.

In this post, I'll walk you through how I set up a 4-router network in GNS3, configured Telnet and SSH on Cisco routers, and used Wireshark to visually prove why one protocol is dangerous and the other is essential.

The Problem: Why Does This Matter?

Most people learn that "SSH is better than Telnet" from documentation. But seeing it live is different.

Telnet operates on Port 23 and sends everything — usernames, passwords, commands — as unencrypted plain text over the network. SSH operates on Port 22 and encrypts every single byte using RSA key pairs.

In a real-world scenario, any attacker with access to your network traffic (via ARP spoofing, a rogue device, or misconfigured infrastructure) can intercept Telnet credentials instantly. SSH prevents this entirely.

Network Topology

Here's the topology I built in GNS3:

IP Address Summary:

Device	Interface	IP Address
R1	f0/0	172.16.2.16/16
R2	f0/0	172.16.2.33/16
R2	f2/0	172.25.177.254/16
R2	f3/0	172.6.16.6/16
R3	f0/0	172.6.16.17/16
R3	f1/0	172.34.5.10/16
R4	f0/0	172.25.4.192/16
R4	f1/0	172.2.2.2/16

Start Wireshark Before Anything Else

This is the most important step that beginners miss.

Before touching any configuration, start packet capture on every router link in GNS3. Right-click on each link → Start Capture. This ensures Wireshark records all configuration traffic from the very beginning.

PHASE 1 — Configure IP + RIP on All Routers (Direct Console)

R1 Console:

Router> enable
Router# configure terminal

Router(config)# hostname R1
R1(config)# interface fastethernet 0/0
R1(config-if)# ip address 172.16.2.16 255.255.0.0
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# router rip
R1(config-router)# version 2
R1(config-router)# network 172.16.0.0
R1(config-router)# no auto-summary
R1(config-router)# exit
R1(config)# exit

R1# write memory

R1 is our "management router" — everything else gets configured from here via Telnet.

The no shutdown command is essential — Cisco router interfaces are administratively down by default. Without this, nothing works.

Configure RIP on R1 :

What Actually Happen in wireshark After Configure R1

R2 Console:

Router> enable
Router# configure terminal

Router(config)# hostname R2
R2(config)# interface fastethernet 0/0
R2(config-if)# ip address 172.16.2.33 255.255.0.0
R2(config-if)# no shutdown
R2(config-if)# exit

R2(config)# router rip
R2(config-router)# version 2
R2(config-router)# network 172.16.0.0
R2(config-router)# no auto-summary
R2(config-router)# exit

R2(config)# enable password cisco
R2(config)# line vty 0 4
R2(config-line)# password cisco
R2(config-line)# login
R2(config-line)# transport input telnet
R2(config-line)# exit
R2(config)# exit

R2# write memory

What are VTY lines? They're virtual terminal lines — the "doors" through which remote users connect to a router. line vty 0 4 means we're configuring 5 simultaneous connections (0 through 4).

R3 Console:

Router> enable
Router# configure terminal

Router(config)# hostname R3
R3(config)# interface fastethernet 0/0
R3(config-if)# ip address 172.6.16.17 255.255.0.0
R3(config-if)# no shutdown
R3(config-if)# exit

R3(config)# router rip
R3(config-router)# version 2
R3(config-router)# network 172.6.0.0
R3(config-router)# no auto-summary
R3(config-router)# exit

R3(config)# enable password cisco
R3(config)# line vty 0 4
R3(config-line)# password cisco
R3(config-line)# login
R3(config-line)# transport input telnet
R3(config-line)# exit
R3(config)# exit

R3# write memory

R4 Console:

Router> enable
Router# configure terminal
Router(config)# hostname R4
R4(config)# interface fastethernet 0/0
R4(config-if)# ip address 172.25.4.192 255.255.0.0
R4(config-if)# no shutdown
R4(config-if)# exit
R4(config)# router rip
R4(config-router)# version 2
R4(config-router)# network 172.25.0.0
R4(config-router)# no auto-summary
R4(config-router)# exit
R4(config)# enable password cisco
R4(config)# line vty 0 4
R4(config-line)# password cisco
R4(config-line)# login
R4(config-line)# transport input telnet
R4(config-line)# exit
R4(config)# exit
R4# write memory

PHASE 2 — Configure PCs (VPCS)

PC1:

ip 172.2.3.3 255.255.0.0 172.2.2.2
save

PC2:

ip 172.34.10.67 255.255.0.0 172.34.5.10
save

PHASE 3 — From R1, Telnet into R2, R3, R4 and Configure Remaining Interfaces + RIP

✅ First Verify — Ping from R1:

R1# ping 172.16.2.33
R1# ping 172.6.16.17
R1# ping 172.25.4.192

All three must succeed before proceeding.

R1 → Telnet → R2:

R1# telnet 172.16.2.33

Password: cisco
R2> enable
Password: cisco
R2# configure terminal

R2(config)# interface fastethernet 2/0
R2(config-if)# ip address 172.25.177.254 255.255.0.0
R2(config-if)# no shutdown
R2(config-if)# exit

R2(config)# interface fastethernet 3/0
R2(config-if)# ip address 172.6.16.6 255.255.0.0
R2(config-if)# no shutdown
R2(config-if)# exit

R2(config)# router rip
R2(config-router)# network 172.25.0.0
R2(config-router)# network 172.6.0.0
R2(config-router)# exit

R2(config)# exit
R2# write memory
R2# exit

Wireshark will show the packets exchanged between the two routers. Right click on the 2nd last telnet packet and got to Follow -> TCP stream. You can see the console commands entered on router 1 to access router 2. It will also show the password as plaintext. If we had configured SSH instead of Telnet then the password wouldn’t be captured as plaintex

Full Command

R1 → Telnet → R3:

R1# telnet 172.6.16.17

Password: cisco
R3> enable
Password: cisco
R3# configure terminal

R3(config)# interface fastethernet 1/0
R3(config-if)# ip address 172.34.5.10 255.255.0.0
R3(config-if)# no shutdown
R3(config-if)# exit

R3(config)# router rip
R3(config-router)# network 172.34.0.0
R3(config-router)# exit

R3(config)# exit
R3# write memory
R3# exit

R1 → Telnet → R4:

R1# telnet 172.25.4.192

Password: cisco
R4> enable
Password: cisco
R4# configure terminal

R4(config)# interface fastethernet 1/0
R4(config-if)# ip address 172.2.2.2 255.255.0.0
R4(config-if)# no shutdown
R4(config-if)# exit

R4(config)# router rip
R4(config-router)# network 172.2.0.0
R4(config-router)# exit

R4(config)# exit
R4# write memory
R4# exit

PHASE 4 — Configure SSH on R4 (R4 Direct Console)

R4# configure terminal
R4(config)# ip domain-name lab.com
R4(config)# crypto key generate rsa

When prompted:

How many bits in the modulus [512]: 1024

R4(config)# ip ssh version 2
R4(config)# username admin password cisco123
R4(config)# line vty 0 3
R4(config-line)# transport input ssh telnet
R4(config-line)# login local
R4(config-line)# exit
R4(config)# exit
R4# write memory

Why 1024 bits? SSH version 2 requires a minimum key size. Less than 768 bits won't work. 1024 is the standard starting point, though 2048+ is recommended for production environments.

login local vs login: Using login local tells the router to check the local username database we just created. Plain login only checks the VTY password — less secure.

After running configuration commands through Telnet, go to Wireshark:

Find any Telnet packet
Right-click → Follow → TCP Stream

You'll see the password typed at the prompt — completely readable. Every command. Every keystroke. All plain text.

This is the moment that makes the SSH comparison real.

PHASE 5 — SSH from R2 into R4

R2# ssh -l admin 172.25.4.192

Password: cisco123
R4> enable
Password: cisco
R4# show running-config

Follow the same steps as before — find an SSH packet, right-click → Follow → TCP Stream.

Compare this with the Telnet stream. The SSH stream shows only encrypted bytes — no readable text, no visible commands, no password.

Same network. Same routers. Completely different security story.

All Encrypted Data :

Final Verification

Run on every router (R1, R2, R3, R4):

show ip interface brief
show ip route
show running-config

With RIP v2 configured on all routers, they share routing information automatically. After about 30–60 seconds for convergence:

Ping PC2 from PC1:

ping 172.34.10.67

📝 Important Notes — Lessons Learned

⚠️ Note 1: RIP First, Telnet Later

Every router that you want to telnet into must have RIP configured on it beforehand — from its own console.

Reason: Telnet works over a TCP connection. For TCP to establish, packets must travel both ways. For packets to travel, routes must exist. Routes come from RIP. No RIP means no route, no route means no ping, no ping means no Telnet — connection will always time out.

✅ Correct order per router: Console → Assign IP → Configure RIP → Configure Telnet → Then telnet in from another router

⚠️ Note 2: The Chicken and Egg Trap

Want to Telnet in    → Need Ping to work
Need Ping to work    → Need a Route
Need a Route         → Need RIP
Want to configure RIP → Need Telnet  ← 🔴 INFINITE LOOP!

The only way out of this loop is to configure RIP from the console first, before attempting any telnet connection.

Telnet vs SSH: Side by Side

Feature	Telnet	SSH
Port	23	22
Encryption	None	RSA + AES
Password in Wireshark	Fully visible	Encrypted
Data Integrity	No	Yes
Authentication	Password only	Password + Public Key
Compliance	Fails PCI DSS	Meets PCI DSS, HIPAA
Industry Status	Deprecated	Standard

What We Learned

The technical takeaways:

Cisco router interfaces are administratively down by default — always use no shutdown
SSH requires a domain name and RSA key pair before it will function
transport input ssh blocks Telnet entirely; transport input ssh telnet allows both
RIP v2 needs 30–60 seconds to converge before routing works across the full network
Wireshark's "Follow TCP Stream" feature is one of the most powerful tools for understanding protocol behavior

The bigger picture:

Seeing credentials in plain text in a packet capture is more convincing than any documentation
Most legacy network devices still run Telnet by default — knowing how to replace it with SSH is a practical skill
Tools like Wireshark aren't just for attackers — they're essential for anyone building or defending networks

Common Mistakes for Beginners

1. Starting Wireshark after configuration
Always start captures before any configuration. You can't capture traffic retroactively.

2. Skipping no shutdown
If interfaces stay down, nothing will connect. Make this a habit on every interface.

3. Using less than 1024-bit RSA keys
SSH v2 won't work. Always use 1024 minimum, 2048 for anything serious.

4. Expecting instant ping success
RIP needs time to advertise routes to all routers. Wait 30–60 seconds after configuration.

5. Mixing up login and login local
login local uses the username database. login uses only the VTY password. For SSH, always use login local.

Conclusion

The gap between Telnet and SSH isn't theoretical — it's something you can see with your own eyes in a Wireshark capture. One protocol hands your credentials to anyone watching the wire. The other makes them invisible.

If you're working with Cisco devices or any network infrastructure, replacing Telnet with SSH isn't optional — it's the baseline. Every compliance framework from PCI DSS to HIPAA requires it, and now you know exactly why.

Try building this topology yourself. Capture the packets. See your password appear in plain text. It's the kind of hands-on lesson that sticks.

All configurations were done in GNS3 with Cisco IOS routers. Wireshark was used for packet analysis.

Lab Task 11 – Monitoring HTTP Traffic with Httpry on Kali Linux — Passive Capture, Live Monitoring & CLF Conversion

Khalif AL Mahmud — Sat, 13 Jun 2026 07:53:14 +0000

When you start digging into network traffic analysis, you quickly realize that Full Packet Capture tools like Wireshark or tcpdump give you everything — which is often too much. Sometimes you just need the HTTP layer: what requests are being made, to which hosts, using which methods, and when.

That is exactly where Httpry fits in. It is a lightweight, specialized HTTP sniffer that sits quietly on a network interface or reads from a captured pcap file and extracts only what matters — HTTP request and response metadata. No noise, no massive binary dumps, just clean HTTP session data.

In this post I will walk through the full Httpry workflow: building it from source, running passive analysis on a captured pcap file, creating log files, converting those logs to Common Log Format, running live monitoring while generating real HTTP traffic, and then repeating the same CLF conversion on the live capture output.

Why Httpry Instead of Just Wireshark?

Full packet capture has its place, but for HTTP-focused monitoring it comes with overhead — storage costs, parsing time, and complexity. Httpry gives you Packet String Data (PSTR): a selected, human-readable subset of network traffic focused on application-layer protocol strings like hostnames, URLs, HTTP methods, and status codes.

Think of it as the difference between recording an entire phone conversation and keeping only a structured call log. The log is smaller, faster to query, and still tells you who called whom, when, and for how long.

What You Will Need

Kali Linux (or any Debian/Ubuntu-based system)
A .pcap file from a previous traffic capture session (I used one from Lab 10 generated with daemonlogger)
git, gcc, make, libpcap-dev installed
Root/sudo access

Step 1 — Update the System

Before anything else, make sure your package lists are current.

sudo apt-get update

Step 2 — Install Build Dependencies

Httpry is not in the default Kali repositories as a pre-built package, so you will compile it from source. It needs libpcap-dev, make, and gcc.

sudo apt install libpcap-dev make gcc

Step 3 — Clone and Build Httpry

git clone https://github.com/jbittel/httpry.git
cd httpry
make
sudo make install

The make step compiles the source and places the binary in /usr/sbin/httpry. You might see a deprecation warning about pcap_lookupdev — that is harmless on modern libpcap versions.

Verify the install:

httpry --version
which httpry

Step 4 — Locate the Captured pcap File (Part i)

For passive analysis I used a .pcap file captured during a previous lab session with daemonlogger. It was stored at /var/log/daemonlogger/.

cd /var/log/daemonlogger
ls
ls -lh capture.1777551302.pcap

Step 5 — Passive Monitoring on the pcap File (Part ii)

The -r flag tells Httpry to read from a pcap file instead of a live interface. This is called passive monitoring — no active capture, just replaying already-captured traffic.

sudo httpy -r capture.1777551302.pcap

(Replace capture.1777551302.pcap with your actual filename.)

Httpry parses the file and prints every HTTP transaction it finds. Each line shows:

Field	Example
Timestamp	`2026-04-30 05:21:20.856`
Source IP	`10.0.2.15`
Destination IP	`54.39.128.230`
Direction	`>` (request) or `<` (response)
Method	`GET`
Host	`http.kali.org`
URI	`/kali/pool/main/l/...`
HTTP Version	`HTTP/1.1`
Status Code	`200 OK` / `302 Found`

At the end of the output you will see a line like 25 http packets parsed.

Step 6 — Create a Log File and Inspect It (Part iii)

The -o flag writes Httpry output to a file instead of (or in addition to) stdout.

sudo httpry -r capture.1777551302.pcap -o httpry_log.txt
cat httpry_log.txt

The saved file includes a header block showing the Httpry version, copyright, and the field names:

# httpry version 0.1.8
# Fields: timestamp,source-ip,dest-ip,direction,method,host,request-uri,http-version,status-code,reason-phrase

Followed by tab-separated data rows for every HTTP event.

Step 7 — Convert to Common Log Format (Part iv)

Httpry's native log format is useful but not the same as Common Log Format (CLF) — the standard format used by Apache, Nginx, and most web server logs. CLF looks like this:

192.168.1.100 - john [16/Oct/2024:12:15:45 -0700] "GET /index.html HTTP/1.1" 200 1024

To convert, I wrote a small Perl script (log2clf.pl) that reads Httpry's tab-separated output and reformats it:

cat > ~/log2clf.pl << 'EOF'
#!/usr/bin/perl
use strict;
use warnings;

while (<STDIN>) {
    chomp;
    next if /^#/;
    next if /^\s*$/;

    my @fields = split(/\t/, $_);
    next unless @fields >= 7;

    my ($timestamp, $direction, $src_ip, $dst_ip, $method, $host, $path, $proto) = @fields;

    next unless defined $method && $method =~ /GET|POST|HEAD/;

    my $url = "http://" . ($host // "-") . ($path // "/");
    my $time_fmt = $timestamp;

    print "$src_ip - - [$time_fmt] \"$method $url $proto\" - -\n";
}
EOF

Then pipe the Httpry log through it:

cat ~/httpry_log.txt | perl ~/log2clf.pl > ~/httpry_clf.txt
cat ~/httpry_clf.txt

The output now matches CLF structure — IP address, timestamp in brackets, quoted request line, and placeholder dashes for status/bytes (since Httpry does not always capture full response metadata for every entry).

Step 8 — Live Monitoring While Generating HTTP Traffic (Part v)

Now for real-time capture. Run Httpry on your active network interface (eth0 or eth1 depending on your setup) and simultaneously generate HTTP traffic from another terminal.

Terminal 1 — start Httpry:

sudo httpry -i eth0

Terminal 2 — generate HTTP traffic:

curl http://example.com
curl http://google.com

Httpry starts printing HTTP events in real time as the curl requests go out and responses come back. When you are done, press Ctrl+C to stop. It will print a summary like:

^CCaught SIGINT, shutting down ...
48 packets received, 0 packets dropped, 4 http packets parsed
8.4 packets/min, 0.7 http packets/min

Step 9 — Save Live Capture to a File (Part vi)

Repeat the live monitoring but this time save the output to a file using -o:

sudo httpry -i eth0 -o live_capture.txt

Generate some HTTP traffic again with curl, then Ctrl+C to stop. Verify the file was written:

cat live_capture.txt

You will see the same header format as before (# Fields: timestamp,...) followed by the live session data.

Step 10 — Convert the Live Capture to CLF (Part vii)

Apply the same CLF conversion to the live capture file. You can reuse or slightly tweak the Perl script:

cat > ~/log2clf.pl << 'EOF'
#!/usr/bin/perl
while (<STDIN>) {
    chomp;
    next if /^#/;
    next if /^\s*$/;
    my @f = split(/\t/, $_);
    next unless @f >= 7;
    my ($ts, $dir, $src, $dst, $method, $host, $path, $proto) = @f;
    next unless defined $method && $method =~ /GET|POST|HEAD/;
    $path //= "/";
    $proto //= "HTTP/1.1";
    print "$src - - [$ts] \"$method http://$host$path $proto\" - -\n";
}
EOF

cat ~/live_capture.txt | perl ~/log2clf.pl > ~/live_clf.txt
cat ~/live_clf.txt

The output confirms the live traffic converted correctly to CLF:

172.66.147.243 - - [2026-05-04 12:44:34.618] "GET http://example.com/ HTTP/1.1" - -
142.250.187.78 - - [2026-05-04 12:44:38.835] "GET http://google.com/ HTTP/1.1" - -

How to Verify Everything Worked

Check	Command	Expected Result
Httpry is installed	`which httpry`	`/usr/sbin/httpry`
Passive read works	`sudo httpry -r file.pcap`	HTTP lines printed, packets parsed count shown
Log file created	`cat httpry_log.txt`	Header + tab-separated HTTP data rows
CLF conversion	`cat httpry_clf.txt`	Lines formatted as `IP - - [timestamp] "METHOD url proto" - -`
Live capture works	`sudo httpry -i eth0`	Real-time HTTP events printed to terminal
Live log saved	`cat live_capture.txt`	Same format as passive log with live timestamps
Live CLF done	`cat live_clf.txt`	CLF lines from live session

What I Learned

Working through this taught me several things I did not fully appreciate before:

Httpry occupies a specific niche. It is not trying to replace Wireshark or tcpdump. It is purpose-built for extracting HTTP metadata quickly — PSTR (Packet String Data). For network defenders who need to know what HTTP activity happened without storing full packet payloads, this is a practical tool.

Log format matters for toolchain compatibility. Httpry's native format is clean and readable, but most SIEM tools, log parsers, and web analytics tools expect Common Log Format. Writing the Perl conversion script made it clear why standardization exists — a few field reorderings and you can feed Httpry output into tools designed for Apache logs.

Passive vs live monitoring are different operational modes. Reading a pcap file is deterministic and repeatable — useful for forensics and post-incident analysis. Live capture on an interface is real-time but ephemeral. Both have their place, and knowing when to use each is part of being a practical network analyst.

Httpry's -r flag is the key for forensic work. Most forensic workflows start with a pcap you already have. Being able to extract HTTP-layer data from it without re-opening Wireshark is genuinely useful.

Common Mistakes

Mistake	Why It Happens	Fix
Running Httpry without `sudo`	Packet capture needs root privileges	Always use `sudo httpry ...`
Wrong interface name	`eth0` vs `eth1` vs `ens33` varies by system	Check with `ip a` or `ifconfig` before running
Perl script not filtering `#` comment lines	The Httpry log file starts with comment headers	Add `next if /^#/;` at the start of the while loop
CLF output shows wrong field order	Tab-split index off by one	Print and count the raw fields to verify `@fields` alignment
`make install` fails with "no such file" for man page	Kali may not have `/usr/man/man1/` pre-created	This is a cosmetic error — the binary installs correctly to `/usr/sbin/`
pcap file has no HTTP traffic	Traffic was captured on HTTPS only	HTTP (port 80) traffic is needed; HTTPS (443) is encrypted and not visible to Httpry
`httpry_log.txt` is empty	Ran without `-q` and output went to stdout only	Use `-o filename.txt` to save to file

Conclusion

Httpry is one of those tools that earns its place precisely because it does one thing and does it well. When you need a fast answer to "what HTTP traffic happened between these IPs during this window?" — whether from a historical pcap or a live interface — Httpry gets you there without the overhead of full packet capture.

The CLF conversion step is a practical bridge between Httpry's output and the broader ecosystem of log analysis tools. Once your data is in CLF, you can pipe it into any number of parsers, dashboards, or SIEM inputs.

If you are building a network monitoring toolkit, Httpry deserves a spot alongside your pcap tools — not instead of them, but as a faster, lighter option for HTTP-specific questions.

Lab Task 10 -Packet Capture on Kali Linux: Daemonlogger Setup, Traffic Generation & Wireshark Analysis

Khalif AL Mahmud — Sat, 13 Jun 2026 05:18:06 +0000

There's a big difference between knowing a network tool exists and actually sitting down, running it, watching the packets pile up, and then making sense of what you captured. This post walks through exactly that — installing Daemonlogger on Kali Linux, generating real mixed traffic using ping, curl, iperf3, and a browser, then loading the .pcap file into Wireshark and pulling out meaningful numbers.

Everything here is from my own hands-on session. The screenshots are real, the packet counts are real, and the mistakes I made along the way were very real too.

Why Daemonlogger?

Most people reach for Wireshark when they want to capture traffic. That's fine for short sessions, but Wireshark's live capture is heavy — GUI, real-time rendering, constant screen updates. Daemonlogger is the opposite: a lightweight, command-line tool that runs quietly in the background and writes everything to a .pcap file. No GUI, no overhead. You generate traffic, stop it when you're done, and then open the file in Wireshark to analyze at your own pace.

For anything resembling real-world passive monitoring, that's a much cleaner workflow.

Environment

OS: Kali Linux 2026.1 (Oracle VirtualBox)
Network Interface: eth0 — IP 10.0.2.15
Tools used: daemonlogger, iperf3, curl, ping, Firefox browser, wireshark

Step 1 — Install Daemonlogger

sudo apt-get install daemonlogger -y

After installation, run it with --help to confirm it's working and to review the available flags:

daemonlogger --help

The key flags you'll use most:

Flag	Purpose
`-i <intf>`	Capture from this network interface
`-l <path>`	Write log files to this directory
`-n <name>`	Set the output filename prefix
`-d`	Daemonize (run in background)

Step 2 — Identify Your Network Interface

Before starting any capture, confirm which interface is active and note its IP address.

ip link show
ifconfig

In my setup, eth0 was the active interface at 10.0.2.15. The loopback lo was also present but not useful for capturing external traffic.

Step 3 — Create Log Directory and Start Capture

Create the directory where Daemonlogger will save the .pcap file:

sudo mkdir /var/log/daemonlogger

Then start the capture:

sudo daemonlogger -i eth0 -l /var/log/daemonlogger/ -n capture

Once you see "sniffing on interface eth0" and the .pcap filename appear, Daemonlogger is running and capturing everything. Leave this terminal open and move on to generating traffic.

Step 4 — Generate Traffic

ICMP — Ping

ping google.com -c 50

The ping resolved google.com to 142.250.187.78 and sent 22 packets before I stopped it. Zero packet loss. The curl to testph.vulnweb.com on port 80 timed out with a connection error — that attempt still generated DNS + TCP SYN traffic worth capturing.

HTTP — curl

curl http://testph.vulnweb.com

Even a failed connection creates traffic. DNS resolution, TCP handshake attempts, and RST/timeout packets all end up in the capture file.

TCP Throughput — iperf3

Open two terminals. In the first, start the iperf3 server:

iperf3 -s

In the second, connect as a client:

iperf3 -c 127.0.0.1 -t 30

The iperf3 test pushed ~43–46 Gbits/sec over loopback for 30 seconds. This floods the capture with a burst of TCP segments that show up clearly later in the IO Graph.

Website Visits — Browser

With Daemonlogger still running, I opened Firefox inside the Kali VM and visited several sites — including an intentionally unencrypted HTTP site:

http://neverssl.com

NeverSSL is designed specifically for this — it never redirects to HTTPS, so the full HTTP request and response are visible in the capture as plain text.

Step 5 — Stop Capture and Check the File

Stop Daemonlogger with:

sudo pkill daemonlogger

Then check what was saved:

ls -lh /var/log/daemonlogger/

Result: 13,439 packets captured in a 9.6 MB file. Zero drops — the system kept up with every single packet.

Step 6 — Install Wireshark and Open the File

sudo apt-get install wireshark -y
wireshark /var/log/daemonlogger/capture*.pcap

Wireshark loaded the full 13,439-packet capture without any issues.

Step 7 — Wireshark Analysis

HTTP Traffic

Display filter:

http

HTTP packet count: 25 (0.2% of total capture)

HTTPS Traffic

Display filter:

ssl || tls

HTTPS packet count: 1,833 (13.6% of total capture)

TCP Traffic

Display filter:

tcp

TCP packet count: 11,739 (87.4% of total capture)

This makes sense — HTTP, HTTPS, and iperf3 all run over TCP. Filtering tcp captures all of them plus the raw handshakes and teardowns.

Top Conversations

Navigate to: Statistics → Conversations → TCP tab

The machine at 10.0.2.15 was the top talker — all outbound traffic originated here. Top destinations:

Source IP	Destination IP	Port
10.0.2.15	34.107.243.93	443
10.0.2.15	34.223.124.45	80
10.0.2.15	34.223.124.45	443
10.0.2.15	44.228.249.3	443

Top Protocols by Usage

Navigate to: Statistics → Protocol Hierarchy

Protocol	% of Packets
TCP	100%
HTTP	8.7%
OCSP	8.7%
ICMP	present in unfiltered view

IO Graph

Navigate to: Statistics → I/O Graph

The IO graph tells the timing story of the entire session:

Spike at ~250s — the 30-second iperf3 burst pushing thousands of TCP segments per second
Quiet baseline — background HTTPS traffic from browser activity
Late spike near ~1000s — the NeverSSL and other website browsing sessions generating another burst

Capturing Login Credentials over HTTP

For any site using plain HTTP (no TLS), Wireshark can show form submissions in full. Apply this filter to find POST requests:

http.request.method == "POST"

Then right-click any matching packet → Follow → HTTP Stream to read the complete request body, including any username and password fields submitted through an HTML form.

This is exactly why HTTPS matters. The same capture on an HTTPS connection shows only encrypted TLS Application Data — credentials are completely invisible.

Results Summary

Metric	Value
Total packets captured	13,439
Capture file size	9.6 MB
HTTP packets	25 (0.2%)
HTTPS / TLS packets	1,833 (13.6%)
TCP packets	11,739 (87.4%)
Packets dropped by kernel	0
Top source IP	10.0.2.15
Top destination ports	443, 80

How to Verify

Step	What to check
Daemonlogger started	Output shows "sniffing on interface eth0"
Packets being captured	`.pcap` file grows in size while traffic runs
Clean stop	Output shows exact packet count and zero drops
Wireshark loads file	Packet list populates, no parse errors
`http` filter	Returns GET/POST/response packets
`ssl \	tls` filter
`tcp` filter	Returns ~87%+ of all packets
Conversations tab	Shows source/dest IP pairs with port numbers
IO Graph	Shows visible spikes at iperf3 burst timing

What I Learned

Going through this hands-on made a few things click that reading never quite did:

TCP is everywhere. Filtering tcp returns 87% of the capture because HTTP, HTTPS, iperf3, and most real-world traffic all run over TCP. The protocol isn't just one thing — it's the transport layer underneath almost everything.

Daemonlogger is better than live Wireshark for background capture. No GUI overhead, no rendering lag, just packets written to disk. For any kind of monitoring scenario, that matters.

Plain HTTP credentials are genuinely, immediately visible. Not "theoretically exposed" — actually readable, in plain text, in a filter result. Seeing it in Wireshark removes any remaining abstract quality from the risk.

IO graphs are often the first place to look. When something unusual happens on a network, the IO graph shows when it happened before you've read a single packet. The iperf3 spike is unmistakable — it's the tallest feature on the graph.

Zero packet drops is worth celebrating. At 43–46 Gbits/sec of iperf3 traffic, the Kali VM kept up with every single packet. That's worth noting because packet drop is a real issue in high-throughput capture environments.

Common Mistakes

Mistake	What happens	Fix
Running daemonlogger without `sudo`	Permission denied — raw socket access requires root	Always prefix with `sudo`
Skipping `mkdir` for the log directory	Daemonlogger exits immediately with path error	Create the directory first
Wrong interface name	No packets captured — capture starts but file stays empty	Verify with `ip link show` before starting
Opening `.pcap` before killing daemonlogger	Wireshark shows truncated/incomplete data	`sudo pkill daemonlogger` first, then open
Using only `ssl` filter	Misses QUIC and TLSv1.3 in newer captures	Use `ssl \
Expecting to see HTTPS credentials	Empty results from POST filter	Credential visibility only works on plain HTTP

Conclusion

The full workflow — Daemonlogger for silent capture, mixed traffic from {% raw %}ping, curl, iperf3, and real browser sessions, then Wireshark for structured analysis — gives you a complete picture of what's happening on a network interface. The numbers from this session (13,439 packets, 87.4% TCP, 1,833 TLS packets, 25 HTTP packets, zero drops) aren't just statistics. They show exactly how a modern endpoint behaves: mostly encrypted HTTPS, with TCP as the invisible backbone underneath all of it, and a small but meaningful slice of plain-text HTTP that should never carry sensitive data.

If you want to actually understand network traffic rather than just read about it, start here. Capture it, count it, follow the streams, and look at the IO graph. The packets tell the whole story.

Lab 9 - Building a Cisco ASA Firewall Lab in GNS3: Inside, DMZ, and Outside Zones with Extended ACLs

Khalif AL Mahmud — Fri, 12 Jun 2026 18:43:17 +0000

Firewalls sit at the heart of every real enterprise network. But reading about them and actually building one are two very different things. I wanted to go beyond theory and get hands-on experience — so I set up a full multi-zone network in GNS3 using a Cisco ASAv firewall, three routers, four PCs, and proper ACL rules.

This article walks through everything: importing the firewall into GNS3, building the topology, configuring security zones, setting up RIP routing, writing extended ACL rules, and verifying it all with pings and ICMP debug traces.

If you've been curious about how enterprise firewalls actually work — this is a good place to start.

Problem Statement

Most networking labs stop at basic routing. But in real environments, you need to separate trusted internal networks from public-facing servers and the outside world — and you need the firewall to enforce those boundaries.

The challenge here was to:

Import and configure a Cisco ASAv firewall inside GNS3
Build a topology with three distinct security zones: Inside (trusted LAN), DMZ (semi-trusted), and Outside (untrusted)
Assign the correct security levels to each firewall interface
Run RIP across all routers and the firewall so the whole topology can communicate
Write extended ACL rules that explicitly allow ICMP (ping) traffic in and out of each zone
Verify everything with ping tests and live ICMP debug traces on the firewall

The Topology

Before touching any commands, it helps to understand what we're building.

Network layout:

Zone	Network	Security Level	Devices
Inside (trusted LAN)	192.168.1.0/24	100	PC4, LAN-Switch
DMZ (semi-trusted)	192.168.20.0/24	50	PC3, DMZ-Switch
Outside (untrusted)	192.168.10.0/24, 192.168.30.0/24	0	PC1, PC2, Routers R1–R3

Firewall interfaces:

Interface	Zone	IP Address
GigabitEthernet0/0	inside	192.168.1.1
GigabitEthernet0/1	dmz	192.168.20.1
GigabitEthernet0/2	outside	192.168.40.2

Router-to-router links:

Link	IPs
R1 f0/0 ↔ R2 f0/0	1.1.1.1 / 1.1.1.2
R2 f1/0 ↔ R3 f0/0	2.2.2.1 / 2.2.2.2
R1 f1/0 ↔ R3 f1/0	3.3.3.1 / 3.3.3.2
R2 f2/0 ↔ ASA Gi0/2	192.168.40.1 / 192.168.40.2
R3 f2/0	192.168.30.1
R1 f2/0	192.168.10.1

Step 1 — Importing the Cisco ASAv Firewall into GNS3

The ASAv isn't built into GNS3 by default — you need to import it manually.

Steps:

Open GNS3 and click the device list panel on the left
At the bottom, click + New template
Choose Install an appliance from the GNS3 server (recommended) → click Next
From the Firewalls category, select Cisco ASAv → click Install
Choose Install the appliance on the GNS3 VM (recommended) → click Next
Select /bin/qemu-system-x86_64 as the Qemu binary → Next
Select ASAv version 9.9.2, click Import, and point it to your asav992.qcow2 file
If GNS3 warns about MD5 mismatch, click Yes to accept anyway
Once the status shows Ready to install, click Next → confirm with Yes → Finish

After installing, right-click the ASAv in your device list → Configure template → change the symbol to the classic asa icon so it's easy to identify on the canvas.

Drag the firewall onto the canvas and start it. Open its console — it will do a double boot (this is normal). Wait until you see:

ciscoasa>

Step 2 — Configuring PC IP Addresses

Each PC is a VPCS node. Open each console and assign IPs:

PC1 (Outside zone — 192.168.30.x):

ip 192.168.30.15 255.255.255.0 192.168.30.1
save

PC2 (Outside zone — 192.168.10.x):

ip 192.168.10.5 255.255.255.0 192.168.10.1
save

PC3 (DMZ zone):

ip 192.168.20.15 255.255.255.0 192.168.20.1
save

PC4 (Inside/LAN zone):

ip 192.168.1.15 255.255.255.0 192.168.1.1
save

Verify with show ip on each PC.

Step 3 — Configuring the Routers

All three routers use Cisco IOS. The configuration pattern is the same for each — assign IPs to interfaces, bring them up, then enable RIP.

R1 configuration:

enable
configure terminal

interface f0/0
 ip address 1.1.1.1 255.255.255.0
 no shutdown
 exit

interface f1/0
 ip address 3.3.3.1 255.255.255.0
 no shutdown
 exit

interface f2/0
 ip address 192.168.10.1 255.255.255.0
 no shutdown
 exit

router rip
 version 2
 no auto-summary
 network 1.1.1.0
 network 3.3.3.0
 network 192.168.10.0
 exit

do wr

R2 configuration:

enable
configure terminal

interface f0/0
 ip address 1.1.1.2 255.255.255.0
 no shutdown
 exit

interface f1/0
 ip address 2.2.2.1 255.255.255.0
 no shutdown
 exit

interface f2/0
 ip address 192.168.40.1 255.255.255.0
 no shutdown
 exit

router rip
 version 2
 no auto-summary
 network 1.1.1.0
 network 2.2.2.0
 network 192.168.40.0
 exit

do wr

R3 configuration:

enable
configure terminal

interface f0/0
 ip address 2.2.2.2 255.255.255.0
 no shutdown
 exit

interface f1/0
 ip address 3.3.3.2 255.255.255.0
 no shutdown
 exit

interface f2/0
 ip address 192.168.30.1 255.255.255.0
 no shutdown
 exit

router rip
 version 2
 no auto-summary
 network 2.2.2.0
 network 3.3.3.0
 network 192.168.30.0
 exit

do wr

Step 4 — Configuring the Cisco ASA Firewall

This is where things get interesting. The ASA uses a concept called security levels — every interface gets a name (zone) and a trust number from 0 to 100. Higher is more trusted.

Open the ASA console:

ciscoasa> en
Password: (just press Enter — no default password)
ciscoasa# configure terminal

Configure the Inside interface (security level 100 — most trusted):

interface gigabitEthernet 0/0
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
 no shutdown
 exit

When you type nameif inside, the ASA automatically sets security-level 100.

Configure the DMZ interface (security level 50):

interface gigabitEthernet 0/1
 nameif dmz
 security-level 50
 ip address 192.168.20.1 255.255.255.0
 no shutdown
 exit

Configure the Outside interface (security level 0 — least trusted):

interface gigabitEthernet 0/2
 nameif outside
 security-level 0
 ip address 192.168.40.2 255.255.255.0
 no shutdown
 exit

Verify your zones and IPs:

show nameif
show ip

Enable RIP on the firewall:

configure terminal
router rip
 version 2
 no auto-summary
 network 192.168.1.0
 network 192.168.20.0
 network 192.168.40.0
 exit

write memory

Step 5 — How ASA Security Levels Work

Before writing ACL rules, it's worth understanding why we need them.

The ASA's default behavior based on security levels:

Traffic Direction	Allowed by Default?
High → Low (e.g., inside → outside)	✅ Yes
Low → High (e.g., outside → inside)	❌ No
Same level → Same level	❌ No (unless configured)

So by default, inside can reach outside, but outside cannot reach inside. Even inside → DMZ pings will fail — because even though the request leaves the inside interface, the ICMP reply coming back from DMZ (lower security) to inside (higher security) is blocked.

This is why we write explicit ACL rules.

Step 6 — Creating Extended ACL Rules for ICMP

We need to allow ICMP traffic (ping) in and out of all three zones. The approach: create a named ACL for each interface in each direction, then bind it to the interface with access-group.

configure terminal

! --- Inside interface rules ---
access-list INSIDE_ACCESS_IN extended permit icmp any any
access-list INSIDE_ACCESS_OUT extended permit icmp any any
access-group INSIDE_ACCESS_IN in interface inside
access-group INSIDE_ACCESS_OUT out interface inside

! --- DMZ interface rules ---
access-list DMZ_ACCESS_IN extended permit icmp any any
access-list DMZ_ACCESS_OUT extended permit icmp any any
access-group DMZ_ACCESS_IN in interface dmz
access-group DMZ_ACCESS_OUT out interface dmz

! --- Outside interface rules ---
access-list OUTSIDE_ACCESS_IN extended permit icmp any any
access-list OUTSIDE_ACCESS_OUT extended permit icmp any any
access-group OUTSIDE_ACCESS_IN in interface outside
access-group OUTSIDE_ACCESS_OUT out interface outside

write memory

Verify all ACLs were created:

show access-list

Step 7 — Verifying with Ping Tests

Test 1: PC1 → PC2 (Outside to Outside)

Both are in the outside zone and communicate through the router infrastructure:

PC1> ping 192.168.10.5

Expected: 5/5 successful pings.

Test 2: PC4 → PC3 (Inside → DMZ)

PC4 is in the trusted LAN, PC3 is in the DMZ:

PC4> ping 192.168.20.15

Expected: 5/5 successful pings after ACLs are applied.

Step 8 — ICMP Debug Trace on the Firewall

The real power of the ASA is visibility. Enable debug mode on the firewall while running pings to see exactly what traffic is passing through:

ciscoasa# debug icmp trace

You'll see live output like:

ICMP echo request from inside:192.168.1.15 to dmz:192.168.20.15 ID=4758 seq=1 len=56
ICMP echo reply from dmz:192.168.20.15 to inside:192.168.1.15 ID=4758 seq=1 len=56

Both request and reply lines appearing means the ACL rules are working correctly.

To stop debug output:

ciscoasa# undebug all

How to Verify Everything Is Working

Check	Command	Expected Result
Firewall zones	`show nameif`	inside/100, dmz/50, outside/0
Firewall IPs	`show ip`	All three interfaces showing correct IPs
Router routes	`show ip route`	RIP routes (R) to all networks
Router interfaces	`show ip int br`	All configured interfaces showing "up/up"
PC addresses	`show ip` (in VPCS)	Correct IP/MASK/GATEWAY
ACL rules	`show access-list`	All 6 ACLs with permit icmp entries
Ping inside→dmz	`ping 192.168.20.15` from PC4	5/5 success
Ping outside→outside	`ping 192.168.10.5` from PC1	5/5 success
Debug trace	`debug icmp trace` on ASA	Paired request/reply lines

What I Learned

The Cisco ASA security level model is elegant — higher levels trust lower ones by default, but you still need explicit ACLs for stateful ICMP control
nameif is the ASA's way of naming and assigning a role to an interface — without it, the interface won't participate in any security policies
RIP on ASA works the same way as on IOS routers — but you have to remember to include all directly connected networks
The debug icmp trace command on the ASA is incredibly useful for real-time traffic verification — you can see exactly which interface traffic arrives on and leaves from
ACE order matters — the ASA processes access-list entries top to bottom and stops at the first match; a broad permit placed above a narrow deny will always win
The ASA blocks inbound ICMP replies by default even when the original request was allowed — which is why you need both in and out ACLs on each interface for full bidirectional ICMP

Common Mistakes

Mistake	What Happens	Fix
Forgetting `no shutdown` on ASA interfaces	Interface stays down, no traffic passes	Add `no shutdown` in interface config mode
Not adding `no auto-summary` in RIP	Classful summarization breaks routing	Always add `no auto-summary` with RIPv2
Applying ACL only in one direction	Ping requests go through but replies are dropped	Create both `_IN` and `_OUT` ACLs per interface
Forgetting `nameif` on ASA interfaces	Interface gets no security level or zone name	Always set `nameif` before assigning an IP
Setting wrong security level on outside	Traffic behavior becomes unpredictable	Outside should always be security-level 0
Not running `write memory` after config	All settings lost after reboot	Run `write memory` after every change
Assigning PC gateway to wrong IP	Pings fail even if firewall is correct	Gateway must match the firewall interface IP for that subnet

Conclusion

Deploying a Cisco ASA firewall in GNS3 goes well beyond just typing commands — it forces you to think about traffic flow, trust boundaries, and why explicit rules matter even when high-to-low traffic is theoretically allowed by default.

The topology we built here mirrors what you'd actually see in a small enterprise: an untrusted outside zone, a DMZ for semi-public services, and a protected internal LAN. Adding RIP made the routing dynamic, and the debug traces made the firewall's decisions fully transparent.

If you want to take this further, try replacing the ICMP-only ACLs with TCP rules for HTTP or SSH, or experiment with blocking specific hosts while allowing the rest of the subnet. The ASA's ACL engine gives you surgical-level control once you understand the order and direction model.

Lab Task 8 - How I Built a Multi-VLAN Network with Inter-VLAN Routing in GNS3 Using a Layer 3 Switch

Khalif AL Mahmud — Fri, 12 Jun 2026 15:08:46 +0000

Network segmentation is one of those concepts that sounds straightforward until you actually sit down and try to wire it up. I wanted to go beyond just reading about VLANs — I wanted to actually configure them, watch the traffic flow, and prove inter-VLAN communication works end-to-end. So I set up a GNS3 lab using a QEMU-based Cisco Layer 3 switch, built a three-PC topology across three VLANs, and got a successful ping from PC1 all the way to PC3.

This post walks through everything: setting up GNS3 with VMware, importing the Layer 3 switch as a QEMU VM, building the topology, configuring VLANs, setting up SVIs as gateways, and verifying inter-VLAN routing works.

The Problem

By default, devices in different VLANs cannot communicate with each other. That's the whole point of VLANs — isolation. But in a real network, you still need controlled communication between segments (e.g., the Sales team reaching the IT team's servers). That's where a Layer 3 switch with SVI (Switched Virtual Interface) routing comes in.

The goal of this lab:

Create three VLANs (VLAN 6 — SALES, VLAN 7 — HR, VLAN 8 — IT)
Connect one VPCS (virtual PC) to each VLAN
Configure a trunk port on the switch
Set up SVI gateways for each VLAN
Enable IP routing so PCs on different VLANs can ping each other

Topology

IP Plan:

Device	Interface	IP Address	Subnet Mask	Gateway	VLAN
PC1	e0	10.0.1.1	255.255.255.0	10.0.1.254	VLAN 6
PC2	e0	10.0.2.1	255.255.255.0	10.0.2.254	VLAN 7
PC3	e0	10.0.3.1	255.255.255.0	10.0.3.254	VLAN 8
SVI VLAN 6	—	10.0.1.254	255.255.255.0	—	—
SVI VLAN 7	—	10.0.2.254	255.255.255.0	—	—
SVI VLAN 8	—	10.0.3.254	255.255.255.0	—	—

Step 1 — Set Up GNS3 VM in VMware

Before anything else, GNS3 needs a backend VM to run QEMU-based appliances. The standard setup uses VMware Workstation with the GNS3 VM image.

Download VMware Workstation Pro and install it (accept the EULA, add it to system PATH).
Download the GNS3 VM .ova file from gns3.com/software/download-vm — choose the VMware Workstation version.
In VMware, go to File > Open, select the .ova, give it a name, and click Import.
Power on the GNS3 VM. You'll see the GNS3 server IP and port in the console.
Open GNS3 on your host, run the Setup Wizard, and choose Run appliances in a virtual machine.
Select VMware as the virtualization engine, pick your imported VM from the dropdown, and finish the wizard.
Go to Edit > Preferences > GNS3 VM, tick Enable the GNS3 VM, and click Apply.

Step 2 — Import the Layer 3 Switch as a QEMU VM

The Cisco IOSvL2 switch runs as a QEMU VM inside GNS3. Here's how to get it in.

Download the cisco-iosvl2.gns3a appliance file from the GNS3 Marketplace.
In GNS3, click the Switches icon in the left panel, then click + New template at the bottom.
Choose Import an appliance (.gns3a extension) and browse to the downloaded file.
Select Install the appliance on the GNS3 VM (recommended).
On the required files screen, select the IOSvL2 version that shows Ready to install and click Next.
The switch will now appear as Cisco IOSvL2 under the Switches panel.

Step 3 — Build the Topology

Drag one Cisco IOSvL2 switch onto the canvas.
Drag three VPCS nodes (PC1, PC2, PC3) onto the canvas.
Connect them:
- PC1 e0 → Switch e0
- PC2 e0 → Switch e1
- PC3 e0 → Switch e2
Add text labels for IP addresses, VLAN names, and gateway values.
Start all devices (green play button).

Step 4 — Configure VLANs on the Switch

Double-click the switch to open its console. Run:

Switch> enable
Switch# configure terminal

Switch(config)# vlan 6
Switch(config-vlan)# name SALES
Switch(config-vlan)# exit

Switch(config)# vlan 7
Switch(config-vlan)# name HR
Switch(config-vlan)# exit

Switch(config)# vlan 8
Switch(config-vlan)# name IT
Switch(config-vlan)# exit

Switch# show vlan brief

Expected output:

VLAN Name                             Status    Ports
---- -------------------------------- --------- --------------------------------
1    default                          active    Gi0/0, Gi0/1, Gi0/2, Gi0/3
6    SALES                            active
7    HR                               active
8    IT                               active

Step 5 — Configure Access Ports

Assign each switch port to the correct VLAN:

Switch# configure terminal

! PC1 connects on Gi0/0 → VLAN 6
Switch(config)# interface gi0/0
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 6
Switch(config-if)# exit

! PC2 connects on Gi0/1 → VLAN 7
Switch(config)# interface gi0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 7
Switch(config-if)# exit

! PC3 connects on Gi0/2 → VLAN 8
Switch(config)# interface gi0/2
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 8
Switch(config-if)# exit

Step 6 — Configure the Trunk Port

On a Layer 3 switch doing inter-VLAN routing, the uplink ports carrying multiple VLANs need to be trunk ports. If you have an uplink or a router-on-a-stick setup, configure it like this:

Switch(config)# interface gi0/3
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# exit

Switch# show interfaces trunk

Step 7 — Configure SVI Gateways and Enable IP Routing

This is the heart of inter-VLAN routing. Each VLAN gets a virtual interface (SVI) with an IP that acts as the default gateway for devices in that VLAN.

Switch# configure terminal

! Enable IP routing — only needed once
Switch(config)# ip routing

! SVI for VLAN 6
Switch(config)# interface vlan 6
Switch(config-if)# ip address 10.0.1.254 255.255.255.0
Switch(config-if)# no shutdown
Switch(config-if)# exit

! SVI for VLAN 7
Switch(config)# interface vlan 7
Switch(config-if)# ip address 10.0.2.254 255.255.255.0
Switch(config-if)# no shutdown
Switch(config-if)# exit

! SVI for VLAN 8
Switch(config)# interface vlan 8
Switch(config-if)# ip address 10.0.3.254 255.255.255.0
Switch(config-if)# no shutdown
Switch(config-if)# exit

Switch(config)# do write

Step 8 — Assign IPs to the PCs

Open each VPCS console and assign its IP and gateway:

PC1:

PC1> ip 10.0.1.1/24 10.0.1.254
PC1> save

PC2:

PC2> ip 10.0.2.1/24 10.0.2.254
PC2> save

PC3:

PC3> ip 10.0.3.1/24 10.0.3.254
PC3> save

How to Verify

1. Check VLANs exist on the switch

Switch# show vlan brief

All three VLANs (6, 7, 8) should be listed as active.

2. Check trunk interface

Switch# show interfaces trunk

Verify the trunk port is up and the expected VLANs are listed.

3. Ping from PC1 to PC3 (cross-VLAN)

PC1> ping 10.0.3.1

Expected output:

84 bytes from 10.0.3.1 icmp_seq=2 ttl=63 time=1.784 ms
84 bytes from 10.0.3.1 icmp_seq=3 ttl=63 time=1.735 ms
84 bytes from 10.0.3.1 icmp_seq=4 ttl=63 time=1.547 ms

What I Learned

Working through this lab made a few things click that had always felt a bit abstract:

VLANs are logical, not physical. Three PCs connected to the same physical switch are completely isolated from each other just by VLAN assignment. It's powerful and the configuration is surprisingly minimal.

SVIs are elegant. Instead of needing a separate router, you assign virtual IPs directly to VLAN interfaces on the L3 switch. The switch handles routing internally. ip routing is the one command that unlocks this.

Access vs. trunk is everything. Getting confused between access ports (one VLAN, for end devices) and trunk ports (multiple VLANs, for switch-to-switch or switch-to-router links) is probably the most common source of VLAN misconfigurations.

GNS3 VM setup matters. Running QEMU-based appliances like the Cisco IOSvL2 requires the GNS3 VM to be properly configured and reachable. If the VM isn't green in GNS3, the switch won't start — so fixing the VM setup first saves a lot of frustration later.

Common Mistakes

Mistake	What Happens	Fix
Forgetting `ip routing` on the switch	Pings between VLANs fail silently	Run `ip routing` in global config mode
Wrong VLAN ID on access port	PC is in the wrong VLAN; can't reach its gateway	Double-check with `show vlan brief`
SVI IP on wrong subnet	Gateway unreachable from the PC	Match the SVI IP to the PC's subnet
Missing `no shutdown` on SVI	SVI stays down; routing doesn't work	Always add `no shutdown` after assigning IP
GNS3 VM not running	QEMU switch won't start	Ensure VM is powered on and green in GNS3
Dot1q encapsulation skipped	Trunk port won't pass VLAN traffic	Add `switchport trunk encapsulation dot1q` before `switchport mode trunk`

Conclusion

This lab is a great way to understand how VLANs actually work in practice — not just the theory. Setting up the environment from scratch (VMware, GNS3 VM, importing the QEMU switch) teaches you to troubleshoot the virtualization layer before you even get to networking. And once the topology is up, watching a ping travel from PC1 in VLAN 6 across the L3 switch into VLAN 8 and land on PC3 makes the whole concept of inter-VLAN routing concrete.

Lab Task 7 - How I Used Wireshark to Capture ICMP and DHCP Traffic in a GNS3 Network

Khalif AL Mahmud — Thu, 11 Jun 2026 19:57:13 +0000

If you've ever wondered what actually happens on the wire when you run a ping command — or how a PC automatically gets its IP address — this post is for you. I set up a small network in GNS3, ran some pings, configured a DHCP server on a Cisco router, and captured everything with Wireshark. Here's exactly what I did and what I found.

The Problem I Was Solving

Networking theory is one thing. Seeing the packets is another.

I wanted to answer three practical questions:

When a ping travels across a link, what IP and MAC addresses does Wireshark actually show — and do they change hop by hop?
How do you configure a Cisco router as a DHCP server so that every PC on the segment gets an address automatically?
What do the four DHCP messages (Discover → Offer → Request → Acknowledge) look like at Layer 2 and Layer 3?

Part A — ICMP (Ping) Analysis

Network Topology

The Part A topology has two routers (R1, R2), two switches, and four PCs spread across three subnets:

Subnet	Network	Device Interfaces
Left LAN	192.168.0.0/24	R1 f0/0 = .0.1 · PC1 = .0.10 · PC2
Link 1 (WAN)	192.168.2.0/24	R1 f2/0 = .2.1 · R2 f0/0 = .2.2
Right LAN	192.168.1.0/24	R2 f2/0 = .1.1 · PC3 · PC4 = .1.10

Configuring R1

R1(config)# interface f0/0
R1(config-if)# ip address 192.168.0.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface f2/0
R1(config-if)# ip address 192.168.2.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# router rip
R1(config-router)# version 2
R1(config-router)# network 192.168.0.0
R1(config-router)# network 192.168.2.0
R1(config-router)# no auto-summary

Configuring R2

R2(config)# interface f2/0
R2(config-if)# ip address 192.168.1.1 255.255.255.0
R2(config-if)# no shutdown

R2(config)# interface f0/0
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# no shutdown

R2(config)# router rip
R2(config-router)# version 2
R2(config-router)# network 192.168.1.0
R2(config-router)# network 192.168.2.0
R2(config-router)# no auto-summary

Configuring PC1 and PC4 (Static IPs)

# PC1
PC1> ip 192.168.0.10 192.168.0.1 24

# PC4
PC4> ip 192.168.1.10 192.168.1.1 24

Task 1 — Ping R1 from PC1, Capture on Link 2

Link 2 sits between Switch1 and R1 (the f0/0 segment, 192.168.0.0/24). Wireshark was started on that link before the ping.

PC1> ping 192.168.0.1

Because source and destination are on the same subnet, the packet never leaves the LAN. At Layer 3 both addresses stay the same for every packet. At Layer 2 the source MAC is PC1's NIC and the destination MAC is R1's f0/0 interface — resolved via ARP before the first echo request goes out.

Field	Value
Src IP	192.168.0.10
Dst IP	192.168.0.1
Src MAC	PC1 NIC MAC
Dst MAC	R1 f0/0 MAC

Task 2 — Ping R2 from R1, Capture on Link 1

Link 1 is the 192.168.2.0/24 WAN link between the two routers.

R1# ping 192.168.2.2

Both ends of this link are directly connected, so IP addresses stay as-is. MACs are the router interface MACs on either side of Link 1.

Field	Value
Src IP	192.168.2.1
Dst IP	192.168.2.2
Src MAC	R1 f2/0 MAC
Dst MAC	R2 f0/0 MAC

Task 3 — Ping R2 from PC4, Capture on Link 3

Link 3 is the 192.168.1.0/24 right-side LAN between Switch2 and R2.

PC4> ping 192.168.1.1

The destination (R2 f2/0) is on the same subnet as PC4, so the packet is delivered directly. Wireshark on Link 3 sees PC4's MAC as source and R2's f2/0 MAC as destination.

Field	Value
Src IP	192.168.1.10
Dst IP	192.168.1.1
Src MAC	PC4 NIC MAC
Dst MAC	R2 f2/0 MAC

Key Insight — Why MACs Change But IPs Don't

IP addresses identify end-to-end communication and stay the same across the entire path. MAC addresses are only meaningful on the local segment — they change at every router hop because the router strips the old frame and builds a brand-new one for the next hop.

Part B — DHCP Configuration and DORA Capture

Network Topology

Part B is simpler: one router (R1) connected through a single switch to four PCs, all on the 192.160.0.0/24 subnet. R1 acts as the DHCP server.

Configuring the Interface on R1

R1(config)# interface f0/0
R1(config-if)# ip address 192.160.0.1 255.255.255.0
R1(config-if)# no shutdown

Configuring the DHCP Pool on R1

R1(config)# ip dhcp excluded-address 192.160.0.1
R1(config)# ip dhcp pool LAN_POOL_B
R1(dhcp-config)# network 192.160.0.0 255.255.255.0
R1(dhcp-config)# default-router 192.160.0.1
R1(dhcp-config)# dns-server 8.8.8.8

The excluded-address line protects the router's own IP from being handed out to a client. Everything from .2 upward is fair game.

Verifying the Interface

R1# show ip interface brief

Confirm that FastEthernet0/0 shows 192.160.0.1 with status up/up.

Requesting IPs on the PCs

PC1> ip dhcp
PC2> ip dhcp
PC3> ip dhcp
PC4> ip dhcp

Each PC runs the full DORA exchange and receives an address:

PC	Assigned IP
PC1	192.160.0.2
PC2	192.160.0.3
PC3	192.160.0.4
PC4	192.160.0.5

Verifying DHCP Bindings on R1

R1# show ip dhcp binding

This lists every IP that has been leased, along with the client MAC and lease expiry time.

The DORA Process — What Wireshark Shows

Wireshark was running on Link 1 (between R1 and Switch1) while PC1 ran ip dhcp. Applying the dhcp display filter reveals four packets:

Filter: dhcp

Discover

The PC has no IP yet. It broadcasts from 0.0.0.0 to 255.255.255.255, asking if any DHCP server is available.

Field	Value
Src IP	0.0.0.0
Dst IP	255.255.255.255
Src MAC	PC1 NIC MAC
Dst MAC	ff:ff:ff:ff:ff:ff

Offer

R1 responds with a proposed IP address, unicast back toward PC1.

Field	Value
Src IP	192.160.0.1
Dst IP	192.160.0.2
Src MAC	R1 f0/0 MAC
Dst MAC	PC1 NIC MAC

Request

PC1 broadcasts again, formally requesting the offered address.

Field	Value
Src IP	0.0.0.0
Dst IP	255.255.255.255
Src MAC	PC1 NIC MAC
Dst MAC	ff:ff:ff:ff:ff:ff

Acknowledge

R1 confirms the lease.

Field	Value
Src IP	192.160.0.1
Dst IP	192.160.0.2
Src MAC	R1 f0/0 MAC
Dst MAC	PC1 NIC MAC

How to Verify Everything Worked

# On R1 — confirm interface is up
R1# show ip interface brief

# On R1 — confirm leases are active
R1# show ip dhcp binding

# On any PC — confirm assigned address
PC1> show

# From PC — test connectivity to gateway
PC1> ping 192.160.0.1

What I Learned

MACs are local, IPs are global. Every time a frame crosses a router, the Layer 2 header is completely rebuilt. The Layer 3 header is untouched.
Wireshark placement matters. Capturing on Link 2 vs Link 1 gives completely different MAC addresses for the same ping, because the frame is re-encapsulated at R1.
DHCP Discover and Request use broadcast at both layers — the PC literally has no address to use yet, so it shouts to everyone.
RIPv2 with no auto-summary is essential when your subnets could be summarized incorrectly by classful routing behaviour.
ip dhcp excluded-address must be configured before the pool, or the router's own IP could be handed to a client and cause an address conflict.

Common Mistakes

Mistake	What Goes Wrong	Fix
Forgetting `no shutdown` on an interface	Interface stays down, no traffic flows	Always run `no shutdown` after assigning an IP
Wrong subnet in `network` command under RIP	Routes not advertised to the other router	Match the exact network address of each interface
Missing `no auto-summary` in RIPv2	Classful summarization silently drops subnets	Always add `no auto-summary` with RIPv2
Not excluding the router IP from DHCP pool	Router's own IP could be leased to a PC	Use `ip dhcp excluded-address` before creating the pool
Applying the wrong Wireshark filter	All protocols shown, hard to find what you need	Use `icmp` or `dhcp` as the display filter
Capturing on the wrong link	MAC addresses won't match what you expect	Understand which segment you're on before starting a capture

Conclusion

Setting up this lab made abstract networking concepts click in a way that textbooks alone never could. Watching the MAC address change at the router boundary while the IP stays constant is one of those genuine "aha" moments. And seeing the DORA exchange live in Wireshark makes DHCP feel concrete rather than magical.

If you're learning networking and haven't tried packet capture in GNS3 yet — start here. The tools are free, the setup is repeatable, and what you see in Wireshark will stick with you far longer than any diagram.

Lab Task 6 - How I Built a Multi-Router DHCP Network in GNS3 with RIP Routing

Khalif AL Mahmud — Thu, 11 Jun 2026 19:09:31 +0000

There's something satisfying about watching a PC automatically grab an IP address from a DHCP server you configured yourself. No typing. No guessing. The router just hands it over.

In this post, I'll walk through how I set up a two-router GNS3 topology where four virtual PCs get their IP addresses via DHCP — across two different subnets, connected through RIP routing. Everything was done inside GNS3 using Cisco IOS routers and VPCS nodes.

By the end, PC1 (on the 192.168.0.0/24 network) was successfully pinging PC4 (on the 192.168.1.0/24 network). That cross-subnet ping only works when routing, DHCP, and IP addressing are all wired together correctly.

The Problem

Running DHCP across a single subnet is straightforward. But what happens when you have two separate LANs connected by routers — and you want DHCP to work on both sides?

You need:

Each router to serve as a DHCP server for its own local subnet
Routing configured between routers so packets can actually travel between subnets
Router interfaces manually assigned static IPs (DHCP is for end devices only)

That's exactly what this topology covers.

Topology Overview

R1 serves DHCP for the 192.168.0.0/24 subnet (PC1 and PC2)
R2 serves DHCP for the 192.168.1.0/24 subnet (PC3 and PC4)
RIP is used to share routing information between R1 and R2
All router interfaces are manually configured (No DHCP on router ports)

Step 1 — Configure R1 Interfaces

Open R1's console and assign static IPs to both interfaces.

R1> enable
R1# configure terminal

R1(config)# interface fa0/0
R1(config-if)# ip address 192.168.0.1 255.255.255.0
R1(config-if)# no shutdown

R1(config)# interface fa2/0
R1(config-if)# ip address 192.168.2.1 255.255.255.0
R1(config-if)# no shutdown

R1(config)# end

Step 2 — Configure R2 Interfaces

Same process on R2, but with its own IP addresses.

R2> enable
R2# configure terminal

R2(config)# interface fa0/0
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# no shutdown

R2(config)# interface fa2/0
R2(config-if)# ip address 192.168.1.1 255.255.255.0
R2(config-if)# no shutdown

R2(config)# end

Step 3 — Configure RIP on R1

RIP version 2 tells R1 to advertise its connected networks so R2 knows how to reach 192.168.0.0/24.

R1(config)# router rip
R1(config-router)# version 2
R1(config-router)# network 192.168.0.0
R1(config-router)# network 192.168.2.0
R1(config-router)# no auto-summary
R1(config-router)# exit

Step 4 — Configure RIP on R2

R2(config)# router rip
R2(config-router)# version 2
R2(config-router)# network 192.168.1.0
R2(config-router)# network 192.168.2.0
R2(config-router)# no auto-summary
R2(config-router)# exit

Step 5 — Verify Routing Tables

After RIP converges (usually within 30–60 seconds), check the routing tables. You should see RIP-learned routes marked with R.

On R1:

R1# show ip route

Expected output includes:

R    192.168.1.0/24 [120/1] via 192.168.2.2, FastEthernet2/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet2/0

On R2:

R2# show ip route

Expected output includes:

R    192.168.0.0/24 [120/1] via 192.168.2.1, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet2/0
C    192.168.2.0/24 is directly connected, FastEthernet0/0

Step 6 — Configure DHCP on R1

R1 will hand out IPs in the 192.168.0.0/24 range to PC1 and PC2.

R1(config)# ip dhcp pool SUBNET1
R1(dhcp-config)# network 192.168.0.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.0.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# exit

R1(config)# ip dhcp excluded-address 192.168.0.1

Step 7 — Configure DHCP on R2

R2 handles DHCP for PC3 and PC4 on the 192.168.1.0/24 subnet.

R2(config)# ip dhcp pool SUBNET2
R2(dhcp-config)# network 192.168.1.0 255.255.255.0
R2(dhcp-config)# default-router 192.168.1.1
R2(dhcp-config)# dns-server 8.8.8.8
R2(dhcp-config)# exit

R2(config)# ip dhcp excluded-address 192.168.1.1

Step 8 — Configure PCs to Use DHCP

In GNS3, each VPCS node just needs a single command to request an IP via DHCP.

PC1:

PC1> ip dhcp

PC2:

PC2> ip dhcp

PC3:

PC3> ip dhcp

PC4:

PC4> ip dhcp

Each PC should respond with something like:

DDORA IP 192.168.0.2/24 GW 192.168.0.1

The DDORA output means the full DHCP handshake completed: Discover → Discover (server) → Offer → Request → Acknowledge.

Step 9 — Verify DHCP Bindings

Run this on both routers to confirm which MAC addresses received which IPs.

R1# show ip dhcp binding
R2# show ip dhcp binding

You should see entries for the PCs that requested IPs, with their assigned addresses and lease times.

Step 10 — Check Interface Summary

R1# show ip int br
R2# show ip int br

All interfaces used in the topology should show up/up.

Step 11 — Ping Tests

Ping PC4 from PC1 (cross-subnet ping — this is the real test):

PC1> ping 192.168.1.3

Expected result:

84 bytes from 192.168.1.3 icmp_seq=3 ttl=62 time=60.528 ms
84 bytes from 192.168.1.3 icmp_seq=4 ttl=62 time=61.646 ms
84 bytes from 192.168.1.3 icmp_seq=5 ttl=62 time=61.215 ms

Ping PC2 from PC3 (reverse direction):

PC3> ping 192.168.0.3

Expected result:

84 bytes from 192.168.0.3 icmp_seq=3 ttl=62 time=61.733 ms
84 bytes from 192.168.0.3 icmp_seq=4 ttl=62 time=47.556 ms
84 bytes from 192.168.0.3 icmp_seq=5 ttl=62 time=62.207 ms

How to Verify Everything is Working

Check	Command	What to Look For
Interface IPs assigned	`show ip int br`	All interfaces `up/up`
RIP routes learned	`show ip route`	`R` entries for remote subnets
DHCP leases issued	`show ip dhcp binding`	MAC-to-IP entries for all PCs
PCs got IPs	`ip dhcp` on each VPCS	`DDORA IP x.x.x.x/24` response
Cross-subnet ping works	`ping <remote PC IP>`	Replies with TTL=62

What I Learned

Working through this lab made a few things click that I hadn't fully internalized before:

DHCP scope matters — The excluded-address command is easy to forget but important. Without it, the router could assign its own interface IP to a PC, causing an IP conflict.

RIP convergence takes time — If you configure DHCP and run ip dhcp on a PC before RIP finishes converging, pings will fail even though DHCP worked. Waiting 30–60 seconds after configuring RIP saves a lot of confusion.

TTL=62 tells a story — When pinging across two routers, the TTL drops by 1 per hop. Seeing TTL=62 (from a starting TTL of 64) confirms the packet traveled through exactly two routers.

DDORA is your confirmation — That output from VPCS after ip dhcp is the clearest sign that the entire DHCP process completed. If you only see D and it stops, your router's DHCP pool isn't reachable.

no auto-summary matters in RIP v2 — Without it, RIP summarizes subnets at classful boundaries. In a topology like this where all subnets share the 192.168.x.x space, it can cause routing issues.

Common Mistakes

Mistake	What Happens	Fix
Forgetting `no shutdown` on interfaces	Interface stays down, no traffic passes	Always follow IP assignment with `no shutdown`
Missing `no auto-summary` in RIP	Remote subnets may not be reachable	Add `no auto-summary` under `router rip`
Not excluding the gateway IP from DHCP pool	Router's own IP could be assigned to a PC	Use `ip dhcp excluded-address` for gateway IPs
Running `ip dhcp` on PCs before RIP converges	Ping fails even though DHCP works	Wait 30–60 seconds after RIP config
Wrong interface selected for DHCP pool	PCs get wrong gateway or no IP	Match `default-router` to the interface facing the PCs
Pinging by IP instead of using the actual assigned address	Misleading results	Always verify the assigned IP via `ip dhcp` response first

Conclusion

This topology covers a lot of ground for what looks like a simple setup. You're dealing with static interface addressing, DHCP pools on two separate subnets, dynamic routing with RIP, and cross-subnet connectivity — all in one lab.

The ping from PC1 to PC4 working end-to-end is a real confidence check. It means your routing table has the right entries, DHCP handed out the correct gateway, and packets are actually traveling the full path through both routers.

If you're building out GNS3 labs and want to go further, try replacing RIP with OSPF, or add a third router and see how the routing table changes.

Lab Task 5 - Subnetting in GNS3: Building a Multi-Subnet Network with OSPF Routing from Scratch

Khalif AL Mahmud — Thu, 11 Jun 2026 15:09:52 +0000

There is a point in every networking journey when reading about subnets stops being enough. You know the formulas, you can do the math on paper — but until you wire up a real (or virtual) topology and watch packets actually cross subnet boundaries, it doesn't fully click.

This post walks through exactly that. I took a single Class C address block (192.168.43.0/24), carved it into /30 and /28 subnets, built a three-router topology in GNS3 with six PCs across four switches, configured OSPF on every router, and verified end-to-end connectivity with ping tests. Everything is documented here — the subnet math, the router commands, the PC configs, and the verification steps.

The Problem: One Address Space, Multiple Isolated Networks

The starting point is a single IP block: 192.168.43.0/24. The goal is to divide it into smaller subnets that serve different parts of the topology.

From the topology diagram:

Two router-to-router links need /30 subnets (point-to-point, only 2 usable hosts needed)
Four LAN segments — each hosting a switch and PCs — need /28 subnets (up to 14 usable hosts)

Borrowing bits from the /24:

/30 = borrow 6 bits from the host portion (30 − 24 = 6)
/28 = borrow 4 bits from the host portion (28 − 24 = 4)

Step 1: Subnet Calculation

Before touching GNS3, the math needs to be right. Here is the full breakdown.

/30 Subnets — Router-to-Router Links

Subnet #	Network Address	Subnet Mask	Usable Hosts	Host Range
/30 Subnet 1	192.168.43.0	255.255.255.252	2	.1 – .2
/30 Subnet 2	192.168.43.4	255.255.255.252	2	.5 – .6

A /30 gives you 4 addresses total: network address, 2 usable hosts, broadcast. Perfect for a point-to-point router link.

/28 Subnets — LAN Segments

Subnet #	Network Address	Subnet Mask	Usable Hosts	Host Range
/28 Subnet 1	192.168.43.16	255.255.255.240	14	.17 – .30
/28 Subnet 2	192.168.43.32	255.255.255.240	14	.33 – .46
/28 Subnet 3	192.168.43.48	255.255.255.240	14	.49 – .62
/28 Subnet 4	192.168.43.64	255.255.255.240	14	.65 – .78

A /28 gives you 16 addresses total: 14 usable. Each LAN segment (Switch + 2 PCs) connects to one of these.

Step 2: IP Address Assignment Plan

With the subnets defined, addresses get assigned to every interface and PC before building anything in GNS3.

Device	Interface	IP Address	Subnet Mask	CIDR
R1	f0/0 (to R2)	192.168.43.1	255.255.255.252	/30
R1	f2/0 (to R3)	192.168.43.5	255.255.255.252	/30
R2	f0/0 (to R1)	192.168.43.2	255.255.255.252	/30
R2	f2/0 (LAN 1)	192.168.43.17	255.255.255.240	/28
R2	f3/0 (LAN 2)	192.168.43.33	255.255.255.240	/28
R3	f0/0 (to R1)	192.168.43.6	255.255.255.252	/30
R3	f2/0 (LAN 3)	192.168.43.49	255.255.255.240	/28
R3	f3/0 (LAN 4)	192.168.43.65	255.255.255.240	/28
PC1	e0	192.168.43.18	255.255.255.240	/28
PC2	e0	192.168.43.19	255.255.255.240	/28
PC3	e0	192.168.43.34	255.255.255.240	/28
PC4	e0	192.168.43.35	255.255.255.240	/28
PC5	e0	192.168.43.50	255.255.255.240	/28
PC6	e0	192.168.43.66	255.255.255.240	/28

Step 3: Build the Topology in GNS3

The topology looks like this:

Step 4: Configure the Routers

Router R1

R1# configure terminal

! Interface toward R2 (/30)
R1(config)# interface fastEthernet 0/0
R1(config-if)# ip address 192.168.43.1 255.255.255.252
R1(config-if)# no shutdown

! Interface toward R3 (/30)
R1(config)# interface fastEthernet 2/0
R1(config-if)# ip address 192.168.43.5 255.255.255.252
R1(config-if)# no shutdown

R1(config)# end
R1# write memory

Static routing is skipped entirely here. OSPF is used so routers discover all subnets dynamically — no manual route entries needed, and the network adapts if something changes.

All routers use OSPF process ID 1 and area 0 (the backbone area).

OSPF on R1

R1# configure terminal
R1(config)# router ospf 1
R1(config-router)# network 192.168.43.0 0.0.0.3 area 0
R1(config-router)# network 192.168.43.4 0.0.0.3 area 0
R1(config-router)# end
R1# write memory

Router R2

R2# configure terminal

! Interface toward R1 (/30)
R2(config)# interface fastEthernet 0/0
R2(config-if)# ip address 192.168.43.2 255.255.255.252
R2(config-if)# no shutdown

! Interface toward Switch1 / LAN1 (/28)
R2(config)# interface fastEthernet 2/0
R2(config-if)# ip address 192.168.43.17 255.255.255.240
R2(config-if)# no shutdown

! Interface toward Switch2 / LAN2 (/28)
R2(config)# interface fastEthernet 3/0
R2(config-if)# ip address 192.168.43.33 255.255.255.240
R2(config-if)# no shutdown

R2(config)# end
R2# write memory

OSPF on R2

R2# configure terminal
R2(config)# router ospf 1
R2(config-router)# network 192.168.43.0 0.0.0.3 area 0
R2(config-router)# network 192.168.43.16 0.0.0.15 area 0
R2(config-router)# network 192.168.43.32 0.0.0.15 area 0
R2(config-router)# end
R2# write memory

Router R3

R3# configure terminal

! Interface toward R1 (/30)
R3(config)# interface fastEthernet 0/0
R3(config-if)# ip address 192.168.43.6 255.255.255.252
R3(config-if)# no shutdown

! Interface toward Switch3 / LAN3 (/28)
R3(config)# interface fastEthernet 2/0
R3(config-if)# ip address 192.168.43.49 255.255.255.240
R3(config-if)# no shutdown

! Interface toward Switch4 / LAN4 (/28)
R3(config)# interface fastEthernet 3/0
R3(config-if)# ip address 192.168.43.65 255.255.255.240
R3(config-if)# no shutdown

R3(config)# end
R3# write memory

OSPF on R3

R3# configure terminal
R3(config)# router ospf 1
R3(config-router)# network 192.168.43.4 0.0.0.3 area 0
R3(config-router)# network 192.168.43.48 0.0.0.15 area 0
R3(config-router)# network 192.168.43.64 0.0.0.15 area 0
R3(config-router)# end
R3# write memory

Why wildcard masks? The wildcard mask is the inverse of the subnet mask. For a /30 (mask 255.255.255.252), the wildcard is 0.0.0.3. For a /28 (mask 255.255.255.240), the wildcard is 0.0.0.15. OSPF uses these to match which interfaces to include in the routing process.

Step 5: Configure the PCs (VPCS)

VPCS uses a simple one-liner per PC. The gateway in each case is the router interface on the same /28 subnet.

# PC1 — LAN1, Switch1
PC1> ip 192.168.43.18 255.255.255.240 192.168.43.17

# PC2 — LAN1, Switch1
PC2> ip 192.168.43.19 255.255.255.240 192.168.43.17

# PC3 — LAN2, Switch2
PC3> ip 192.168.43.34 255.255.255.240 192.168.43.33

# PC4 — LAN2, Switch2
PC4> ip 192.168.43.35 255.255.255.240 192.168.43.33

# PC5 — LAN3, Switch3
PC5> ip 192.168.43.50 255.255.255.240 192.168.43.49

# PC6 — LAN4, Switch4
PC6> ip 192.168.43.66 255.255.255.240 192.168.43.65

Step 6: Verify Routing Tables

After OSPF converges (usually within 30–60 seconds), check that each router has learned all subnets.

R1# show ip route

Expected output will include O (OSPF-learned) entries for all /28 subnets that R1 doesn't directly own, alongside C (Connected) entries for its own /30 links.

R2# show ip route
R3# show ip route

How to Verify: Ping Tests

The real confirmation is cross-subnet pings.

Ping PC6 from PC1

PC1 is on 192.168.43.16/28 (LAN1, connected to R2).

PC6 is on 192.168.43.64/28 (LAN4, connected to R3).

Traffic must travel: PC1 → R2 → R1 → R3 → PC6.

PC1> ping 192.168.43.66

Expected: 5 successful replies from 192.168.43.66.

Ping PC5 from PC3

PC3 is on 192.168.43.32/28 (LAN2, connected to R2).

PC5 is on 192.168.43.48/28 (LAN3, connected to R3).

Traffic must travel: PC3 → R2 → R1 → R3 → PC5.

PC3> ping 192.168.43.50

Expected: 5 successful replies from 192.168.43.50.

What I Learned

Working through this end-to-end, a few things stood out that are easy to get wrong or gloss over in theory:

Wildcard masks trip people up. When you first encounter OSPF's network command, the wildcard syntax feels backwards. The key insight is: it's not a subnet mask. It's a "don't care" mask. Bits set to 1 mean "I don't care about this bit." So 0.0.0.15 means the last 4 bits are flexible — matching any address in that /28 block.

OSPF needs all networks advertised. Forgetting to include even one network statement under router ospf means that subnet won't be shared with neighbors. The ping will fail and it's not immediately obvious why — show ip route on the remote router will simply be missing that subnet.

Subnet size selection is deliberate. Using a /30 for a router-to-router link instead of a /28 isn't just aesthetics — it conserves address space. A /28 wastes 12 addresses on a link that only ever needs 2. When you're working with limited address space, that discipline matters.

Label everything before you configure. Trying to assign IPs while building the topology in GNS3 leads to mistakes. Doing the full address plan first on paper (or in a table) and then just applying it makes configuration mechanical and fast.

Common Mistakes

Mistake	Why It Happens	How to Fix
Wrong wildcard mask in OSPF	Confusing it with subnet mask	Wildcard = bitwise inverse of subnet mask
PC default gateway not set	Assuming it's automatic in VPCS	Always include the gateway in the `ip` command
Interface left in `shutdown` state	Cisco routers default to shutdown	Always add `no shutdown` after configuring an interface
Subnet overlap	Miscalculating block boundaries	Use a subnet calculator to verify ranges before assigning
OSPF not converging	Not enough time after configuration	Wait 30–60 seconds; use `show ip ospf neighbor` to check adjacency
Missing `network` statement	Only configuring some interfaces in OSPF	Run `show ip ospf interface brief` to see which interfaces are in OSPF
Wrong subnet mask on PC	Copying the router's mask without checking	Each PC mask must match the `/28` subnet it sits in (`255.255.255.240`)

Conclusion

Subnetting is one of those topics where the gap between understanding it and actually doing it is wider than expected. Building this topology — calculating the blocks, assigning addresses, configuring interfaces, running OSPF, and watching the pings succeed — closes that gap in a way that no amount of reading does.

The key workflow that made it clean: plan first, configure second, verify last. Get the entire address table done before opening GNS3. Then configuration becomes mechanical, and any failures point clearly to a mistake in either math or typing.

If you're working through something similar, the routing table output from show ip route is your best debugging tool. If a subnet is missing there, OSPF hasn't learned it — and the ping will fail before it even tries.