Clientless VPN mit dem WatchGuard Access Portal (“reverse-proxy”, ab Fireware 12.5)

Ab der Version 12.5 (derzeit als Beta verfügbar) unterstützt WatchGuard ein sog. Clientless VPN. Dahinter verbirgt sich die Möglichkeit, dem Benutzer nach der Anmeldung über das Access Portal auch interne Web-Ressourcen zur Verfügung zu stellen.

Unterstützte Authentifizierungen:

• Firebox-DB
• Active-Directory
• SAML über Identity Portale
  • z.B. AuthPoint IdP
  • z.B. Okta
• RADIUS
  • Microsoft NPS
  • AuthPoint für Radius 2FA
  • weitere Radius Server
• SecurID
• LDAP

Funktionsweise:

Nachdem man sich beim Access Portal anmeldet (hier ist mit AuthPoint auch 2-Faktor-Authentifizierung möglich).

erscheinen die Applikationen die dem Benutzer / der Benutzergruppe zugeordnet sind:

Mögliche Applikationen:

• RDP-Sitzungen
• SSH-Sitzungen
• externe Web-Applikationen (bei denen per SAML die Authentifizierung weitergereicht werden kann)
• interne Web-Applikationen (hier reagiert die WatchGuard als “reverse Proxy”).

beim Klick auf die Applikation wird dann die hinterlegte URL aufgerufen. Sofern diese URL dann (extern gesehen) auf die Firewall zeigt, erkennt die WatchGuard bei diesen Zugriffen die bereits aktive Authentifzierung und reicht den Request nach innen durch. Das Ganze funktioniert über sogenannte URL-Mappings, bei denen der Domain-Name und das interne Ziel (und Port) festgelegt werden können.
Beispielsweise: https://webmail.maiers.de => https://10.10.x.y, mit URL-Mapping “/” auf “/”.

Voraussetzungen:

• externer DNS-Eintrag für den entsprechenden Namen (hier webmail.maiers.de) => zeigt auf die IP der WatchGuard/ des Access Portals
• das Default-Zertifkat der Watchguard sollte zur Vermeidung von Browser-Warnungen ein Multi-Domain- bzw. SAN- (Subject Alternative Name) Zertifkat sein
• alternativ ein Wildcard-Zertifikat – für die Tests habe ich ein Wildcard-Zertifikat von LetsEncrypt verwendet
• die Weiterleitung nach Innen kann über DNS-Name erfolgen (wenn die Firebox den Namen zur richtigen internen(!) IP auflösen kann
• Alternativ verwendet man einfach die IP-Adresse des internen Servers
• der HTTP(S)-Request wird dann von der Firebox an die IP weitergeleitet – der verwendete DNS-Name im HTTP(S)-Request wird durchgereicht
• der interne Server muss dann auf auf den Namen (SNI) reagieren und die entsprechende Seiten ausliefern
• ein Portmapping ist möglich, falls es notwendig sein sollte. (dann gibt man als Internal URL https://10.10.x.y:port ein)
• ein Mapping auf die Firewall selbst (https://interne.ip.der.firewall:8080/auth/login/) ist möglich. Somit kann dem Admin einen gesicherten 2-Faktor-Zugang über dieses Portal zur Verfügung gestellt werden.

Getestet wurde dies mit der Version 12.5 Beta 1, die derzeit auf dem Beta-Portal zur Verfügung steht. Erfahrungsgemäß dauert der Beta-Zyklus etwa 6-8 Wochen, mit einem Erscheinen der 12.5 ist somit vermutlich frühestens Ende Juni zu rechnen, vermutlich eher im Juli diesen Jahres.