Hello, in my scenario I would like to connect 150 home office laptops to our company network via Mikrotik via Wireguard.
I hope for your support in this regard.
Current scenario: these 150 laptops are connected to our company network using IPSEC via a Bintec router. RADIUS is implemented in IPSEC for our Active Directory.
Now Wireguard does not provide for RADIUS as a pure connection protocol - because there is no user authentication. The problem here is that I can secure the computer, but I don't know who is sitting in front of it and I can't prevent someone from copying the Wireguard tunnel to a USB stick and using it elsewhere.

Therefore I MUST know who is sitting in front of the computer. Now Mikrotik itself has great solutions in the router. My idea here is similar to that in IPSEC - the laptop connects to the company's Mikrotik via Wireguard and only accesses the integrated HotSpot portal. There the user has to authenticate himself (HotSpot with RADIUS to the Active Directory) and then the company access is opened.
Based on the “Last Handshake” entry in the Wireguard peer, the HotSpot access is closed again after time XXX.

Now I've built a test setup for this, but I'm not getting anywhere. I see that I can connect the HotSpot to an Ethernet interface but not to a Wireguard interface. HotSpot appears to be tied to a physical interface, while Wireguard is a virtual interface - more of a routing endpoint.

Now I could try to solve the whole thing by routing via 2 Mikrotik devices
- Mikrotik 1: external: the Internet access with Wireguard connection (Wireguard IP of the Mikrotik 192.168.30.1/24 - The remote laptops in the range 192.168.30.2-192.168.30.254)
internal: forwarding to Mikrotik 2 (e.g. IP: 192.168.25.1/24)
- Mikrotik 2: external: the connection of Mikrotik 1 with HotSpot on this connection (e.g. IP: 192.168.25.2/24)
internal: forwarding to the company network (IPs 172.16.0.0/12).

However, ideally I would have depicted the whole thing within ONE microtic.
I had already tried: Wireguard endpoint in an interface list. The interface list into a bridge. The bridge as an interface in the HotSpot. Unfortunately, this doesn't work.

I need support here. How do I get the Wireguard interface 192.168.30.1/24 placed on the Mikrotik internal hotspot?
The home office laptops may only be able to see the HotSpot page; IP addresses in the company network can only be accessed after authorization.

(english ist translate with google-translator) - in German:
HotSpot-Lösung von Mikrotik zur Freigabe Wireguard verwenden???

Hallo, ich möchte gern in meinem Szenario 150 Home-Office-Laptops über die Mikrotik per Wireguard an unser Firmennetzwerk anbinden.
Hierzu hoffe ich auf eure Unterstützung.
Aktuelles Szenario: diese 150 Laptops sind mittels IPSEC über einen Bintec-Router an unser Firmennetzwerk angeschlossen. Im IPSEC ist ja RADIUS zu unserem Active Directory implementiert.
Nun sieht ja Wireguard als reines Verbindungsprotokoll kein RADIUS vor - weil keine Benutzer-Authentifizierung. Problem hierbei - ich kann zwar den Rechner absichern, aber ich weiß nicht wer davor sitzt und ich kann auch nicht verhindern, das jemand den Wireguard-Tunnel auf einen USB-Stick kopiert und anderswo weiter verwendet.

Daher MUSS ich wissen, wer vor dem Rechner sitzt. Nun hat ja Mikrotik selbst tolle Lösungen im Router. Meine Idee hierbei ist nun ähnlich der im IPSEC - der Laptop verbindet sich über Wireguard mit der FirmenMikrotik und kommt dort jedoch ausschließlich nur an das integrierte HotSpot-Portal. Dort muss sich der Benuter authentifizieren (HotSpot mit RADIUS zum Active Directory) und anschließend wird der Firmenzugang geöffnet.
Anhand des Eintrages "Last Handshake" im Wireguard-Peer wird nach Zeit XXX der HotSpot-Zugang wieder geschlossen.

Jetzt hab ich mir hierzu eine Teststellung gebaut, aber komme nicht weiter. Ich sehe, das ich den HotSpot an eine Ethernet-Schnittstelle koppeln kann aber nicht an eine Wireguard-Schnittstelle. HotSpot ist anscheinend an eine physische Schnittstelle gebunden, während Wireguard eine virtuelle Schnittstelle - eher ein Routing-Endpunkt - ist.

