How can I allow only one specific ethernet device to be connected in one of the Mikrotik ethernet port and block any other device ?

The aim is to exclude any other device to connect onto that ethernet port.

Add a static ARP entry for the desired device on the appropriate Ethernet port.
Set this ethernet ports ARP mode to reply-only.
-Chris

Right Chris. Merci vielmal !!

the problem is that i already use the reply-only option on DHCP server and on the network bridge, so that only the devices logged through my DHCP server are accepted on the network. this blocks devices with static addresses.

if i use your config, then all devices connected on the port i want to restrict, will get a DHCP lease and arp entry and if i configure the ethernet port as reply-only , then all devices will be accepted via DHCP whereas i only want to accept ONE specific device on that specific ethernet port with its MAC own address....

tricky ?

Is there a reason not to just use "Src MAC Address" (on the Advanced tab when using WinBox) as part of a firewall rule?

Ah, I didn't realize that ethernet port is a bridge member.

In this case I'd suggest a bridge filter like this:
This drops all traffic on this port NOT coming from the specified MAC address.
-Chris

errors :

in/out-bridge-port matcher not possible when interface (bridge1) is not slave
in/out-interface matcher not possible wheninterface (ether2) is slave - use master instead (bridge1)
in-bridge-port matcher not possible when bridge use-ip-firewall is disabled

Error 1: is related to error 2, fixed below:
Error 2: For this scenario, ether2 has to be a direct member of the bridge, remove its master port and bind it to the bridge.
Error 3: activate IP firewall in bridge settings. (In Winbox: Bridge -> Settings)

Good luck!
-Chris

found the solution, you need to put the rule in the filter rules of the bridge !

Ok, next question :

Now the ethernet port filters and allows a device with a specific MAC addess. That's good.

But if that device is itself bridged with other devices, the filter blocks those other devices.

How can I configure so that these bridged devices are not blocked ?

Now this is getting tricky as we're now leaving the way L2 is designed to work.
If you're really in desperate need of this, I think the only way is scripting.
Remove the static ARP entry from your ARP table and let DHCP handle this address (can still be set to static but DHCP needs to handle it).

Now create a scheduler script - or even better, a netwatch item, like this:
"Check this MAC addresses interface in ARP table and if it's either not present or on a wrong interface, block all MAC addresses on ether2 but this one.
As soon as it's back on this interface, allow all MAC addresses on ether2".



-Chris

I have a Video Intercom Door Station. It's on ethernet 23. I would like to block any attempt of connection throught that cable that does not belong to my intercom.

I have set:

/interface bridge filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=drop in-interface=ether23-slave-local
in-bridge=bridge-local
src-mac-address=!00:00:05:00:00:02/FF:FF:FF:FF:FF:FF log=no log-prefix=""

This is not it's mac (i have it copied from here). But i still can see the image from it and am able to connect to it.

Any ideas?

I'd say the rule has to be in chain=input, not chain=forward, if the destination MAC of the frame is the Mikrotik itself, i.e. if the Mikrotik routes the stream from the camera somewhere else. chain=forward would be correct if the Mikrotik was just bridging the stream from the camera to another device on the same bridge.

Plus a hint - protection by MAC address is not enough. If I wanted to barge into your network this way, learning the MAC address of the door station would be among the first items on my ToDo list. So you must treat the door station as a malicious device and let it only send data where you want it to. And still, unless there is a certificate-based authentication between the door station and the monitor, the bad guy will be able to feed your video surveillance system with a movie of your friend waiting at the door if he replaces the door station with a player sending the stream to the same destination from the same MAC address.

Maybe include a minimum connection up time to be required to allow data to pass from the MAC on that ether port.
0ther options could include a trigger script on ethernet connection that checks for a correct telnet,ssh,web response to enable the port.

is it possible to allow two MAC adresses on one port with bridge filter ?

regards, Richard

is it possible to allow two MAC adresses on one port with bridge filter ?

Sure. Bridge filter rules work the same way like all other rules in the system, they are evaluated one by one, first to last, until the first one matches or the list gets exhausted.

