Ideas for securely managing Mikrotik devices

Hi!

I am looking for suggestions and ideas how to best securely manage Mikrotik devices of several sites. Please also correct or complete my thoughts about this:

  • Mikrotik device is router at each site
  • all Mikrotik devices in each site behind router can be reached via Romon through the router
  • dedicated Mikrotik device or VM in our hosting center to be used as vpn server
  • all routers from the different sites should dial in to the vpn server
  • vpn dialin for technicians computer to the vpn server
  • technician can access all routers via winbox through the vpn

Considerations:

  • sites have their own vpn configurations (L2TP with IPSec) which should not be touched or affected
  • easy to configure configuration (3-5 cli commands?) so new devices can be easily set up
  • each device should have its own certificate or password
  • security security security!
  • nice to have: if you klick refresh on winbox it should show all devices
  • vpn server should only masquerade and route technicians device
  • all site routers should only be accessible through that vpn for the technician and routers should not be connected anywhere else through the vpn
  • possibility to isolate access from one router to another in the vpn?
  • monitoring through the vpn

what would be the best approach for this? If I start with L2TP/IPsec then it may collide with existing configuration and it is a little complex to set up.

Hmmmm nobody has any comments or suggestions?

Thoughts:

  1. for remote management of the Mikrotiks themselves, the throughput is not the key factor for choice of a VPN.
  2. you’ve stated there is L2TP/IPsec on the devices to be managed, but you haven’t stated whether these are L2TP servers or L2TP clients.

All the “ppp-like” VPNs are equally simple to configure, the IPsec configuration is a bit more complex for a beginner. So unless the connections between the CHR and the sites are lossy, I would recommend to use SSTP with certificate verification at both client and server.

However, there is no way to check the contents of the clients certificate at server side - whoever presents a valid certificate signed by a root CA the server knows is granted accesss (which makes sense as the public address of the client may change), and I am not sure whether the SSTP server checks the CRLs so that you could block clients by revoking their certificates. If it doesn’t, you would have to use one root CA per each client in order to be able to disable the client by removing the root CA certificate from the server’s certificate store.

Identification of a particular client by its particular certificate is currently only possible with IKEv2. Another reason to spend time on learning IPsec is that IKEv2 is currently the only VPN type where you can push routes to a Windows PC from the Mikrotik, this feature is not supported by RouterOS for “ppp-like” VPNs. This may be useful for the technicians, as they wouldn’t need to manually enter routes to the managed Mikrotiks in order not to lose internet connection while connected to the VPN server (or push all their internet traffic through that server, which is what you probably wouldn’t prefer).

As for the “refresh in Winbox”, I suspect this would require L2 transparency from the technician’s machine to all the routers so that their MNDP advertisements could reach the technicians’ machines, or at least an L3 point-to-point tunnel from the technician’s machine to each managed Mikrotik. The MNDP messages have a broadcast destination address so they are not routed between subnets and/or tunnels. So this won’t work with the Windows’ embedded VPN client even in SSTP mode. After all, it’s a neighbor (i.e. adjacent devices) discovery.

Isolation between clients etc. are tasks for the firewall on the “VPN server”, nothing really special; use of the VPN tunnels only for management is a matter of routing (or IPsec policy matching) and firewall on the managed Mikrotiks themselves.

yes, throughput is not needed

actually they are servers.

I am now trying to connect via SSTP. my problem is that it seems I can not bridge the SSTP connections from mikrotik devices to the L2TP/IPsec connection of technician.

from vpn server I can ping all connected devices but from one device to another it does not work. I created a bridge with proxy-arp enabled. in PPP Profile I did chooses that bridge. but that does not work. Any idea?

I do not need really that. it would be nice but technician can also look up ip number in vpn server.

Correct, you cannot bridge them, because the stock VPN client of Windows (or any other one I know) doesn’t support BCP, so bridging is not possible. So the L2TP, despite its name, only establishes an L3 tunnel, just like with any other type of VPN the stock client supports.

The idea of arp=proxy-arp is just that devices in some IP subnet in an L2 segment, which normally send packets directly to each other, could send packets to addresses which fit into that subnet but are actually not connected to the same L2 segment, but this is not the same thing as L2 transparency. So it only makes sense to use arp=proxy-arp when you assign addresses from a LAN subnet to individual L3 clients - it makes the router respond the arp requests coming from the hosts in the L2 segment on behalf of these L3 clients, so the L2 hosts send the packets for these clients to the MAC address of router which forwards them to the real destination.

Also, as you said you wanted to prevent the clients from talking to each other, I don’t think it is a good idea to use L2 tunnels to them. Isolation at L2 requires /interface bridge filter rules in this case, because the tunnels are added to the bridge automatically (due to configuring the bridge name in the /ppp profile row) and you cannot control properties like bridge horizon. And the bridge filter rules would be a nightmare - with bridge horizon, you’d just set one horizon value to all technicians’ PCs, and another one to all the managed devices, but with bridge filter rules, you’d need a full matrix, and with dynamically generated interface names, you’d need a script to dynamically generate them.

But if you insist, you can extend the “management bridge” even to the technicians’ PCs if you install OpenVPN clients on the PCs and configure OpenVPN for bridging (TAP) mode. Another possibility is to run CHRs in Hyper-V on technicians’ PCs, but you wanted it simple, didn’t you? And L2 transparency is not necessary for any other purpose than the WinBox neighbor discovery.

Actually, with L2TP and Windows, Bridging works fine on Windows. People dial in with L2TP/Ipsec, get an IP Number from the same IP range as the internal network and with proxy-arp it works fine to access all. Or do you mean that it wont work to access other VPN connections like this?

And yes I am aware that the devices will see each other. I think this is not preventable if I want a simple solution.

What you describe is not bridging. The tunnel between the Windows PC and the router is an L3 one, only IP packets without the Ethernet header (MAC addresses, ethertype) travel through that tunnel. So no ARP can get through, and packets with dst-address=255.255.255.255 originating in other subnets are not routed to the tunnel. So the neighbor discovery works between the ends of the tunnel, but not beyond them. With true bridging, you would see all Mikrotik devices connected to the router’s LAN in Winbox connected via the tunnel.


Do you have any other reason to bridge all the managed Mikrotiks together than to allow the neighbor discovery to work? If not, you can use L3 tunnels too, and IP firewall which is stateful and much more flexible with its dynamically populated interface lists and address lists. So by using two different interface lists, “mikrotiks” and “technicians”, you can set rules allowing technicians to initiate connections to mikrotiks but not to other technicians, and not allowing mikrotiks to initiate connections anywhere.

Ok, I was not clear with my previous answers. I know that seeing all Mikrotik devices in neighbour discovery wont work in most cases. This is ok, it was just an idea (nice to have) but not a must.

I just want to be able to dial in via VPN to the VPN Server and then in winbox type in the internal IP number of other Mikrotik device to access it.

So what I need is just a simple secured connection between several Mikrotik devices to the mikrotik vpn server, where I can access them via their IP number from my vpn connection to the vpn server.

BTW: I have other configurations, which need proxy-arp in order to work as Windows clients are dialing in via L2TP/IPSec and get an IP address from the internal network. It works only with proxy-arp set.