8
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 ...
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 ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 560846
Url: https://administrator.de/forum/watchguard-ikev2-mobile-vpn-mit-nps-560846.html
Ausgedruckt am: 26.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
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.
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.
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.
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
Was mir im NPS Log noch aufgefallen ist, was bei der WLAN Auth definitiv nicht so ist. (siehe Bild)
Wenn ich die Einwahl über Android teste (selbes IKEv2 Profil) sieht der LOG EIntrag im NPS normal aus. Also domain\User
Hi,
Ähm du meinst uner Einstellungen/VPN den Dialog?
Hast du zum einrichtung das skript von WG benutzt?
Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?
Wir fahren genau dieses Konstrukt auch
VG
Deepsys
Ä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?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.
Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?
Wir fahren genau dieses Konstrukt auch
VG
Deepsys
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
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
Zitat von @Deepsys:
Hi,
Ähm du meinst uner Einstellungen/VPN den Dialog?
Hast du zum einrichtung das skript von WG benutzt?
Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?
Wir fahren genau dieses Konstrukt auch
VG
Deepsys
Hi,
Ä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?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.
Ist der Radius/NPS im der wg korrekt eingetragen?
Wie sehen die Regeln im Radius aus?
Wir fahren genau dieses Konstrukt auch
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 ...
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 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?
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.https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
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.
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 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?
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.https://watchguardsupport.secure.force.com/publicKB?type=KBArticle&S ...
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.
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.
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
die AD-Gruppe, welche zurück geschickt wird von dem RADIUS-Server (und AD-Gruppe natürlich)
Mfg.
Zeki Dawood
