MAC-based exception in a Mikrotik hotspot
There was a job to build a limited, authentication-based Internet access system at a client’s apartman-building site. It was quickly accomplished with the built-in hotspot module of the Mikrotik router.
During the current remodel the owner has replaced the old TVs with new flat-screen smart TVs, so we had the task to connect them to the Internet. Connection requirements were:
- WiFi should be available in the apartment
- guests should be able to access Internet with user/password credentials
- TVs should access Internet without password
- when the TV cables are connected into laptops the system should ask for password anyway
The first two points were already done with the previous setup, we just had to extend the system to offer the third and fourth points.
To enable TVs to access Internet without password we could simply connect them to a LAN-segment instead of the hotspot-segment, but with that step we would have also enabled password-less access for anyone who uses the cable from the TV in a laptop. This would intervene with the fourth requirement.
Alternative idea was to use software-based solution instead of a hardware-based one. At this point I have to mention that the goal was to make the password-less access difficult to use, not to implement a third-level DoD security.
The software-based solution had a huge positive impact on the cabling as well, because we did not have to pull new cables from the racks, we just had to add a short patch from the existing AP-routers to the TVs.
Base of the solution is identifying the MAC of the TVs among the network commications, as well as the extendability of the hotspot firewall rules.
The packets which come from the desired MACs have to be marked as soon as possible in the Mikrotik packet flow so we can bend the existing rules according our needs. This would be the mangle::prerouting chain:
/ip firewall mangle add chain=prerouting connection-state=new src-mac-address=74:00:00:00:00:5A action=mark-packet new-packet-mark=hotspotjump
After this we are able to add rules addressing these, “hotspotjump” marked, packets and to add any additional TV’s – or any other equipment’s – MAC can be added to the solution just with this rule, all of the rules below will be used for them as well.
After enabling the hotspot module the associated port’s communication will be fully managed by the hotspot’s algorithm and the user will be asked for credentials when neccessary. This authentication steps have to be circumvented by the packets originated from authorized equipment.
For this we have to modify the default chains in two specific points.
The packets originated from the hotspot port in the nat::dstnat chain will be routed into nat::hotspot, and here starts the idenfication and authorization of the communication.
Second point would be the beginning of the filter::hs-unauth chain. Unathorized packets end up herein.
If we manage to add one conditional jump in these two places we will be able to sneak our way around the hotspot module.
A basic return rule have to be added in those places for the desired effect:
/ip firewall nat add chain=hotspot packet-mark=hotspotjump action=return place-before=14
/ip firewall filter add chain=hs-unauth packet-mark=hotspotjump action=return place-before=26
This will simply reroute the packets back into the previous chain instead of going through the actual chain.
What we have achieved
- WiFi is available in all apartments
- new TVs can connect without credentials
- using the TVs’ cables in laptops we still have to provide credentials to access the Internet