Jetzt könnte ich versuchen, das Ganze mittels Routing über 2 Mikrotik-Geräte zu lösen
- Mikrotik 1: extern: der Internet-Zugang mit Wireguard-Anbindung (Wireguard-IP der Mikrotik 192.168.30.1/24 - Die Remote-Laptops im Bereich 192.168.30.2-192.168.30.254)
intern: Weiterleitung zur Mikrotik 2 (Bsp IP: 192.168.25.1/24)
- Mikrotik 2: extern: der Anschluss der Mikrotik 1 mit HotSpot auf diesem Anschluss (Bsp IP: 192.168.25.2/24)
intern: Weiterleitung zum Firmennetzwerk (IPs 172.16.0.0/12).

Dies ganze hätte ich jedoch idealerweise gleich innerhalb EINER Mikrotik abgebildet.
Versucht hatte ich bereits: Wireguard-Endpunkt in eine Interface-List. Die Interface-List in eine Bridge. Die Bridge als Interface im HotSpot. Leider klappt dies jedoch nicht.

Hier benötige ich Unterstützung. Wie bekomme ich die Wireguard-Schnittstelle 192.168.30.1/24 auf den Mikrotik-internen HotSpot gelegt?
Die Home-Office-Laptops dürfen ausschließlich die HotSpot-Seite sehen können, erst nach Authorisierung können IP-Adressen im Firmennetzwerk angesprochen werden.

Never noticed that, anything L3 interfacish doesnt show up on interface list ( wg, ipip,gre etc...). Which limits your options...... perhaps two routers is the only way.

It be nice if there was an "enterprise" version of their Back-To-Home (BTH) features using to RADIUS/etc. BTH deal with turning user/passwd credentials into a WG peer on router, which kinda your underlying problem in trying to move from IPSec+RADIUS. Issue is Mikrotik's BTH apps all require an admin (or similar) account on router to enable the peer configuration from those credentials. BTH does have a "share" feature to add more peers without creds, but for 100+ users that likely wouldn't work well at that scale.

Perhaps there is some path to making hotspot work with WG – it's very cleaver. But I don't take it as a good sign that /ip/hotspot does not let you listen on the WG directly. As @anav points out, while hotspot servers are L3, the hotspot setup is done on some L2 interface (for some reason presumablely).

Only thing I can think of trying is using action=netmap the WG subnet to/from the Hotspot subnet. Netmap allows subnet/ranges (many-to-many), so here perhaps two netmap NAT rules: 192.168.30.0/24 <=> 192.168.25.0/24. Now may want to use address-list etc to avoid including the router IP. But I'm guessing, more trying give ideas... I'm not sure netmap solve it – but you need to get WG IP through the hotspot firewall rules somehow...

Hi Amm0,
this is exactly my problem. How do I get the Wireguard interface into the hotspot?
I'll test it with the action=netmap - maybe something will work with it. I can “misuse” a physical port for this

Methinks its not possible.

Two MT routers maybe......

Whether possible, I dunno actually. With experimentation, maybe. We know this:
/ip/hotspot has a "Setup" wizard, but in the lists to setup wireguard interface are not selectable.
So it needs to on a physical or VLAN port to even have a chance of work – hotspot creates a bunch of dynamic firewall rules that uses what was select in "setup" & need those for it to work.

How do I get the Wireguard interface into the hotspot?
I'll test it with the action=netmap - maybe something will work with it. I can “misuse” a physical port for this

That's the concept. Maybe our WG experts know for sure. My "netmap" idea is based on that you cannot use "Hotspot LAN" IP addresses directly for WG peer (unlike something like L2TP).
So core of netmap idea is map the entire WG subnet to the Hotspot LAN subnet. And place 2 action=netmap rules to capture it both ways, BEFORE any of the dynamic firewall rules. Since hotspot uses chains, you're looking for to be before the "jump" in regular chains (since that they only way the dynamic hotspot rules get invoked).

But @anav will till you I'm a theory guy. And "netmap" is only idea I got here. No promises it work. But for sure want to test hotspot works generally BEFORE trying it with WG and netmap.

