Community discussions

MikroTik App
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 10:46 am

I would like to setup multiple cAP ac's such that they are all on the same VLAN, but all clients are isolated. My main switch (a D-Link DGS-1012-24) has a traffic segmentation feature which blocks package forwarding between ports (even via routes across different switches as it filters based on the MAC addresses in the dynamic MAC table) which allows to achieve client isolation (in combination with Wi-Fi client isolation on the APs), however some switches in the network (Netgear GS308E) do not have a traffic segmentation feature. If I am understanding correctly I would hence need to put each additional AP on these switches on a different VLAN which, however, would be annoying to setup (as there are multiple SSIDs) and would presumably prevent fast roaming as the client's IP addresses would change switching between VLANs.

My question is whether there is a way to enforce client isolation on the APs directly, perhaps via some filter rules, e.g. blocking all packages addressed to other IPs within the same subnet except the gateway's IP.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 2:37 pm

what do you mean by client isolation.

All clients on the same CAPAC can see each other but not other CAPACs clients.
All clients on all capacs on th same vlan can see each other but not see the wired clients that are on the same vlan
or every single wifi client on all capacs on the same vlan cannot see each other or wired clients on the same vlan
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 2:54 pm

In "CAPsMAN forwarding" mode, client isolation works among clients of all physical cAPs (if activated of course) because the virtual wireless interface runs at the CAPsMAN machine. In "local forwarding" mode, you would need bridge filter rules on each of the cAPs, allowing only frames to/from the MAC address of the gateway (and, in more complex cases, any other devices in the subnet that have to be accessible for all wireles clients) to be forwarded across the Ethernet interface, and the rest to be dropped. I can't say which approach uses more CPU.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 8:25 pm

what do you mean by client isolation.

All clients on the same CAPAC can see each other but not other CAPACs clients.
All clients on all capacs on th same vlan can see each other but not see the wired clients that are on the same vlan
or every single wifi client on all capacs on the same vlan cannot see each other or wired clients on the same vlan
I wrote "in combination with Wi-Fi client isolation on the APs", so the third option is the closest (though, there will be no wired clients in the same VLAN, only Wi-Fi hotspots).
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 8:27 pm

In "CAPsMAN forwarding" mode, client isolation works among clients of all physical cAPs (if activated of course) because the virtual wireless interface runs at the CAPsMAN machine. In "local forwarding" mode, you would need bridge filter rules on each of the cAPs, allowing only frames to/from the MAC address of the gateway (and, in more complex cases, any other devices in the subnet that have to be accessible for all wireles clients) to be forwarded across the Ethernet interface, and the rest to be dropped. I can't say which approach uses more CPU.
The first option seems to bottleneck all traffic through one of the cAPs, right? That seems to strain one device quite a bit. I think, I will go with the bridge filter rules then. Thanks.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Wed Sep 08, 2021 10:28 pm

The first option seems to bottleneck all traffic through one of the cAPs, right?
It depends on what you mean by bottleneck. The CAPsMAN need not run on one of the APs, it can as well run on a wireless-less router, and there must be some device in the whole network that acts as a router and firewall, unless each of the cAPs has its own internet connection and serves these roles, which would contradict to what you wrote about all clients of the same SSID sharing the same VLAN. So if the packets from the wireless clients have to pass through a single device on their way to internet, there's little difference whether they get encapsulated into VLAN frames or into CAPsMAN frames. Both is done by CPU in case of wireless traffic - the "hardware acceleration" of L2 processing only works for ethernet-to-ethernet forwarding.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 1:38 pm

The CAPsMAN need not run on one of the APs, it can as well run on a wireless-less router, and there must be some device in the whole network that acts as a router and firewall
I have a pfSense router which I would like to keep. I also do not want to buy and install another device, hence I will use one of the cAP's for CAPsMAN and the configuration of all APs.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 2:23 pm

In "CAPsMAN forwarding" mode, client isolation works among clients of all physical cAPs (if activated of course) because the virtual wireless interface runs at the CAPsMAN machine. In "local forwarding" mode, you would need bridge filter rules on each of the cAPs, allowing only frames to/from the MAC address of the gateway (and, in more complex cases, any other devices in the subnet that have to be accessible for all wireles clients) to be forwarded across the Ethernet interface, and the rest to be dropped. I can't say which approach uses more CPU.
@sindy,
That is not true...
Client to client forwarding works between clients connected on the same interface. https://help.mikrotik.com/docs/display/ROS/CAPsMAN
In Manager Forwarding is controled by CapsMAN in Local Forwarding is controlled by CAPs...

If for example you create two Interfaces on a CapsMAN configuration, for example Test1 and Test2, then:
- If Clients connect on same Interface e.g Test1 and Client-to-Client is enabled the result is Successful communication between each other
- If Clients connect on same Interface e.g Test1 and Client-to-Client is disabled the result is unsuccessful communication between each other
- If clients connect on different Interfaces, one on Test1 and the other on Test2 the communication is successful regardless if Client-to-Client is enabled or disabled...
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 4:29 pm

Oops, sorry... I forgot the virtual interfaces created on
the CAPsMAN are nevertheless individual ones. But they are still connected to a single bridge so the horizon functionality may be used to isolate them.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 4:46 pm

- If clients connect on different Interfaces, one on Test1 and the other on Test2 the communication is successful regardless if Client-to-Client is enabled or disabled...
I don't know what is exactly possible in CAPsMAN, I am running a Unifi wireless network here (with MikroTik router).
In the Unifi APs there is a bridge filter that disallows broadcast and multicast traffic towards the wireless interface unless it is from some pre-registered MAC addresses (where you enter the router's MAC).
That means that ARP requests from clients towards other clients are filtered even when it is accross different APs, which makes client-to-client communication difficult (I would not say impossible).
Maybe something similar can be done here?
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 6:11 pm

Oops, sorry... I forgot the virtual interfaces created on
the CAPsMAN are nevertheless individual ones. But they are still connected to a single bridge so the horizon functionality may be used to isolate them.
@sindy,
Even if it was two different CAPs, completely different devices, under CapsMAN, if one Client is connected to Test1 of CAP1 and the second client on Test1 of CAP2, they will successfully communicate even if client-to-client forwarding is set to no.
Client to Client forwarding will affect clients connected on the same Interface, either if it is a virtual one or an Interface of another CAP.

So yes, split horizon i guess is what should be used ...
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 6:46 pm

This is actually a very useful thread.
So I have finally discerned possibly a useful capsman functionality or two to be exact.
a. the ability to isolate clients on the same capac on the same vlan
b. the ability to isolate clients on different capacs but on the same vlan.

Questions
(1) Can I assume that capsman is actually required for a, and b, and this canNOT be done with a regular setup of a capsman (local).

(2) in b., are wifi clients also isolated from wired users on the same vlan
in b. are wired users isolated from wifi users on the capac
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 7:32 pm

The first line should be writren like this:

a. the ability to isolate clients on the same capac on the same virtual or real wireless interface

(1) Can I assume that capsman is actually required for a, and b, and this canNOT be done with a regular setup of a capsman (local).
You can do a) on stand-alone APs as well. For doing b) you need CAPsMAN and local-forwarding=no


