Hi all,
I run with very limited satellite internet and to ensure my queues work i need the staff to remain on their vlan for guest access to remain usable.
when staff login via their ssid they are granted access via hotspot using mac cookie with a 365d timeout as to allow ease of access.
Is there anyway using scripting or such to block the hotspot hosts mac addresses from my other vlans as they always find out the other wifi passwords.
You can always use bridge filtering to prevent particular MAC addresses from using wrong VLANs; the additional CPU load caused by bridge filtering should not be a problem given you have a limited uplink bandwidth:
However, if I understand it right, there’s the chicken or egg problem - to learn the MAC address of a device belonging to staff member, the staff member has to connect to the “correct” SSID first, and if he doesn’t, he is treated as a guest as you cannot ask the guests to tell you their MAC addresses in advance. Even if there is some site the staff members must use, and that site is only accessible via a dedicated VLAN or from a dedicated IP address range, nothing prevents them from using another device to pretend it is a guest one (leaving aside MAC spoofing, no idea what is the technical qualification of your staff members).
Sounds like a staff issue with passwords and its not really a router issue.
Misuse of IT equipment and information is grounds for dismissal in many companies.
Hi Sindy,
This sounds like it is what i am after. I can force the chicken or the egg by when we dont have guests i will disable the network, it wont stop MAC Addreess spoofing but thats a tradeoff i will have to deal with. Currently i dont have any interfaces in a bridge as i deal with a single sfp interface with vlan subinterfaces for my LAN.
To get this to work do i simply add everything into the bridge (sfp, vlan1, vlan2 etc?) or can i simply apply the rules.
Of course bridge rules won’t work without a bridge. But if I get you right, the wireless APs are external devices connected via the SFP, correct? Because otherwise there would have to be a bridge already. So yes, you need to add a bridge, in all /interface vlan rows change the interface from sfp1 to the name of the bridge, and make sfp1 the single member port of the bridge.
And then you can add a script that will check the list of external MAC addresses on the staff VLAN and add those for which no bridge filter rule exists for dropping packets coming from the guest vlan, and schedule it to run every minute or so. But if your DHCP server in the staff VLAN is the Mikrotik itself, use the script attached to the dhcp server instead of the scheduler, as there you have the leaseActMAC variable, which makes the script much simpler. On the other hand, debugging the lease scripts is harder than debugging normal ones.
After thinking the idea above a bit more, I suggest to trash it and use a different approach - if every single frame has to be matched against potentially tens of bridge filter rules, the CPU may have a tough time (you haven’t stated your RB model). So instead, you can do the following:
set arp on all the /interface vlan rows for the wireless connections to reply-only, and set add-arp on the /ip dhcp-server rows to yes. Doing so will ensure that devices that do not ask for IP address using DHCP (i.e. ones with manually configured IP addresses) won’t receive any IP packets because the router won’t use ARP protocol to determine the MAC addresses to send them to. So the client devices will have to use DHCP to get network access.
for each MAC address to which a lease is assigned by the DHCP server serving the staff vlan, the script will create a static lease linked to the DHCP server serving the guest vlan, with block-access set to yes - or, maybe even better, with a normal IP address from the correct range but with address-lists set to some address list name, which in turn will make sure that the firewall mangle rules will mark the packets from/to these addresses for the same speed limits like the staff VLAN has, so it will appear to work normally except that the impact on guest bandwidth will be the same regardless which VLAN/SSID the staff member will use. So the time until they realize they need a dedicated device, which has never connected to the staff SSID, to override the limitations should be a few weeks longer.
Hi Sindy,
Been playing around with this and think if i set a static IP for each host with server ‘all’ this will mean regardless of which vlan they will be issued the staff ip address and therefore have no internet access on the other vlans. can use /ip dhcp-server lease make-static however is there a way to define which server to use?
Correct, but a full ban will draw attention to the fact that some countermeasures are taken.
I’m not sure I understand properly what you ask.
Sure you can restrict the validity of a static lease to a single DHCP server instance, by setting the server property of that static lease to the name of that server instance. However, this means that DHCPDISCOVER requests arriving to other server instances will be served according to these instances’ own policies, i.e. from their generic address pools. I.e. a static lease bound specifically to the server instance serving the staff vlan won’t prevent the cheating staff members from getting an IP from a guest pool when registered to another SSID → vlan → dhcp server instance.
But if the actual question is “can I have a lease that is ‘static’ in terms that a given MAC to only use a given DHCP server, but let it get an IP address from a pool rather than a fixed one”, then the answer is “yes, once you have a static lease (no matter whether you create it ‘manually’ or through conversion of a dynamic one using make-static, you can set its server parameter to any of the servers (or all), and you can specify a pool as address”. So you can have one pool for real guests, and another pool for cheating staff members, both in the same subnet and VLAN handled by the same DHCP server instance, and you can use firewall rules matching on the src-address range copying 1:1 the pool for cheating staff to assign low-bandwidth QoS packet-marks.
As for the guest-imitating devices used by cheating staff members, another script can keep track of MAC addresses seen on guest SSID during subsequent cruises, and move them to the limited QoS category too.
This is the solution i have come up with starting to test properly now.
Any time a new dhcp connection is made from the staff server it looks for any other dhcp leases
removes all of them but one which is then changed from its server to server state all.
this means that once a staff member connects to the staff ssid any ssid after that they are still issued a staff ip.
This means that they have no internet on other SSID’s (no default gateway) using the arp reply only on the guest network ensures that they cant set a static on the guest ssid.
I believe this is an elegant enough solution for now.
Thank you for your help
J