Network SecurityNetworking SecurityAdvanced

Infrastructure ACLs: protecting routers and network devices at the edge

By Mohamed Fayas 8 min readUpdated 15 October 2026

In short: An infrastructure ACL is applied inbound at every edge of the network and blocks traffic from outside that is addressed to the network devices themselves, while allowing normal traffic to pass through. It is built in four parts: anti-spoofing, the few protocols that must reach devices, a deny for everything else to infrastructure addresses, and a permit for transit traffic.

What an infrastructure ACL protects

Routers, switches and firewalls have IP addresses on their interfaces and loopbacks. Attackers on the internet can send traffic straight to those addresses: login attempts on SSH, floods aimed at the CPU, or forged routing packets. Users and customers almost never need to talk to these addresses. An infrastructure ACL (iACL) uses that fact: at each point where traffic enters your network, it denies traffic addressed to your infrastructure from outside, except the few protocols that genuinely need it.

It works best when all router and switch addresses come from a dedicated, contiguous block, for example 10.255.0.0/16 for loopbacks and links. Then a single line can protect every device.

The four-part structure

Figure 1. An infrastructure ACL is applied inbound at the network edge. It protects the routers themselves while letting customer and user traffic pass through.

Anti-spoofing: drop packets from outside that claim to come from private (RFC 1918), loopback or your own address ranges. They cannot be genuine on an external link.
Required protocols: permit what must reach the edge routers: BGP (TCP 179) from your provider's peering address, NTP from known servers, and selected ICMP types for path MTU discovery and troubleshooting.
Protect the infrastructure: deny all other traffic whose destination is the infrastructure block, and log it.
Transit traffic: permit everything else, which is traffic passing through to users, servers and customers. Normal firewall policy applies to that further in.

An example for an internet edge

In this example the infrastructure block is 192.0.2.0/24 (a documentation range standing in for your public router addresses) and the provider's BGP peer is 198.51.100.1.

ip access-list extended IACL-EDGE
 remark 1 - anti-spoofing
 10 deny ip 10.0.0.0 0.255.255.255 any
 20 deny ip 172.16.0.0 0.15.255.255 any
 30 deny ip 192.168.0.0 0.0.255.255 any
 40 deny ip 127.0.0.0 0.255.255.255 any
 50 deny ip 192.0.2.0 0.0.0.255 any
 remark 2 - required protocols to infrastructure
 60 permit tcp host 198.51.100.1 host 192.0.2.1 eq bgp
 70 permit tcp host 198.51.100.1 eq bgp host 192.0.2.1
 80 permit udp any eq ntp 192.0.2.0 0.0.0.255
 90 permit icmp any 192.0.2.0 0.0.0.255 packet-too-big
 100 permit icmp any 192.0.2.0 0.0.0.255 echo-reply
 remark 3 - deny everything else to infrastructure
 110 deny ip any 192.0.2.0 0.0.0.255 log
 remark 4 - transit
 120 permit ip any any
!
interface GigabitEthernet0/0
 description Internet provider
 ip access-group IACL-EDGE in

Line 80 is broad for simplicity; in production, restrict NTP to the servers you actually use. Before applying an iACL, run it with a final permit ip any any log in a maintenance window, or use a classification ACL, to see which traffic would be dropped. A missing line for a protocol you forgot, such as an IPsec VPN terminating on the router, will cut services off.

Working alongside other protections

An iACL is one layer. It pairs with uRPF, which drops packets whose source address could not have arrived on that interface, and with control plane policing (CoPP), which rate-limits whatever does reach the router's CPU, including traffic from inside. Inside the network, management access should still be restricted with access-class on VTY lines and a separate management network. These are covered in Securing routing. Filtering spoofed sources at the edge is also good internet citizenship, as recommended in BCP 38.

Real-world example: a hosting company's edge

A small hosting company noticed its edge routers' CPU climbing at night, and logs showed thousands of SSH login attempts against router loopback addresses from all over the world. Each router had a VTY access-class, so the attempts failed, but the router still had to process every connection. The team moved all router addresses into one block and deployed an iACL inbound on both provider links, permitting only BGP from the two providers, NTP and a few ICMP types. Attack traffic was then dropped in hardware at the interface, CPU returned to normal, and the logs from line 110 gave the security team a clean record of probing attempts.

Practice

Where is an infrastructure ACL applied, and in which direction?

Inbound on every interface where traffic enters the network from outside, such as provider links.

Why is it helpful to number all routers from one contiguous block?

One ACL line can then deny external traffic to every infrastructure address, which keeps the iACL short and easy to maintain.

Why must the last line of an iACL permit transit traffic?

Without it, the implicit deny would drop all customer and user traffic passing through the network, not just traffic aimed at the routers.

Key takeaways

An iACL blocks external traffic aimed at network devices while transit traffic passes.
Structure: anti-spoofing, required protocols, deny to infrastructure, permit transit.
A dedicated, contiguous infrastructure address block makes iACLs simple.
Test with logging before enforcing so you do not cut off BGP, VPN or NTP.
Combine iACLs with uRPF, CoPP and VTY access-class.

Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author