(2) in b., are wifi clients also isolated from wired users on the same vlan
in b. are wired users isolated from wifi users on the capac
With appropriate bridge configuration on CAPsMAN device wireless users are safe from wired ones as well. And vice versa.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Thu Sep 09, 2021 10:01 pm

From my point of View, the most effective way to isolate Wireless Clients is:

CapsMan Forwarding:
- Disable Client to Client forwarding to isolate clients on the Same Interface, whatever that is, virtual or CAP device
- Set Bridge Horizon to same Value so that wireless clients from different wireless interfaces can not communicate to each other...

Enabling Bridge Horizon disables Hardware Offload, so it would not be a good choice to enable it on an ethernet Port. So supposing that the ethernet ports are on another VLAN, communication with these ports will still be impossible with the correct VLAN implementation ofcorse.

But in case both wireless and ethernet devices are on the same VLAN, and we still want to isolate them, then i guess Bridge Firewall is the only way ( Hardware Offload must be manually disabled for Bridge Firewall to work )

Local Forwarding:
-Use of the Bridge Firewall ( on the CAP device ) to allow communication only with the Router and not between other devices on the same Layer2 Network...
-Disable Client to Client forwarding to isolate clients on the Same Interface
Last edited by Zacharias on Tue Sep 14, 2021 1:52 pm, edited 1 time in total.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Mon Sep 13, 2021 3:51 pm

Is there a way to configure this kind of bridge filter in an automated manner? I am already using CAPsMAN to setup the Wi-Fi networks across all APs, but I am stuck here as there does not seem to be a function to configure the bridge in CAPsMAN.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Mon Sep 13, 2021 10:48 pm

there does not seem to be a function to configure the bridge in CAPsMAN.
Correct, there is unfortunately none, CAPsMAN ony takes care about the wireless interfaces. So you have to add the bridge filter rules device by device.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Tue Sep 14, 2021 1:12 am

Correct, there is unfortunately none, CAPsMAN ony takes care about the wireless interfaces. So you have to add the bridge filter rules device by device.
It seems one can automate the setup using SSH and Python. Something like this (note: untested code):

Relevant documentation: https://wiki.mikrotik.com/wiki/Manual:I ... ket_Filter
import paramiko
from getpass import getpass
ip_address = ["192.168.88.%i" % i for i in range(0, 100)]
user = raw_input("Input username: ")
passw = getpass()
for ip in ip_address:
  ssh.connect(hostname=ip,username=user, password=passw)
  stdin, stdout, stderr = ssh.exec_command("/interface bridge filter add action=allow chain=forward mac_protocol=ip dst-address=192.168.2.1 vlan-id=2")
  stdin, stdout, stderr = ssh.exec_command("/interface bridge filter add action=drop chain=forward vlan-id=2")
  print(stdout.read())
Question: Does that filter command make sense? It is supposed to blog any packages on VLAN 2 except those targeted at the gateway. Maybe I should also block any level 2 packets? It would be annoying to go by MAC adresses though.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Tue Sep 14, 2021 1:54 pm

Notice though, that with Bridge Firewall you can not drop communication between wireless clients connected on the same interface, because that most obviously is handled by the wireless driver.
So you should disable client to client forwarding to catch devices connected to the same interface and then use Bridge Firewall to drop the rest communication between different interfaces, either wireless or not...
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Tue Sep 14, 2021 11:10 pm

Notice though, that with Bridge Firewall you can not drop communication between wireless clients connected on the same interface, because that most obviously is handled by the wireless driver.
So you should disable client to client forwarding to catch devices connected to the same interface and then use Bridge Firewall to drop the rest communication between different interfaces, either wireless or not...
Yeah, I have already disabled client-to-client forwarding using CAPsMAN.

My new problem is: How can I gain access to a cAP ac in CAPs mode. The CAPsMAN device did assign it an IP (192.168.88.235). I tried to access it via SSH, Telnet and WebFig via Ethernet 1 to no avail.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Client isolation within VLAN and fast roaming

Tue Sep 14, 2021 11:21 pm

My new problem is: How can I gain access to a cAP ac in CAPs mode. The CAPsMAN device did assign it an IP (192.168.88.235). I tried to access it via SSH, Telnet and WebFig via Ethernet 1 to no avail.

CAPsMAN only provisions wireless interfaces. The rest you have to do yourself (or some autoconfiguration magic does it for you in some mysterios way). Your best chance is to use Winbox and if it can discover xAP ac, click on its MAC address. If it doesn't work, connect you management PC to ether2 and retry.
Last edited by mkx on Tue Sep 14, 2021 11:21 pm, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Tue Sep 14, 2021 11:21 pm

My new problem is: How can I gain access to a cAP ac in CAPs mode. The CAPsMAN device did assign it an IP (192.168.88.235). I tried to access it via SSH, Telnet and WebFig via Ethernet 1 to no avail.
How did you get the cAP ac into the CAP mode? Because what you describe normally doesn't happen, apart from the wireless interfaces being remotely controlled, it behaves like a regular DHCP client with both Ethernet ports bridged together, so unless there is some other setup blocking access to ssh/telnet/webfig, something is broken.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Wed Sep 15, 2021 12:08 am

How did you get the cAP ac into the CAP mode? Because what you describe normally doesn't happen, apart from the wireless interfaces being remotely controlled, it behaves like a regular DHCP client with both Ethernet ports bridged together, so unless there is some other setup blocking access to ssh/telnet/webfig, something is broken.
I have a managed switch (all ports are untagged VID = 1, i.e. default) to which I connected my PC and the first cAP (via ether1) which I configured as CAPsMAN server. In the wireless tab I enabled CAPs for the CAPsMAN to control it's own radios. Then I conneced the second cAP (via ether1) to the managed switch while keeping the reset button pressed for 10 seconds (5 seconds after the LED started blinking). Both cAPs successfully got adopted and started sending the SSIDs configured in CAPsMAN. Finally, I looked up the second cAP's IP in the leases tab of the first cAP's DHCP Server section to which I then tried to connect from the PC.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Wed Sep 15, 2021 12:15 am

I conneced the second cAP (via ether1) to the managed switch while keeping the reset button pressed for 10 seconds (5 seconds after the LED started blinking) ... Finally, I looked up the second cAP's IP in the leases tab of the first cAP's DHCP Server section to which I then tried to connect from the PC.
This sounds like a pretty standard procedure to me, so the only issue I could imagine would be a routing one if the DHCP server wouldn't assign a default gateway to the CAP. But as you say the PC is in the same subnet and VLAN, it cannot be the reason. Can you ping the CAP from the PC, and can you ssh to it from the cAP running CAPsMAN?