I have hex poe with pretty default configuration powering on my 3 outdoor cameras. Ether1 plugged to my network and ether 2,3 and 5 connected to cameras. I was thinking about restricting those ports to my devices MAC only so if anyone unplugs my camera and connects other device it won't get thru. What is the best way to achieve that? Firewall rules based on MAC?

Against stupid attackers, a bridge firewall filter linking MAC address to a port is sufficient. A clever attacker will copy the camera's MAC address to his device, so only 802.1X is a safe method, unless the attacker can extract the password for 802.1X from the camera. The question is whether your cameras support 802.1X.

I see IEEE 802.1X enable checkbox on my hikvision cam along with some parameters like protocol, version, user, password, so I assume it is supported.
What now?
Should I find tutorial how to setup IEEE 802.1X on mikrotik yes?
Is it better to set it directly on hex poe managing only those 3 cams, or better on my central router which holds capsman as well?

802.1X enables forwarding through an Ethernet interface to a directly connected device if the latter authenticates properly. So 802.1X must be enabled on the hEX PoE itself. However, with RouterOS 6.x, you need an external RADIUS server for 802.1X to work because Mikrotik's own one (UserManager) doesn't handle EAP in RouterOS 6.x. The UserManager in RouterOS 7 does, but RouterOS 7 is still in beta stage.

I managed to setup RADIUS server on my QNAP NAS and connected hEX PoE with it (I could authenticate on router using user from RADIUS), but nothing else. I was playing with it nearly 2h and I think there is issue on camera side - it doen't have EAP-TTLS which I set on hEX. I think I will stick with firewall by MAC, it's better than nothing.

