Use Mikrotik's HotSpot solution to unblock Wireguard???

There are some GPO hacks using scripting that might be used as a basline but I’d never use them as a replacement for SD-WAN. You still have to support end users or the branch office with manual administration when things go south.

If you prefer not to depend on a third-party web server provider for administration, most SD-WAN solutions offer on-premise installation of the network controller. I’m not sure about TailScale, but HeadScale and ZeroTier support running your own controller. Some SD-WAN solutions are also able to manage a mixture of IPsec, WireGuard and other both encrypted and unprotected tunnel types.

Thank you for your tips on alternatives to my idea. So far I have already implemented the solution for my 150 remote laptops using Bintec-IPSEC.
At Bintec there was a “collective IPSEC endpoint” in the RXL 12500 central router. This created a temporary IPSEC endpoint for each remote laptop dialed in and also deleted it again when the remote laptop went offline. Each laptop had the same IPSEC client configuration, authenticated when dialing in using RADIUS and Active Directory. In addition, a daily changing password had to be entered in order to make the IPSEC configuration usable as a file in the laptop when the laptop was started up.
There were never any problems with it, there were one-off costs of around €90 per client - the purchase of the Bintec IPSEC client.
We have to move away from Bintec (technology too old, no current products and Bintec has gone bankrupt). We already use Mikrotik as the branch and central router, Wireguard works great between the branches, so my plan was to also use the remote laptops through it.

Whether Wireguard + Hotspot will work - and above all be SAFE, remains to be seen once it is running.

If this doesn’t work, my second choice is to map the Bintec IPSEC tunnel endpoint in Mikrotik, since I’ve already bought all the IPSEC clients over the years anyway. It remains to be seen whether such a collection endpoint with Active Directory authentication via RADIUS is feasible there. I’m currently putting my energy into the Wireguard+HotSpot idea. It seems modern, high-performance to me and I’m hoping to use scripting to automate the 150 endpoints with their different Wireguard keys. For example, the remote laptop is connected locally to the company network, a script reads the client’s public key and automatically creates an endpoint in the Mikrotik. Or something like that…

However, if none of this works, an SD-WAN variant would be the next choice. This is also associated with not inconsiderable monthly costs :wink:

auf Deutsch:
ich danke euch für eure Tipps zu Alternativen zu meiner Idee. Bisher habe ich ja bereits die Lösung für meine 150 Remote-Laptops mittels Bintec-IPSEC umgesetzt.
Bei Bintec gab es im Zentralrouter RXL 12500 einen “Sammel-IPSEC-Endpunkt”. Dieser hat je eingewählten Remote-Laptop einen temporären IPSEC-Endpunkt erzeugt und auch wieder gelöscht, wenn der Remote-Laptop offline ging. Jeder Laptop hatte die gleiche IPSEC-Client-Konfiguration, authentifiziert wurde bei der Einwahl mittels RADIUS und Active Directory. Zusätzlich Musste noch ein sich täglich änderndes Passwort eingegeben werden, um die IPSEC-Konfiguration beim Hochfahren des Laptops erstmal als Datei in den Laptop nutzbar zu bekommen.
Es gab nie Probleme damit, je Client entstanden Einmalkosten von ca 90€ - der Kauf des Bintec IPSEC Client.
Wir müssen von Bintec weg (Technik zu alt, keine aktuellen Produkte und Bintec Konkurs gegangen). Als Filial- und Zentralrouter setzen wir bereits Mikrotik ein, Wireguard klappt prima zwischen den Filialen, daher war mein Plan, auch die Remote-Laptops darüber zu nutzen.

Ob Wireguard + Hotspot zum laufen kommt - und vor Allem SICHER ist, bleibt abzuwarten, wenn es denn erstmal läuft.

Wenn dies nicht funktioniert, ist meine zweite Wahl, in Mikrotik den IPSEC-Tunnel-Endpunkt der Bintec abzubilden, da ich eh bereits die IPSEC-Clients alle über die Jahre gekauft habe. Ob dort so ein Sammel-Endpunkt mit Active-Directory Authentifizierung über RADIUS machbar ist, bleibt abzuwarten. Derzeit stecke ich erstmal meine Energie in die Wireguard+HotSpot-Idee, die erscheint mir modern, performant und ich habe Hoffnung, mittels Scripting, die 150 Endpunkte mit ihren unterschiedlichen Wireguard-Schlüsseln zu automatisieren. z.B. der Remote-Laptop ist im Firmennetz lokal angeschlossen, ein Script liest den Public-Key des Clients aus und legt automatisiert einen Endpunkt in der Mikrotik an. Oder so ähnlich…

