# Infrastructure Access-List

**URL:** https://forum.networklessons.com/t/infrastructure-access-list/1270
**Category:** Lessons Discussion
**Created:** [December 29, 2016, 7:54pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270 "2016-12-29T19:54:48Z")
**Posts on this page:** 17
**Page:** 1

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [December 29, 2016, 7:54pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/1 "2016-12-29T19:54:48Z")

</div>

This topic is to discuss the following lesson:

> **[Infrastructure Access-List](https://networklessons.com/network-fundamentals/infrastructure-access-list)**
>
> This lesson gives you an example of some of the things you might find in an infrastructure access-list on a Cisco IOS router.

---

<div class="post-metadata">

### Author: ![sales2161](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/sales2161/32/1432_2.png) [@sales2161](https://forum.networklessons.com/u/sales2161)
#### Post date: [March 3, 2019, 11:17pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/2 "2019-03-03T23:17:51Z")

</div>

Hello,

There is a typo:  
`"R1(config-ext-nacl)#deny ip 224.0.0.0 31.255.255.255 any`  
Let me explain these statements:  
224.0.0.0 /4 is the multicast range." ( I think it should be 15.255.255.255 instead)

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [March 4, 2019, 10:07am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/3 "2019-03-04T10:07:49Z")

</div>

Hello sales2161

Yes you are correct, I’ll let Rene know.

Thanks!

Laz

---

<div class="post-metadata">

### Author: ![walter.nakatana](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/walter.nakatana/32/3864_2.png) [@walter.nakatana](https://forum.networklessons.com/u/walter.nakatana)
#### Post date: [May 9, 2020, 4:33pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/4 "2020-05-09T16:33:36Z")

</div>

Hi,

is this scenario relevant int he real world, in our production network, all our routers site behind fortigate firewalls,

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [May 11, 2020, 7:06am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/5 "2020-05-11T07:06:09Z")

</div>

Hello Walter

The idea of an infrastructure access list is more of a concept than an actual implementation strategy. The idea is to ensure that there are some fundamental best practices that should be enabled at the edge of your network, to protect and secure it. Now at the very least, if you simply have a router, you must employ these as simple access lists on that router, ensuring that you are blocking the appropriate ICMP packets, private addresses, and fragments, to name a few.

Now if you have a firewall or some sort of security appliance on the edge of the network, in most cases, these restrictions are already in place thanks to the default settings on the firewall. If not, then these restrictions should be configured on the security device at the edge of your network.

The concept is described here simply as a minimum security precaution that should be ensured on any network edge device.

I hope this has been helpful!

Laz

---

<div class="post-metadata">

### Author: ![walter.nakatana](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/walter.nakatana/32/3864_2.png) [@walter.nakatana](https://forum.networklessons.com/u/walter.nakatana)
#### Post date: [May 11, 2020, 7:37am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/6 "2020-05-11T07:37:07Z")

</div>

Hi Laz,

thanks helped alot.

WN

---

<div class="post-metadata">

### Author: ![Carlos.lopezg78](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/c/b782af/32.png) [@Carlos.lopezg78](https://forum.networklessons.com/u/Carlos.lopezg78)
#### Post date: [May 17, 2021, 7:47am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/7 "2021-05-17T07:47:36Z")

</div>

Laz!! Does cisco share a guide with best practices on how to implement ACL in this kind of scenario? Very interesting lesson guys!

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [May 19, 2021, 5:15am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/8 "2021-05-19T05:15:13Z")

</div>

Hello Carlos

Yes, Cisco does have documentation that describes general guidelines and best practices in this regard. The following document describes many of these best practices:

> **[Protecting Your Core: Infrastructure Protection Access Control Lists](https://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html)**
>
> This document presents guidelines and recommended deployment techniques for infrastructure protection access control lists (ACLs). Infrastructure ACLs are used to minimize the risk and effectiveness of direct infrastructure attack by explicitly...

I hope this has been helpful!

Laz

---

<div class="post-metadata">

### Author: ![j.degruijter](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/j.degruijter/32/3872_2.png) [@j.degruijter](https://forum.networklessons.com/u/j.degruijter)
#### Post date: [March 28, 2022, 8:43am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/9 "2022-03-28T08:43:43Z")

</div>

Hi Rene / Laz,

In the first part of infrastructure ACLs you mention only allowing certain types of ICMP.

I was wondering how you figured out which keywords to use. In my IOSv version there are ± 50 keywords available. The Cisco documentation I have found says these keywords match ICMP types & codes but does not specify which ones exactly. Could I for example use the keyword traceroute instead of time-exceeded and unreachable?

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [March 30, 2022, 8:17am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/10 "2022-03-30T08:17:10Z")

</div>

Hello Jurrian

Yes indeed, there are many options to choose from when creating an ACL used to filter ICMP traffic. Most of these options correspond to the various ICMP Type and Code fields found within the ICMP header. These are two 8-bit fields that are used to specify the nature of the control message. Specifically, the kind of message is identified by the value of the Type field, and the Code field gives additional context information for the message.

For example, take a look at this partial list of options for an ICMP ACL:

```auto
R-1(config-ext-nacl)#permit icmp any any ?
  <0-255> ICMP message type
  administratively-prohibited Administratively prohibited
  alternate-address Alternate address
  conversion-error Datagram conversion
  dod-host-prohibited Host prohibited
  dod-net-prohibited Net prohibited
  dscp Match packets with given dscp value
  echo Echo (ping)
  echo-reply Echo reply
  fragments Check non-initial fragments
  general-parameter-problem Parameter problem
  host-isolated Host isolated
  host-precedence-unreachable Host unreachable for precedence
  host-redirect Host redirect

```

The `administratively-prohibited` keyword corresponds with an ICMP control message with Type 3 Code 9. Similarly, the `host-isolated` keyword corresponds with Type 3, Code 8.

To see all of the types and codes available, take a look at this IANA ICMP parameters list:

> **[Internet Control Message Protocol (ICMP) Parameters](https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml)**

Keep in mind that some type and code combinations have been deprecated.

Remember that ICMP is much more than simply a ping or a traceroute. It is a control protocol that supports the IP suite. It is used to send error messages and operational information that enables and supplements IP connectivity. If you choose to filter some types of ICMP messages using ACLs, you must first fully understand their purpose before attempting to apply any such filtering.

I hope this has been helpful!

Laz

---

<div class="post-metadata">

### Author: ![martinkuntov](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/m/c5a1d2/32.png) [@martinkuntov](https://forum.networklessons.com/u/martinkuntov)
#### Post date: [January 27, 2024, 7:49pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/11 "2024-01-27T19:49:34Z")

</div>

HI Laz, Team,

Could you help me understand this access list:

```auto
R1(config-ext-nacl)#permit tcp host 3.3.3.3 host 1.1.1.1 eq bgp
R1(config-ext-nacl)#permit tcp host 3.3.3.3 eq bgp host 1.1.1.1

```

I thought it will be like this:

```auto
R1(config-ext-nacl)#permit tcp host 3.3.3.3 host 1.1.1.1 eq bgp
R1(config-ext-nacl)#permit tcp host 1.1.1.1 host 3.3.3.3 eq bgp

```

Kind Regards,  
Martin

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [January 29, 2024, 6:39am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/12 "2024-01-29T06:39:23Z")

</div>

Hello Martin

Let’s take a look at the topology again:

 ![image](https://forum.networklessons.com/uploads/default/original/2X/0/0410d95545a28cdf2abf76fbe0cfe578de0319bb.png)

All ACLs that we are creating in this lesson are in an **inbound direction** relative to R1. So they would be typically applied on the Fa0/0 interface in an incoming direction.

That means that by definition, the source IP in our ACL can never be 1.1.1.1. So for that reason alone, you wouldn’t want to apply something like this:

> [@martinkuntov](#):
>
> ```auto
> R1(config-ext-nacl)#permit tcp host 1.1.1.1 host 3.3.3.3 eq bgp
> 
> ```

…since you’re only filtering incoming traffic, that is, traffic coming from the Internet towards R1. If you do, then it will never be matched, because 1.1.1.1 would never be a source of incoming traffic.

The purpose of this access list is to allow BGP sessions to take place. In a BGP session, one router acts as a listener (or server), while the other initiates the connection (as a client). The listening router listens on TCP port 179 for incoming BGP connections. The router initiating the connection uses a random high-numbered port as its source port but connects to port 179 on the listening router. Because we don’t know if R1 is the listener or the client, we must allow for both contingencies, and that is why both statements are included.

I hope this has been helpful!

Laz

---

<div class="post-metadata">

### Author: ![martinkuntov](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/m/c5a1d2/32.png) [@martinkuntov](https://forum.networklessons.com/u/martinkuntov)
#### Post date: [February 4, 2024, 3:21pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/13 "2024-02-04T15:21:17Z")

</div>

Hi Laz,

Thanks for the explanation 🙂

Best Regards,  
Martin

---

<div class="post-metadata">

### Author: ![davidilles](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/davidilles/32/9686_2.png) [@davidilles](https://forum.networklessons.com/u/davidilles)
#### Post date: [February 16, 2025, 12:47pm UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/14 "2025-02-16T12:47:57Z")

</div>

Hello, everyone.

Does the name of the ACLs refer to the fact that they protect the internal infrastructure?

Another question is, the first ACL example

```auto
R1(config-ext-nacl)#permit icmp any any echo-reply 
R1(config-ext-nacl)#permit icmp any any unreachable 
R1(config-ext-nacl)#permit icmp any any time-exceeded 
R1(config-ext-nacl)#deny icmp any any

```

Would this one be applied inbound or outbound or both? If inbound, that would allow the internet to reply with these messages while if it was outbound, it would allow the internal hosts with these messages.

Thank you.  
David

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [February 20, 2025, 6:41am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/15 "2025-02-20T06:41:49Z")

</div>

Hello David

> [@davidilles](#):
>
> Does the name of the ACLs refer to the fact that they protect the internal infrastructure?

Yes indeed. An **Infrastructure** ACL is used to **protect network infrastructure devices** , such as routers, switches, firewalls, and servers. Infrastructure ACLs are characterized by the fact that they filter and restrict traffic **destined for these devices** , unlike “traditional” ACLs that filter transient traffic, or traffic **between hosts**.

> [@davidilles](#):
>
> Would this one be applied inbound or outbound or both?

It depends on what you want to achieve. Based on these particular ICMP message types, I believe that this should be applied outbound. Since we are looking at Infrastructure ACLs, it is likely that we want to protect our edge router R1. These are the types of messages you would expect R1 to respond with, in the event that a ping is received. It may also be prudent to specify a destination IP of the R1 device so that if there is a destination somewhere inside the network, it will not be further propagated. The idea here is that specifically ICMP control traffic is filtered. You can adjust and tweak the details based on your specific needs.

I hope this has been helpful!

Laz

---

<div class="post-metadata">

### Author: ![gregcastillo89](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/gregcastillo89/32/5362_2.png) [@gregcastillo89](https://forum.networklessons.com/u/gregcastillo89)
#### Post date: [July 3, 2025, 3:31am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/16 "2025-07-03T03:31:52Z")

</div>

Is the final statement in the bgp access list required since there is an implicit deny all at bottom? Or is it just good practice?

---

<div class="post-metadata">

### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [July 4, 2025, 6:03am UTC](https://forum.networklessons.com/t/infrastructure-access-list/1270/17 "2025-07-04T06:03:34Z")

</div>

Hello Gregory

You’re right, strictly speaking, as far as the functionality of the ACL goes, the final deny statement is not necessary. Whether you put it in or not will not make a difference in how it operates because there is that implicit deny any any at the end.

However, it is helpful to add the explicit deny statement as in the lesson for these reasons:

1. It more clearly states what your intention is, and it is useful when other engineers view your config to know what you wanted to achieve.
2. It can be useful if you want to log matches to that deny statement using the `log` keyword at the end.

Does that make sense?

I hope this has been helpful!

Laz
