First (expected) situation:
Notebook (192.168.1.11) connected to Mikrotik via Ethernet.
Tablet (192.168.1.12) connected to Mikrotik via Wi-Fi.
If we send ping packages from Notebook to Tablet they are drops, as should be according Firewall rules.
Second (not expected) situation:
Notebook (192.168.1.11) connected to Mikrotik via Wi-Fi.
Tablet (192.168.1.12) connected to Mikrotik via Wi-Fi.
In this case, if we send ping packages from Notebook to Tablet we got it back. Firewall rules not applied.
No traffic if you watch traffic through: Tools - > Torch.
No icmp packets between Tablet and Notebook if use Second situation.
What’s wrong and what to do to fix it for work rules Firewall and was in sight packages in Tools - > Torch?
Would have to see complete config to assess properly.
/export hide=sensitive file=yourlatestconfig
In general, if items are in the same LAN or VLAN, there is no way to block traffic between them because they are connected at layer 2, whilst firewall rules are applied at the router, layer 3.
Thus the trick is to put one LAN on a bridge, and the other not on a bridge, or both on separate bridges, or both off bridges and on separate LANs.
This may be a case for VLANs for example where you have ethernet and wifi for home users and then you provide separate WIFI for guest users.
In this case on your bridge you create a VLAN and then use one chain on the AP for the guest user or a virtual WLAN for the guest user.
It appears your unit is an AP and not a router??? However, perhaps via RouterOS, it has some use as a router.
Looks like a 2.4Ghz two chain unit??
There are also two specific functions in Mikrotik APs for client isolation. Not sure since its been awhile since I looked at that but one is easy to find and the other not so easy.
At least one of them is for Client to Client ISOLATION. In this case you want to block two users on the same WLAN from seeing each other. It is probably based on mac address.
It should work for you but the VLAN method and use of the router firewall is better security.
Hmm I thought version 6.43.8 got rid of slave and master interface configurations??
In any case please post entire config…
/export hide=sensitive file=yourlatestconfig
(shows up in files, download to PC, open in notepad++ cut and paste here and apply code parenthesis from above text modification line)
It did. But if some device started life pre-6.40 and received upgrades, then upgrade script didn’t change names of interfaces. Only setting master-port=ether2-master on all slave ports was removed …
@Anastasia: are you completely sure that laptop indeed uses address 192.168.1.11 in both wired and wireless case?
Your second “unexpected” condition is correct and is totally expected for me.
The traffic doesn’t even enter the bridge - it remains in the wireless interface, the two devices use your wlan interface as a wireless switch.
Mitigation would be disabling default-forward on the AP - this will isolate clients connected to the same wireless interface.
OP set default-forwarding=no on wireless interface already. However, manual says that
This is the value of forwarding for clients that do not match any entry in the access-list
. OP has access-list constructed and there’s again “forwarding=” with default value of “yes”.
The problem might be then the following: does bridge send packets back to the ingress port? If forwarding was set to no, then all packets from wireless client 1 would be sent to bridge. Even if bridge rules would allow those packets to be delivered to wireless client 2, do those packets get sent back to wifi “port”?
Sorry, didn’t notice the default-fwd=no in the config.
As OP also set default-authentication=no and created an access list with default-forward=yes per client, this setting overrides the setting in the interface setting.
So we’re still talking about a default-forward issue on the w/l interface.
-Chris
I found a possible problem. in settings Wireless → Access_List are the leaf access. Where indicated in the hand value of the Forwarding = Yes. if you remove the check mark (Forwarding = No), then everything is fine, the data exchange stops. Seems the problem solved.