Wenn jedoch auch das alles nicht funktioniert, wäre dann eine SD-WAN-Variante die nächste Wahl. Diese ist ja auch mit nicht unerheblichen monatlichen Kosten verbunden :wink:

There are some highly important factors I think you should consider before making any decisions:

Encryption and throughput bottlenecks:

  • WireGuard encryption (ChaCha20) is software-based and lacks hardware acceleration support (on any platform) unlike IPsec. Consequently, the total throughput is constrained by the CPU power of the router which is usually sufficient for only a limited number of simultaneous connections.
  • Mikrotik is primarily a router, not a dedicated VPN endpoint concentrator like the RXL12500. Thus, the Mikrotik router most likely won’t handle throughput very well for 150 concurrent WireGuard sessions. You will need a sufficiently powerful dedicated server running solely WireGuard for this purpose.

Script compatibility and maintenance dependencies:

  • Mikrotik doesn’t prioritize script compatibility. If your production environment heavily depends on scripting it may break unexpectedly.
  • Do yourself a big favor, don’t put yourself or your organization in danger by developing your own solution that relies on potentially unreliable ROS scripting. If you create your own solution, everything depends on you which means you are a personal single point of failure! This means that if you are the only person responsible for creating and maintaining a solution, then if something goes wrong, you are the only one who can fix it. This might be a big problem if you are not available or if you do not have the necessary skills to fix the problem.
  • You’ll have to develop your own AD integration from scratch.

Cost-effective VPN solutions:

  • As you seem to be aware of, WireGuard is just a tunnel protocol, not a complete VPN solution like the one you are using from Bintec.
  • Tailscale and ZeroTier are cost-effective SD-WAN options, and Teldat also offers its own SD-WAN solutions. Additionally, there are many others on the market – including open-source solutions like ZeroTier and Tailscale (which offer maintenance contracts for 24/7 support) as well as purely commercial solutions.

Generally worth considering:

  • Always perform a TCO calculation: consider price, performance, time to market, operational and maintenance costs and hard dependencies.
  • Always perform a POC using realistic performance and quality tests before deploying anything into production.

Bottom line and final recommendations:

  • Hire an independent network specialist for a few hours to brainstorm solutions and potential issues. Consider the cost as an investment for the future and a receipt for your plans.
  • For a preliminary evaluation of SD-WAN to get a feel for how it works you might perform a small-scale test using a standard PC as an SD-WAN server and a few participants like yourself. This won’t interfere with the existing router or internal network if you masquerade the SD-WAN ingress traffic. I’d suggest starting testing both ZeroTier and Tailscale which can be installed simultaneously on both the SD-WAN server and the client PCs.
  • Implement SD-WAN or your VPN of choice on a dedicated server (aka VPN concentrator) and let Mikrotik act as a pure router. You will need a dedicated VPN concentrator to handle 150 concurrent VPN sessions in any case.

Good luck!

Very well stated. If we’re covering risks… I’d add that nothing stops Mikrotik from changing how /ip/hotspot works internally – it very well may not relay on specific firewall extensions in future.

But I get the problem here. There is some “missing middle-ground” between Tailscale & simple some way to deal with peers/key using some credentialing scheme like RADIUS. Nothing against Tailscale, but does bring philosophy and add’l complexity with it. …when WG peer management is all that’s needed.

To me, this just seem like a natural extension to Back-To-Home. e.g. “Back-To-Work”. Given all the under-pinning for WG peers is already in Mikrotik desktop/smartphone apps today … the subtle details of using RADIUS instead of /user in the process isn’t all that different from the “Sharing” feature in BTH. They could even skip/disable the proxy service part of BTH to limit scope since an organization likely has a public IP (or should, if being a VPN concentrator for “Back-To-Work”).

Also…I’d never seen “headscale” mentioned above before: https://github.com/juanfont/headscale. That seems worth a look — worse case with headscale if it didn’t work, is you change DNS to the “real” Tailscale and have to pay them.

Thank you very much for your comments, they really help me a lot.
Unfortunately, I didn’t get any further with my variant and the tips here, which ultimately result in my own firewall rules and the transfer of data traffic from the Wireguard network to the HotSpot network with transfer to the pre-HotSpot chain. The construct seems to have no future.
I could see from numerous logging that the netmap is taking effect, that the transfer to the pre-hotspot chain (presumably the entry point into the HotSpot application) works, but the normal Mikrotik WebIf is still displayed on the client.

