DEV Community

Khalif AL Mahmud
Khalif AL Mahmud

Posted on

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

#firewall #gns3 #networking #ciscoasa

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:

  1. Open GNS3 and click the device list panel on the left
  2. At the bottom, click + New template
  3. Choose Install an appliance from the GNS3 server (recommended) → click Next
  4. From the Firewalls category, select Cisco ASAv → click Install
  5. Choose Install the appliance on the GNS3 VM (recommended) → click Next
  6. Select /bin/qemu-system-x86_64 as the Qemu binary → Next
  7. Select ASAv version 9.9.2, click Import, and point it to your asav992.qcow2 file
  8. If GNS3 warns about MD5 mismatch, click Yes to accept anyway
  9. 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>
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

PC2 (Outside zone — 192.168.10.x):

ip 192.168.10.5 255.255.255.0 192.168.10.1
save
Enter fullscreen mode Exit fullscreen mode

PC3 (DMZ zone):

ip 192.168.20.15 255.255.255.0 192.168.20.1
save
Enter fullscreen mode Exit fullscreen mode

PC4 (Inside/LAN zone):

ip 192.168.1.15 255.255.255.0 192.168.1.1
save
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verify your zones and IPs:

show nameif
show ip
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verify all ACLs were created:

show access-list
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

To stop debug output:

ciscoasa# undebug all
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)