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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1067443883
Url: https://administrator.de/contentid/1067443883
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
22 Kommentare
Neuester Kommentar
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 ?!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 @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.
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.
OK, zeig doch bitte noch die Detailseite des Server Certificates und dessen 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.
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.
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 .