Packet Tracer Configure Extended Acls Scenario 1

When you first fire up Packet Tracer and set out to configure extended ACLs in what we call Scenario 1, you might think it’s just a matter of dragging a few devices onto the canvas and typing a few commands. So naturally, in practice, the real challenge is understanding how the ACL interacts with your topology, where you place the statements, and why a tiny mistake can block traffic you actually need. Let’s walk through the whole process, from the first click to the moment you see the ping succeed, and we’ll also cover the pitfalls that trip most beginners up Less friction, more output..

What Is Packet Tracer Extended ACLs Configuration (Scenario 1)

In Packet Tracer, an extended access control list (ACL) lets you filter traffic based on source and destination IP addresses, ports, and protocols. The goal is to allow web traffic from the workstation to the server while blocking everything else. Scenario 1 is a common lab that mimics a small office network: a router, a switch, a server, and a workstation all connected in a simple topology. Think of the ACL as a bouncer at a club—only the right guests get in, and the rest are turned away That's the part that actually makes a difference..

Key Elements of Scenario 1

• Router – the gateway that actually enforces the ACL.
• Switch – connects devices locally; usually no ACL needed here.
• Workstation – the client that wants to reach the server.
• Server – the resource that should be reachable only on specific ports.
• Extended ACL – defined on the router, applied inbound or outbound based on where you want the filter.

Why It Looks Simple at First

The moment you open the topology, everything seems ready to go. You can ping the server right away, which makes it tempting to skip the ACL altogether. But real‑world networks rarely allow that kind of openness. The ACL is your chance to practice the exact syntax and logic you’ll use on actual Cisco gear, and Packet Tracer is the perfect sandbox to get it right before you touch production equipment That's the whole idea..

You'll probably want to bookmark this section.

Why It Matters / Why People Care

Most network engineers start with basic (standard) ACLs because they’re easier to read. Even so, standard ACLs only look at source IP addresses, which is rarely enough for modern security needs. Extended ACLs give you granularity: you can say “allow HTTP from 10.0.0.2 to 192.168.1.10, but deny everything else.” That level of control is what keeps corporate data safe, protects servers from unwanted scans, and ensures bandwidth is used for the right applications.

In a lab setting, mastering extended ACLs early means you’ll understand how to apply them inbound versus outbound—a distinction that can make or break a design. And it also prepares you for more complex scenarios, like dynamic ACLs, time‑based rules, or integrating with DHCP reservations. Honestly, this is the part most guides get wrong: they treat the ACL as a single command rather than a policy that must align with your network architecture.

How It Works (or How to Do It)

Below is a step‑by‑step walkthrough of Scenario 1. I’ll break it into logical chunks, each with its own H3 heading, so you can follow along without getting lost Simple as that..

Step 1: Build the Topology

1. Open Packet Tracer and select Network Devices → Router.
2. Place an ISR 2901 (or any router you prefer) on the canvas.
3. Add a Switch (Catalyst 2960) next to the router and connect them with an Ethernet cable.
4. Connect a Workstation to the switch and a Server to another switch port (or directly if you want a simpler layout).
5. Give each device logical IP addresses that make sense for the scenario:
   • Router interface 0/0: 192.168.1.1/24
   • Switch 0 (connected to router): 192.168.1.2/24
   • Workstation: 10.0.0.2/24 → 10.0.0.2
   • Server: 10.0.0.10/24 → 10.0.0.10

Step 2: Verify Connectivity Before the ACL

Before you add any ACL, ping from the workstation to the server to confirm the baseline works. And this will be your reference point after you apply the ACL. If the ping fails at this stage, double‑check your IP scheme and switch VLAN settings.

No fluff here — just what actually works It's one of those things that adds up..

Step 3: Create the Extended ACL

1. Access the router’s command line via Desktop → Command Prompt Less friction, more output..

2. Enter global configuration mode: conf t That's the part that actually makes a difference..

3. Define a new extended ACL, for example:

   ip access-list extended WEB_ACCESS
     permit tcp 10.0.0.2 0.0.0.0 any eq 80
     deny ip any any
   

   • permit tcp – we’re allowing TCP traffic.
   • 10.0.0.2 0.0.0.0 – source is the workstation.
   • any – destination can be anything (the server’s IP will match).
   • eq 80 – only port 80 (HTTP).
   • deny ip any any – everything else is blocked.

   Note: The deny ip any any line is crucial. Without it, the default implicit deny only applies to matching traffic, leaving non‑matching packets to be processed by any other ACLs or routes.

