I need to install an additional wAP device in my yard and I’d like to secure as much as possible the physical connection between it and the router (hEX RB750G3).
As no matter how secure I run the Ethernet cable, one might still physical access the wAP, disconnect it and connect an unauthorized device to get access to my LAN (complex to explain why I cannot fully secure the cable).
wAP will be managed by CAPsMAN on hEX, having same configuration as other 2 wAPs I currently have inside the house.
Is there any way to protect the router and rest of LAN in case another device than the authorized wAP is connected?
I saw some ideas of filtering at bridge level, I don’t know if they’re secure enough and if the solution drops the transfer speed or not.
Is there any possibility to implement some scripts to automatically disable Ethernet port of the hEX in case there is something else connected to it than the authorized wAP, without sacrificing the performance of the hEX?
Isolating the AP from the rest:
Create a dedicated /30 transport network for this certain AP and make ARP on those two interfaces (ether on hEX, ether1 on AP) static.
Configure seperate datapaths for all your WiFi networks for manager forwarding and apply these data paths to your AP.
That might impact the APs performance as manager-forwardiing is a CPU-hog on AP side.
Parse your logs and look for the AP-facing ethernet port going down. As soon as it goes down, disable it.
Create a dedicated (physical) network for all your CAPs. Connect all your CAPs to this network only. Do not assign any IP addresses to any device here. Make sure MAC-winbox, MAC-telnet, etc. are not accessible from this network.
Obviously, CAPsMAN will be using L2 transport, and you will have to use managed forwarding in this case. Don’t worry, hEX should be powerful enough for such load.
Use RoMON when you need access to individual CAPs.
Use certificates to authenticate CAPs to manager and vice versa in your CAPsMAN setup.
Setting up 802.1x is not that you can do quick and easy. At least not for only one device.
This does nearly the same. Schedule it to run every minutes. (or 5 minutes)
:if ([/interface get ether2 running] = true) do={
:local mac [/interface ethernet switch host get [find ports=ether2] mac-address]
:if ($mac != "20:DB:F2:1D:A0:0B") do={
:log info "ether2 is not running, shutting down"
/interface ethernet set ether2 disabled=yes
}
}
If port is down, do nothing.
If port is up, test against mac, and if its not correct, shut down the port.
This way, you do not have problem with power loss.
Thank you everybody for your answers.
I’ll try to implement some scripts, starting from Jotne proposals. I’m wondering what happens if someone plugs a switch between the wAP and hEX: will router see the MAC of the switch?
If there are any other ideas, fell free to share them here, any improvement is more than welcome.
I do see that mac address are handled differently on different devices.
hAP-Lite
/interface ethernet switch host print
hEX
/ip arp print
does not work, since it list mac pr interface group (bridge)
So I do see mac for Bridge1 covers port 2-5
And mac for ether1 outside
Also mac for each other VLAN is listed.
So I will have to look at that to see how it works.
PS if you add a switch between router and ap, you should see all mac listed, more than one if there more than one device.
So it that case we also test for number of mac, and set max one, and one the correct one.
You could then use the first solution I did post that take down the interface if some one turns off or remove the equipment.
If the wap is an Mikrotik Wifi wap, you can use nearly the same as above, but use /ip neighbor print information to see that correct neighbor still is present. MNDP (CDP).
the wAP is Mikrotik (wAP AC) and it will be managed by CAPsMAN together with other 2 wAP AC.
maybe this can help to implement some extra checks in the scripts (sorry, I’m really a noob regarding Mikrotik scripting).
Please take another look at the solution andriys proposed.
You really don’t want to disable network interfaces, because they will be disabled when you don’t expect it (e.g. power outage, update, whatever) and require manualy intervention.
Also, they are disabled after at most the chosen interval, so this is a delayed protection setup.
Isolate properly (don’t offer dhcp or ip on the network) and use CAPsMAN + certificates for the radios.
@Jotne, not sure what $mac != “20:DB:F2:1D:A0:0B” will evaluate to if there are more mac entries for the interface, and there is always the mac address of the local interface.
@Radu, the client MAC address will not appear on the physical link if CAPsMAN managed forwarding is used.
thanks Nescafe.
Idea is that I cannot isolate WiFi devices from LAN devices and vice-versa. But in the same time I need to protect some LAN devices from being accessible by an unauthorized device that might plug into LAN using the exposed Ethernet cable used by external wAP.
It seems to be quite a complex task to secure an external WiFi, I’ll try to find another location to install it, so Ethernet cable is not easy reachable.
It takes the MAC address of the unit found by MNDP (CDP), should only be one.
local if "ether2"
local mac "20:DB:F2:1D:A0:0B"
:if ([/interface get $if running] = true) do={
:local ifmac [/ip neighbor get [find interface~"^$if;"] mac-address]
:if ($ifmac != $mac) do={
:log info "$if is not running, shutting down"
/interface ethernet set $if disabled=yes
}
}
PS this is not tested, and may feil since it takes some time for the device to start to send neighbor packets.
To find mac of neighbor devices, type /ip neighbor print, or just one if: /ip neighbor print where interface~“ether2”
Consider ether3-5 trusted and ether2 untrusted. Remove ether2 from bridge. Do not add IP. Just connect WAP and use certificates.
Add managed CAPsMAN interfaces to trusted network. LAN devices on ether3-5 can communicate with wireless devices via bridge.
Port ether2 is secured (nothing else but WAP will work).
Consider ether3-5 trusted and ether2 untrusted. Remove ether2 from bridge. Do not add IP. Just connect WAP and use certificates.
Add managed CAPsMAN interfaces to trusted network. LAN devices on ether3-5 can communicate with wireless devices via bridge.
Port ether2 is secured (nothing else but WAP will work).
Will this work only if datapath in CAPsMAN is set as manager forwarding? I doubt it can work if it’s set as local forwarding - and in this case unfortunately I lose the speed 5GHz band might offer (but it’s not a dramatic loss vs security I get).
In my previous tests with current setup (hEX as router and CAPs Manager + 2 wAP AC as CAPs) I cannot get above 40-50Mbps download/upload speed no matter how I test and what band I use if manager forwarding is enabled.
If local forwarding is enabled, I can reach easily above 200Mbps download/upload if I use 5G band.
Based on my reading, manager forwarding is a CPU intensive task (am I right that wAP CPU is the bottleneck?). Is it true for all configurations, or is there any trick to be done to improve speed also for manager forwarding setup?
Sorry for all these stupid questions, I’m still learning.
Thanks,
Radu
I would rather expect the manager to be more CPU critical rather then individual CAPs…
Have you tried looking at /tool profile (on both your CAP and manager boxes) while doing your tests? Also how exactly did you test (i.e. what tools did you use- simple file transfer, iperf, btest, something else; also what protocols; etc)?
I did basic tests using speedtest app on Android phone on 5G WiFi, changing only from Local Forwarding to Manager Forwarding on Data Path between the 2 tests (nothing else):
For manager forwarding I have in average:
100Mbps on speedtest
wAP CPU usage @ 85% on cpu0 / 45% on wireless in /tool profile
hEX CPU usage @ 96% on one cpu and low usage on rest of CPUs in /tool profile
For local forwarding I have in average:
300Mbps speedtest
wAP CPU usage @ 50% on cpu0 / 30% on wireless in /tool profile
hEX CPU usage @ 20% on one cpu and low usage on rest of CPUs in /tool profile
I know they are not professional tests, but at least we see that maximum transfer speed is limited on Manager Forwarding by the CPU limitation - and the “guilty” one is the CPU of wAP AC, not the CPU of hEX.
not good, as all MAC addresses of WiFi clients connected to the wAP will be visible on this Ethernet interface.