On hEX PoE which my cameras are connected to I created rules as below in section bridge-> filters, but I still can connect to them from my PC if I change MAC in rule for test purposes.
Is it because from my side they are treated as destination not source and it is ok (I don't have opportunity to connect other device instead of camera now) or I made a mistake and something needs fixing?

If the PC was in the same LAN, the forward chain in /interface bridge filter would be relevant.

If the traffic between the PC and the cameras is routed, the input chain filters traffic from external device (camera) to the router itself (so you match on src-mac-address), and the output chain filters the traffic from the router to the external device (so you match on dst-mac-address).

Cameras are in same LAN as PC so I understand I am interested in forward rule

I created drop rule for both directions and changed MAC to different (oirignal ends up with 17) and I still can access camera via IP in browser, so it is not working as it should be.

If L2 forwarding on switch chip is permitted (hw=yes on /interface bridge port rows which is set by default), the frames between Ethernet ports of the switch chip bypass the CPU and hence bridge filter rules.

As you've got hEX PoE, you can use /interface ethernet switch rule without disabling the hardware forwarding.

I created "redirect to cpu" rule on switch1/eth2 but now when I provide cam MAC it stops working (only cam traffic is redirected to CPU) which is exactly opposite of what I want to achieve.
In my understanding solution would be same switch rule with !MAC where all MACs except cam's would be redirected to CPU and cut off, and cam would flow outside CPU, but sadly switch rule doesn't accept !MAC.

I guess its to advanced for me :(

You're almost there :)
The switch chip rules are also evaluated top to bottom until the first match. There is no "action" as such. So your rule set could look as follows:

1. switch=switch1 ports=ether1 src-mac-address=10:20:30:00:00:10/FF:FF:FF:FF:FF:FF
2. switch=switch1 ports=ether2 src-mac-address=10:20:30:00:00:20/FF:FF:FF:FF:FF:FF
3. switch=switch1 ports=ether3 src-mac-address=10:20:30:00:00:30/FF:FF:FF:FF:FF:FF
4. switch=switch1 ports=ether1,ether2,ether3 new-dst-ports=""

The first three rules, matching on a particular ingress port and a particular source MAC address, work as "accept" ones - frames match them and no handling is specified for those frames, so they are just let through unchanged.
The fourth rule matches on just a port list, so it matches any frame which ingresses through any port on the list; as the new-dst-ports list is empty, it effectively works as a drop one - these frames are not allowed to be egress through any port.

In the example, no rules match on switch1-cpu and ether4 and ether5, so frames which ingress through these ports are let through without limitation.

For the opposite directon, you can create rules which would match on these remaining ingress ports and dst-mac-address:

5. switch=switch1 ports=switch1-cpu,ether4,ether5 dst-mac-address=10:20:30:00:00:10/FF:FF:FF:FF:FF:FF new-dst-ports=ether1
6. switch=switch1 ports=switch1-cpu,ether4,ether5 dst-mac-address=10:20:30:00:00:20/FF:FF:FF:FF:FF:FF new-dst-ports=ether2
7. switch=switch1 ports=switch1-cpu,ether4,ether5 dst-mac-address=10:20:30:00:00:30/FF:FF:FF:FF:FF:FF new-dst-ports=ether3
8. switch=switch1 ports=switch1-cpu,ether4,ether5 new-dst-ports=switch1-cpu,ether4,ether5
Rules 5 to 7 allow frames with a particular destination MAC address, which ingress via one of those ports, to reach only a particular destination port. The frames which do not match any of those are caught by rule 8, which allows them to be egress via any of the other ports in this group, but not through any port among ether1 ... ether3.

First of all thank You for Your patience.
I totally understand what You wrote and it makes perfect sense in my logic, but sadly doesn't work.
My setup:
eth1 - connection with rest of the network
eth2 - cam1
eth3 - cam2
eth4 - disabled
eth5 - cam3
Settings on hEX PoE: This setup breaks connection to cameras immidiately. As soon as I disable rule number 3 it is starting to work.
My first guess was that MAC are assigned wrongly, so they are not being catched in rules 0,1,2. To test that I left rule 3 disabled and I set rules 0,1,2 to "redirect to cpu" - cameras stop working. So they were catched correctly via MAC filtering. Now I change one letter in each MAC, boom, they are working again, so catching works well, but they were not catched now because MAC is wrong.

Summarizing looks like rule 3 somehows overlap rules on top, even they are higher on the list.

Add new-dst-ports=switch1-cpu,ether1 to rules 0,1,2 (as numbered on your printscreen). It seems that omitting the new-dst-ports parameter from the rule completely has the same effect as explicitly specifying new-dst-ports="". Plus the Set New Dst. Ports column seen in Winbox does not exist in command line at all, so it seems to be generated based on the presence or absence of the new-dst-ports parameter of the row, so I may not be the only one confused.

Also, I forgot one rule in the second group yesterday, to be placed between your 3rd and your 4th:
switch=switch1 ports=switch1-cpu,ether1 dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF new-dst-ports=ether2,ether3,ether5
It is necessary to allow also broadcast traffic (ARP in your case) to reach the cameras.
To permit any non-unicast address rather than just the broadcast one, the dst-mac-address in this rule would be 01:00:00:00:00:00/01:00:00:00:00:00.

Less important, you don't need to redirect the frames to CPU in order to drop them. Just give them an empty new-dst-ports list.

You are indeed forum guru.
Thank You once more, it works like a charm now. All cameras accessible with all rules enabled and when I change MAC camera stops responding.

Posting final settings, maybe someone will find it useful one day. Environment described few posts above.. Thanks again, take care.

Woops, hEX PoE became unaccessible today. I couldn't connect to it from my PC via IP/MAC. I did reboot via MAC telnet from my main router and after reboot it was still unaccessible and without IP address.
Again via MAC telnet from main router I disabled rules 0-8 and it instantly got IP address from DHCP and became accessible. What happened? My DHCP lease time is 3h, I would understand if it would stop working after 3h, but it worked for nearly whole day.

Should I add some more rule to accept DHCP traffic from eth1?

Hm, switch1-cpu and ether1 have to be added to the new-dst-ports list in rule 4 above.

DHCP lease renewal uses unicast addresses, which explains why it didn't fail after first expiration. What puzzles me more is why it eventually failed, it means that the renewal hasn't succeeded for some reason, so the lease has expired and the client started sending DHCPDISCOVER, which goes to broadast address and hence it got caught by rule 4.

So far so good :)

Against stupid attackers, a bridge firewall filter linking MAC address to a port is sufficient. A clever attacker will copy the camera's MAC address to his device, so only 802.1X is a safe method, unless the attacker can extract the password for 802.1X from the camera. The question is whether your cameras support 802.1X.

https://networkengineering.stackexchang ... t-bridging