I had my input chain to block everything apart from clients on my main VLAN - Similar to the securing your router wiki page. I have noticed that clients from other VLANS try to access the router using ports such as 67,68 (DHCP), NETBIOS related and various other ports like 37942, 59838, 57621 the list goes on. DHCP works fine despite this.

At the moment I have locked things down further to only allow my admin PC and second Mikrotik to have input chain access, and hence even more entries shown in the log.

Should I allow all LAN clients access as per the wiki page or just allow admin machines?
Should I be allowing certain ports e.g. 67,68

You have to allow access to all services offered by router. If router is acting as DHCP server, then you have to allow connections to UDP port 67 (originating from port 68). Ditto for TCP/UDP ports 53 (any source port number) if router is acting as DNS server for clients. Etc.

As to other probed connections: modern OSes (most notably Windows, but other as well) probe LAN hosts to discover various services which are then presented to users. Mostly that's harmless. If you're blocking those attempts, then there's no benefit in logging them ... only if you're debugging something.

Thanks mkx

I will allow 67 although DHCP somehow manages to work without. I use separate DNS server so should be ok there.
It's quite scary how many connections my phone tries to make to the router when it connects to wifi including quite a few ICMP requests.

DHCP works because the DHCP server is "closer to the wire" than the firewall (but nevertheless the packets are seen by the firewall). In another words, dropping DHCP packets from client to server using IP firewall has no effect as it is done too late. Where you really need to block DHCP from some clients, you have to use bridge filtering for that.

Hmmm, I have always setup my dhcp server from the router, and have never forwarded ports 67????
Not sure what I am missing in the explanation above. Is there a different way to have the router do DHCP??

As @sindy explained, DHCP is an IP service which is not entirely L3. But IMHO deserves a (positive) firewall filter rule just in case if handling somehow changes some time in the future. Quite some time I've had a similar experience: I was trying to set up DHCP server on a linux host sitting on a trunk interface. I wanted DHCP server to only answer DHCP requests on certain VLAN interfaces, but instead it answered all DHCP requests from all VLANs. I then changed the landscape of my LAN so I can't easily test if this is still the case after all these years.

DHCP works because the DHCP server is "closer to the wire" than the firewall (but nevertheless the packets are seen by the firewall). In another words, dropping DHCP packets from client to server using IP firewall has no effect as it is done too late. Where you really need to block DHCP from some clients, you have to use bridge filtering for that.

Thanks for the explanation. I have added in a rule anyway just so I don't see it in the log.

Talking of bridge filtering - can I check that is the best place to stop some clients on a VLAN having access others on the same VLAN - I think this is another instance where the firewall has no effect.

Talking of bridge filtering - can I check that is the best place to stop some clients on a VLAN having access others on the same VLAN - I think this is another instance where the firewall has no effect.

Yes. With a caveat ... connection has to pass the bridge (e.g. both parties are connecting to different ports). If there's a (VLAN-aware) switch in your LAN and both connection endpoints connect to that switch, then setting on RB's bridge won't affect the connectivity ...

I will experiment. I have an IOT VLAN. I want to allow some wireless clients to communicate (MQTT etc) but block some completely apart from internet access

Talking of bridge filtering - can I check that is the best place to stop some clients on a VLAN having access others on the same VLAN - I think this is another instance where the firewall has no effect.

Correct that the IP firewall has no effect there.

Bridge filtering is a bit tricky when it comes to affecting communication at L2. First, there must be no shorter path for the traffic between the two hosts in question, so if both are connected to the same dumb switch connected to the Mikrotik, bridge filtering won't help.

Even if both are connected directly to Mikrotik, direct forwarding by its switch chip (aka hardware acceleration of bridging) has to be disabled on at least one of the ports in order that the traffic was forced through the software bridge, or switch chip rules have to be used instead.

And if VLANs are involved, the bridge filter functionality has some limitations.

Plus even a bug exists on some CPU architectures (I cannot remember whether it is limited to VLAN-tagged frames or not).

For wireless clients, blocking of client-to-client forwarding on the AP may be possible; if an external AP is connected to the Mikrotik, bridge filtering won't help.

This is going to be interesting and make my head hurt I think.
I have a second Mikrotik as an AP with a trunk connecting the two. I will do some testing with my phone as I can wander around and connect it both routers.

Agreed grumpy my head hurts. What is really cool is that one can block same vlan members from each other using bridge filtering.
@sindy Just to be clear, is the blocking by IP, or my MAC, and can it be granular aka just for certain ports?

@mkx. Okay, so I should make it part of my basic config then to do this........
{input chain}
......
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow NTP service" connection-state=\
new dst-port=123 in-interface-list=LAN protocol=udp src-address-list=\
NTPserver
add action=accept chain=input comment="Allow LAN DHCP queries-UDP" \
connection-state=new dst-port=67 in-interface-list=LAN protocol=udp
add action=drop chain=input comment="Drop All Else"

Ok I have added the mac address of my phone in the bridge filter of the main router action=drop

Testing across the same VLAN
Pings are blocked when the phone and endpoint are connected via different devices. e.g. phone via router, endpoint via AP
Pings succeed when phone and other device are both connected to the same device i.e. both connected to router or both connected to AP. (both connected to AP understandable as there is no filtering set there)

So bridge filtering has no effect when both devices are connected via same radio.
Edit: This makes sense as both devices are using the same interface and therefore not traversing the bridge.

Next is maybe to try wireless access lists

I have succeed to block selected clients from communication on the same VLAN (Sorry for being very off topic from my original question)

Solution was to use a combination of bridge filtering and wireless access list

To stop communication across devices on the same radio/AP block device with Wireless access list - add mac and disable forwarding - duplicate this on both mikrotiks
To stop communication across devices on different APs block by using bridge filtering on main router

A bit long winded but seems to be working. Clients still have internet access, but just cannot talk to other devices on the same VLAN.