Or maybe actually, a 2nd idea is to use a "action=jump" in firewall, based on WG's subnet, to the hotspot chain. You'd have also configure hotspot somehow to know about the WG IP in its configuration (and again not hotspot expert either). But idea here be to get WG to go through those dynamic hotspot chains, using same method it uses: action=jump.

Thank you very much for your ideas, I will test and give feedback. I'm excited myself .

Joining the collective brainstorming:

I tried adding the same subnet to both a Wireguard interface and a loopback bridge but to no avail. If all of this setup doesn't go anywhere, I'd recommend setting up port knocking for access to the company network and thus adding the wanted layer of security

Damit du nicht Google Translate benutzen musst

Ich habe versucht, dasselbe Teilnetz Wireguard und eine Loopback-Bridge zuzuordnen, umsonst. Wenn das Ganze nicht funktionieren wird, würde ich dir vorschlagen, dass du "port knocking" für Zugang zum Firmennetzwerk einstellst und dadurch die gewünschte Sicherheitsschicht einführst

Damit du nicht Google Translate benutzen musst

Port knocking - an interesting method - I'm always happy to learn something about it here.
Unfortunately, I still don't know WHO is sitting in front of the computer. Among other things, I have to prevent an employee who has left the company from entering our company network.

Auf Deutsch :
port knocking - eine interessante Methode - ich freu mich, hier immer wieder was dazu zu lernen.
Leider weiß ich dadurch aber immer noch nicht, WER vor dem Rechner sitzt. Ich muss ja auch u.a. erreichen, einen ausgeschiedenen Mitarbeiter daran zu hindern, unser Firmennetzwerk zu betreten.

There is a possibility to setup port knocking and know which user is sitting behind the computer - you can use different port combinations for the port knocking and use the src-address selector in the firewall rules so that the port knocking sequence only applies to the exact user. When you don't want the user to be able to access the company network, you just disable the rules for his port knocking sequence und delete the peer. Example configuration:

Auf Deutsch:

Es gibt eine Möglichkeit, dass du Port Knocking einstellst und weiß genau welcher Benutzer hinter dem Rechner steht: Du kannst verschiedene Port-Kombinationen nutzen sowie den src-address-Selektor in den Firewall-Regeln, damit die Port-Knocking-Sequenz nur für den gewünschten Benutzer gilt. Wenn der Benutzer kein Zugang zum Firmennetzweek haben sollte, deaktivierst du die zu der Port-Knocking-Sequenz gehörigen Regeln und löschst den Peer. Beispielhafte Komfiguration:
Note: The last three rules can be copied and altered for a different user
---
Notiz: Die letzten drei Regeln kann kopiert und nach einem anderen Benutzer geändert werden

Yikes, cant imagine doing that for 150 users........

Hello, I was now able to carry out the first tests. Unfortunately the hotspot doesn't work. My configuration:
Wireguard-Network: Mikrotik 192.168.30.1/24
Remote-Laptop: IP 192.168.30.88/32 - DNS in Wireguard 192.168.30.1
Wireguard works, the laptop is connected to the Internet via an LTE router, the Mikrotik via a DSL modem. I get a connection and can, for example: call up the Mikrotik's WebIF.

HotSpot-Network: Mikrotik 192.168.31.1/24
the hotspot itself works. I connected for pre-Tests my remote-laptop via ether2, obtained a 192.168.31.254 via DHCP and was able to authenticate myself at the HotSpot using DNS-Name zugang.local.
/ip hotspot profile
set [ find default=yes ] login-by=http-chap
add dns-name=zugang.local hotspot-address=192.168.31.1 html-directory=flash/hotspot http-cookie-lifetime=2h login-by=cookie,http-chap,https name=HotSpot
/ip hotspot
add address-pool=HotSpot-Pool addresses-per-mac=unlimited disabled=no interface=HotSpot-Bridge name=HotSpot profile=HotSpot
/ip hotspot user profile
set [ find default=yes ] add-mac-cookie=no on-login="/ip hotspot host remove [find where address=\"\$address\" and !authorized and !bypassed] "
/ip hotspot ip-binding
add address=192.168.31.0/24
add address=0.0.0.0/0 type=blocked
/ip hotspot user
add name=admin
/ip hotspot walled-garden
add comment="place hotspot rules here" disabled=yes server=HotSpot
/ip hotspot walled-garden ip
add action=accept comment=Zugang_HotSpot-Portal disabled=no !dst-address dst-address-list=HotSpot_Whitelist !dst-port !protocol !src-address !src-address-list

