12-29-2013 07:36 PM - edited 03-07-2019 05:17 PM
Hi I have a home network up and running well that uses a Cisco 1801.
I am just trying to increase my understanding of some it's config and I'm confused by ACLs on a VLAN interface.
Ok so I 'be the router' and imagine packets flowing to me and from me
I have two VLANs configured
VLAN 10 - 10.10.10.0 / 25
VLAN 20 - 10.10.10.128 /27
So for example, one of my Virtual Machines has an address 10.10.10.6 and is on VLAN 10.
Another has an address of 10.10.10.134 and is on VLAN 20.
I want to allow 10.10.10.6 access to 10.10.10.134, but prevent other VLAN 10 devices access.
So I create an ACL and apply it inbound of interface Vlan 20.
The config below works as desired, but I don't understand why.
If the packet filtering is for the inbound direction of the interface, then my logic would state that the source address of the packet to be filtered would be 10.10.10.6, not 10.10.10.134.
Can someone help me understand. Thanks.
interface Vlan20
ip access-group ACL-INBOUND in
!
ip access-list extended ACL-INBOUND
permit ip host 10.10.10.134 host 10.10.10.6 log-input
Solved! Go to Solution.
12-30-2013 12:59 AM
A vlan SVI is no different than a physical interface in regards to an acl ie.
an acl applied inbound to an SVI controls traffic from devices in that vlan
an acl applied outbound to an SVI controls traffic to devices in that vlan
I want to allow 10.10.10.6 access to 10.10.10.134, but prevent other VLAN 10 devices access.
access-list 101 permit ip host 10.10.10.6 host 10.10.10.134
access-list 101 deny ip 10.10.10.0 0.0.0.127 host 10.10.10.134
access-list 101 permit ip any any
int vlan 10
ip access-group 101 in
the above acl allows 10.10.10.6 to talk to 10.10.10.134 but blocks all the other 10.10.10.x/25 clients from talking to 10.10.10.134. It then allows 10.10.10.x/25 clients to talk to everything else. Note you may not want the "permit ip any any" at the end but you would probably want other permit lines so i included a general permit all.
Hopefully you can see it is the same concept as applying an acl to a physical interface in terms of inbound and outbound. Probably where the confusion came from was that you applied the acl to vlan 20 so it actually blocked the return traffic and not the initial packets coming from vlan 10.
It's generally a better approach to filter the packets at their source.
Jon
12-29-2013 07:43 PM
You're correct in your thinking. The reason that the above acl works is because the return traffic is allowed and everything else on vlan 20 is denied. Think of it this way, if you had an acl inbound on vlan 20, anything sourced from vlan 20 (any host on that vlan) trying to get out has to go to the vlan 20 svi on the INBOUND side. If you had the same vlan 20 source address, but you had the acl on vlan 10, you could apply the acl in the OUTBOUND direction. So, these two acls do the same thing:
int vlan 20
ip access-group ACL-INBOUND in
access-list ACL-INBOUND
permit ip host 10.10.10.134 host 10.10.10.6 log-input
OR
int vlan 10
ip access-group ACL-INBOUND out
access-list ACL-INBOUND
permit ip host 10.10.10.134 host 10.10.10.6 log-input
The difference is the svi that you're applying it to and the direction that it's in.
Another example would be for vlan 20:
int vlan 20
ip access-group ACL-INBOUND in
access-list ACL-INBOUND
permit ip host 10.10.10.134 host 10.10.10.6 log-input
Or you could change your acl and apply outbound to:
access-list ACL-OUTBOUND
permit ip host 10.10.10.6 host 10.10.10.134 log-input
Then on vlan 20:
int vlan 20
ip access-group ACL-OUTBOUND
HTH,
John
*** Please rate all useful posts ***
12-29-2013 08:21 PM
I'm still confused.
Is this anything to do with why an ACL that blocks ip addresses of devices on the same VLAN does not work, but yet the devices have to be explicitly permitted access to the gateway address of that VLAN (the router) in order for them to reach other subnets?
For example...
With a 10.10.10.0 / 25 subnet
ip access-list ACL-IN
deny ip host 10.10.10.4 host 10.10.10.5
Does nothing for these devices connected via a L2 switch to the router because the devices at those addresses communicate without the use of the router as they are in the same broadcast domain.
but the rules change if I want any device in this subnet to be able to use the router at 10.10.10.1 to access another subnet.
10.10.10.1 is the same broadcast domain but yet I have to change my access list like below
ip access-list ACL-IN
deny ip host 10.10.10.4 host 10.10.10.5
permit ip host 10.10.10.1 10.10.10.0 0.0.0.127
Where is a good source for simple explanations of ACLs? Not so much the syntax, but more an overview on how the processing works on the flow of traffic to and from the router.
I understand that an ACL tied inbound to a physical port say Fa1....The source address in the ACL would control the traffic coming into the router via that port and the destination address would control traffic leaving via that port.
Why are the rules changed for VLANs?
I need an analogy
I need an explanation that begins like....."Think of a VLAN / SVI as an....."
Thanks anyway
12-30-2013 12:59 AM
A vlan SVI is no different than a physical interface in regards to an acl ie.
an acl applied inbound to an SVI controls traffic from devices in that vlan
an acl applied outbound to an SVI controls traffic to devices in that vlan
I want to allow 10.10.10.6 access to 10.10.10.134, but prevent other VLAN 10 devices access.
access-list 101 permit ip host 10.10.10.6 host 10.10.10.134
access-list 101 deny ip 10.10.10.0 0.0.0.127 host 10.10.10.134
access-list 101 permit ip any any
int vlan 10
ip access-group 101 in
the above acl allows 10.10.10.6 to talk to 10.10.10.134 but blocks all the other 10.10.10.x/25 clients from talking to 10.10.10.134. It then allows 10.10.10.x/25 clients to talk to everything else. Note you may not want the "permit ip any any" at the end but you would probably want other permit lines so i included a general permit all.
Hopefully you can see it is the same concept as applying an acl to a physical interface in terms of inbound and outbound. Probably where the confusion came from was that you applied the acl to vlan 20 so it actually blocked the return traffic and not the initial packets coming from vlan 10.
It's generally a better approach to filter the packets at their source.
Jon
12-30-2013 03:03 AM
Dear friends,
Perhaps this quickly-boiled picture removes some doubts about the SVIs and the in/out direction regarding the SVIs:
Imagine a multilayer switch as having a "router" inside. This router is connected to defined VLANs using its interface Vlan interfaces to provide inter-VLAN routing. All in and out descriptions refer to interface Vlan.
Best regards,
Peter
06-22-2017 10:48 AM
Access-lists has been configured as per below matrix table and show command. But a PC in D01 cannot reach a PC in DMZ though it can reach dmz gateway
|
DESTINATION |
||||||||
D01 |
D02 |
D03 |
DMZ |
|
|
|
|
||
SOURCE |
D01 |
√ |
x |
x |
√ |
|
|
|
|
D02 |
x |
√ |
x |
√ |
|
|
|
|
|
D03 |
x |
x |
√ |
√ |
|
|
|
|
|
DMZ |
x |
x |
x |
√ |
|
|
|
|
CS-SW#show access-lists
Extended IP access list 100
10 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.20.0 0.0.0.255 (28 match(es))
Extended IP access list 101
10 permit ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255
20 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
Extended IP access list 102
10 permit ip 192.168.20.0 0.0.0.255 192.168.20.0 0.0.0.255
Extended IP access list 103
20 permit ip 192.168.20.0 0.0.0.255 192.168.20.0 0.0.0.255
Note: All access lists has been applied in inbound direction
interface Vlan1
ip access-group 100 in
!
interface Vlan10
ip access-group 101 in
!
interface Vlan20
ip access-group 102 in
Kindly advise
06-22-2017 10:37 PM
Access-lists has been configured as per below matrix table and show command. But a PC in D01 cannot reach a PC in DMZ though it can reach dmz gateway
|
DESTINATION |
||||||||
D01 |
D02 |
D03 |
DMZ |
|
|
|
|
||
SOURCE |
D01 |
√ |
x |
x |
√ |
|
|
|
|
D02 |
x |
√ |
x |
√ |
|
|
|
|
|
D03 |
x |
x |
√ |
√ |
|
|
|
|
|
DMZ |
x |
x |
x |
√ |
|
|
|
|
CS-SW#show access-lists
Extended IP access list 100
10 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.20.0 0.0.0.255 (28 match(es))
Extended IP access list 101
10 permit ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255
20 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
Extended IP access list 102
10 permit ip 192.168.20.0 0.0.0.255 192.168.20.0 0.0.0.255
Extended IP access list 103
20 permit ip 192.168.20.0 0.0.0.255 192.168.20.0 0.0.0.255
Note: All access lists has been applied in inbound direction
interface Vlan1 //D01
ip address 192.168.1.1 255.255.255.0
ip access-group 100 in
!
interface Vlan10 //D02
ip address 192.168.10.1 255.255.255.0
ip access-group 101 in
!
interface Vlan20 //DMZ
ip address 192.168.20.2 255.255.255.0
ip access-group 102 in
Kindly advise as am bit confused
08-14-2017 01:11 PM
Thanks Peter. This thread and comment might be 4 years old but his diagram broke it down Barney style for me and was extremely effective in helping me understand how the ACLs for SVIs work.
Nick
08-15-2017 07:48 AM
Nick,
Thank you very much for letting me know. I really appreciate it - and I am glad the diagram helped!
Best regards,
Peter
08-18-2018 10:44 AM
Peter,
THANK YOU
12-30-2013 03:54 AM
Thank you.
It becomes a lot more clear when you apply the ACL to the source of the traffic that is to be filtered.
Another thing with ACLs that I was not clear about until your example....
When a deny statement is encountered that filters a particular ip address entering an interface....
deny ip host 10.10.10.6 10.10.10.0 0.0.0.127
permit ip any any
Processing for the 10.10.10.6 address is stopped, and any further ACL statement that implicitly allows that address will not include that address in it's processing because it has been previously denied....Is this correct?
12-30-2013 04:00 AM
deny ip host 10.10.10.6 10.10.10.0 0.0.0.127
permit ip any any
Processing for the 10.10.10.6 address is stopped, and any further ACL statement that implicitly allows that address will not include that address in it's processing because it has been previously denied....Is this correct?
It is stopped for the host 10.10.10.6 when the destination IP is from the 10.10.10.x/25 network. So, yes if the first line matches then the acl processing stops ie. it does not get to the "permit ip any any" line.
However if 10.10.10.6 tried to access anything else ie. not a 10.10.10.x/25 address then the first line does not match so it would go to the second line and be allowed.
Jon
12-30-2013 04:18 AM
The entire ACL is stopped when a match is made?
So further packets with non matching ip addresses are processed by restarting the ACL list processing from the top?
12-30-2013 04:28 AM
The entire ACL is stopped when a match is made?
So further packets with non matching ip addresses are processed by restarting the ACL list processing from the top?
Yes, once a match is made that is it, no more entries in the acl are checked. Each packet is checked in isolation against the acl and it is checked starting at the top line and working it's way through until a match is made. If it gets through all the lines and no match is made then the packet is denied because there is an implicit deny at the end of an acl.
This is often why you see acls with specfic permit/deny lines then a "permit ip any any" at the end.
Because you run sequentially through the acl if your acl is large it is best practice to try and place the acl lines that will be matched the most at the top of the acl.
Jon
12-30-2013 04:52 AM
Brilliant explanation....Thank you.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide