mr.klix
Goto Top

Watchguard IKEv2 Mobile VPN mit NPS

Hallo zusammen,

bin gerade etwas am verzweifeln.
Ziel ist es die User demnächst auf ein IKEv2 Mobile VPN mit Radius (NPS Server 2016) Authentifizierung umzustellen. IKEv2 mit Zertifikat und lokalen Firebox Usern läuft problemlos. Sobald ich auf den Radius umstelle bekomme ich keine Verbindung zu stande. Es soll die Mitgliedschaft der AD VPN-User Gruppe geprüft werden und entsprechend Zugang zum Netz gewährt werden.

Ich nutze den nativen Win10 1903 VPN Client um die Verbidnung zu testen. Das Watchguard Cluster M270 ist auf dem aktuellsten Stand 12.5.2

Folgende Log's erhalte ich.

NPS:
Die NPS Eventlogs melden: Event 6272 Network Policy Server granted access to a user. Soweit so gut.

Client:

Windows Eventlogs:
Event 20221 Quelle: RasClient
Event 20222 Quelle: RasClient
Event 20223 Quelle: RasClient
Event 20224 Quelle: RasClient

zum Schluss:

Event 20227 CoID={507D3DF9-9A50-466F-98B1-5EDA8F0CD022}: Der Benutzer "Domain\User" hat eine Verbindung mit dem Namen "WG IKEv2" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: -2143157998.

Watchguard:
Firebox Diagnostic LOG: 2020-03-25 21:54:15 WG2 admd RADIUS:check RADIUS authenticator (172.20.1.1) failed
Firebox Event: 2020-03-25 22:00:13 WG2 admd Authentication of MUVPN user [dk@RADIUS] from 84.59.XXX.XXX was rejected, Recv timeout msg_id="1100-0005"


Scheinbar geht die Radius Auth durch. An der korrekten Rückmeldung hapert es jedoch.

Hat eventuell jemand ein ähnliches Konstrukt am laufen und möchte mal seine Config mit mir durchgehen? Werde aus der Sache einfach nicht mehr schlau.


PS:
Die Watchguard KB Artikel habe ich natürlich gelesen und befolgt. Config mehrfach überflogen, geprüft, gelöscht und wieder neu gemacht. Immer das selbe Bild.

Meine Quellen
- Einrichtung Firebox: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fir ...
- Einrichtung NPS: https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
- IIKEv2: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fir ...

Content-ID: 560846

Url: https://administrator.de/contentid/560846

Printed on: December 7, 2024 at 21:12 o'clock

chgorges
chgorges Mar 25, 2020 at 22:29:34 (UTC)
Goto Top
Hi,

hört sich blöd an, aber den NPS hast du zwischendurch mal neugestartet? In der letzten Zeit konnten gefühlt 10 Threads mit NPS-Problem mit einem Neustart des Servers behoben werden.
Mr.Klix
Mr.Klix Mar 26, 2020 updated at 07:13:54 (UTC)
Goto Top
Zitat von @chgorges:

Hi,

hört sich blöd an, aber den NPS hast du zwischendurch mal neugestartet? In der letzten Zeit konnten gefühlt 10 Threads mit NPS-Problem mit einem Neustart des Servers behoben werden.

Hatte ich tatsächlich noch nicht gemacht. Hat das Problem leider nicht gelöst. Wäre zu schön gewesen face-big-smile

Was mir im NPS Log noch aufgefallen ist, was bei der WLAN Auth definitiv nicht so ist. (siehe Bild)

nps_issue


Wenn ich die Einwahl über Android teste (selbes IKEv2 Profil) sieht der LOG EIntrag im NPS normal aus. Also domain\User
Deepsys
Deepsys Mar 26, 2020 at 11:03:47 (UTC)
Goto Top
Hi,


Zitat von @Mr.Klix:
Ich nutze den nativen Win10 1903 VPN Client um die Verbidnung zu testen.
Ähm du meinst uner Einstellungen/VPN den Dialog?
Hast du zum einrichtung das skript von WG benutzt?

Firebox Diagnostic LOG: 2020-03-25 21:54:15 WG2 admd RADIUS:check RADIUS authenticator (172.20.1.1) failed
Firebox Event: 2020-03-25 22:00:13 WG2 admd Authentication of MUVPN user [dk@RADIUS] from 84.59.XXX.XXX was rejected, Recv timeout msg_id="1100-0005"


Scheinbar geht die Radius Auth durch. An der korrekten Rückmeldung hapert es jedoch.
Nein tut es nicht, der Radius Authenticator ist schon failed, wohl wegen TimeOut?

Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?

Wir fahren genau dieses Konstrukt auch face-smile

VG
Deepsys
Deepsys
Deepsys Mar 26, 2020 at 11:16:22 (UTC)
Goto Top
Wenn der NPS ablehnt, weil Konto gesperrrt oder anmeldedaten falsch, dann sieht das in der WG so aus:

Authentication of MUVPN user [deepsys@doamin] from 19.23.13.108 was rejected, user binding error,check your username or password, pri=4, proc_id=admd, msg_id=1100-0005

Klappt alles, dann so:

Authentication of MUVPN user [VPN-W10@RADIUS] from 94.14.16.210 was accepted, pri=6, proc_id=admd, msg_id=1100-0004
Mr.Klix
Mr.Klix Mar 26, 2020 updated at 13:30:47 (UTC)
Goto Top
Zitat von @Deepsys:

