11-03-2020 04:02 PM
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)
Solved! Go to Solution.
11-03-2020 04:43 PM
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.
11-03-2020 04:43 PM
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.
11-04-2020 10:05 AM
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
11-09-2020 12:49 AM
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
11-09-2020 12:50 AM
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)