now I connect the two technologies using:
add action=netmap chain=srcnat comment=HotSpot_zu_ZuHauseLP log=yes log-prefix=netmap_HotSpot_zu_ZuHauseLP src-address=192.168.31.0/24 to-addresses=192.168.30.0/24
add action=netmap chain=dstnat comment=ZuHauseLP_zu_HotSpot dst-address=192.168.30.0/24 log=yes log-prefix=netmap_ZuHauseLP_zu_HotSpot to-addresses=192.168.31.0/24
Both rules are at the top of the firewall rule list at positions 1 and 2

Unfortunately, I can still access the Mikrotik's WebIF when I type access.local in the browser. In other words, the hotspot “doesn’t show itself”.

I have now evaluated the logging for the two netmap rules and only see several almost identical (all to port: 53) log entries for the dstnat rule such as:
netmap_ZuHauseLP_zu_HotSpot dst: in:A3_ZuHauseLP out:(unknown 0), connection-state:new proto UDP, 192.168.30.88:49516->192.168.30.1:53, len 57

So Mikrotik probably doesn't want to make it that easy for us
maybe there's something wrong with my netmap rules?

in Deutsch:
Hallo, ich konnte jetzt erste Tests durchführen. Leider greift der Hotspot nicht. Meine Konfiguration:
Wireguard-Netz: Mikrotik 192.168.30.1/24
Remote-Laptop: IP 192.168.30.88/32 - DNS in Wireguard 192.168.30.1
Wireguard funktioniert, der Laptop ist per LTE-Router im Internet, die Mikrotik per DSL-Modem. Ich bekomme eine Verbindung und kann z.B: das WebIF der Mikrotik aufrufen.

HotSpot-Netz: Mikrotik 192.168.31.1/24
der Hotspot an sich funktioniert. Ich hatte für Tests meinen Remote-Laptop über ether2 angeschlossen, per DHCP eine 192.168.31.254 bezogen und mittels zugang.local konnte ich mich am HotSpot authentifizieren.
Konfig siehe oben.

jetzt verbinde ich die beiden Technologien mittels:
add action=netmap chain=srcnat comment=HotSpot_zu_ZuHauseLP log=yes log-prefix=netmap_HotSpot_zu_ZuHauseLP src-address=192.168.31.0/24 to-addresses=192.168.30.0/24
add action=netmap chain=dstnat comment=ZuHauseLP_zu_HotSpot dst-address=192.168.30.0/24 log=yes log-prefix=netmap_ZuHauseLP_zu_HotSpot to-addresses=192.168.31.0/24
Beide Regeln stehen ganz oben in der Firewall-Regellist an Position 1 und 2

Leider kann ich immer noch das WebIF der Mikrotik aufrufen, wenn ich zugang.local in den Browser eingebe. Sprich, der Hotspot "zeigt sich nicht".

Ich habe nun das Logging auf die beiden netmap-Regeln ausgewertet und sehe lediglich mehrere fast identische (alle zu Port :53) Log-Einträge zur dstnat-Regel wie z.B.:
netmap_ZuHauseLP_zu_HotSpot dst: in:A3_ZuHauseLP out:(unknown 0), connection-state:new proto UDP, 192.168.30.88:49516->192.168.30.1:53, len 57

Also ganz so einfach will es uns die Mikrotik wohl doch nicht machen
vielleicht ist auch etwas mit meinen netmap-Regeln nicht in Ordnung?

[...]
Unfortunately, I can still access the Mikrotik's WebIF when I type access.local in the browser. In other words, the hotspot “doesn’t show itself”.
[...]
So Mikrotik probably doesn't want to make it that easy for us
maybe there's something wrong with my netmap rules?

No doubt. The netmap may not be enough, dunno. But other suggestion is to look hotspot "jump" rules in /ip/firewall/filter and .../nat.

