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).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
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.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.
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.The first option seems to bottleneck all traffic through one of the cAPs, right?
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.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
@sindy,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.
I don't know what is exactly possible in CAPsMAN, I am running a Unifi wireless network here (with MikroTik router).- 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,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.
You can do a) on stand-alone APs as well. For doing b) you need CAPsMAN and local-forwarding=no(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).
With appropriate bridge configuration on CAPsMAN device wireless users are safe from wired ones as well. And vice versa.(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
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.there does not seem to be a function to configure the bridge in CAPsMAN.
It seems one can automate the setup using SSH and Python. Something like this (note: untested code):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.
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())
Yeah, I have already disabled client-to-client forwarding using CAPsMAN.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...
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.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.
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.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.
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?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.
The basic idea of your filter setup does make sense, but...Does that filter command make sense?
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.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?
[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
# 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
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.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.
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=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
By the way, what is the expected CPU overhead and throughput reduction one can expect from using such filters.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
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.@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...
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.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:
Code: Select allchain=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
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.By the way, what is the expected CPU overhead and throughput reduction one can expect from using such filters.
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.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.
# 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
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=""
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.)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?
# 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
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=""
local 10.90.0.15 port 61481 connected to 10.90.0.14 port 5201
can=$'\x18'
cr=$'\r'
ssh -tt host "$can${cmds/\n/$cr}$can"
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.Unfortunately, it seems to be impossible to enter the safe mode via SSH commands.
/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
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.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.
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.If the client keeps sending ARP requests, it should mean it has already received a DHCPOFFER.
To make it clearer let's say C = client and GW = gateway.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?
You can't bridge bridges together, so this won't work.Maybe using two bridges?
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.Could there be a bug in RouterOS or the switch that my config is not working?
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.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)?
/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
This solves the problem. No idea why.I just have to wait a long time.
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.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.
could you explain what is happening here again, as the answers are scattered across the thread?Code: Select all/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
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.could you explain what is happening here again, as the answers are scattered across the thread?
- any broadcast and frames from A0:36:9F:81:21:4E are allowed on the specified VLAN are allowed
- why explicitly mac-protocol=arp?
- anything else is dropped
thx for the quick replyThis is potentially a bug or documentation issue.
easily?horizon functionality may be used to isolate them.
https://wiki.mikrotik.com/wiki/Manual:M ... n_bridgingby the way is there any good resource where I could read up all aroundeasily?horizon functionality may be used to isolate them.
thx, I love to read MT docshttps://wiki.mikrotik.com/wiki/Manual:M ... n_bridgingby the way is there any good resource where I could read up all around
easily?
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.thx, I love to read MT docs
which is not relevant on APs has they don't offer this on WLAN interfacesWhat should be mentioned about Bridge Horizon is that its a software feature and disables hardware offloading when used on hardware offloaded ports...
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).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...which is not relevant on APs has they don't offer this on WLAN interfacesWhat should be mentioned about Bridge Horizon is that its a software feature and disables hardware offloading when used on hardware offloaded ports...
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?
May I express myself wrongly:You say its not relevant and after that you ask if it can be done on a core switch...
So it was totally relevant...