CommScope RUCKUS Community Forums

rodolfo_mendes · ‎11-03-2020

Hello,

I'ḿ new in Ruckus enviroment and I would like to replace UNIFI devices from my home. My first steps, replace the Unifi Switch for 3 ICX 7150 (12p), but I found it a little difficult to configure the 1st SW (layer 3). The other 2 SW (layer 2) are ok.

I created the ACL but I don't know if is correct. Somebody could help me

Thanks!

Rodolfo

My network

VLAN 71 - Management - 192.168.71.0/24
VLAN 72 - Local - 192.168.72.0/24 (Computers)
VLAN 73 - IoT - 192.168.73.0/24 (IoT device)
VLAN 74 - SecSystem - 192.168.74.0/24 (IP cameras / NVR)
VLAN 79 - Guest - 192.168.79.0/24

My ACLs:

Objective: Just permit Internet traffic

ip access-list extended GUEST_RULES
permit udp any any eq bootps
permit udp any any eq bootpc
permit tcp any any eq dns
permit udp any any eq dns
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any

Objective: Just permit Internet traffic and multicast (chromecast)
ip access-list extended IOT_RULES
permit udp any any eq bootps
permit udp any any eq bootpc
permit tcp any any eq dns
permit udp any any eq dns
permit udp 192.168.73.0 0.0.0.255 any eq 5353
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip 192.168.73.0 0.0.0.255 any

Objective: Just permit subnet traffic
ip access-list extended SS_RULES
permit udp any any eq bootps
permit udp any any eq bootpc
permit tcp any any eq dns
permit udp any any eq dns
permit ip any 192.168.74.0 0.0.0.255
permit icmp host 192.168.74.110 host 192.168.74.12 (NVR to WIFI Cam)
permit tcp host 192.168.74.110 host 192.168.74.12 eq http (NVR to WIFI Cam)
permit tcp host 192.168.74.110 host 192.168.74.12 eq rstp (NVR to WIFI Cam)

netwizz · ‎11-03-2020

We would need to see your configuration to know where you apply these and in what direction to know if it is truly correct.

Your guest rules are probably good.

You might want to look up the evaluate command for ACLs if it is supported on that platform. It lets you nest or call other access lists and sort of make them hire architectural.

Your last rule makes no sense...

permit icmp host 192.168.74.110 host 192.168.74.12 (NVR to WIFI Cam)
permit tcp host 192.168.74.110 host 192.168.74.12 eq http (NVR to WIFI Cam)
permit tcp host 192.168.74.110 host 192.168.74.12 eq rstp (NVR to WIFI Cam)

The reasoning is packets actually have to cross a layer-3 interface where an ACL is applied for it to work. Then it is directional. That is to say traffic within the same subnet will not be filtered by an ACL this way. It will simply be switched within the VLAN once ARP resolves its physical address.

Traffic that’s routed can have ACLs put on it via its Layer-3 interfaces... You also need to allow the traffic back though, too being it is stateless. Likely not a problem unless you apply your list on both ingress and egress though, so pay attention to direction.

TCP supports the established flag... not certain if this platform supports reflexive access lists, but research that otherwise you need to allow the traffic back

The last line of your IOT Rules are is inclusive of permit udp 192.168.73.0 0.0.0.255 any eq 5353 (meaning it also matches)

Given the order, IP will also carry the UDP. Perhaps you want the counters though...

Let’s say you have VRI or SVIs

int ve 73

ip address 192.168.73.1/24

int ve 79

ip address 192.168.79.1/24

If traffic is coming from 192.158.73.110 going to 192.168.79.200 traffic would go IN ve 73 and OUT ve 79. That is to say traffic need not go flow through an interface like water... the above traffic never goes out ve 73 to get to 192.168.79.200. It

flow in one then [routing process] then new packet gets generated and flows out ve 79, which is where the destination subnet is directly-connected.

I hope this helps. You would have an opportunity to place an ACL ingress 73 or egress 79 to act on my source and destination above ... depending upon whether you want to filter before or after the routing process.

Typically, Extended ACLs have a lot more granularity and are placed close to the source... they include source and destination. Standard ACLs are typically placed near the destination... they reference the source though.

Once a match is made, execution stops processing and traffic is permitted or denied. ACL statements below are not executed. Think of an ACL as returning a true (permit) or false (deny) because they are used for a lot of other things like QoS, route filtering, and a bunch of other things... A permit statement would get traffic into a class/queue for QoS for example. That class/queue could be attached to a policer for example to drop the traffic or some quantity of it.

Regardless, last there is an implicit deny all at the end, so if you have an ACL that permits one thing, it automatically returns deny if there isn not any match. On some platforms an empty ACL blocks all traffic, on others it ironically allows all.

... Hope this helps. If you post your config, we can be of better help.

View solution in original post

netwizz · ‎11-09-2020

Configure it like this:

Switch(config)# int e 1/1/6

I am not sure if this is necessary unless this interface is tagged in multiple VLANS:

Switch(config-if-e1000-1/1/6)# per-vlan 74

Switch(config-if-e1000-1/1/6-vlan-74)# ip access-group SS_RULES in

netwizz · ‎11-09-2020

Anyway, overall this looks better; good work. I have read your ACLs and at a glace you appear to be correct in everything except perhaps some minor remark definitions.

remark Block intra-VLAN traffic:
sequence 50 deny ip any 10.0.0.0 0.255.255.255
sequence 60 deny ip any 172.16.0.0 0.15.255.255
sequence 70 deny ip any 192.168.0.0 0.0.255.255

That remark conflates intra (within the same) with inter (not the same) VLAN traffic.

Additionally, this is a Layer-3 control not a VLAN control. The best definitions for those subnets is RFC1918 or "private" subnets.

i.e. remark Block access to RFC1918 private subnets.

netwizz · ‎11-09-2020

FYI, this is implicit at the end of your ACL... If it were left off the behavior is the same. The downside of adding it is if you insert an item later it by default gets added at the end of the ACL where it can never be executed ... unless you delete that sequence before or after your addition... or insert the new sequence by number between the two (i.e. sequence 85). You can probably tell the switch to renumber the sequences on ICX much like you can other vendors.

... so in many ways it is not good to have a deny all at the end being it is implicitly already there... BUT the counters might be helpful, so I could see a reason for it if you want it for that.

remark Block Internet Access:
sequence 90 deny ip any any

rodolfo_mendes · ‎11-09-2020

I tested apply ACL in VE level but I got error below, i think this is my version behavior.

SSH@ICX7150-C12 Router(config-vif-73)#ip access-group IOT_RULES in
ERROR:UACL cannot be configured/unconfigured at VE-level, please do it at vlan-level.

Thanks you once again.

May the force be with you!!

CommScope RUCKUS Community Forums

ICX 7150 ACL - Home user