Does that filter command make sense?
The basic idea of your filter setup does make sense, but...
  • the cliens only use the IP address of the gateway to determine its MAC address, i.e. they only send an IP packet whose IP dst-address matches the one of the gateway if they want to talk to the gateway device itself, not if they want to use it as a gateway
  • the clients must be allowed to to send ARP packets to broadcast MAC address
  • the clients must be allowed to send DHCPDISCOVER IP/UDP packets to broadcast MAC address
So I'd use in-interface to determine the direction (wireless to ethernet or ethernet to wireless), and drop all frames in the ethernet->wireless direction unless their source MAC address is the one of the gateway or of the DHCP server if these are separate devices.

So for a colocated gateway and DHCP server, a single rule should be enough:
chain=forward in-interface=ether1 mac-protocol=vlan vlan-id=2 src-mac-address=!00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=drop

If the gateway and the DHCP server are separate devices, you'll need an action=accept rule matching on the other src-mac-address before the action=drop one.

Other than that, as you seem to be into scripting in general, you can theoretically use the ssh-exec function in RouterOS script to do the same what you do in Python if that has any benefits for you.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Fri Sep 17, 2021 10:48 pm

This sounds like a pretty standard procedure to me, so the only issue I could imagine would be a routing one if the DHCP server wouldn't assign a default gateway to the CAP. But as you say the PC is in the same subnet and VLAN, it cannot be the reason. Can you ping the CAP from the PC, and can you ssh to it from the cAP running CAPsMAN?
It's true that I deactivated the default route, but that should not matter, as you said, because all devices are hooked to an unmanaged switch.

I cannot even ping the second AP from the CAPsMAN one:
[admin@MikroTik] > ip dhcp-server lease print
Flags: X - disabled, R - radius, D - dynamic, B - blocked
 #   ADDRESS                 MAC-ADDRESS       HOST-NAME     SERVER     RATE-LIMIT     STATUS  LAST-SEEN
 0 D 192.168.88.253          8C:16:45:2E:CB:21 DESKTOP-0S... defconf                   bound   2m38s
 1 D 192.168.88.252          2C:C8:1B:63:7C:15 MikroTik      defconf                   bound   1m
[admin@MikroTik] > ping 192.168.88.252
  SEQ HOST                                     SIZE TTL TIME  STATUS
    0 192.168.88.252                                          timeout
    1 192.168.88.252                                          timeout
    sent=2 received=0 packet-loss=100%
[admin@MikroTik] >> /system ssh 192.168.88.252 user=admin
connectHandler: Connection timed out
Here is my config:
# sep/13/2021 03:58:39 by RouterOS 6.47.9
# software id = HRRU-123U
#
# model = RBcAPGi-5acD2nD
# serial number = E2810...
/caps-man channel
add band=2ghz-g/n control-channel-width=20mhz extension-channel=disabled name=ch_2.4
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=XXXX name=ch_5 skip-dfs-channels=yes
/interface bridge
add admin-mac=2C:C8:1C:12:8B:4F auto-mac=no comment=defconf name=bridge
/interface wireless
# managed by CAPsMAN
# channel: 2422/20/gn(18dBm), SSID: MYAP_test, local forwarding
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-612B3C wireless-protocol=802.11
# managed by CAPsMAN
# channel: 5180/20-Ceee/ac/P(20dBm), SSID: MYAP_test, local forwarding
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-612B3D wireless-protocol=802.11
/caps-man datapath
add bridge=bridge local-forwarding=yes name=dp_myAP vlan-id=51 vlan-mode=use-tag
add bridge=bridge local-forwarding=yes name=dp_myAP_guest vlan-id=52 vlan-mode=use-tag
/caps-man rates
add basic=12Mbps name=rate_2.4 supported=12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps
/caps-man security
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myAP
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myAP_guest
/caps-man configuration
add channel=ch_2.4 country=switzerland datapath=dp_myAP mode=ap name=cfg_myAP_2.4 rates=rate_2.4 security=sec_myAP ssid=MYAP_test
add channel=ch_2.4 country=switzerland datapath=dp_myAP_guest mode=ap name=cfg_myAP_guest_2.4 rates=rate_2.4 security=sec_myAP_guest ssid=MYAP-Guest_test
add channel=ch_5 country=switzerland datapath=dp_myAP mode=ap name=cfg_myAP_5 security=sec_myAP ssid=MYAP_test
add channel=ch_5 country=switzerland datapath=dp_myAP_guest mode=ap name=cfg_myAP_guest_5 security=sec_myAP_guest ssid=MYAP-Guest_test
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/caps-man manager
set enabled=yes
/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=cfg_myAP_2.4 name-format=prefix-identity name-prefix=2.4 slave-configurations=cfg_myAP_guest_2.4
add action=create-dynamic-enabled hw-supported-modes=an master-configuration=cfg_myAP_5 name-format=prefix-identity name-prefix=5 slave-configurations=cfg_myAP_guest_5
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface wireless cap
# 
set caps-man-addresses=127.0.0.1 enabled=yes interfaces=wlan1,wlan2
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
/ip dhcp-client
# DHCP client can not run on slave interface!
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system routerboard mode-button
set enabled=yes on-event=dark-mode
/system script
add comment=defconf dont-require-permissions=no name=dark-mode owner=*sys policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=\
    "\r\
    \n   :if ([system leds settings get all-leds-off] = \"never\") do={\r\
    \n     /system leds settings set all-leds-off=immediate \r\
    \n   } else={\r\
    \n     /system leds settings set all-leds-off=never \r\
    \n   }\r\
    \n "
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Fri Sep 17, 2021 11:06 pm

First, try pinging 192.168.88.252 from the CAPsMAN one with arp-ping=yes interface=bridge - it should respond, indicating that there's a firewall issue.