Hi,


Zitat von @Mr.Klix:
Ich nutze den nativen Win10 1903 VPN Client um die Verbidnung zu testen.
Ähm du meinst uner Einstellungen/VPN den Dialog?
Hast du zum einrichtung das skript von WG benutzt?

Firebox Diagnostic LOG: 2020-03-25 21:54:15 WG2 admd RADIUS:check RADIUS authenticator (172.20.1.1) failed
Firebox Event: 2020-03-25 22:00:13 WG2 admd Authentication of MUVPN user [dk@RADIUS] from 84.59.XXX.XXX was rejected, Recv timeout msg_id="1100-0005"


Scheinbar geht die Radius Auth durch. An der korrekten Rückmeldung hapert es jedoch.
Nein tut es nicht, der Radius Authenticator ist schon failed, wohl wegen TimeOut?

Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?

Wir fahren genau dieses Konstrukt auch face-smile

VG
Deepsys


Hey, danke für deine Rückmeldung.

Ja das Skript genutzt.

Wenn ich die Verbindung von extern aufbaue, geht die Kommunikation bis zum NPS durch. In den NPS Log's kann ich sehen das der User Zugriff erhält. Der Auth Response kommt allerdings aufgrund von Timeout nicht zurück. Das sehe ich in den LOG'S vom stronSWAN VPN Client.
Eventuell ein MTU Size Problem? Habt ihr in die Richtung etwas konfiguriert?

Ansonsten habe ich den NPS wie von Watchguard beschrieben konfiguriert.
https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
Deepsys
Deepsys Mar 26, 2020 at 21:59:18 (UTC)
Goto Top
Zitat von @Mr.Klix:
Zugriff erhält. Der Auth Response kommt allerdings aufgrund von Timeout nicht zurück. Das sehe ich in den LOG'S vom stronSWAN VPN Client.
Naja, guck lieber auf den Firewall Log face-wink


Eventuell ein MTU Size Problem? Habt ihr in die Richtung etwas konfiguriert?
Nein, das ist bestimmt kein Problem (Ich wundere mich immer über die MTU Fragen, da habe ich noch nie was geändert ...)

Ansonsten habe ich den NPS wie von Watchguard beschrieben konfiguriert.
https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
Nee, habe ich händisch gemacht, wir authentifizieren direkt gegen AD-Gruppen und nicht mit IKEv2-Users.

Hmm, pingbar ist der NPS von der Firebox aus?
Sind die Firebox und der NPS im gleichem Netz?
Irgendwas dazwischen, irgendeine Sicherheitssoftware auf dem NPS?

Du kannst das auch anders testen, richte dir über den Firebox Manager (nicht den Policy Manager) mal lokale Zugänge auf die FB ein, und das mit RADIUS. Ich meine das geht, dann teste das mal so.

Ansonsten hast du doch Support von WG, frage das mal nach.
Die können auch mal in deine Konfig gucken, evtl. ist das was falsch.
Mr.Klix
Mr.Klix Mar 27, 2020 at 10:49:16 (UTC)
Goto Top
Zitat von @Deepsys:

Zitat von @Mr.Klix:
Zugriff erhält. Der Auth Response kommt allerdings aufgrund von Timeout nicht zurück. Das sehe ich in den LOG'S vom stronSWAN VPN Client.
Naja, guck lieber auf den Firewall Log face-wink


Eventuell ein MTU Size Problem? Habt ihr in die Richtung etwas konfiguriert?
Nein, das ist bestimmt kein Problem (Ich wundere mich immer über die MTU Fragen, da habe ich noch nie was geändert ...)

Ansonsten habe ich den NPS wie von Watchguard beschrieben konfiguriert.
https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
Nee, habe ich händisch gemacht, wir authentifizieren direkt gegen AD-Gruppen und nicht mit IKEv2-Users.

Ja wir auch, den Part habe ich natürlich angepasst.

Hmm, pingbar ist der NPS von der Firebox aus?

Ja

Sind die Firebox und der NPS im gleichem Netz?

ja

Irgendwas dazwischen, irgendeine Sicherheitssoftware auf dem NPS?

Nein

Du kannst das auch anders testen, richte dir über den Firebox Manager (nicht den Policy Manager) mal lokale Zugänge auf die FB ein, und das mit RADIUS. Ich meine das geht, dann teste das mal so.

Ansonsten hast du doch Support von WG, frage das mal nach.

Ist der nächste Schritt.

Die können auch mal in deine Konfig gucken, evtl. ist das was falsch.

Habe den Spass mal an einem anderen Standort eingerichtet. Läuft auf Anhieb. Wende mich jetzt erstmal an den Support. Werde das Cluster heute abend mal durchbooten.

Vielen Dank für deinen Rat. Werde berichten sobald ich die Lösung habe.
ZekiDawood
ZekiDawood Feb 21, 2022 updated at 14:19:28 (UTC)
Goto Top
Ich stande vor dem gleichen Problem, Lösung war hierbei WG-Gruppe, welche den RADIUS als Authentifizierungsserver verwendet muss den gleichen Namen haben wie
die AD-Gruppe, welche zurück geschickt wird von dem RADIUS-Server (und AD-Gruppe natürlich)

Mfg.
Zeki Dawood