Guys,

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?

Thanks for your support,
Kind regards,
Radu

I can think of a couple of scenarios:

1. 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.

2. Parse your logs and look for the AP-facing ethernet port going down. As soon as it goes down, disable it.

3. Consider 802.1X.

-Chris

I would do it this way:

1. 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.
2. 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.
3. Use RoMON when you need access to individual CAPs.
4. Use certificates to authenticate CAPs to manager and vice versa in your CAPsMAN setup.

2. Parse your logs and look for the AP-facing ethernet port going down. As soon as it goes down, disable it.

No need parse logs, just schedule this script to run every minute.
If interface goes down, shut it down completely.

But if power goes down, or you changes the device, you need to turn on port manually.

A follow up.

3. Consider 802.1X.

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 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.

Tested on hAP Lite

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.

Regards,
Radu

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.

not good, as all MAC addresses of WiFi clients connected to the wAP will be visible on this Ethernet interface.
Still searching for solution

Radu

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).

Radu

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.

cheers,
Radu

This may then work.

It takes the MAC address of the unit found by MNDP (CDP), should only be one.
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"

Will try and let you know
Thanks

Radu.

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.

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).

Radu

Yes, it will only work if CAPsMAN manager forwarding is used. Why do you think 5G speed will suffer?

Yes, it will only work if CAPsMAN manager forwarding is used. Why do you think 5G speed will suffer?

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)?

@andriys,

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.

Regards,
Radu

Well, we have a small CAPsMAN setup here in the office (12 access points 8 out of which are wAP ac). I did a small test and observed ~45% load on CPU of wAP ac at about 100Mbps transfer speed (one or two TCP streams, local file transfer; in our case the speed was limited by the client- we didn't have an ac-capable client at hand). So you probably have something in your configuration that eats another 40% of CPU. As to the manager, we are using CCR1009 here, so it is no surprise it was mostly idle all the time.

Hello again,

I think I've reached my technical limitations, as I don't understand some things, like...

1. I made some extra tests and configuration changes regarding Manager Forwarding and I reach the following conclusion: there is a single configuration of CAP and Manager certificates possible that prevents continuous disconnects of CAPs from Manager. If I do anything else regarding certificates, I have constant (more than once per minute) CAP disconnects from Manager.

I need to set Manager with "Certificate" and "CA Certificate" to AUTO and unselect "Require Peer Certificate".
I need to set CAPs with "Certificate" to REQUEST and select "Lock to CAPsMAN"

I think this is very strange, I cannot understand why CAPs keep disconnecting unless there are certificates involved into the management connection.
I don't know if having certificates setup this way influences the speed of WiFi transfer.

2. As I had local forwarding in the past, the wireless interface of CAP was added to wAP bridge. I removed all wireless interfaces from all bridges on all wAP (I still prefer to have IP connection so I kept ethernet in bridge, with IP assigned) and switched back to Manager forwarding.
Now I can get 200Mbps with Manager forwarding, instead of 100Mbps in the past, still not 300 as with local forwarding.
Could this (wireless interfaces part of bridge in wAP) influence speed in Manager forwarding?
What could still put overload on wAP processor to limit transfer to 200Mbps in Manager forwarding in the new setup vs local forwarding?


I attach here the partial config of hEX and one of the wAP (all are similar, just different IP, identity and MAC addresses) - what I think it's relevant for the problems described above - in case someone is willing to debug this further.

All the best,
Radu