Extended IP access list FILTER_VLAN_36
10 permit ip any 192.168.2.0 0.0.0.255
20 deny ip any 192.168.0.0 0.0.128.255
30 permit ip any any
40 permit icmp any any
Extended IP access list FILTER_VLAN_50
10 permit ip any any
20 permit icmp any any
----------------------------------
VLAN50 (192.168.50.0/24) is IT VLAN and should see all vlans, but any other shouldn't.
VLAN36 (192.168.36.0/24) is example. But when i try to rdp to my pc in VLAN50 i have access.
Where is mistake?
We do not need an ACL on VLAN 50 if that one is permitted to view all.
Line 10 in the VLAN36 ACL permits traffic to any IP address that starts with 192, so that is the rule that matches traffic from VLAN 36 to VLAN 50.
Hi mercy_angel,
There are a few components to string together to make an ACL work the way you intend it to. All that you have provided in your post is a couple of ACLs. You also need to specify how these ACLs are applied although if I recall, with VLAN ACLs there's no direction to the ACL. This is one thing which makes them different to regular ACLs which are applied to interfaces in a direction (inbound or outbound) like a firewall. VLAN ACLs concept is different.
Ref #1 : https://www.kareemccie.com/2015/04/what-is-difference-between-router.html
Ref #2: https://www.networkstraining.com/vlan-access-map-example-configuration/
In your other post on here, you mention a similar problem. In fact, the same problem with the mask is seen in your ACL on line 10. See if you can spot it?
Quote from: mercy_andelExtended IP access list FILTER_VLAN_36
10 permit ip any 192.168.2.0 0.0.0.255
20 deny ip any 192.168.0.0 0.0.128.255
30 permit ip any any
40 permit icmp any any
If you are unable to spot the issue with line 10, then use this online subnet calculator and enter in the details from line 10 and see if you can spot the difference between the subnet calculator value and your ACL value
http://www.subnet-calculator.com/cidr.php Apart from the issue with line 10, another possibility which I can think of is that maybe the ACLs are not applied?
Quote from: Dieselboy on January 10, 2021, 10:04:20 PM
Hi mercy_angel,
There are a few components to string together to make an ACL work the way you intend it to. All that you have provided in your post is a couple of ACLs. You also need to specify how these ACLs are applied although if I recall, with VLAN ACLs there's no direction to the ACL. This is one thing which makes them different to regular ACLs which are applied to interfaces in a direction (inbound or outbound) like a firewall. VLAN ACLs concept is different.
Ref #1 : https://www.kareemccie.com/2015/04/what-is-difference-between-router.html
Ref #2: https://www.networkstraining.com/vlan-access-map-example-configuration/
In your other post on here, you mention a similar problem. In fact, the same problem with the mask is seen in your ACL on line 10. See if you can spot it?
Quote from: mercy_andelExtended IP access list FILTER_VLAN_36
10 permit ip any 192.168.2.0 0.0.0.255
20 deny ip any 192.168.0.0 0.0.128.255
30 permit ip any any
40 permit icmp any any
If you are unable to spot the issue with line 10, then use this online subnet calculator and enter in the details from line 10 and see if you can spot the difference between the subnet calculator value and your ACL value http://www.subnet-calculator.com/cidr.php
Apart from the issue with line 10, another possibility which I can think of is that maybe the ACLs are not applied?
So what is idea behind this. You have some servers on subnet 192.168.2.0/24. so all vlans must SEE THAT.
And i dont see why permit on 192.168.2.0 0.0.0.255 (which is /24) have problem with it?
Dieselboy brings up an important point: we need to see the statements that apply the ACL to either inbound or outbound traffic on the VLAN. If those are missing, then the ACL is not active.
@mercy_angel I want to try and help but I think what we need to do is connect somewhere in the middle in terms of myself as a network engineer and yourself where you can visualise a scenario which you are wanting to achieve.
Are you able to provide more information around your situation?
BTW ACLs are evaluated from top to bottom. The first rule to be evaluated is the lowest line number. Each line is evaluated until there is a match and once there is a match then no more rules are evaluated.
Quote from: deanwebb on January 11, 2021, 07:19:20 AM
Dieselboy brings up an important point: we need to see the statements that apply the ACL to either inbound or outbound traffic on the VLAN. If those are missing, then the ACL is not active.
Thanks I checked again and looks l was incorrect earlier - VLAN ACL does get applied in a direction.
On older routers where ACLs were the firewall there was a way to deny traffic inbound from the internet but permit traffic from inside to the outside to gain internet access and allow the ACL to permit the reply traffic that would normally be denied by the "internet inbound" ACL. Can this be done with VLAN ACLs? Else it will just deny the traffic all the time.
Quote from: https://community.cisco.com/t5/networking-documents/how-to-configure-acls-to-permit-only-established-connections-and/ta-p/3127503The established keyword indicates that packets belong to an existing connection if the Transmission Control Protocol (TCP) datagram has the Acknowledgment (ACK) or Reset (RST) bit set.
Example:
access-list 100 permit tcp any any establishedThere's a good example here:
https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html Under the heading "Allow Only Internal Networks to Initiate a TCP Session"
It describes the scenario where traffic from network A can initiate sessions to network B but network B traffic to A is denied (unless it is part of the return traffic to connections initiated from A).
"10 permit ip any 192.168.2.0 0.0.0.255" - this means that, traffic with any source IP and a destination IP of 192.168.2.x will be permitted if matching this line where this ACL is applied. IF traffic matches this line then line 20 will not be checked against this same traffic. However if you have traffic with any source and a destination of 192.168.50.x then it will not match line 10 and it will go to the next line to be checked there.
This is where I See a problem (did you find it??) hint: because the subnet mask is invalid for line 20 so I am unsure what the switch/router will do in this case. This IOS ACL config is really just an interface. Essentially the system runs an OS which we dont get to see, so these ACLs must be translated into something in the underlying system. I will stick with what I said in the other post and suggest that you resolve this issue in the first instance and see what happens. Maybe the router will not match any traffic on line 20 and so the next line will be evaluated in your ACL.
Line 30 permits any traffic (any source and any destination) and so it could be that your deny rule is not being applied and therefore all traffic is matching line 30.
But this is all guesses based on the limited information which you've provided.
Quote from: Dieselboy on January 11, 2021, 08:07:03 PM
@mercy_angel I want to try and help but I think what we need to do is connect somewhere in the middle in terms of myself as a network engineer and yourself where you can visualise a scenario which you are wanting to achieve.
Are you able to provide more information around your situation?
BTW ACLs are evaluated from top to bottom. The first rule to be evaluated is the lowest line number. Each line is evaluated until there is a match and once there is a match then no more rules are evaluated.
Quote from: deanwebb on January 11, 2021, 07:19:20 AM
Dieselboy brings up an important point: we need to see the statements that apply the ACL to either inbound or outbound traffic on the VLAN. If those are missing, then the ACL is not active.
Thanks I checked again and looks l was incorrect earlier - VLAN ACL does get applied in a direction.
On older routers where ACLs were the firewall there was a way to deny traffic inbound from the internet but permit traffic from inside to the outside to gain internet access and allow the ACL to permit the reply traffic that would normally be denied by the "internet inbound" ACL. Can this be done with VLAN ACLs? Else it will just deny the traffic all the time.
Quote from: https://community.cisco.com/t5/networking-documents/how-to-configure-acls-to-permit-only-established-connections-and/ta-p/3127503The established keyword indicates that packets belong to an existing connection if the Transmission Control Protocol (TCP) datagram has the Acknowledgment (ACK) or Reset (RST) bit set.
Example:
access-list 100 permit tcp any any established
There's a good example here: https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html
Under the heading "Allow Only Internal Networks to Initiate a TCP Session"
It describes the scenario where traffic from network A can initiate sessions to network B but network B traffic to A is denied (unless it is part of the return traffic to connections initiated from A).
"10 permit ip any 192.168.2.0 0.0.0.255" - this means that, traffic with any source IP and a destination IP of 192.168.2.x will be permitted if matching this line where this ACL is applied. IF traffic matches this line then line 20 will not be checked against this same traffic. However if you have traffic with any source and a destination of 192.168.50.x then it will not match line 10 and it will go to the next line to be checked there.
This is where I See a problem (did you find it??) hint: because the subnet mask is invalid for line 20 so I am unsure what the switch/router will do in this case. This IOS ACL config is really just an interface. Essentially the system runs an OS which we dont get to see, so these ACLs must be translated into something in the underlying system. I will stick with what I said in the other post and suggest that you resolve this issue in the first instance and see what happens. Maybe the router will not match any traffic on line 20 and so the next line will be evaluated in your ACL.
Line 30 permits any traffic (any source and any destination) and so it could be that your deny rule is not being applied and therefore all traffic is matching line 30.
But this is all guesses based on the limited information which you've provided.
yeah i understand, but when i tried to change line 20 to match whole subnet 192.168.0.0 0.0.255.255 vlan from IT department cant connect to it.
So dont understand how to change that.VLAN_50 (192.168.50.0/24) must see all other vlans, and thats what i did.
Just to say, access group is INSIDE
ip access-group FILTER_VLAN_36 in
What is all the traffic you want to permit? List those lines first, all of them.
Then deny the other traffic.
Quote from: deanwebb on January 18, 2021, 07:48:52 AM
What is all the traffic you want to permit? List those lines first, all of them.
Then deny the other traffic.
vlan36 192.168.36.0/24 should see only 192.168.2.0/24 and ofc have acess to internet.
vlan50 is it deparments, that must see all subnets.
It is not good to have other offices to see it deparmtnent subnet
Quote from: mercy_angel on February 12, 2021, 05:21:30 AM
Quote from: deanwebb on January 18, 2021, 07:48:52 AM
What is all the traffic you want to permit? List those lines first, all of them.
Then deny the other traffic.
vlan36 192.168.36.0/24 should see only 192.168.2.0/24 and ofc have acess to internet.
vlan50 is it deparments, that must see all subnets.
It is not good to have other offices to see it deparmtnent subnet
While a human can understand that, a router or firewall cannot. If you list them as IP ranges and not as sentences, then we get closer. Specify each range that needs traffic allowed, IP range style.
I'll have a go...
Quote from: mercy_angel on February 12, 2021, 05:21:30 AM
Quote from: deanwebb on January 18, 2021, 07:48:52 AM
What is all the traffic you want to permit? List those lines first, all of them.
Then deny the other traffic.
vlan36 192.168.36.0/24 should see only 192.168.2.0/24 and ofc have acess to internet.
vlan50 is it deparments, that must see all subnets.
It is not good to have other offices to see it deparmtnent subnet
ip access-list extended mercy_angel_1
permit ip 192.168.36.0 0.0.0.255 192.168.2.0 0.0.0.255 log
deny ip 192.168.36.0 0.0.0.255 192.168.50.0 0.0.0.255 log
remark mercy angels all subnets
permit ip 192.168.50.0 0.0.0.255 any
remark give vl36 access to the internet ofc
permit ip 192.168.36.0 0.0.0.255 any
remark - It is not good to have other offices to see it deparmtnent subnet
i will make seperate extended list for all subnets, so acl4_vlan36, acl4_vlan44 etc and that acl put into vlan IN traffic
ip access-list extended acl4_vlan36
permit ip any 192.168.2.0 0.0.0.255 log
deny ip any 192.168.50.0 0.0.0.255 log
permit ip any any
but now I from 50 vlan cant see that vlan, i cant connect to those pcs
Right. Maybe it's not allowed because of your source IP? What do you think about that?
yeah, source ip is ANY which means all ips from that vlan36. And its ok, i cant reach vlan 50, but vlan 50 also cant reach that subnet, but it should
I can see that in the ACL you mentioned in your post above, the source is matching "any". I know nothing more about your network, including if there are other ACLs at play.
i said earlier
VLAN50 (192.168.50.0/24) is IT VLAN and should see all vlans, but any other shouldn't.
VLAN36 (192.168.36.0/24) is example. But when i try to rdp to my pc in VLAN50 i have access.
so i create all seperate extended acl and put INSIDE path into the vlan itself, so its not one acl for all vlans.
i am having a bunch of /24s and all what i need is that my vlan 50 see all vlans and all the others see only 192.168.2.0/24 (some server vlan)
This conversation is going to continue to go around in circles until we get more information. I'm sorry, but you're going to have to give more details. When you say "all vlans", we need to know what the other network ranges are. So far, all we have are the two VLANs, and they seem to be numbered arbitrarily. You say that you have "a bunch of /24s", but we don't have specifics on them.
The specifics matter.
The direction of traffic also matters. When you say the IT VLAN should see all vlans, but any other shouldn't, that raises a problem with bidirectional traffic. Traffic must be allowed to return to the IT VLAN from other VLANs, and any UDP responses (such as responses to SNMP polling) must also be explicitly permitted. If you are blocking traffic from all VLANs to the IT VLAN, then you are also blocking the return traffic that started from the IT VLAN.
VLAN ACLs are *not* stateful, so they will *not* automatically permit response traffic. A stateful firewall in between the IT VLAN and all other VLANs would allow automatic permits on return TCP traffic, but would still need explicit rules to permit UDP and ICMP responses, when needed.
i just put in all interface vlans this
ip access-group FILTER_VLAN_36 in
and vlan is
Extended IP access list FILTER_VLAN_36
10 permit ip any 192.168.2.0 0.0.0.255
20 deny ip any 192.168.0.0 0.0.128.255
30 permit ip any any
40 permit icmp any any
and now you will not have access to IT department, but IT department cant see this VLAN36 BUT IT SHOULD!
This is problem.
That ACL denies all inbound traffic from 192.168.0.0/17 except from 192.168.2.0/24. Your IT VLAN is 192.168.50.0/24, so it is blocked.
If you add a permit ip any 192.168.50.0 0.0.0.255,
(above the deny) the IT VLAN traffic should be allowed.
<admin edit>
Quote from: deanwebb on March 22, 2021, 09:04:12 AM
That ACL denies all inbound traffic from 192.168.0.0/17 except from 192.168.2.0/24. Your IT VLAN is 192.168.50.0/24, so it is blocked.
If you add a permit ip any 192.168.50.0 0.0.0.255, (above the deny) the IT VLAN traffic should be allowed.
<admin edit>
you are right, but that vlan will see IT VLAN if I add permit 192.168.50.
but idea is that only IT has access to all other vlans, not vice versa
Then what you want is a firewall, that can permit the stateful connections that you describe.