It was my understand that when you disable (or uncheck in winbox) the Default Forward option, (for a wireless interface), this keeps any devices connected to that wireless interface from communicating DIRECTLY with each other?

However, i have 2 x PCs, and connected them to a MT radio, with Default FW off, yet they can still ping each other.

Do i have this incorrect? or is something not working as it should?

ROS 6.32.3 on a RB 433 Both devices are on the same subnet (192.168.1.X / 24) and both devices are able to access the internet (both with default forward on and with it off, as they should).

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n channel-width=20/40mhz-Ce \
default-forwarding=no disabled=no mode=\
ap-bridge name=wlan2-5Gn radio-name=5g-R52hN-D4CA6D132949 rx-chains=0,1 \
security-profile=mainWPA2only ssid=HouseN-5gN tx-chains=0,1 \
wireless-protocol=802.11 wmm-support=enabled

thanks

Hi,

really no feedback until now?
I have the same 'issue'. If i uncheck Client to Client Forwarding in CAPsMAN Datapath, users on the same AP can still ping each other.
The Default Forward Option isnt available in gui on that specific AP (controlled by CAPsMAN or not) - but the option is still available via cli.
But it has no effect on the client to client communication.
CAPsMAN is installed on an CCR1036 and one of the AP is an RBwAP2nDr2, both runs on 6.40.4.
What am i doing wrong? Do i need an access list on the CAPsMAN config too?

Best regards
andreas

If two or more client PCs access the same AP and Client to Client Forwarding is unchecked, if you believe the description of the wiki, you should not be able to connect between clients.
https://wiki.mikrotik.com/wiki/Manual:CAPsMAN

Did you check with support?


Likewise, as for the Default Forward option, there is a case of "do not matching" in the access list, so it seems that it is necessary to set an access list in order to control this area.
https://wiki.mikrotik.com/wiki/Manual: ... properties

Hi Kometchtech,

thanks for your reply - i maybe found a solution... Layer2 communication was disable correctly, but the icmp found its way over layer3...
I created a rule that drops icmp within that subnet - that solves it quickly.
So everything worked as expected, i just expected another behaviour...

Regards