cancel
Showing results for 
Search instead for 
Did you mean: 

ICX 7150 ACL - Home user

rodolfo_mendes
New Contributor II

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)

1 ACCEPTED SOLUTION

netwizz
Contributor III

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

8 REPLIES 8

netwizz
Contributor III

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.

 

Hello NETWizz,

Thank you for the response and troubleshooting tips.

Some additional information:

VLAN 72 (Local) can access all others VLAN and internet.

VLAN 73 (IoT) can access internet and specific IP in VLAN 74 (NVR). There are some devices that can access internet (NO_INTERNET rule).

VLAN 74 (Cams) can't access internet just subnet traffic

VLAN 79 (Guest) can access just internet.


How to block traffic between hosts in same vlan? 
Am I the right track?


Current configuration:
!
ver 08.0.95aT213
!
stack unit 1
  module 1 icx7150-c12-poe-port-management-module
  module 2 icx7150-2-copper-port-2g-module
  module 3 icx7150-2-sfp-plus-port-20g-module
  stack-port 1/3/1
  stack-port 1/3/2
!
!
global-stp
!
!
!
default-vlan-id 71
!
vlan 71 name DEFAULT-VLAN by port
 router-interface ve 71
 spanning-tree
 ip access-group NO_INTERNET out
!
vlan 72 name Local by port                                        
 tagged ethe 1/1/3 to 1/1/5 ethe 1/2/1 to 1/2/2 ethe 1/3/1 to 1/3/2 
 untagged ethe 1/1/1 to 1/1/2 
 router-interface ve 72
!
vlan 73 name IoT by port
 tagged ethe 1/1/3 to 1/1/5 ethe 1/3/1 to 1/3/2 
 router-interface ve 73
 ip access-group IOT_RULES in
!
vlan 74 name SS by port
 tagged ethe 1/2/2 ethe 1/3/1 to 1/3/2 
 untagged ethe 1/1/6 to 1/1/12 
 router-interface ve 74
 ip access-group SS_RULES in
!
vlan 79 name Guest by port
 tagged ethe 1/1/3 to 1/1/5 ethe 1/2/1 to 1/2/2 ethe 1/3/1 to 1/3/2 
 router-interface ve 79
 ip access-group GUEST_RULES in
!
aaa authentication web-server default local
aaa authentication login default local
boot sys fl sec
enable aaa console
ip dns server-address 192.168.71.200
ip route 0.0.0.0/0 192.168.71.200
!
no telnet server
username super password .....
!
!
clock timezone gmt GMT-03
!
!
ntp
 server 192.168.71.200
!
!
no web-management http
web-management https
!
!
manager registrar
!
interface ethernet 1/3/1
 speed-duplex 1000-full
!
interface ethernet 1/3/2
 speed-duplex 1000-full
!
interface ve 71
 ip address 192.168.71.199 255.255.255.0
!
interface ve 72
 ip address 192.168.72.199 255.255.255.0
!
interface ve 73
 ip address 192.168.73.199 255.255.255.0
!
interface ve 74
 ip address 192.168.74.199 255.255.255.0
!
interface ve 79
 ip address 192.168.79.199 255.255.255.0
!
!
!
!                                                                 
ip access-list extended GUEST_RULES
remark Permit DHCP:
sequence 10 permit udp any any eq bootps 
sequence 20 permit udp any any eq bootpc 
remark Permit DNS:
sequence 30 permit tcp any any eq dns 
sequence 40 permit udp any any eq dns 
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 
remark Permit others traffic:
sequence 80 permit ip any any 
!
ip access-list extended IOT_RULES
remark Permit DHCP:
sequence 10 permit udp any any eq bootps 
sequence 20 permit udp any any eq bootpc 
remark Permit DNS:
sequence 30 permit tcp any any eq dns 
sequence 40 permit udp any any eq dns 
remark Permit send mDNS packets:
sequence 50 permit udp 192.168.73.0 0.0.0.255 any eq 5353          
remark Block inter-VLAN traffic:
sequence 60 deny ip any 10.0.0.0 0.255.255.255 
sequence 70 deny ip any 172.16.0.0 0.15.255.255 
sequence 80 deny ip any 192.168.0.0 0.0.255.255 
remark Permit Internet access:
sequence 90 permit ip 192.168.73.0 0.0.0.255 any 
!
ip access-list extended NO_INTERNET
remark Block Internet Access Printer/WIFI Cam:
sequence 10 deny ip host 192.168.73.10 any log 
sequence 20 deny ip host 192.168.73.12 any log 
!
ip access-list extended SS_RULES
remark Permit DHCP:
sequence 10 permit udp any any eq bootps 
sequence 20 permit udp any any eq bootpc 
remark Permit DNS:
sequence 30 permit tcp any any eq dns 
sequence 40 permit udp any any eq dns 
remark Permit subnet communication: <<has no effect>>
sequence 50 permit ip any 192.168.74.0 0.0.0.255 
remark Permit NVR to IoT Cam (VLAN73):
sequence 60 permit icmp host 192.168.74.110 host 192.168.73.12    
sequence 70 permit tcp host 192.168.74.110 host 192.168.73.12 eq http
sequence 80 permit tcp host 192.168.74.110 host 192.168.73.12 eq rtsp
remark Block Internet Access:
sequence 90 deny ip any any 

I have to chop this up.  It keeps telling me my post is too big!

Have not delved into 08.0.95 builds due to a COVID directive to not make any changes that might require myself or another person go onsite if something goes wrong (unlikely being I have upgraded hundreds of ICX devices through dozens of software versions over the years)… still haven't had one not boot and function... *knocks on wood* On a 08.0.90x build.


I have not seen rules like these applied directly under the VLAN configuration.  Usually I see those on the VE Layer-3 interfaces.  Not saying this is wrong:


vlan 123 name test

untagged ethe 1/1/1

router-interface ve 123

ip access-group My_RULE in

!


In the past I have always seen it on the Layer-3 Interface:

interface ve 123

ip address 10.1.1.1 255.255.255.0

ip access-group My_RULE in

!


I will take a look at this next time I am just messing around with an ICX 7xxx switch.


I like this comment you made (Right you are):

remark Permit subnet communication: <<has no effect>>
sequence 50 permit ip any 192.168.74.0 0.0.0.255 

You ASKED:

Q: How to block traffic between hosts in same vlan? 


A: With another popular vendor whom shall remain nameless the answer is vlan maps.


With ICX equipment, I am 99% sure you need to enable (this is literally the command):

enable ACL-per-port-per-vlan


I think that feature requires a reload (reboot) to enable... Obviously do a write mem (or copy run start first)... at least a reload was required last time I enabled it as a requirement for another feature I was using (I think that feature was DHCP Snooping)