Step 4: Apply the ACL to the Appropriate Interface

Now you need to decide where to place the ACL. Practically speaking, the typical approach is to apply the ACL inbound on the router’s interface that faces the workstation’s subnet (or outbound on the interface that faces the server’s subnet). In Scenario 1, the workstation is on a different subnet than the server, so traffic must go through the router. Let’s apply it inbound on the router’s FastEthernet0/0 (the one connected to the switch that the workstation uses) And that's really what it comes down to..

interface fa0/0
 ip access-group WEB_ACCESS in

Step 5: Test the ACL

1. From the workstation, ping the server’s HTTP address (or open a web browser and deal with to http://10.0.0.10). You should see successful HTTP requests.
2. Try pinging a different port (e.g., Telnet on port 23) or ping the server directly. Those attempts should fail, confirming the deny rule works.
3. Verify the ACL is indeed active by checking the router’s configuration: `

show access-lists WEB_ACCESS. You should see hit counters incrementing on the permit tcp line for successful HTTP traffic and on the deny ip any any line for blocked attempts like ICMP pings or Telnet connections.

Step 6: Troubleshooting Common Issues

If the traffic isn’t behaving as expected, run through this quick checklist:

• Direction Matters: An ACL applied in on fa0/0 filters traffic entering the router from the workstation. If you applied it out on the server-facing interface instead, the source IP in the ACL would still be the workstation (10.0.0.2), but the logic flow changes. Ensure the direction matches your design.
• Implicit Deny: Remember that every ACL ends with an implicit deny ip any any. If you only wrote the permit line, all other traffic (including return traffic from the server to the workstation) would be dropped. Because this is a standard stateless ACL (not a reflexive or CBAC/ZBF setup), you must explicitly permit the return traffic (TCP established) or allow the specific return ports if testing stateless flows. Correction for this lab: Since the workstation initiates the TCP 3-way handshake to port 80, the server replies with source port 80. The current ACL permit tcp host 10.0.0.2 any eq 80 only matches the initial SYN packet (dest port 80). The return SYN-ACK packet has source port 80 and destination port >1023. This return packet hits the deny ip any any. To fix this in a stateless ACL, change the permit line to: permit tcp host 10.0.0.2 host 10.0.0.10 eq 80 And add a line for return traffic: permit tcp host 10.0.0.10 eq 80 host 10.0.0.2 gt 1023 established (Note: The established keyword matches TCP ACK/RST bits, allowing only responses to initiated sessions).
• Routing vs. Switching: Verify the workstation’s default gateway is 192.168.1.1 (Router fa0/0) and the server’s gateway is its respective router interface. If both devices are on the same VLAN/subnet (Layer 2), the ACL on the router will never see the traffic.
• Wildcard Masks: Double-check your wildcard masks. 0.0.0.0 means "match this specific host exactly." 0.0.0.255 matches a /24 subnet.

Step 7: Clean Up (Optional)

To remove the ACL and restore full connectivity for the next lab:

conf t
interface fa0/0
 no ip access-group WEB_ACCESS in
exit
no ip access-list extended WEB_ACCESS

Conclusion

You have now successfully built a network topology in Cisco Packet Tracer, configured IP addressing across subnets, and implemented a standard Extended ACL to enforce a specific security policy: allowing only HTTP traffic from a single workstation to a server while denying all other IP traffic.

This exercise demonstrates the fundamental "deny by default" posture of Cisco ACLs and highlights the critical importance of directionality (inbound vs. outbound) and statefulness (handling return traffic). While stateless ACLs like the one configured here are excellent for basic filtering and traffic classification, production environments often migrate toward Zone-Based Policy Firewalls (ZPF) or Context-Based Access Control (CBAC) for automatic session tracking.

Use this topology as a sandbox. But experiment by:

1. Adding a second workstation and writing a deny statement for it before the permit statement (order of operations). Even so, 2. Logging denied packets (deny ip any any log) and observing the console/syslog output. On the flip side, 3. Applying the same ACL outbound on the server-side interface and comparing the logic required.

Not the most exciting part, but easily the most useful That's the part that actually makes a difference. And it works..

Mastering ACL syntax and logic is a cornerstone skill for any network engineer pursuing CCNA or CCNP certification. Keep practicing—packet-by-packet logic becomes intuitive with repetition Nothing fancy..