See /ip/hotspot is essentially implemented as some dynamic firewall rules. But if you look at them, they use some FW extensions to take actions based on a "hotspot=" state. e.g.
and in particular a "hotspot=!auth".

So perhaps create a static rule, based on WG src-address, that mimics the dynamic action=jump rules, in both NAT and filter, added by /ip/hotspot to the forward and input chain. i.e., the action=jump is what essentially "forks" the traffic based on the "hotspot=!auth" from the firewall rule.

But the key detail is the hotspot state looks available to use in your own firewall rules. Thus, theoretically, could have similar fork for hotspot=!auth or hotspot=auth in your filter rule, except matching on the WG addresses.

See docs, but

hotspot (auth | from-client | http | local-dst | to-client; Default: ) - Matches packets received from HotSpot clients against various HotSpot matchers.
auth - matches authenticated HotSpot client packets
from-client - matches packets that are coming from the HotSpot client
http - matches HTTP requests sent to the HotSpot server
local-dst - matches packets that are destined to the HotSpot server
to-client- matches packets that are sent to the HotSpot client

There a bit more complexity I'm sure, but that's be the concept.

Re the netmap rule not working...
I had CHR open, so added hotspot to look at the rules hotspot generates more. So yeah the netmap isn't triggering the various rule "hotspot=!auth,from-client action=jump jump-target=hs-unauth" need to steer traffic.

So those WG peer IP getting netmap'ed does NOT seem to cause the "hotspot=from-client" to be set. Since the hotspot= is a Mikrotik extension to Linux firewall, IDK how the "from-client" get determined... But it very well could check the /ip/firewall config to know what IP ranges it set to and sets the hotspot's "from-client" state BEFORE the netmap. Or worse, matching on interface (which may be more likely & netmap cannot fake an interface). But dunno, and seems netmap isn't fooling hotspot.

That's why I suggested static rules that only use hotspot=auth or =!auth & BUT NOT using the =from-client or =to-client parts – since you can match on the WG IP yourself, and use the same jump-target= used in the dynamic rules. Perhaps once the traffic gets to the hotspot added chain= like hs-unauth etc. etc., maybe that be enough?

I strongly advise against using WireGuard in this case.

Manually administering 150 WireGuard connections will likely be a counterproductive solution. It will probably result in complex manual administrational (nightmare) tasks with the risk of long lead times and ultimately lead to increased costs for operations management and dissatisfied end users.

My recommendation is to instead use a solution based on SD-WAN such as ZeroTier or TailScale (which btw is built on WireGuard). This minimizes the administration needs to an absolute minimum since everything is easily managed centrally from a web-based control station. The client installation is also very easy, either by manually installing the client or making it fully automated using ADAC or SCCM/MECM. The rest of the configuration is performed using the web admin tool.

Furthermore, SD-WAN also offers excellent possibilities for seamless integration with Active Directory which might for example control connections using group policies and more granularly with object access control for Active Directory domains.

Some additional advantages are that you might replace IPsec with the built-in encryption already present in SD-WAN as well as provide people who travel frequently easy access to the office network. SD-WAN utilizes all available networks ensuring seamless roaming without downtime.

I can promise you one thing; once you've started using SD-WAN you never ever want to go back to manually administered and static VPN tunnels.

@Larsa makes good points. And disclaimer: I use ZeroTier myself because all the WG key deployment stuff is so manual. But, I get the desire to avoid needing to use some SD-WAN SaaS/cloud thing.

And I do like the concept here as a "DIY two factor auth" for WG peers. But...I still think Mikrotik should have built-in "Back to Work" option in BTH feature as that does deal with WG peer deployment from some auth creds e.g. just /users today, but don't think RADIUS be big leap beyond current BTH... since it already creates a peer from some creds today.

Now it's true WG peer deployment is pretty raw/difficult. But if there AD or some central management of desktops... WG peer deployment might be slightly easier in that case... than if just random users. I presumed OP accepted having to figure out the peer deployment part here

tailscale might be best and simplest solution. Especially, because there is also (open source) headscale available, a do-it-yourself central manager, in case you do not trust a third party.

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

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

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.