02 Networking · Cisco ACLs · Batfish

Validating a network access rule change

This lab tests one ACL change against required and blocked traffic, corrects a deliberate regression, and repeats the baseline checks.

Issue: Will an ACL change restore the required HTTPS path without opening guest-to-admin access or changing unrelated policy?
Decisive evidence: An earlier deny rule blocked user HTTPS traffic to the server. Removing that rule restored the intended path.E01
Result: Removing the inserted deny restores user HTTPS while guest-to-admin traffic remains blocked.
Boundary: Batfish covers the complete policy model.Full limit

Completion: Complete within stated scope
Execution: Batfish model and Packet Tracer checks
Review: Automated consistency checks
Evidence: Selected evidence on this page

Cisco Packet Tracer 9
802.1Q
Cisco ACLs
Batfish

Project scope

What was built and checked.

Project record: The policy intent, four-zone configurations, Batfish model, representative Packet Tracer checks, and failure, correction, and rollback comparisons.

Interactive view

Compare the ACL before and after the deny rule.

The selected state follows user HTTPS through the ACL boundary. The guest-to-admin boundary stays visible as a negative check.

Choose a viewBaselineInserted faultCorrection

User HTTPS reaches the server and the guest boundary remains closed.

01
Users10.20.10.0/24
02
USERS_INInbound policy
03
HTTPS server10.20.30.80:443
04
Guest boundaryAdmin remains blocked

Change boundary

Required access returned. Closed paths stayed closed.

Scroll to compare

CheckInserted faultAfter correction

Users to server HTTPSDeniedAllowed

Admin to serverUnchangedAllowed

Guest to adminUnchangedDenied

RollbackNot applicableBaseline restored

Change sequence

Intent first, then regression, correction, and rollback.

01
Write the required, prohibited, and unaffected flows before editing the ACL.
02
Model the complete policy in Batfish and record the baseline result.
03
Insert one earlier HTTPS deny and observe the declared regression.
04
Remove the inserted rule, repeat the checks, and reopen the untouched rollback state.

Evidence from the lab

The checks used to reach the conclusion.

Selected outputs from the lab. Sensitive and unnecessary details are omitted.

Four-zone access-control lab with users, admin, servers, and guests connected through a routed boundary — E01 · Derived from lab evidenceFour-zone topologyUsers, admin, servers, and guests share the same addressing and policy intent across the model and simulator.
View artifact Back to C01

5 deny tcp 10.20.10.0 0.0.0.255 host 10.20.30.80 eq 443
12 match(es)

HTTPS request : Request Timeout

E02 · Captured lab outputControlled regressionAn earlier deny for users-to-server HTTPS recorded matches while the workstation request timed out.

View artifact Back to C01

ip access-list extended USERS_IN
no 5

permit tcp 10.20.10.0 0.0.0.255 host 10.20.30.80 eq 443
6 match(es)

HTTPS request : Pass

E03 · Captured lab outputCorrectionRemoving sequence 5 returned traffic to the intended permit, which then recorded the restored request.

View artifact Back to C01

Full evidence archive8 additional artifacts

Users to server HTTPS : Pass
Admin to server ICMP  : Pass
Guest to admin ICMP   : Denied
GUESTS_IN deny matches: 4

E04 · Captured lab outputRollback boundary checkAfter a fresh baseline run, the required server path returned while guest-to-admin traffic remained denied.

View artifact Back to C02

Public package
• 19 indexed files
• Batfish state evaluations
• Packet Tracer transcript and screenshots
• source provenance
• SHA-256 values

E05 · Captured lab outputPublic evidence indexThe manifest records the size and SHA-256 value of 19 published model, result, provenance, topology, and screenshot files.

View artifact Back to C01

Packet Tracer workstation browser showing the baseline HTTPS page — E06 · Captured lab outputBaseline HTTPS pathPacket Tracer returned the application page before the test deny was added.
View artifact Back to C01

Packet Tracer workstation browser showing the HTTPS request timeout — E07 · Captured lab outputInserted faultThe same workstation request timed out after the earlier HTTPS deny was inserted.
View artifact Back to C01

Packet Tracer router command output showing 12 matches on the inserted deny — E08 · Captured lab outputDeny counterThe inserted sequence recorded 12 matches, tying the timeout to that ACL entry.
View artifact Back to C01

Packet Tracer workstation browser showing the restored HTTPS page — E09 · Captured lab outputCorrected HTTPS pathAfter sequence 5 was removed, the workstation loaded the same application page again.
View artifact Back to C01

Packet Tracer router command output showing six matches on the intended permit — E10 · Captured lab outputPermit counterThe intended permit recorded six matches after the correction.
View artifact Back to C01

Packet Tracer guest workstation showing the admin network test remained denied — E11 · Captured lab outputBlocked path stayed blockedThe rollback check still denied the guest-to-admin test, keeping the change inside its intended scope.
View artifact Back to C02

Result and limits

What changed, and what this lab does not prove.

Result

The inserted deny blocked user HTTPS. Removing it restored the intended path while guest-to-admin traffic remained blocked.

Limit

Batfish covers the complete policy model. Packet Tracer corroborates representative flows on an adapted router-on-a-stick topology. Automated checks passed, but the project was not reviewed by an external network engineer.

Claims and evidence

What the evidence supports.

An earlier deny rule blocked user HTTPS traffic to the server. Removing that rule restored the intended path.

The manual simulator check covers the declared HTTPS path.

EvidenceE01 E02 E03

After the rollback check, guest traffic to the admin network was still blocked.

This is Packet Tracer corroboration, not physical Cisco hardware execution.

EvidenceE04