I have an hAP AC2 that I want to use for a permanent encrypted tunnel to a box in datacentre that acts as gateway (as in routes all WAN traffic to it).
I already run an OpenVPN server, and initially each client was running an OpenVPN tunnel.
Unfortunately Mikrotik seems to ignore OpenVPN and only support insecure configuration (weak cyphers and no TLS auth).
The other alternative is IPSec. It is a very tedious thing to setup (especially when there is existing OpenVPN infrastructure), and very easy to block by the people in the middle. It also cannot be hidden as HTTPS traffic. In addition it is unreliable on networks that drop UDP packets.
Also this: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec
Ultimately OpenVPN from security, reliability and easy of use beats the IPSec, yet Mikrotik is completely ignoring it…
I also prefer the way OpenVPN presents itself as an interface, thus making routing easy.
While I am here I would like to hear opinion regarding two options:
OpenVPN client with weak cyphers and password auth
or
It also looks like IPSec on hAP AC2 only supports up to SHA256…
Does anyone know timeframe of when (if ever) Mikrotik will support TLS auth for OpenVPN?
Surely OpenVPN is the kind of product that most Mikrotik customers would use (enthusiasts and tiny ISPs)?
Mikrotik were adding new features to OpenVPN in the ROSv7 Beta - so its likely they are going to concentrate on it again - its possible some of the limitations were based on the older kernel and now they putting the newer kernel in they might be able to expand support.
As compared to what? To OpenVPN using UDP as transport? In general VPNs using TCP as transport have their own kind of problems on lossy networks, so I’d like to understand better what you actually have in mind.
I found Strongswan quite well documented, from zero knowledge to a working system (with Mikrotik on the other end of the link) in a few hours.
This is true for hardware-accelerated encryption. You can use sha512 as well but the CPU will have to deal with it (encryption and authentication must be done either both in hardware or both in software).
OpenVPN TCP under port 443, no firewall is normally dropping packets to that port or queues it for special DPI.
Cannot really have IPSec tunnel in a hostile environment without being noticed.
Having UDP traffic under port 500 and 4500 is screaming to the BOFH that runs the network - “hey look at this guy, he is running IPSec”.
Yes, but if OpenVPN was working properly on Mikrotiks, I would only need to spend 2 minutes to generate new certs. If it wasn’t for broadening my knowledge, the few hours for relearning IPSec setup would cost me more in time than the cost of the mikrotik device (many times over). Last time (decade ago) I setup IPSec I swore that I would not touch it ever again.
I am happy to sacrifice CPU and throughput for security. I run OpenVPN permanently on my android phone, surely if the CPU on a phone can handle this (while doing many other things), the ARM on something like hAP AC2 should be also able to handle modern cyphers?
I get your point, but I’m afraid it all depends on the actual hostility of the environment. First, I’ve seen firewalls doing MITM and then DPI on https (as they are made by renown vendors, their CA certificates are trusted so the browsers happily accept the forged site certificates signed by those). On one of them I’ve tried an IKE(v1) based Cisco VPN and it ruined it by manipulating its packets’ contents, hard to say whether intentionally or due to a bug. So I suspect that if such a firewall wouldn’t find http traffic as the TLS payload, it would not let it through anyway.
I originally supposed that you talked about unreliable networks rather than firewalls policing traffic from the internal network to the internet.
With both OpenVPN and IPsec, you can use a different port for UDP than 1194 and 4500 (and 500 if the client needs it) by means of NAT rules; the question is again just the degree of paranoia of the firewall admin.
That’s a matter of personal choice. If you don’t intend to use IPsec routinely, there is no point in learning it; if you do, addition of a new client into an already running environment is as easy as with OpenVPN. But as you mention the value of your time (nothing bad about that!), I assume you haven’t given RouterOS 7 beta a try? As people here report that the OpenVPN implementation there finally started supporting UDP transport, maybe there are other improvements too?
Well, my remark was at first place a technical one, correcting your statement that sha512 was not supported on hAP ac² at all. And regarding CPU usage, the CPUs in phones are usually several times more powerful than those in SOHO routers such as the hAP ac2, and deal with the VPN traffic of a single client; the router typically has to deal with VPN traffic of tens or hundreds of clients so hardware acceleration of encryption makes sense. Again, it is a matter of personal preference - if you don’t mind dedicating a router to each two or three clients, why couldn’t you run encryption in software.
Back when I was “all about open source”… I used OVPN all day.
When I moved to Mikrotik… I found a all but deserted protocol. I asked about OVPN being brought up to modern standards… And there was chatter about “next router OS release…”
That was ~10 years ago.
If you want to use OVPN… Don’t kid yourself and think “it’s just around the corner in Mikrotik.”
Get used to using IPSec or get something like the Pi OVPN solution going.
One detail I might have missed: I am planning to use mikrotiks as OpenVPN clients (so each device will handle a single connection).
Regarding V7 beta is there a feature list?
I am cautious with bricking, as I do not have immediate access to a windows box to do a recovery (last time I tried with wine it failed to netinstall).
The sad state of OpenVPN has nothing to do with kernel support. It is caused by the fact that MikroTik re-implemented OpenVPN in their router instead of just using the open source implementation, maybe because of licensing issues.
As this work apparently was done in a very unprofessional way, nobody inside MikroTik wants to touch it to add new features.
The current v7 beta again shows no signs of “just dropping in standard OpenVPN” so while there now have been some very wanted features (wanted by others!) that have been added, like UDP support, there will still be a long road ahead before it is reasonably compatible with standard OpenVPN.
And now that people are moving on from OpenVPN to Wireguard, this whole thing is likely to repeat all over again.
If the GPL is the issue here, I have a very simple solution:
Release the OpenVPN as a package not bundled in RouterOS. Provide a link on the website and be done with it.
Saying that Mikrotik has to deal with GPL already anyway (for their modified kernels and whatever else they hack), so having another thing that is bound to GPL licence should not be an issue. Unless of course Mikrotik is doing dirty and not conforming to the GPL…
I do not see any reason why not have a reference implementation of OpenVPN in RouterOS anyway. Pretty much all Linux distros have it in their repos. RouterOS is a linux distro, albeit esoteric one.
I believe I found a solution to my problem: a raspberry pi like device to provide OpenVPN with a static route from Mikrotik. This is not ideal, because now hAP AC going to be used as dumb access point/switch, which is a waste of two arm cores.
I’m not sure if it is only GPL, I have had another router which originally had OpenVPN but then dropped it. Maybe there are some other issues, I have not researched it.
My proposed solution is to add a feature to RouterOS where you can run a user process uploaded in a folder, running as a restricted user and chrooted to that folder, and then you could use that feature to run special services that MikroTik does not or cannot offer.
Like OpenVPN, Wireguard, a full-featured DNS server (local zones with all record types, DoH, DoT, filtering etc), a webserver, and more of those things that so may people have requested.
Maybe when someone from MikroTik comes to this thread, they could solve this mystery for us, why they decided to write own implementation, instead of using standard one. It’s been more than ten years since that happened, hasn’t the usual time after which secret archives are opened already passed?
And user processes, custom packeges, or whatever it would be, I wouldn’t say not to it. But it should be for exotic stuff, something needed by me and hundered people in the whole world, not for something as popular as OpenVPN.
SergeiF I got the same setup (raspberry Pi running OpenVPN client) but I cannot get the routing to work correctly. When I use the Pi as the gateway no issue, everything is working correctly (I setup IP forwarding and basic rules to enable sessions out and established sessions back in on the OpenVPN tunnel). However when I try to route the traffic from the Mikrotik device, it doesn’t work. Did you need to setup some source NATing or simply setup the static route? During holidays I will setup some Wireshark but I am hoping you help here. thank you
