Hi. I have a hEX S with a PPPoE connection to my ISP in ether1. In ether2, I have an AP connected and in ether3 and 4, I have a 802.3ad bonding rule for my Synology NAS. For all ports except ether1, I have a Bridge (LAN-marked in interface list) assigned to them, this bridge also has a DHCP server running with an address pool of 192.168.1.1/24. The case is I’d like to disable DHCP for all ports so if I plug in my computer to any of them I shouldn’t get an IP but at the same time have DHCP available for users connecting to WiFi through the AP connected to ether2. The Synology NAS and the AP have both static IPs.
Don’t know if I expressed myself correctly feel free if needed to ask more about my intentions.
I suppose you are talking about the variant when someone connects a PC instead of the Synology or AP, not about the case when someone connects a PC to ether5 which is the only unused port on the bridge? If so, there is no reliable way except if the Synology and the AP would both support 802.1x and you had an external RADIUS server (still no signs of Mikrotik’s embedded User Manager to support EAP authentication).
A poor man’s solution could be to set both the Synology and the AP to use VLAN tagging, so an ordinary PC would not be able to ask for a lease, but the black hat guy can still use a linux PC with VLAN support and get the address anyway, so the question is what type of events you want to handle - mistakes or attacks.
Yes, I mean avoiding giving out an IP to a hypothetical PC connected to the ports used by the Synology and the AP. I want this to avoid mistakes and have only the AP available for users to connect. I don’t think I can use VLAN tagging if I want to still access my Synology and RouterOS through WiFi.
(still no signs of Mikrotik’s embedded User Manager to support EAP authentication).
Just FYI: EAP support for User Manager is in RouterOS7.0beta5 . To my experience all works fine, even with EAP control in RouterOS 6, except for Windows clients I did have no access. With the RADIUS server in the Synology NAS it works for all clients.
I think you can if the AP is capable to do VLAN tag manipulation - some are, some are not. The idea was that the VLAN would only be tagged at the interconnect ports between the Synology and the AP, whilst the AP clients would see it untagged. I don’t have any Synology nearby but I suppose it can use VLAN tagging.
In that case, game over, because the DHCPDISCOVER received from a device directly connected by an Ethernet cable looks exactly the same as a DHCPDISCOVER received via the AP. Only the client’s MAC address and client-ID differ, but there is no bit in MAC address which would distinguish wired interfaces from wireless ones.
It was my first thought, but it only allows to block incoming DHCP traffic on some physical ports and permit it on others, while the OP seeks protection from requests coming through the same physical port - if an AP is connected there, let them through, if someone disconnects the AP and connects a PC instead, don’t.
But this explanation made me realize an almost-solution, if only script execution could be triggered by more events… @migi28, you could use a script to check that the AP itself responds to a ping, and once it stops, disable the DHCP server until it starts responding again. The problem is the time between the disconnection of the cable and connection of the other one - you would have to schedule the script to run every second because “ethernet port went down” is not an event you could use to spawn a script execution.
Sure, blocking incoming traffic by L3 and/or L4 headers using bridge filter as such works, it’s only the detection of what is currently connected to the port what causes the trouble.
No need to list how many possibilities it unlocks.