Now I’ve already tried to connect the NCP Secure client to an IPSEC Road Warrior client (IKEv1). I see incoming logging entries, but that doesn’t work yet either. But I probably have to open a new topic here for this. The topic of Wireguard and HotSpot is not yet completely off the table, but you are right, it should work reliably in the end.


Deutsch:
Vielen Dank für eure Ausführungen, die helfen mir wirklich sehr.
Mit meiner Variante und den Tipps hier, die schlussendlich in eigene Firewall-Regeln und der Übertragung des Datenverkehrs vom Wireguard-Netz ins HotSpot-Netz mit Übertragung in die pre-HotSpot-Chain enden, bin ich leider auch nicht weiter gekommen. Das Konstrukt scheint keine Zukunft zu haben.
Ich konnte in zahlreichem Logging erkennen, das das netmap greift, das das Übertragen in die pre-hotspot-Chain (vermutlich der Einstiegspunkt in die HotSpot-Anwendung) funktioniert, aber dennoch das normale Mikrotik-WebIf am Client angezeigt wird.

Jetzt habe ich schonmal versucht den NCP-Secure-Client auf einen IPSEC-Road-Warrior-Client (IKEv1) zu connecten, ich sehe zwar eingehende Logging-Einträge, aber das klappt aktuell auch noch nicht. Aber hierzu muss ich vermutlich ein neues Thema hier eröffnen. Das Thema Wireguard und HotSpot ist noch nicht final vom Tisch, aber ihr habt schon recht, es sollte am Ende zuverlässig funktionieren.

I guess both were true:

... in 7.22beta1, it seems this "hotspot-over-wireguard" was added:

Now I have not tested it yet, but still think it's a worthwhile concept.

I did a quick test and see login coming up if navigated, and see a user session. Now it did not fully work in https, but that may be related to testing 7.22 reverse-proxy.

Also, importantly, with WG you cannot use DHCP option to flag the captive portal. I did not fully configure it and the SSL/https is tricky business to get right. So how to force pages to login is something IDK yet... RN, I think, you're waiting to hit an http:// URL otherwise (AFAIK - not a hotspot expert & did not mess with it much)

But I added a new WG interface, allowed via firewall filter, and created a peer like this which used 10.5.50.101 on "WG client" which is within the range used by /ip/hotspot/setup with default and using wg1 as interface in hotspot, having done a /certificate/enable-ssl-certificate beforehand.

This was the WG peer I used — which may not be 100% right — used on an iPhone with WG client, and via LTE (so not on same LAN as test).

And, I suppose you could do this on BackToHome WG peers too, and set /ip/hotspot to use BTH's 192.168.216.0/24 subnet, and turn BTH into WG-as-a-service. Or, more practically, for testing this hotspot-over-wireguard feature, since BTH at least deal with peer configuration and "sharing" configs

It also works perfectly with https and user manager.

/ip hotspot/host/print 
Flags: D - DYNAMIC; A - AUTHORIZED
Columns: MAC-ADDRESS, ADDRESS, TO-ADDRESS, SERVER
#    MAC-ADDRESS        ADDRESS    TO-ADDRESS  SERVER  
0 DA 00:00:00:00:00:00  10.5.50.5  10.5.50.5   hotspot1
/ip hotspot/cookie/print 
Flags: M - MAC-COOKIE
Columns: USER, MAC-ADDRESS, EXPIRES-IN
#   USER              MAC-ADDRESS        EXPIRES-IN   
0 M web@fxxxxxxo.it  00:00:00:00:00:00  4w1d23h59m44s
/user-manager/session/print 
Flags: A - active 
 0   user=web@fxxxxxxo.it acct-session-id="80500001" nas-port-type=wireless-802.11 nas-port-id="wg8-hotspot" nas-ip-address=127.0.0.1 calling-station-id="00:00:00:00:00:00" 
     user-address=10.5.50.5 status=start,stop,interim,close-acked,expired started=2026-01-08 10:52:18 ended=2026-01-08 10:58:33 terminate-cause=lost-service uptime=6m15s download=15.2MiB 
     upload=967.3KiB last-accounting-packet=2026-01-08 10:58:33 

 1 A user=web@fxxxxxxo.it acct-session-id="80500002" nas-port-type=wireless-802.11 nas-port-id="wg8-hotspot" nas-ip-address=127.0.0.1 calling-station-id="00:00:00:00:00:00" 
     user-address=10.5.50.5 status=start started=2026-01-08 10:59:40 uptime=0s download=0 upload=0 last-accounting-packet=2026-01-08 10:59:40