Hello,

For a building hosting students, I'm trying to replicate current wireless policy with Mikrotik switches.

Currently, a student guest WiFi device can only communicate with non-RFC1918 devices (all traffic to RFC1918 addresses ie 192.168.0.0, 172.16.0.0, 10.0.0.0 is discarded by WiFi AP).
How can I efficiently enforce the same rule with a RouterOS (or SwOS if necessary) Mikrotik switch ?
If that matters, switches are from CRS3XX product line.

Of course, this rule should be implemented on most but not all Ethernet ports.

Best regards

Good question.
I dont think switches normally can stop L2 traffic between clients unless they are on a different vlan.
However those on the same vlan will be able to communicate.
The advantage of wifi is that you can stop wifi clients from reaching other as well (which is like L2 blocking at the wifi level).

Having all access the internet is the easy part
Blocking L3 between subnets is also doable.

If you want it to be done exactly as you described (based on ip address ranges) use switch chip access rules:
https://wiki.mikrotik.com/wiki/Manual:C ... _.28ACL.29

Or bridge firewall:
https://wiki.mikrotik.com/wiki/Manual:I ... e_Firewall

Another possibility is to use a port isolation switch chip feature:
https://wiki.mikrotik.com/wiki/Manual:S ... _isolation

Or bridge horizon feature:
https://wiki.mikrotik.com/wiki/Manual:M ... n_bridging

Keep in mind, that bridge firewall and bridge horizon are software features and are handled by CPU not the switch chip, so they are not suitable for high load situations on CRS line devices.

If you want it to be done exactly as you described (based on ip address ranges) use switch chip access rules:
https://wiki.mikrotik.com/wiki/Manual:C ... _.28ACL.29

Or bridge firewall:
https://wiki.mikrotik.com/wiki/Manual:I ... e_Firewall

Another possibility is to use a port isolation switch chip feature:
https://wiki.mikrotik.com/wiki/Manual:S ... _isolation

Or bridge horizon feature:
https://wiki.mikrotik.com/wiki/Manual:M ... n_bridging

Keep in mind, that bridge firewall and bridge horizon are software features and are handled by CPU not the switch chip, so they are not suitable for high load situations on CRS line devices.

Going with "switch rules" (item 1 from above list), I think I got what I was after ie dropping non-Internet traffic.&
I edited one rule per RFC1918 address family (one for 10.0.0.0/8, another for 172.16.0.0/12 and the last one for 192.168.0.0/16), each rule being applied to specified switch ports.

I did'n't find any way to conveniently:
- define this list of specific switch ports
- nor group these 3 address families into one meta-address family
but this is not blocking.

I've not tried to measure performances, yet.

Thank you very much for all !

I did'n't find any way to conveniently:
- define this list of specific switch ports
- nor group these 3 address families into one meta-address family

I don't think there is a way to do it differently.

You are welcome.

The only thing you need to have in mind about your solution: you don't really block communication between client ports.
Only the ip traffic, and only for users that get their ip's from your DHCP server.
For example nothing stops two users who manually assigns non-RFC1918 addresses to connect to each other.

For example nothing stops two users who manually assigns non-RFC1918 addresses to connect to each other.

Nothing in what you've set so far, that is - look at "port isolation", you want each tenant to be able to reach only the gateway, not other tenants, because if one tenant's device is infected by malware, he can infect all the other ones if it can reach them. And if you deal with tech students, you can expect all the worst