22
Pfsense 2.5.1 mit EAP-MSChapv2
Hallo zusammen,
ich habe nun die erste Firewall auf 2.5.2 aktualisisert und seither geht VPN über ikev2 und EAP-MSChapv2 nicht mehr. Ich hatte bisher immer das selbe gemacht. Zertifikat erstellt, VPN eingerichtet und mit TheGreenBow VPN Client verbunden. Nun erhalte ich beim Versuch folgende Meldung:
20210721 08:47:35:623 TIKEV2_xxx No CA for certificate "C = US, ST = xxx, L = xxx, O = xxx, emailAddress = xxxxx, CN = www.xxx.xx"
20210721 08:47:35:624 TIKEV2_xxx Authentication failure : no certificate from remote endpoint.
Ich konnte die Meldung schon mal minimieren, indem ich ein neues erstellt habe und als "Server Certificate" definiert habe. Nun gibt es nur noch
Authentication failure : no certificate from remote endpoint.
Ich habe das auch einfach mal exportiert und bei mir im PC mit eingebunden beim GreenBow Client aber das ändert auch nichts. Ich weiss nicht was genau pfsense mit der Version 2.5 geändert hat, aber bevor ich die überall installiere müsste ich das Problem erst mal lösen
Kann mir eventuell jemand helfen?
ich habe nun die erste Firewall auf 2.5.2 aktualisisert und seither geht VPN über ikev2 und EAP-MSChapv2 nicht mehr. Ich hatte bisher immer das selbe gemacht. Zertifikat erstellt, VPN eingerichtet und mit TheGreenBow VPN Client verbunden. Nun erhalte ich beim Versuch folgende Meldung:
20210721 08:47:35:623 TIKEV2_xxx No CA for certificate "C = US, ST = xxx, L = xxx, O = xxx, emailAddress = xxxxx, CN = www.xxx.xx"
20210721 08:47:35:624 TIKEV2_xxx Authentication failure : no certificate from remote endpoint.
Ich konnte die Meldung schon mal minimieren, indem ich ein neues erstellt habe und als "Server Certificate" definiert habe. Nun gibt es nur noch
Authentication failure : no certificate from remote endpoint.
Ich habe das auch einfach mal exportiert und bei mir im PC mit eingebunden beim GreenBow Client aber das ändert auch nichts. Ich weiss nicht was genau pfsense mit der Version 2.5 geändert hat, aber bevor ich die überall installiere müsste ich das Problem erst mal lösen
Kann mir eventuell jemand helfen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1067443883
Url: https://administrator.de/contentid/1067443883
Printed on: April 19, 2024 at 08:04 o'clock
22 Comments
Latest comment
Du arbeitest mit einem US Zertifikat ??? Nicht dein Ernst, oder ?
Das Tutorial zu dem Thema hast du gelesen und alle dortigen Schritte umgesetzt ?
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das Tutorial zu dem Thema hast du gelesen und alle dortigen Schritte umgesetzt ?
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
no certificate from remote endpoint.
Bedeutet ja das du entweder das neu erstellte Zertifikat auf der FW nicht aktiviert hast (und/oder das alte nicht gelöscht hast) oder vergessen hast das Zertifikat auf den VPN Client zu exportieren ?!
Ich habe beide Zertifikate gerade komplett neu gemacht und auch exportiert. So wie es in der Anleitung steht. Das mit dem US ist laut der Doku sogar egal. Ist aktuell aber nicht mehr der Fall. Jedoch erhalte ich leider immer noch die selbe Fehlermeldung. Trotz Import auf dem Client.
Authentication failure : no certificate from remote endpoint.
Bei dem Fehler wurde wohl vergessen das neue Zertifikat explizit dem VPN Dienst in den Einstellungen zuzuweisen und den Dienst mal neu zu starten.Das mit dem US ist laut der Doku sogar egal
Nicht wenn es abgelaufen ist oder die Uhrzeit in der FW oder Client nicht stimmt. Das Default Zert. der Box sollte man aber natürlich aus guten Gründen niemals aktiv nutzen.Habs hier grad mal an einer 2.5.2 getestet und rennt zumindestens mit dem embeddeten Windows 10 VPN Client und dem VPN Client unter Mac OS Big Sur sowie iOS fehlerlos !
Das default Cert habe ich auch nie verwendet.
So so... und dann zeigt er oben ein US Zertifikat an ?! 🤔Ein Schelm wer Böses dabei denkt...
Zitat von @149062:
Authentication failure : no certificate from remote endpoint.
Bei dem Fehler wurde wohl vergessen das neue Zertifikat explizit dem VPN Dienst in den Einstellungen zuzuweisen und den Dienst mal neu zu starten.Beim TheGreenBow VPN Client kann ich in den Einstellungen ein Zertifikat mit einbinden zur Authemtisierung. Das ist auch dort drinnen. Deswegen bin ich ja so ratlos
. Uhrzeit etc. ist überall gleich.Zitat von @aqui:
Habs hier grad mal an einer 2.5.2 getestet und rennt zumindestens mit dem embeddeten Windows 10 VPN Client und dem VPN Client unter Mac OS Big Sur sowie iOS fehlerlos !
Das mit dem US ist laut der Doku sogar egal
Nicht wenn es abgelaufen ist oder die Uhrzeit in der FW oder Client nicht stimmt. Das Default Zert. der Box sollte man aber natürlich aus guten Gründen niemals aktiv nutzen.Habs hier grad mal an einer 2.5.2 getestet und rennt zumindestens mit dem embeddeten Windows 10 VPN Client und dem VPN Client unter Mac OS Big Sur sowie iOS fehlerlos !
Das default Cert habe ich auch nie verwendet. Ich habe die beide immer neu hergestellt und natürlich bei der Zeitzone die richtigen Angaben gemacht.
Zitat von @letstryandfindout:
Beim TheGreenBow VPN Client kann ich in den Einstellungen ein Zertifikat mit einbinden zur Authemtisierung.
Nee, ich meine an der pfSense!Beim TheGreenBow VPN Client kann ich in den Einstellungen ein Zertifikat mit einbinden zur Authemtisierung.
Das ist auch dort drinnen.
Das ist Blödsinn und falsch wenn du MsChapv2 mit Username und Kennwort auf der PfSense als Auth eingestellt hast .Trial n Error bringt hier nix du musst das Auth Protokoll verstehen und auf der pfSense richtig konfigurieren
.Klappt hier übrigens ebenfalls problemlos sowohl mit MsChapv2 als auch EAP-TLS mit Zertifikaten, mit dem Default Windows 10 Client auf ner aktuellen PFSense 2.5.2. Mit Windows 11 geht es übrigens auch.
Guckst du
Fazit: Arbeitet wie vorgesehen
. wenn du MsChapv2 mit Username und Kennwort auf der PfSense als Auth eingestellt hast
Hört sich dann eher so an als ob der TO L2TP mit IPsec nutzt und gar kein native IKEv2 IPsec ?!? Da ist MS-CHAPv2 ja Usus.
Dann frag ich mich was ich falsch mache. Denn bis 2.4.X lief es ja. Also noch mal das CA ist anglegt und wenn ich den Mobile Client angelegt habe mit MsChapv2, wähle ich natürlich das erstellte Zertifikat auch aus. Phase 1 und 2 haben sich vor dem Update nicht verändert. Nur eben, dass ich nun diese Fehlermeldung erhalte. Auch ist das Zertifikat nach wie vor gültig. Daher frage ich mich was oder wie ich das Auth Protokoll der pfSense richtig konfigurieren soll.
Meine Phase 1 sieht aus wie deine oben auf deinem Bild. Mobile + User ebenfalls.
Meine Phase 1 sieht aus wie deine oben auf deinem Bild. Mobile + User ebenfalls.
Zeig mal die Einstellungen für die Certs der pfSense sind dort auch sämtliche SANs enthalten?.
Und auch alle Settings des Clients.
Und auch alle Settings des Clients.
Meinst du die Sachen?
OK, zeig doch bitte noch die Detailseite des Server Certificates und dessen SANs.
Eine für dich warscheinlich eher doofe Frage aber was meinst du genau mit SANs?
Zitat von @letstryandfindout:
Eine für dich warscheinlich eher doofe Frage aber was meinst du genau mit SANs?
Eine für dich warscheinlich eher doofe Frage aber was meinst du genau mit SANs?
Subject Alternative Name
Und genau die fehlen Inden Bildern (...weiter unten)
Dort müssen sämtliche Identifier (FQDNs/IPs) hinterlegt sein mit denen die PFSense angesprochen wird. Bei dir ist es ja laut den Bildern oben die IP Adresse und die muss dort dann auch hinterlegt sein weil du als Identifier "IP address" in den IPSec Settings hinterlegt hast.
Das heisst wenn ich dich richtig verstehe, dass die IP von der Firewall noch eingetragen werden muss? Denn von den ganzen mobilen Clients wird es ja schwer, die haben ja schliesslich keine fixe. Und spannend, dass das ganze vor dem Sprung auf die Version ging. Aber so lernt man immerhin was dazu. Danke dir auf jeden Fall für deine Geduld und Hilfe.
Zitat von @letstryandfindout:
Das heisst wenn ich dich richtig verstehe, dass die IP von der Firewall noch eingetragen werden muss?
Ja! ein Zertifikat ohne jegliche SANs wird heutzutage übrigens fast überall als ungültig angesehen! Dort gehört mindestens der Common-Name rein und eben zusätzliche IPs oder andere von dieser Firewall von extern genutzte Domainnamen!Das heisst wenn ich dich richtig verstehe, dass die IP von der Firewall noch eingetragen werden muss?
Denn von den ganzen mobilen Clients wird es ja schwer, die haben ja schliesslich keine fixe.
Das ist ja auch Blödsinn die brauchen das nicht. Für die Remote-Identity reicht dann "any".An deiner Stelle würde ich die Clients gleich alle mit Client-Zertifikaten betanken und EAP-TLS machen und in der Remote-Identity dann den DN (DistinguishedName) der CA als Identity setzen.
1
Du bist eine Granate!!!! Das any war die Lösung!!!! Vielen vielen vielen vielen Dank.
Was eine schwere Geburt... 😉 Übrigens: Das hiesige Tutorial beschreibt das doch auch eindeutig und weist explizit auf die Konfig der FQDN Namen mit Auswirkungen auf die Clients usw. hin !
Lesen hilft wirklich ! Case closed...
Lesen hilft wirklich ! Case closed...
Joa, manch einer braucht halt einen Einlauf wenn es von oben nicht rein will 
.
.1
👍 🤣
Da gebe ich dir Recht. Aber immerhin bin ich nun um einiges schlauer und habe viel gelernt. Du kriegst eventuell nun einen Beipass nach all dem Stress ;) aber hast immerhin dein Karma Konto mehr als aufgefüllt. Danke noch mal.
und habe viel gelernt. Du kriegst eventuell nun einen Beipass nach all dem Stress ;) aber hast immerhin dein Karma Konto mehr als aufgefüllt. Danke noch mal.
