Skip to content
AvailabilitySign inBook a DemoStart free lab
All free lab files

Access Control Lists: Configuring & Verifying

PC1 pings a server through R1 and gets an explicit deny back, even though the ACL looks like it permits PC1's subnet. Find out what the router actually stored.

Download .unlNo lab server? Practise it in your browser
The lab as it opens in PNETLab: R1 routing between PC1's LAN and SRV1's server segment, with the symptom, objectives and checklist on the canvas.

What you'll practise

  • Configure an extended ACL with permit/deny entries and wildcard masks
  • Apply an ACL to an interface in the correct direction (in vs out)
  • Read show access-lists and show ip interface to verify ACL placement
  • Understand wildcard masks and how they differ from subnet masks
  • Diagnose a host caught by an ACL's implicit deny

Set it up

  1. 1

    Have the node image ready

    Images are not included. The file expects your own licensed copy of:

    • L3-ADVENTERPRISEK9-M-15.4-2T.bin

    If your copy has a different name, open each node's Edit dialog after importing and pick your image from the list.

  2. 2

    Copy it to the server and fix permissions

    Replace <your-server> with the IP address or hostname of your EVE-NG or PNETLab server.

    $ scp access-control-lists-lab.unl root@<your-server>:/opt/unetlab/labs/
# then, logged in to the server:
$ /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
  3. 3

    Open it and start the nodes

    The canvas notes list the objectives, and the workbook walks through the fix.

Inside the lab

Real console output captured live: R1 explicitly denies PC1's traffic instead of timing out, the signature of an ACL block.
After the fix: PC1 reaches SRV1 across R1, captured live from PC1's own console.

Free to use and share under CC BY 4.0. Please credit LabFabric with a link to this page.