If it responds, try /tool mac-telnet 2C:C8:1B:63:7C:15 (the login and password are asked by the CAPsMAN one, so the fact that you get asked doesn't mean the remote device is accessible). If you can't log in using mac-telnet, try connecting the cAP to the switch using its ether2 and try again.

If you succeed with mac-telnet via either interface, export the configuration and post it here.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Client isolation within VLAN and fast roaming

Sat Sep 18, 2021 11:20 am

In the context of this, does anyone here have broad knowledge of the impact that this client isolation will have on the typical devices in use today?
I mean, those people walking around with phones and accompanying watches (Apple or Android), the users of phones and laptops that somehow work together, etc, are they going to experience reduced service on the network?
I see that for example these watches have a WiFi connection but I do not know if they use that to communicate to the phone on the same local network, or if they both connect to a cloud server and communicate via that. Or maybe they use Bluetooth for the direct communication between devices a single user owns?

Of course I understand it would affect use of devices like Chromecast where both the Chromecast and a user's device are connected to the same network and they directly discover eachother using multicast. But now that we have migrated the original Wifi-connected Chromecasts to ethernet-connected TVs with Chromecast functionality built-in, would it be safe to turn on client isolation?
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Sat Sep 18, 2021 11:44 pm

@pe1chl,
Nice question...
I think that way as well, that is why i tend to not block communication between wireless clients in the same broadcast domain...
But it all depends on the level of security you want to apply...
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sun Sep 19, 2021 12:31 am

@sindy
First, try pinging 192.168.88.252 from the CAPsMAN one with arp-ping=yes interface=bridge - it should respond, indicating that there's a firewall issue.
This finally worked after I restarted it again in normal mode, and put into CAPs mode via WebFig. Not sure why. For the next cAP ac I tried it worked immediately.
chain=forward in-interface=ether1 mac-protocol=vlan vlan-id=2 src-mac-address=!00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=drop
However wouldn't this still allow clients to flood the network with broadcast and other traffic and potentially L2 malware? Ideally such traffic should be filtered at each AP. How about this rule instead or even in addition to the one you suggested:
chain=output out-interface=ether1 mac-protocol=vlan vlan-id=2 dst-mac-address=![00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=drop
By the way, what is the expected CPU overhead and throughput reduction one can expect from using such filters.
Last edited by solarium14 on Sun Sep 19, 2021 10:58 am, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Client isolation within VLAN and fast roaming

Sun Sep 19, 2021 10:41 am

@pe1chl,
I think that way as well, that is why i tend to not block communication between wireless clients in the same broadcast domain...
But it all depends on the level of security you want to apply...
Yes, I am asking this question for a network with hundreds of users that are not in direct contact with me (guests and employees using a company wifi) and while I see that sometimes devices are scanning the entire IP space I am not sure if these are "hackers" or some legitimate user where e.g. the phone is trying to find the IP address of the same user's watch.
Blocking it would improve the security and efficiency of the network (the latter by reducing the number of 'slow' broadcasts), but it would not be good when I hear weeks later "your network is sh*t because I cannot use my Apple Watch on it!", for example.
Therefore, before blocking client-to-client traffic I would want to know if that is in day-to-day use with modern devices, or if everything communicates via cloud servers today.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Sun Sep 19, 2021 11:20 am

However wouldn't this still allow clients to flood the network with broadcast and other traffic and potentially L2 malware? Ideally such traffic should be filtered at each AP. How about this rule instead or even in addition to the one you suggested:
chain=output out-interface=ether1 mac-protocol=vlan vlan-id=2 dst-mac-address=![00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=drop
You must permit clients to send ARP requests and DHCPDISCOVER requests which both have the broadcast MAC address as the destination one. The ARP requests must be able to reach the gateway router, and the DHCPDISCOVER requests must be able to reach the DHCP server.

But whilst the bridge filter on the source cAP will let them through, the bridge filters at all the other cAPs will not, because their source MAC address will not be the "correct" one. So it is enough to do it the way I've suggested, and you don't need to selectively match on vlan-encap=arp in one rule, and vlan-encap=ip ip-protocol=udp dst-port=67 in another.

If a rogue client decides to create an ARP or a DHCPDISCOVER storm, you cannot do anything about that at this level, but your switch interconnecting the cAPs with the rest of the network may possibly be able to throttle such a flood on ingress.
By the way, what is the expected CPU overhead and throughput reduction one can expect from using such filters.
Depending on your cAPs model, you may be able to implement the L2 filtering rules using the /interface ethernet switch rule menu rather than the /interface bridge filter one. If you do, you don't need to worry about additional CPU load, as these rules are executed at wire speed by the switching part of the SoC. Otherwise try and see, I have no idea what the impact will be. If the impact is noticeable, I'd recommend to put an action=accept out-interface=ether1 rule as the very first one, so that 1/2 of frames would hit just this single one, then those allowing the traffic from the individual permitted MAC addresses but a single one coming in via ether1, and finally the one dropping all traffic coming in via ether1 that doesn't come from the last permitted MAC address. The rule matching on the gateway router's MAC address should be the first one in this group, again so that most frames that came in via ether1 would only get matched against two rules in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Client isolation within VLAN and fast roaming

Sun Sep 19, 2021 11:50 am

You must permit clients to send ARP requests and DHCPDISCOVER requests which both have the broadcast MAC address as the destination one. The ARP requests must be able to reach the gateway router, and the DHCPDISCOVER requests must be able to reach the DHCP server.
It is possible to do "something" about the ARP storms that result from clients "scanning" the IP space. You can filter the ARP requests in a bridge filter and only allow the ARPs for the router IP, and not ARPs for other IPs, or you can ratelimit those.
I have experimented with this in a UniFi network where broadcast/multicast between WiFi clients can be filtered in a crude way.
It is also possible to allow client-client traffic in such a network by using proxy arp on the router, and indeed to measure what kind and amount of inter-client
traffic there is using suitable firewall rules.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sat Oct 16, 2021 6:29 pm

I was able to set this up with the following BASH script. It relies on fping for fast pings, but you can also replace that line by normal ping.
# Preparations to get passwordless login to work. CAPsMAN provisions the same authorized key to all CAP devices (and also seems to disable password-based SSH).
capsman="192.168.51.2"
ssh-keygen -f Mikrotik -t rsa -b 4096 -m PEM
scp Mikrotik admin@"${capsman}":Mikrotik
scp Mikrotik.pub admin@"${capsman}":Mikrotik.pub
ssh admin@"${capsman}" "/user ssh-keys import public-key-file=Mikrotik.pub"
ssh admin@"${capsman}" "/user ssh-keys private import user=admin private-key-file=Mikrotik"

# Actual configuration script
set -e
# Rule tag
cmt="comment=my_rules"
# Gateway MAC address
gwmac="a1:29:2e:31:31:1e/FF:FF:FF:FF:FF:FF"
cmds=("/interface ethernet switch rule remove [/interface ethernet switch rule find $cmt]")
for vid in 2 3 4; do
  # Empty value for new-dst-ports means 'drop', no action provided means accept. Filters ingress.
  cmds+=("/interface ethernet switch rule add switch=switch1 ports=ether1 mac-protocol=vlan\
         vlan-id=$vid src-mac-address=$gwmac $cmt")
  cmds+=("/interface ethernet switch rule add switch=switch1 ports=ether1 mac-protocol=vlan\
         vlan-id=$vid new-dst-ports=\"\" $cmt")
done
cmds=("/interface ethernet switch rule remove [/interface ethernet switch rule find $cmt]")

for ip in 192.168.51.{10..50}; do
  print $pi
  fping -r 0 $ip
  if [ $? -eq 0 ]; then
    ls ~/.ssh/Mikrotik
    for cmd in "${cmds[@]}"; do
      echo "$cmd"
      ssh -i ~/.ssh/Mikrotik -o StrictHostKeyChecking=no admin@$ip "${cmd}"
    done
  fi
done
The configured rules for each VLAN printed directly from one of the CAP devices:
switch=switch1 ports=ether1 src-mac-address=a1:29:2e:31:31:1e/FF:FF:FF:FF:FF:FF mac-protocol=vlan vlan-id=3 copy-to-cpu=no redirect-to-cpu=no mirror=no
switch=switch1 ports=ether1 mac-protocol=vlan vlan-id=3 copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""
This does not seem to work. The first rule should be allowing ingress from the GW (by ommiting the new-dst-ports parameter) and the second rule should block any other ingress (by setting the new-dst-ports parameter to the empty string). However, I am able to run iperf3 between two CAP deviced hooked up to the same switch that does not support client isolation.

It seems I have to use L3 filtering after all. Or is there something wrong about my rules?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Sat Oct 16, 2021 6:39 pm

How does the rest of the configuration look like? Switch chip rules are normally just working, so it looks really strange. Is VLAN 3 tagged on the switch ports to which the cAPs are connected?
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sat Oct 16, 2021 9:42 pm

How does the rest of the configuration look like? Switch chip rules are normally just working, so it looks really strange. Is VLAN 3 tagged on the switch ports to which the cAPs are connected?
I did not change anything else, only CAPsMAN did some configuations. VID 3 is tagged on the switch as proven by the fact that I am getting IPs from the DHCP server of that VLAN. I've bound iperf3 to the respective IPs in that subnet via the -B argument, which should guarantee the iperf3 traffic takes a detour. I am also not seeing traffic on ntopng on my router, so it must be going through the switch(es). (I've ommitted the other VLANs in the config below.)
# oct/16/2021 20:34:07 by RouterOS 6.47.9
# software id = HLFL-NU8D
#
# model = RBcAPGi-5acD2nD
# serial number = E3213FC023E1
/interface bridge
add admin-mac=2C:C8:... auto-mac=no comment=defconf name=bridgeLocal
/interface wireless
# managed by CAPsMAN
# channel: 2422/20/gn(18dBm), SSID: MY-test, local forwarding
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
# managed by CAPsMAN
# channel: 5180/20-Ceee/ac/P(20dBm), SSID: MY-test, local forwarding
set [ find default-name=wlan2 ] disabled=no ssid=MikroTik
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether1
add bridge=bridgeLocal comment=defconf interface=ether2
/interface ethernet switch rule
add comment=my_rule mac-protocol=vlan ports=ether1 src-mac-address=A0:36:.../FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3
add comment=my_rule mac-protocol=vlan new-dst-ports="" ports=ether1 switch=switch1 vlan-id=3
/interface wireless cap
#
set bridge=bridgeLocal discovery-interfaces=bridgeLocal enabled=yes interfaces=wlan1,wlan2
/ip dhcp-client
add comment=defconf disabled=no interface=bridgeLocal
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Sat Oct 16, 2021 10:25 pm

I had to have a look at my own switch chip rules to spot the issue. There's a catch - whereas in /interface bridge filter rules, the value specified as mac-protocol is always matched against offset 12 of the frame, and there is a separate match field, vlan-protocol, to match the protocol field inside the 802.1Q tag, switch rules work different - by configuring a match on vlan-id, you implicitly make them match on value 0x8100 at offset 12 (along with the VID field at offset 14), and the value specified as mac-protocol is matched against the protocol field inside the 802.1Q tag in this case.

So none of your rules actually matches any traffic.

Just remove mac-protocol=vlan from both rules and you should be good.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sun Oct 17, 2021 1:27 am

Thank you for looking into this. Unfortunately, removing the mac-protocol parameter did not help. This is what the rules look like now:
switch=switch1 ports=ether1 src-mac-address=A0:36:.../FF:FF:FF:FF:FF:FF vlan-id=3 copy-to-cpu=no redirect-to-cpu=no mirror=no
switch=switch1 ports=ether1 vlan-id=3 copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""
However, I am still getting through via iperf3:
local 10.90.0.15 port 61481 connected to 10.90.0.14 port 5201
This connection does not get established when both clients are connected to the same cAP (as expected as client-to-client forwarding is disabled in CAPsMAN). But that proves that my means of testing the firewall/switch rules is not flawed. I am using Nirsoft's WifiInfoView for connecting to a particular AP (as all use the same SSID).
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Sun Oct 17, 2021 5:46 pm

I've just tried exactly the same (in my "real" rules, I match on a particular mac-protocol):

/interface ethernet switch rule
add new-dst-ports="" ports=ether1 src-mac-address=64:D1:54:xx:xx:x3/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=5


This does block traffic from 64:D1:54:xx:xx:x3 in VLAN 5, whereas traffic from the same MAC address keeps passing through in VLAN 6.
When I change vlan-id from 5 to 6, traffic from that MAC address starts passing in VLAN 5 and stops passing in VLAN 6.
When I change src-mac-address from 64:D1:54:xx:xx:x3/FF:FF:FF:FF:FF:FF to 64:D1:54:xx:xx:x4/FF:FF:FF:FF:FF:FF, the traffic starts passing again.

This confirms that your switch chip rules themselves are correct. However, if I change vlan-mode on ether1 under /interface ethernet switch port from secure to disabled, the traffic starts passing through although the rule is still in place.

So first, you have to tell the switch chip which VLANs you use (one row per VLAN):
/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=1
...
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=x

(independent-learning defaults to yes but given your simple topology, I think it is not necessary - on the other hand, setting it to no saves just a few memory slots).

Only after doing that, you can enable VLAN handling at individual ports (and I still recommend to activate safe mode first, by pressing Ctrl-X):
/interface ethernet switch port set switch1-cpu,ether1,ether2 vlan-mode=secure default-vlan-id=1
(default-vlan-id may not be 1 in your case).
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sun Oct 17, 2021 11:37 pm

Thanks, enabling VLAN mode and adding the VLANs in the first place did the trick!

Unfortunately, it seems to be impossible to enter the safe mode via SSH commands. I tried sending CAN (C-X, or \x18) like this:
can=$'\x18'
cr=$'\r'
ssh -tt host "$can${cmds/\n/$cr}$can"
However I was not able to run any command with this, also tying variations with newline and carriage return, as well as very simple commands like /system identity set name=Test.

It would be really handy to have a command for entering safe mode like /system safe-mode on|off.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Mon Oct 18, 2021 11:49 am

Unfortunately, it seems to be impossible to enter the safe mode via SSH commands.
I don't think safe mode is necessary during non-interactive script access. It is really helpful when you try the configuration changes manually, but you should use only previously validated commands in non-interactive scripts. The reason why I have suggested it here was because a single mistake in configuring VLANs on the switch chip may lock you out of the device and in case of cAP ac in particular, there is no other way to regain access than reset to defaults, so at least a chair is usually necessary :) But once you debug the commands manually, the concept is proven and the result will be always the same if the initial state is the same.

Other than that, you can revert the changes manually, using things like change X ; delay 3m ; change -X (execution of the command line finishes even if the management connection is interrupted), and if you don't lose connection, you break the execution. Or you can use a regular scheduled script, using /system script and /system scheduler. This is useful when the loss of management connection is planned and the new connection uses a different interface etc.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Mon Oct 25, 2021 11:36 pm

Thanks a lot @sindy for the help so far. After I had some issues with the slave SSIDs, I redid everything starting from an empty configuration, but I am now stuck at the switch rules again. When I deactivate the switch rules and switch VLAN configuration, everything works fine. However, with the rules enabled, WLAN traffic arrives at the gateway, but the gateway does not pass the switch filters as the client keeps asking "Who is ..." via ARP and never receives a DHCP lease. I double-checked the MAC address.
/system identity
set name=CAPsMAN

/caps-man datapath
add client-to-client-forwarding=no local-forwarding=yes name=dp_myap vlan-id=2 vlan-mode=use-tag
add client-to-client-forwarding=no local-forwarding=yes name=dp_myap_guest vlan-id=3 vlan-mode=use-tag

/caps-man rates
add basic=12Mbps name=rate_2.4 supported=12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps

/caps-man security
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myap passphrase=myappasswd
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myap_guest passphrase=myappasswd

/caps-man channel
add band=2ghz-g/n control-channel-width=20mhz extension-channel=disabled name=ch_2.4
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=XXXX name=ch_5 skip-dfs-channels=yes

/caps-man configuration
add channel=ch_2.4 country=germany datapath=dp_myap mode=ap name=cfg_myap_2.4 \
    rates=rate_2.4 security=sec_myap ssid=myap
add channel=ch_2.4 country=germany datapath=dp_myap_guest mode=ap name=\
    cfg_myap_guest_2.4 rates=rate_2.4 security=sec_myap_guest ssid=\
    myap-guest-test
add channel=ch_5 country=germany datapath=dp_myap mode=ap name=cfg_myap_5 \
    security=sec_myap ssid=myap
add channel=ch_5 country=germany datapath=dp_myap_guest mode=ap name=\
    cfg_myap_guest_5 security=sec_myap_guest ssid=myap-guest-test

/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=\
    cfg_myap_2.4 name-format=prefix-identity name-prefix=2.4 \
    slave-configurations=cfg_myap_guest_2.4
add action=create-dynamic-enabled hw-supported-modes=an master-configuration=\
    cfg_myap_5 name-format=prefix-identity name-prefix=5 slave-configurations=\
    cfg_myap_guest_5
    
/interface bridge
add name=bridge
/interface bridge port
add bridge=bridge interface=ether1

/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=bridge

/caps-man manager
set enabled=yes

/interface wireless cap
set caps-man-addresses=127.0.0.1 enabled=yes interfaces=wlan1,wlan2 bridge=bridge

/ip address
add address=192.168.51.2/24 interface=bridge network=192.168.51.0

/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=1
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=2
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=3

/interface ethernet switch rule
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=2
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=2
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=3

/interface ethernet switch port set switch1-cpu,ether1,ether2 vlan-mode=secure default-vlan-id=1
Last edited by solarium14 on Thu Oct 28, 2021 2:16 pm, edited 2 times in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Mon Oct 25, 2021 11:54 pm

with the rules enabled, WLAN traffic arrives at the gateway, but the gateway does not pass the switch filters as the client keeps asking "Who is ..." via ARP and never receives a DHCP lease. I double-checked the MAC address.
If the client keeps sending ARP requests, it should mean it has already received a DHCPOFFER. Normally, the client first broadcasts a DHCPDISCOVER, receives some DHCPOFFER in response, possibly from multiple servers, chooses one of these servers to send a DHCPREQUEST to (and to do that, it already needs to send an ARP request first because DHCPREQUEST is a unicast packet) and gets a DHCPACK from that server.

Is the gateway and the DHCP server the same device? Can you sniff at ether1 while the wireless client is trying and the rule with new-dst-ports="" is disabled, to see the whole DHCP exchange?
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Tue Oct 26, 2021 12:26 am

If the client keeps sending ARP requests, it should mean it has already received a DHCPOFFER.
The client had the gateway IP cached because it already had a lease from a previous successful connection (when I removed the switch rules and the switch VLANs). I.e. the DHCP works when the rules are removed.

Yes, the gateway and the DHCP server are the same device.

I was able to nail it down to disabling the new-dst-ports="" rule; then I see the whole DHCP exchange. Somehow the bypass rule for the GW is not working. I am going to investigate sniffing ether1 directly tomorrow.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Tue Oct 26, 2021 8:40 pm

I sniffed ether1, but it only recorded the ingress even though direction was set to 'any'.

With all switch rules enabled, the only traffic I am seeing on the relevant VLAN is a single DHCP ACK coming from the gateway. I guess this is then not coming through as the bypass rule somehow does not work? The MAC addresses do match though.

With all switch rules disabled, I am seeing additionally some ARP "is at" messages and so on and the client then has an internet connection.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Wed Oct 27, 2021 12:31 am

I keep forgetting about it as it is not very logical - to sniff both directions on an interface, you have to set hw=no on the respective /interface bridge port row even if the frames you're interested in go to/from the CPU, which is always the case for ethernet <=> wifi frames. Doing so should not bypass the switch chip rules, but even if it does, it doesn't interfere with the purpose of the test - to see what packets are there when the DHCP exchange works properly.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Wed Oct 27, 2021 6:33 am

I recorded with hw=no and all switch rules disabled, and this time I saw the whole DHCP procedure (Request and then ACK). Interestingly, it does not help only disabling the block rule for the particular VLAN. I need to disable all rules for this to work.

With the switch rules enabled, I am seeing DHCP Discover, followed by Offer, Request, ACK, Request, ACK, Request, ACK etc. So the response from the DHCP server is blocked.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 12:04 am

Where can you see it? In the sniff running on the cAP? It's crazy - the Offer should be coming from the same src-mac like the ACK, and as the Request came from the client, it means that the Offer must have made it to the client. So I don't get why the ACK doesn't. Can you check the src-address of the ACK is the same like the one of the Offer?
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 12:20 am

Perhaps I missed it, but why is there a need to deploy these bridge filter rules on all CAP devices? Isn't it just easier to set horizon=1 for the bridge ports for wlan1 and wlan2? I've never tried it, but I wonder if the "bridge horizon" setting under CAPsMAN datapath config will work when using local forwarding?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 9:15 am

The point is to prevent wireless clients associated to different cAPs from talking to each other, plus it needs to be selective per VLAN. So your remark is important in terms that switch chip rules cannot prevent 2.4 GHz clients of a cAP from talking to 5 GHz clients of the same cAP, but due to the VLAN constraint, it requires bridge filter rules to handle that, as the bridge horizon would act on all VLANs.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 12:08 pm

Where can you see it? In the sniff running on the cAP? It's crazy - the Offer should be coming from the same src-mac like the ACK, and as the Request came from the client, it means that the Offer must have made it to the client. So I don't get why the ACK doesn't. Can you check the src-address of the ACK is the same like the one of the Offer?
To make it clearer let's say C = client and GW = gateway.

In case of disabled rules, C sends Request, GW sends ACK. Not sure why the client does not send Discover in the first case, maybe because it was again relying on some cache. I redid the first case with disabled rules with a different client and got the full Discover (C), Offer (GW), Request (C), ACK (GW).

In case of any(!) enabled rule, it is Discover (C), Offer (GW), Request (C), ACK (GW), Request (C), ACK (GW). I also redid this case with a different client and got the same sequence, but not repeating requests. So the client actually receives an IP address and then commences to send an ARP probe on that address to check if it is available, I guess. Then it accounces its IP three times. After that it enters an endless loop asking via ARP who has the gateway IP address. So it seems the switch rules do not break DHCP, but they do break ARP. In the successful case with disabled switch rules, I am seeing the ARP reply from the gateway ("10.90.0.1 is at IntelCor_:..."). Very strange?

The same MAC addresses are consistent in all cases.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 2:04 pm

If the DHCP client wants to verify that the IP it got leased from the server is not used by any other host, it may send an ARP request for that address before starting to use it, but it should consider the fact that it doesn't receive any response as a positive outcome of the test.

As you say that it behaves like this (request/ack, request/ack, ...) even if you disable only the rules with new-dst-ports="", it must be something general. Have you set vlan-mode=secure only at ether1 or also at switch1-cpu?

Second, spawned by @mducharme's remark, do you plan to use both the 2.4 GHz interfaces and the 5 GHz interfaces for the VLANs where clients should not be able to talk to each other? If yes, you'll have to use bridge filter rules anyway.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 2:25 pm

I set vlan-mode=secure all intefaces as you suggested before. My pasted /export above (which I fixed in the meanwhile) somehow ommitted the last two lines.

Good point about the 2.4 GHz and 5 GHz inter-client traffic. Too bad this cannot be filtered at switch/chip level. Maybe using two bridges? I guess I'd have to set them up first with Ansible or BASH on each cAP ac before CAPsMAN provisions the rest then. But I'm doing traffic automation already, so this would not be difficult to do.

Could there be a bug in RouterOS or the switch that my config is not working? I would prefer switch rules over bridge rules for the performance advantage.

My main switch has an ARP spoofing protection feature, perhaps that is interferring. Though why would that only interfere when the switch rules are enabled, and why only on the traffic toward the cAP ac (if it did)?
Last edited by solarium14 on Thu Oct 28, 2021 5:38 pm, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Thu Oct 28, 2021 3:33 pm

Maybe using two bridges?
You can't bridge bridges together, so this won't work.

Could there be a bug in RouterOS or the switch that my config is not working?
I cannot imagine any other explanation at the moment. Because if "accept" rules alone, followed by no "drop" rules, break things, something must be terribly wrong. But do one more test, disable all the switch chip rules and only add ones matching on just the VLAN ID and nothing else, and not restricting new-dst-ports.

My main switch has an ARP spoofing feature, perhaps that is interferring. Though why would that only interfere when the switch rules are enabled, and why only on the traffic toward the cAP ac (if it did)?
I don't know what ARP spoofing means, but as you say, why should it only interfere when the switch chip rules are active. So no, it's not the explanation.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming  [SOLVED]

Thu Oct 28, 2021 6:37 pm

I think I figured it out. I added another rule for letting the ARP traffic pass in particular. Now it works! Thanks, sindy for the amazing help and mducharme for the important point that I also need to segregate the radios. I'm going to use VLANs for this.

This is the working configuration:
/system identity
set name=CAPsMAN

/caps-man datapath
add client-to-client-forwarding=no local-forwarding=yes name=dp_myap vlan-id=2 vlan-mode=use-tag
add client-to-client-forwarding=no local-forwarding=yes name=dp_myap_guest vlan-id=3 vlan-mode=use-tag

/caps-man rates
add basic=12Mbps name=rate_2.4 supported=12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps

/caps-man security
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myap passphrase=myappasswd
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm name=sec_myap_guest passphrase=myappasswd

/caps-man channel
add band=2ghz-g/n control-channel-width=20mhz extension-channel=disabled name=ch_2.4
add band=5ghz-n/ac control-channel-width=20mhz extension-channel=XXXX name=ch_5 skip-dfs-channels=yes

/caps-man configuration
add channel=ch_2.4 country=germany datapath=dp_myap mode=ap name=cfg_myap_2.4 \
    rates=rate_2.4 security=sec_myap ssid=myap
add channel=ch_2.4 country=germany datapath=dp_myap_guest mode=ap name=\
    cfg_myap_guest_2.4 rates=rate_2.4 security=sec_myap_guest ssid=\
    myap-guest-test
add channel=ch_5 country=germany datapath=dp_myap mode=ap name=cfg_myap_5 \
    security=sec_myap ssid=myap
add channel=ch_5 country=germany datapath=dp_myap_guest mode=ap name=\
    cfg_myap_guest_5 security=sec_myap_guest ssid=myap-guest-test

/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=\
    cfg_myap_2.4 name-format=prefix-identity name-prefix=2.4 \
    slave-configurations=cfg_myap_guest_2.4
add action=create-dynamic-enabled hw-supported-modes=an master-configuration=\
    cfg_myap_5 name-format=prefix-identity name-prefix=5 slave-configurations=\
    cfg_myap_guest_5
    
/interface bridge
add name=bridge
/interface bridge port
add bridge=bridge interface=ether1

/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=bridge

/caps-man manager
set enabled=yes

/interface wireless cap
set caps-man-addresses=127.0.0.1 enabled=yes interfaces=wlan1,wlan2 bridge=bridge

/ip address
add address=192.168.51.2/24 interface=bridge network=192.168.51.0

/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=1
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=2
add independent-learning=no ports=switch1-cpu,ether1,ether2 switch=switch1 vlan-id=3

/interface ethernet switch rule
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=2
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=2 mac-protocol=arp
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=2
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3 mac-protocol=arp
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=3

/interface ethernet switch port set switch1-cpu,ether1,ether2 vlan-mode=secure default-vlan-id=1
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Sat Oct 30, 2021 2:34 pm

One more issue I am facing now is that CAPsMAN provisioning is working very unrealiably with the reset button method. I tried adding pass rules for untagged traffic of any kind, for mac-protocol=arp and ip and the same for VLAN ID 1, however none of that helped. Sometimes the remote CAP shows up other times it doesn't, without any consistent condition (sometimes when disabling all entry in switch VLAN and rules, sometimes when re-adding them), sometimes I just have to wait a long time. Maybe it's glitches occurring due to using VID 1 as (untagged) switch management VLAN and access ports for another VLAN for the Wi-Fi/CAPsMAN management? But it did work reliably before I redid the configuration from scratch.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Mon Nov 01, 2021 1:44 pm

I just have to wait a long time.
This solves the problem. No idea why.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Client isolation within VLAN and fast roaming

Sat Nov 06, 2021 5:10 am

The point is to prevent wireless clients associated to different cAPs from talking to each other, plus it needs to be selective per VLAN. So your remark is important in terms that switch chip rules cannot prevent 2.4 GHz clients of a cAP from talking to 5 GHz clients of the same cAP, but due to the VLAN constraint, it requires bridge filter rules to handle that, as the bridge horizon would act on all VLANs.
In this case, another solution might be to enable local-proxy-arp on the router interface for the device that handles routing for the VLAN where you want to allow communication between clients, in addition to bridge horizon. It will not allow direct communication per se, but the traffic will be actually routed between the two clients on the same VLAN.
 
PackElend
Member Candidate
Member Candidate
Posts: 268
Joined: Tue Sep 29, 2020 6:05 pm

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 6:31 pm

/interface ethernet switch rule
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=2
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=2 mac-protocol=arp
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=2
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3
add ports=ether1 src-mac-address=A0:36:9F:81:21:4E/FF:FF:FF:FF:FF:FF switch=switch1 vlan-id=3 mac-protocol=arp
add new-dst-ports="" ports=ether1 switch=switch1 vlan-id=3
could you explain what is happening here again, as the answers are scattered across the thread?
  1. any broadcast and frames from A0:36:9F:81:21:4E are allowed on the specified VLAN are allowed
  2. why explicitly mac-protocol=arp?
  3. anything else is dropped

I would like to create a Guest-WLAN (LAN) wherein only Gateway (www) shall be reachable.
I have CCR as the core router, which runs DHCP, CAPsMAN etc. I have a CRS as a core switch and some CAPs.
CAPsMAN works in local-forwarding=yes.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18959
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 8:47 pm

My response is if it is this complicated its not well implemented on the device itself.
I personally use business class APs where I can assign vlans to SSIDs, and I dont lose sleep over it.
 
solarium14
newbie
Topic Author
Posts: 38
Joined: Wed Sep 08, 2021 10:17 am

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 9:37 pm

could you explain what is happening here again, as the answers are scattered across the thread?
  1. any broadcast and frames from A0:36:9F:81:21:4E are allowed on the specified VLAN are allowed
  2. why explicitly mac-protocol=arp?
  3. anything else is dropped
I think you understood it all correctly. The intention here is to deny all incoming traffic except traffic from the gateway. I've explicitly allowed mac-protocol=arp because the switch chip did not let the gateway through otherwise. I do not know why this is necessary as the first rule should already allow any incoming gateway traffic. This is potentially a bug or documentation issue.
 
PackElend
Member Candidate
Member Candidate
Posts: 268
Joined: Tue Sep 29, 2020 6:05 pm

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 10:15 pm

This is potentially a bug or documentation issue.
thx for the quick reply :)
would you report it to support (otherwise I would do it for you)?


by the way is there any good resource where I could read up all around
horizon functionality may be used to isolate them.
easily?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 10:22 pm

by the way is there any good resource where I could read up all around
horizon functionality may be used to isolate them.
easily?
https://wiki.mikrotik.com/wiki/Manual:M ... n_bridging
 
PackElend
Member Candidate
Member Candidate
Posts: 268
Joined: Tue Sep 29, 2020 6:05 pm

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 10:26 pm

by the way is there any good resource where I could read up all around

easily?
https://wiki.mikrotik.com/wiki/Manual:M ... n_bridging
thx, I love to read MT docs ;)
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Mon Jul 04, 2022 10:51 pm

