I just set up a wireguard tunnel and it is straightforward.
I usually use gre/ipsec for site to site vpn with both static public IP and l2tp/ipsec clients for routerboards having dynamic address.
I'm considering to move all those tunnels in wireguard mode, what about ? pros, cons, etc ?
Thank you
If you control the whole ecosystem end to end that’s fine but if you are dealing with cloud at some point that will be an issue this is mostly YMMV
WireGuard works really well on RouterOS and is much simpler to manage compared to IPsec, especially once it’s set up.
Pros:
- Very easy configuration and cleaner setup
- Lower CPU usage and better throughput in most cases
- Fast reconnection and stable tunnels
- Works well for site-to-site and road-warrior setups
Cons / things to keep in mind:
- No built-in dynamic peer discovery like IPsec + L2TP
- Endpoint IP changes need scripts or keepalive tuning
- If you integrate with some cloud providers, IPsec is still more widely supported
If you control both ends of the tunnel, migrating makes sense. For dynamic or third-party environments, IPsec may still be the safer choice. Many people run both depending on the use case.
1 Like
I would add some (quite rare) issues dealing with WireGuard on RouterOS (I’ve been using WireGuard with RouterOS since 7.14) that you should be aware of :
→ RouterOS does not support well changes in existing peers sometimes, like the “endpoint-address”, “endpoint-port”, or DNS record change (could be an important factor if you use DynDNS setup for your dynamic addresses. In this case, prefer the dynamic side initiating the connection towards the static one). For the DNS issue, a simple “dns flush” will not resolve the issue, you will need to reboot or remove/recreate the peer
→ Some WireGuard implementations does not have the same default configuration dealing with MTU. For example, if you create a WireGuard tunnel between a RouterOS device and a pfSense, default pfSense MTU is 1500. I don’t have any other example in mind.
→ As @anon47717385 mentionned, WireGuard does not implement any “site-to-site/server-client scheme”. So your configurations will be very similar between these two modes, which is very flexible, you simply mount a tunnel that permits IP packets to go through
→ Unlike client-side implementations of WireGuard, AllowedIPs does not create dynamic routes, you will have to create your routes yourself.
→ Consider adding a PersistentKeepalive value (I usually set “25”), which sends a packet through the tunnel each X seconds to reload the UDP state stables of firewalls / routers that forward the tunnel. Also, as far I remember, (in 7.14 at least, IDK for now), if you did not set a PersistentKeepalive, the router would not initiate the connection. I didn’t try with newer versions, maybe this is resolved
→ If you plan to use IPv6 LL addresses in your tunnels, avoid version from 7.15.X to 7.16.X. I’ve sent a support ticket that was resolved in 7.17 where WireGuard IPv6 LL addresses would disappear until a reboot when the tunnel interface was put in a VRF.
That's only because that UI part of pfSense is dumb (probably reused for all kind of interfaces). In their docs they have instruction to lower the MTU to the appropriate value:
1 Like
Thanks,
I would mostly use Wireguard for RB to RB tunnel, and like my actual L2TP VPNs, is the dynamic client initiating the connection to the static server.
The only concer now is the RB have to run V7 ROS and many of them are actually old and cheap V6 ones (rb450, rb433, rb750, rb951, mAp lite, hAp lite etc.) , despite they are used just to setup tunnel, I don't know if V7 would be too heavy to be managed...
From personal experience, RB750 (as in Hex) and mAP Lite (also mAP) can run ROS7 just fine including Wireguard.
Wireguard was the main reason I upgraded those devices to ROS7.
1 Like
ROS7 will not run with only 32MB of RAM.
Do you have issue with upgrade on the 64MB RAM 16MB Flash devices? Where can the update .npk file be stored on such device?
That's interesting, because this
Software Specifications - RouterOS - MikroTik Documentation
says:
It is also not compatible with MikroTik devices that have 32MB of RAM or less
Can you upgrade to 7.20.6?
Note: We do not recommend running v7 on hardware that does not have at least 64 MB of RAM.
I can't recommend either. Had v7 on my hap lite some years ago. It was painfully slow and rebooted every few days. It was only configured with quickset CPE template. It was a big trouble. Since I downgraded to v6 again, this little hap lite is running rock solid again. Plenty of uptime and not a single issue.
1 Like
I see that the .npk file is only 7MB and small enough for the free storage space, unlike the ones for other architectures. But then MikroTik is wrong in the documentation. Or maybe they write that so that they'll be able to break compatibility anytime in future versions when they add more bloat.
As long as you stay with normal wireless drivers (where applicable) I haven't seen any issue upgrading on those devices. Zero.
For those devices able to use wifiwave2 drivers and only having 16Mb of storage (AC2, cap AC, cap XL AC, wap AC) , that's something else.
There have been a couple where I had to revert to netinstall but certainly not all.
1 Like
I can confirm that 7.x (I seem to remember I tried 7.14.3) does work on hap Lite, but I can also confirm that compared to to 6.49.19 it "feels" more sluggish, at least in Winbox/terminal interaction.
It was just an experiment, so I cannot confirm the unstable behaviour infabo reported, and - for the particular use I had for that device (plain link in station-pseudobridge mode to get a slow internet connection for updates/upgrades to a couple of devices that are normally operating "air-gapped", so only briefly switched on when doing maintenance) both v6 and v7 worked just fine.
I reverted to v6 only because I have other hap Lites on that same release, to keep all on the same version that would IMHO be more convenient if a swap would be needed.
For the SMIPS devices, the RAM size is indeed the issue. For me, an SSH session was breaking BFD on a hAP lite (TC to be precise), the same configuration on Powerbox (exactly the same QCA9533 CPU but 64 MB RAM) runs flawlessly.