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

RouterOS General
1

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.

2

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.

3

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…

4

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

5

Methinks its not possible.

6

Brainstorming along …
A separate bridge perhaps ? Not ideal but might work ?

7

Two MT routers maybe…

8

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.


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.

9

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.

10

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

11

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 :slight_smile:

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

12

:mrgreen:

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 :smiley: :
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.

13

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: :slight_smile:

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:

/ip firewall filter
add action=drop chain=input src-address-list=Schwarze_Liste
add action=drop chain=forward src-address-list=Schwarze_Liste
add action=add-src-to-address-list chain=input dst-address="Wireguard_Netzwerkadresse" in-interface="Wireguard_Interface" src-address-list=!Sicher psd=21,3s,3,1 address-list=Schwarze_Liste address-list-timeout=1440m
add action=drop chain=input dst-address="Firmennetzwerk" in-interface="Wireguard_Interface" src-address-list=!Sicher connection-state=!established
add action=add-src-to-address-list chain=input src-address="Benutzeradresse" dst-address="Wireguard_Netzwerkadresse" protocol=tcp dst-port=1234 in-interface="Wireguard_Interface" address-list=Schritt1 address-list-timeout=90s
add action=add-src-to-address-list chain=input src-address-list=Schritt1 src-address="Benutzeradresse" dst-address="Wireguard_Netzwerkadresse" protocol=tcp dst-port=123 in-interface="Wireguard_Interface" address-list=Schritt2 address-list-timeout=90s
add action=add-src-to-address-list chain=input src-address-list=Schritt2 src-address="Benutzeradresse" dst-address="Wireguard_Netzwerkadresse" protocol=tcp dst-port=12 in-interface="Wireguard_Interface" address-list=Sicher address-list-timeout=120m

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

14

Yikes, cant imagine doing that for 150 users…

15

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 :sunglasses:
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 :sunglasses:
vielleicht ist auch etwas mit meinen netmap-Regeln nicht in Ordnung?

16

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.

/ip/firewall/nat add hotspot=<tab>
auth     from-client     http     local-dst     to-client

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.

17

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?

18

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.

19

@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 :wink:

20

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.