thx, I love to read MT docs ;)
If that was irony, the simple summary is that bridge horizon is a static method of preventing L2 loops. If a frame arrives through a bridge port with a certain horizon value, it can be forwarded out through any other port except those with the same horizon value.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Tue Jul 05, 2022 3:09 pm

What should be mentioned about Bridge Horizon is that its a software feature and disables hardware offloading when used on hardware offloaded ports...
 
PackElend
Member Candidate
Member Candidate
Posts: 268
Joined: Tue Sep 29, 2020 6:05 pm

Re: Client isolation within VLAN and fast roaming

Tue Jul 05, 2022 3:32 pm

What should be mentioned about Bridge Horizon is that its a software feature and disables hardware offloading when used on hardware offloaded ports...
which is not relevant on APs has they don't offer this on WLAN interfaces

The only question remaining is, do you have to do this on devices, e.g. a core switch, which are between the AP and CAPsMAN?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Client isolation within VLAN and fast roaming

Tue Jul 05, 2022 3:46 pm

do you have to do this on devices, e.g. a core switch, which are between the AP and CAPsMAN?
I would say there's no need - since the goal is client isolation, it is enough if the APs themselves drop packets from other clients (i.e. in the practical implementation, drop everything except packets from the gateway).
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: Client isolation within VLAN and fast roaming

Tue Jul 05, 2022 4:46 pm

What should be mentioned about Bridge Horizon is that its a software feature and disables hardware offloading when used on hardware offloaded ports...
which is not relevant on APs has they don't offer this on WLAN interfaces

The only question remaining is, do you have to do this on devices, e.g. a core switch, which are between the AP and CAPsMAN?
You say its not relevant and after that you ask if it can be done on a core switch... :lol:
So it was totally relevant...
 
PackElend
Member Candidate
Member Candidate
Posts: 268
Joined: Tue Sep 29, 2020 6:05 pm

Re: Client isolation within VLAN and fast roaming

Tue Jul 05, 2022 6:35 pm

You say its not relevant and after that you ask if it can be done on a core switch... :lol:
So it was totally relevant...
May I express myself wrongly:
  • Do you use hardware offloaded ports on APs? Then it is relevant otherwise it is not.
  • Traffic coming from the AP going upstream to a core switch, does not have to be isolated again on the core switch (as answered before), so changing Bridge Horizon does not have to be done, so hardware offloading will not be affected.
I hope is understood now, what I wanted to say :)
thx

Who is online

Users browsing this forum: hjf and 82 guests