Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

IPsec VPN für mobile Benutzer auf der pfSense Firewall einrichten

Mitglied: aqui

aqui (Level 5) - Jetzt verbinden

09.05.2017, aktualisiert 18.03.2019, 28522 Aufrufe, 39 Kommentare, 14 Danke


Allgemeine Einleitung

Das folgende Tutorial beschreibt die VPN Anbindung von mobilen Benutzern mit Windows 10, Mac OS, Linux sowie Smartphones und Pads unter Apple iOS und Android an die populären Firewalls pfSense (Netgate) und ihrem Fork OPNsense.
Alles mit den bordeigenen VPN Clients auf den Endgeräten und OHNE Installation von VPN Zusatzsoftware.
Entsprechende Hardware bieten diverse Händler an bzw. ist hier im Forum mit einem eigenen_Tutorial beschrieben.
Es ist eng angelehnt an das hiesige Standort_VPN_Praxis_Tutorial und ergänzt dieses.
Die Sammlung der weiterführenden Links am Schluss weist auf weitere Themen bezogene Informationen hin.
Ziel ist es bei privaten oder KMU VPN Vernetzungen, ohne großes Probieren, schnell zu einer funktionierenden VPN Anbindung von mobilen Benutzern zu kommen. Sei es per Laptop oder Smartphone.
Die hier vorgestellten Beispiele und Screenshots können mehr oder minder auch auf andere VPN Hardware übertragen werden. IPsec ist ein weltweiter Standard und benutzt überwiegend gleiche Algorithmen.
Ein klein wenig Basiswissen zum Thema Netzwerke, IP Adressen und IPsec VPNs generell sollte wie immer vorhanden sein ! Aber auch Netzwerk Laien sollten mit diesen hier geschilderten Werkzeugen sehr schnell zum Erfolg kommen.
Es empfiehlt sich ggf. die hiesigen Basis Tutorials zum IPsec Protokoll noch einmal zu lesen. Für die harten Fälle bleibt dann immer das Forum mit entsprechender Hilfe.
Los gehts....


Vorbereiten der pfSense für die Basiskonfiguration:

Die aktuellen, bordeigenen VPN IPsec Clients fast aller Betriebssysteme und Smartphones nutzen in der Regel das moderne IKEv2 Verfahren. Deshalb muss zuallererst eine neue und vor allem eigene CA und ein Server Zertifikat erstellt werden für die späteren Clients. Im Gegensatz zum älteren IKEv1 erfordert das IKEv2 Verfahren ein entsprechendes Zertifikat.
Man-in-the-Middle Attacken auszuschließen bedingt bei IKEv2, dass sich das VPN-Gateway vorab mit einer RSA-Signatur und einem vertrauenswürdigen X.509-Zertifikat ausweisen muss.
Aus naheliegenden Gründen sollte niemals das per Default installierte (US) Zertifikat der pfSense oder OPNsense verwendet werden !
Zur eigenen Sicherheit ist immer ein eigenes Zertifikat also Pflicht und die Basis der Vertraulichkeit eines VPNs. Das Default Zertifikat sollte nach Abschluß der Installation des eigenen Zertifikats zwingend gelöscht werden !

Die Schritte zur Zertifikats Neueinrichtung sind schnell erledigt. Dazu geht man folgendermaßen vor:

  • Menü: System -> Cert Manager.
 Auf dem “CA” Reiter "Add" klicken für eine neue CA Authority. “Descriptive Name” ist der Name des Zertifikats was man später den Benutzern gibt. Hier gilt es keine Leer- und Sonderzeichen zu verwenden. Binde- und Unterstrich ist erlaubt. Z.B. "vpnca" oder "firewall-ca".
  • Method: "Create an internal Certificate Authority"

  • Key length: 2048

  • Digest Algorithm: sha256
  • Lifetime: 3650 days (10 Jahre Gültigkeit).

  • Den Rest füllt man entsprechend seiner Daten aus, Ländercode etc. Der Inhalt ist nicht wichtig für die Funktion
  • "Common Name”: Hier MUSS exakt der Name rein der oben bei "Descriptive Name" verwendet wurde ! (Beispiel hier "vpnca" oder "firewall-ca")
  • Save klicken zum Sichern

Server Zertifikat erstellen:

  • Menü: System -> Cert Manager.
  • Auf dem “Certificates” Reiter "Add" klicken für ein neues Server Zertifikat.
  • Method: "Create an internal certificate”.
  • Eine Beschreibung Descriptive Name angeben wie z.B. "IKEv2 VPN".
  • Für die “Certificate Authority” wählt man jetzt die CA aus, die man gerade oben im ersten Schritt eingerichtet hat.
  • Key length, Digest algorithm, und Lifetime belässt man auf dem Default 2048 und sha256. Lifetime wie in Schritt 1 auf 10 Jahren (3650 days) belassen sofern man nicht in einem kürzeren Abstand neue Zertifikate ausgeben will !
  • Certificate Type”: Server Certificate. --> (ACHTUNG: Dieser Schritt ist WICHTIG, das das Zertifikat als Server Zertifikat deklariert wird ! (Siehe Fragen Threadverlauf unten mit Fehlern wenn das vergessen wurde !))
  • Die Daten wie Ländercode usw. so belassen wie sie sind und in der CA Konfig vorher eingegeben wurden.
  • Common und Alternative Names: Einige nehmen hier den VPN Server Hostnamen im DNS. Andere nur die WAN IP (geht nur wenn die statisch ist) Wieder andere beides oder einen Namen. Dieser Punkt ist extrem wichtig für den onboard Windows 10 IKEv2 VPN Client, denn dieser püft das Zertifikat darauf. Hat man nur einen Common Name eingegeben und connected mit der IP Adresse verweigert der Windows Client die VPN Verbindung. Mac OS, iOS oder StronSwan sind da erheblich toleranter. Der folgende Konfig Schritt deckt alle 3 Optionen ab, so das man hier immer auf Nummer sicher geht das es später klappt:
  • “Common Name”: Der Hostname dieser pfSense Firewall wie im General Setup definiert oder im DNS. (ohne Domain Suffix)
setupname - Klicke auf das Bild, um es zu vergrößern
  • Unter Alternative Names jetzt “Add” klicken, “FQDN or Hostname” auswählen und den Hostnamen eingeben 
wie oben ohne Suffix.
  • Nochmals “Add” klicken, “FQDN or Hostname” auswählen und den kompletten FQDN Hostnamen mit Suffix eingeben.
  • Nochmals “Add” klicken, “IP Adress” auswählen und die WAN IP Adresse eingeben sofern eine statische vorhanden. (Entfällt bei wechselnder WAN IP. In einem Kaskaden Setup wie weiter unten beschrieben setzt man hier die statische WAN IP ein.)
zertcomname - Klicke auf das Bild, um es zu vergrößern
  • Ggf. weitere Namen nach diesem Schema eingeben. Eine dieser Alternativen muss immer mit dem Client übereinstimmen. DNS Namen sind gerade für den WIN 10 VPN Client wichtig.
  • Save zum Sichern klicken.

Zum Schluss muss noch das CA Zertifikat für die Installation bei den Clients exportiert werden :
  • Menü: System > Cert Manager und dort den "CAs" Reiter klicken.
  • Hier das blaue "Siegel Icon" rechts in der Ecke klicken das aussieht wie eine kleine Sonne. Bei Mouseover zeigt der Hilfetext "Export CA" ! Es wird eine Datei <commonname>.crt exportiert die nachher später auf die VPN Clients kopiert werden muss.
Diese Datei ist sehr WICHTIG und wird später für die Client Einrichtung gebraucht, also gut sichern !
Wie der Client Import des Zertifikats genau gemacht wird erklärt das Tutorial später unten in der Einrichtung der diversen VPN Clients im Detail.

Damit ist die Zertifikatserstellung auf der Firewall abgeschlossen.

! ACHTUNG !:
Das alte Default Zertifikat (US Zertifikat) was die pfSense automatisch mitbringt sollte man jetzt unbedingt LÖSCHEN wenn nicht schon geschehen !!
Dazu ist zuerst das SSL GUI für den Webzugriff auf die FW auf dieses neu generierte Zertifikat einzustellen unter Systems --> Advanced --> Admin Access:

pfssl - Klicke auf das Bild, um es zu vergrößern
Hier wählt man das eigene zuvor generierte Zertifikat anhand seines Namens aus und geht dann zurück in die Zertifikats Verwaltung um das Default (US) Zertifikat der pfSense dann final zu löschen. Mit der Umstellung erhält es dann auch das "Papierkorb Symbol" zum löschen.
Nach einem Reboot sollte alles sauber sein und ein Login dann mit dem eigenen Zertifikat problemlos klappen. Im Browser muss dann ggf. einer neue Ausnahme zustimmen, da ja auch dies ein selbstgeneriertes Zertifikat ist und die meisten Browser dafür eine Ausnhame anfordern !

Es ist sehr sinnvoll sich jetzt auf dem "Dashboard" noch das IPsec Widget zu installieren zur schnellen Übersicht.
Dies geschieht mit einem Klick auf "+" und Auswahl von "IPsec", damit man die IPsec VPN Verbindungen auch alle monitoren und damit managen kann:
ipsecwidget - Klicke auf das Bild, um es zu vergrößern

Weiter geht es jetzt mit der IPsec VPN Einrichtung für die mobilen Benutzer.

Mobiles Client IPsec VPN auf der pfSense einrichten:

Jetzt wird der eigentliche IPsec Tunnel für die mobilen Benutzer eingerichtet. Dazu sind folgende Schritte der Reihe nach zu machen:

  • Menü: VPN > IPsec -> Mobile Clients.
  • “IKE Extensions”: Haken setzen bei “Enable IPsec Mobile Client Support” 

  • “User Authentication”: Local Database anwählen (Blau markieren !) 

  • “Group Authentication”: None. 

  • “Virtual Address Pool”: Haken setzen bei “Provide a virtual IP address to clients”. ACHTUNG: Hier muss ein IP Netzwerk gewählt werden was komplett unbenutzt ist und NIRGENDWO im gesamten Netzwerk auftaucht.
 (Beispiel hier 10.98.1.0 /24)
ipsec1b - Klicke auf das Bild, um es zu vergrößern
  • Haken setzen bei: “Provide a list of accessible networks to clients". 

  • Der Rest bleibt ohne Haken (Default). Wer möchte kann die Banner Option anhaken und eine kurze Begrüßungsmessage angeben ala "Willkommen im VPN von xyz".

  • Save und dann Apply klicken

IPsec Phase 1 Konfiguration:

Nun erscheint automatisch der “Create Phase 1” Knopf den man klickt um die IPsec Phase 1 zu definieren. Wenn nicht geht man auf den Reiter "Tunnels" und klickt dort “Add P1”.
Dort dann folgende Eingaben machen:

  • “Key Exchange version”: auf IKEv2.
  • "Internet Protocol" und "Interface" belässt man auf IPv4 und WAN.
  • “Description”: "Mobiluser Phase 1" (was immer man will hier, ist nur kosmetisch).
  • “Authentication method” auf “EAP-MSChapv2
  • “My Identifier”: ‘Distinguished name’, und hier jetzt den zuvor konfigurierten Common Name oder die (statische) WAN IP angeben. ACHTUNG: Der Name MUSS zwingend mit dem "Common Name" aus dem ersten Schritt oben zur Erstellung des Server Zertfikats übereinstimmen !!
  • “Peer Identifier”: any.
  • “My Certificate”: Hier das Server Zertifikat aus dem ersten Schritt auswählen.
  • “Encryption algorithm”: “AES” und “256
  • “Hash algorithm”: SHA256
  • DH key group auf: 14 (2048 bit)
  • Lifetime auf 28800 setzen
  • MOBIKE auf enable
  • Haken entfernen: Disable Rekey
  • Haken entfernen: Disable Reauth
  • Haken setzen bei: Enable DPD, hier Delay auf 35 und Max.failures auf dem Default von 5 belassen.
  • Save und Apply klicken
ips2 - Klicke auf das Bild, um es zu vergrößern

IPsec Phase 2 Konfiguration:

Jetzt springt man in der pfSense Konfig zurück auf den "Tunnels" Reiter und sieht dort den Eintrag für “Mobile Client” den man gerade eingerichtet hat und klickt darunter den “Show Phase 2 Entries” Knopf und dann “Add P2” um die Phase 2 zu konfigurieren:

  • “Mode”: Tunnel IPv4
  • Das Local Network setzt man jetzt wie gewünscht. Normal ist immer “LAN subnet”, also das lokale LAN an der pfSense. Sollen weitere lokale Netzwerke an der pfSense (ggf. VLANs) in den Tunnel geroutet werden sie hier eingetragen.
  • ACHTUNG: Wer den gesamten Client Traffic in den Tunnel routen will setzt “Local Network” auf “Network”, und gibt 0.0.0.0 als Adresse und /0 für das Subnet ein.
  • “NAT/BINAT”: None.
  • "Description”: "Mobile Nutzer Phase 2". (was immer man will hier, ist nur kosmetisch).
  • “Protocol”: ESP
  • “Encryption Algorithms”: Hier Haken bei AES" und "256” wählen und Haken bei AES256-GCM und Auto dahinter.
  • “Hash Algorithms”: SHA256, SHA384, SHA512 anhaken.
  • “PFS Key Group”: 14(2048 bit)
  • “Lifetime”: 3600
  • “Automatically ping host”: leer lassen.
  • Save und dann Apply klicken
ipsecneu1 - Klicke auf das Bild, um es zu vergrößern

Im Überblick sehen die Phase 1 und Phase 2 Parameter dann so aus:
ipsecneu2 - Klicke auf das Bild, um es zu vergrößern

Benutzername und Passwörter für den VPN Zugriff einrichten:

  • Menü: VPN > IPsec -> Pre-Shared Keys Reiter hier “Add” klicken um einen neuen User einzurichten
  • “Identifier” ist der Benutzername fürs Login z.B. testuser
  • “Secret type”: EAP
  • “Pre-Shared Key”: Ist das Passwort für den Benutzer z.B. Geheim123. ACHTUNG: die pfSense mag auch hier keine Sonderzeichen. Also nur Ziffern und Groß- Kleinschreibung nutzen !
  • Save klicken zum sichern und ggf. für weitere User wiederholen
  • Dann “Save” und“Apply” klicken.

Firewall Regeln für IPsec einrichten

  • Menü: Firewall > Rules -> IPsec Reiter
  • Ist dort eine "allow all" Regel vorhanden ist nichts zu tun. Falls nicht...
  • “Add” klicken für eine neue Regel auf dem IPsec Interface
  • “Action”: Pass
  • “Interface”: IPsec
  • “Address Family”: IPv4
  • “Protocol”: any
  • “Source”: any
  • “Destination”: any
  • Save und Apply klicken.
ACHTUNG: Ein warnendes Wort:
Das ist erstmal eine Scheunentor Regel für den Test. Diese sollte man nachher etwas dichter ziehen auf die IP Adressen des Client und Zielnetzes und ggf. der Anwendungen (TCP/UDP Protokollports) sofern hier eine höhere Sicherheit gewünscht ist.
Die IPsec WAN Port Regeln (ESP, UDP 500 und 4500 auf die WAN IP der pfSense passieren lassen) sollte die pfSense schon automatisch eingerichtet haben aber eine Kontrolle kann nicht schaden !

Damit ist die Konfiguration der pfSense Firewall abgeschlossen und man kann jetzt mit der Einrichtung der VPN Clients auf den Endgeräten beginnen.


VPN Client mit Windows 10:

Die gute Nachricht ist, wie bereits Eingangs bemerkt, das KEIN dedizierter Software Client wie Shrew oder Greenbow usw. mehr benötigt wird um eine VPN Verbindung mit der pfSense zu etablieren !
Alles kann man mit direkt mit Windows 10 Bordmitteln und ohne jegliche zusätzliche Software erledigen. Das stellt einen erheblichen Vorteil dar gegenüber der FritzBox und anderen IPsec basierten VPN Servern die mit Windows VPN Clients, immer noch eine separate extra IPsec Clientsoftware erzwingt.
Die Installation klappt auch mit Versionen ab Windows 7 und 8, allerdings muss dort mit regedit eine Anpassungen in der Registry gemacht werden sofern man Windows und Apple iOS oder Mac OS Endgeräte gleichermaßen mit dem IPsec VPN bedienen möchte. (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters erfordert ein zusätzliches DWORD NegotiateDH2048_AES256 mit dem Wert 1)
Weiter gehts...

Zertifikat in Windows 10 importieren:

  • Jetzt kommt das exportierte Server Zertifikat in Form der .crt Datei die man oben von der pfSense exportiert hat wieder ins Spiel !
Diese wird unter Windows 10 mit dem Zertifikats Manager importiert. Smartphones usw. sendet man es z.B. ganz einfach per Email Attachment.
  • Auf dem Windows 10 Client PC die oben exportierte Zertifikats Datei <name>.crt doppelklicken und "Öffnen".
  • "Zertifikat installieren" klicken.
  • Dann "Lokale Computer" und "Weiter" auswählen und Security Abfrage mit "Ja" abnicken.
  • Jetzt "Alle Zertifikate in folgendem Speicher speichern" auswählen und "Durchsuchen" klicken
  • Hier "Vertrauenswürdige Stammzertifizierungsstellen" auswählen und mit "OK" bestätigen.
  • Dann "Weiter" klicken und Beenden mit OK. Hat alles geklappt erscheint ein "Der Importvorgang war erfolgreich" Window.
  • Fertig
Im Windows certmgr sieht das so aus:
winzert - Klicke auf das Bild, um es zu vergrößern

VPN Verbindung unter Windows 10 anlegen:

Für die Einrichtung der eigentlichen VPN Verbindung kann man sich in Windows 10 das Leben sehr erleichtern und die bordeigene Powershell dafür nutzen.
Das erspart endloses Geklicke im VPN Adapter Setup.
Dazu öffnet man einfach die Powershell mit Administratorrechten (Rechtsklick) und gibt folgende 3 Befehle ein die man hier einfach per Cut and Paste aus der Vorlage nimmt.
ACHTUNG: Bevor man das macht, sollte man das Kommando natürlich VORHER editieren ! und auf seine IP Adress Belange anpassen !
01.
Add-VpnConnection -Name "pfSense" -ServerAddress "88.1.2.3" -TunnelType IKEv2 -EncryptionLevel Required -AuthenticationMethod EAP -SplitTunneling -AllUserConnection
  • Den Parameter "-Name" kann man frei wählen und ist der Name der VPN Verbindung. Dieser Name MUSS bei den folgenden 2 Kommandos absolut identisch sein !
  • "-ServerAddress" bestimmt die WAN IP Adresse der pfSense, sprich das VPN Server Ziel. Hier kann man statt der IP Adresse natürlich auch einen Domainnamen verwenden wie z.B. meinepfsense.dyndns.org wenn man mit DynDNS arbeitet oder man einen festen DNS Hostnamen hat.
(Betreibt man die Firewall in einer Kaskade mit einem Router davor und Port Forwarding, ist natürlich die dortige Router WAN IP (oder Hostname) das Ziel !)

Das nächste Powershell Kommando setzt die IPsec Parameter:
01.
Set-VpnConnectionIPsecConfiguration -ConnectionName "pfSense" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru
und das VPN Routing noch aktivieren mit:
01.
Add-VpnConnectionRoute -ConnectionName "pfSense" -DestinationPrefix 192.168.1.0/24 -PassThru
ACHTUNG: Der Parameter "-ConnectionName" MUSS bei allen 2 Kommandos IMMER absolut identisch sein zum oben gewählten Namen der VPN Verbindung !
  • "-DestinationPrefix 192.168.1.0/24" gibt das lokale LAN Netzwerk der pfSense an. Ggf. an eigene IP Adress Nutzung anpassen.
Hier kann man mit der Subnetzmaske spielen sofern man mehrere IP Netze oder einen ganzen Bereich in den Tunnel routen will.
Z.B. routet "-DestinationPrefix 192.168.0.0/16" alle 192.168er Netze in den Tunnel und "-DestinationPrefix 10.0.0.0/8" alle 10er Netze usw.
Bei unterschiedlichen Netzen die sich nicht über die Maske zusammenfassen lassen wiederholt man das Add-VpnConnectionRoute Kommando für diese Netze.

Natürlich kann man sich das Client Setup auch im Windows Netzwerk- und Freigabecenter über die VPN Konfig zusammenklicken wer die Powershell fürchtet:
ipsecw10a - Klicke auf das Bild, um es zu vergrößern

Gesamten VPN Client Traffic in den VPN Tunnel senden:

Wer den gesamten Client Traffic von remote in den IPsec VPN Tunnel routen will um z.B. in einem öffentlichen Hotspot gesichert über seinen Heimanschluss zu surfen etc. lässt einfach den Parameter -SplitTunneling im Add-VpnConnection Kommando oben weg. Der Default Gateway Redirect ist dann Default.
Wichtig:
Man muss, wenn man so den gesamten Traffic in den Tunnel routen will, dann zusätzlich auch in der pfSense Phase 2 IPsec Konfiguration oben unter Local network "Network" wählen und eine Wildcard Route mit 0.0.0.0 /0 dort eintragen !
Damit werden dann auch für andere Clients (Smartphone, etc.) alles in den VPN Tunnel gesendet.


VPN Client mit Apple MacOS:

Ebenso wie bei Windows ist zuerst wieder die oben von der Firewall exportierte CA Zertifikatsdatei in den Mac Schlüsselbund zu importieren und als vertrauenswürdig zu markieren:
  • Dazu die .crt Datei doppelklicken zum Importieren
  • In der Schlüsselbundverwaltung das Zertifikat doppel- oder rechtsklicken und "Information" wählen.
  • Hier jetzt unter Vertrauen das Aufklappmenü öffnen und "Bei Verwendung dieses Zertifikats" die Einstellung auf Immer vertrauen setzen.
vpnmac1 - Klicke auf das Bild, um es zu vergrößern
  • Schlüsselbundverwaltung schliessen
  • Unter Apfel -> Systemeinstellungen -> Netzwerk und + das VPN mit der Funktion "IKEv2" hinzufügen:
vpnmac4 - Klicke auf das Bild, um es zu vergrößern
..und die VPN Parameter eintragen:
vpnmac3 - Klicke auf das Bild, um es zu vergrößern
Die "Entfernte ID" entspricht wieder dem Common Name des Server Zertifikats.
Lokale ID bleibt leer.
Mit Klick auf "Authentifizierungseinstellungen" konfigureirt man Username und Passwort.
Haken setzen bei "VPN-Status in der Menüleiste zeigen" so das man die VPNs bequem über die Taskleiste steuern kann.
Die Installation des Mac OS Clients ist damit abgeschlossen.


VPN Client auf iPhone und iPad (iOS) einrichten:

Das Einrichten des VPN Clients ist wie üblich bei Apple iOS eigentlich ein Selbstgänger der, Menü geführt, fast keiner Erklärung mehr bedarf.
Zuallererst muß auch hier wieder das obige Client Zertifikat importiert werden !
Das erledigt man ganz einfach indem man sich die Zertifikats Datei als Email Attachment (Email Anhang) aufs iPhone/iPad sendet. Entweder direkt oder über einen Email Account auf den man mit dem iPhone Web Browser (Safari) zugreifen kann. Als iChat Anhang geht es ebenso wie mit Airdrop.
Man klickt dann einfach auf die Zertifikatsdatei und importiert und installiert sie damit.
In der Profilansicht unter Allgemein -> Profile kann man das kontrollieren das es da auch richtig gelandet ist:
ioscert - Klicke auf das Bild, um es zu vergrößern
Der Rest ist dann schnell erledigt:
  • Auf iPhone oder iPad geht man ins Setup (Zahnrad) und wählt dort das Menü Allgemein --> VPN und fügt einen VPN Account vom Typ IKEv2 hinzu. Ganz genau so wie es oben schon bei Mac OS und Windows beschrieben würde.
  • Identisch dazu trägt man die Entfernte ID ein, die wieder dem Common Name entspricht (hier im Beispiel pfsense) und setzt die Benutzer Authentisierung auf Benutzername und Passwort mit den in der pfSense definierten Userdaten unter IPsec -> Pre Shared Keys.

ios1 - Klicke auf das Bild, um es zu vergrößern

Aktiviert man jetzt das VPN ist es sofort verbunden:
ios2 - Klicke auf das Bild, um es zu vergrößern



VPN Client auf Android Smartphones einrichten:

Die Verfügbarkeit von IKEv2 in Android-Versionen ist leider aufgrund der verschiedenen Hersteller und deren unterschiedlichen Versionen nicht so einheitlich wie bei Apple iOS und deshalb abhängig vom Hersteller des mobilen Endgerätes.
So bietet z.B. Samsung IKEv2 in vielen Android-Distributionen seiner Endgeräte an, andere Hersteller verzichten darauf und dann muss man dort doch wieder einen extra Client verwenden. Das ist der Preis den man leider bei der Android Vielfalt zahlen muss.

Sollte also kein bordeigenes IKEv2 verfügbar sein, muss eine entsprechende App verwendet werden.
Hier bietet sich als Klassiker natürlich der bekannte, kostenlose StrongSwan Client aus dem Play Store an:
https://play.google.com/store/apps/details?id=org.strongswan.android& ...
Da auch das pfSense VPN auf StrongSwan basiert klappt die Installation reibungslos und sofort auf Anhieb.
Nach der Installation der StrongSwan App muss man zuerst üblicherweise wie oben wieder die erforderliche Zertifikatsdatei installieren.
Dazu sendet man sich auch hier am einfachsten die .crt Zertifikatsdatei wieder als Email Attachment aufs Telefon wie es schon beim iPhone/iPad oben beschrieben ist.
Ein simpler Doppelklick reicht dann zur Installation.
Oder alternativ kopiert man sie auf die SD Karte oder den internen Speicher und installiert das Zertifikat von dort.
Einige Androiden geben die interne SD Karte auf dem PC als USB Stick frei oder haben eine Download App mit FTP Server oder können von Windows Freigaben (CIFS Share) kopieren. Alles geht, Hauptsache die Datei kommt irgendwie aufs Telefon oder Tablet.
Im Setup dient dann der Menüpunkt Sicherheit --> Zertifikate von SD Karte installieren zur Installation.
Hat man es erfolgreich importiert kann und sollte man das unter Sicherheit -->Vertrauenswürdige Anmeldedaten (Zertifikate ansehen) bei den Nutzer Zertifikaten kontrollieren.

andr1 - Klicke auf das Bild, um es zu vergrößern

Android VPN Client konfigurieren:

Der Einrichtung des VPNs ist dann identisch wie man es oben schon bei den anderen Clients gesehen hat und im Setup der StrongSwan App schnell erledigt.
Der folgenden Screenshot zeigt die Einstellungen:

andr2 - Klicke auf das Bild, um es zu vergrößern

Wer es etwas strikter haben will weist das Zertifikat fest zu statt der automatischen Auswahl:
andr5 - Klicke auf das Bild, um es zu vergrößern

Nach dem Einrichten kommt auch hier die VPN Verbindung sofort zustande:
andr6 - Klicke auf das Bild, um es zu vergrößern


Linux VPN Client einrichten:

Grundeinrichtung:
Die Einrichtung eines Linux Clients wird hier am Beispiel eines Raspberry Pi geschildert und gilt damit für alle Debian basierten Installationen wie Ubuntu, Mint usw.
Auch hier kommt wieder das StrongSwan IPsec zum Einsatz.
Das StrongSwan Packet installiert man mit dem folgenden Kommando:
sudo apt install strongswan libcharon-extra-plugins

Wichtig !:
Bevor man mit der Konfiguration fortfährt muss auf dem Linux Rechner das IPv4 Forwarding aktiviert sein. Ohne diese Aktivierung kann der Client kein Tunnelinterface und eine Route dahin anlegen.
Dazu editiert man die Datei /etc/sysctl.conf mit dem Editor sudo nano /etc/sysctl.conf und sucht dort nach der Zeile #net.ipv4.ip_forward=1 !
Dann entfernt man das davorliegende "#", speichert die Datei und rebootet den RasPi bzw. Linux Rechner.

StrongSwan Konfiguration:
Zuerst kopiert man, wie schon von den anderen Clients gewohnt, das oben exportierte Zertifikat der pfSense in das StrongSwan Zertifikatsverzeichnis /etc/ipsec.d/certs
Die zentrale Konfigurations Datei für den IPsec Client findet man unter /etc/ipsec.conf.
Diese hat den folgenden Inhalt:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration

config setup
	# strictcrlpolicy=yes
	# uniqueids = no

# Add connections here.
# VPN connections

conn pfsense
      keyexchange=ikev2
      right=88.1.2.3
      rightsubnet=192.168.1.0/24
      rightid=pfsense
      rightauth=pubkey
      leftsourceip=%config4
      leftcert=pfsense.crt
      leftauth=eap-mschapv2
      eap_identity=testuser
      dpdaction=restart
      auto=add

include /var/lib/strongswan/ipsec.conf.inc 
Anzupassen sind die folgenden Parameter an die eigenen Belange:
  • right = VPN WAN Ziel IP Adresse der Firewall (Hier simuliertes Internet im 88er Netz).
  • rightsubnet = Lokales LAN an der Firewall. Hat man mehrer kann man diese Komma getrennt angeben.
  • rightid = Common Name der Firewall.
  • leftcert = Dateiname des exportierten pfSense Zertifikats.
  • eap_identity = Username (Beispiel: testuser)

Als letzten Schritt editiert man die Passwort Datei /etc/ipsec.secrets und trägt dort den Usernamen und Passwort ein:
# This file holds shared secrets or RSA private keys for authentication.
include /var/lib/strongswan/ipsec.secrets.inc
user1 : EAP Geheim123 
Nun steht einem finalen Test nichts mehr im Wege.

Funktions Check:
Um die Konfigurations Datei neu einzulesen muss man den IPsec Stack neu starten was mit ipsec restart erledigt wird. Den Client startet man dann mit ipsec up <conn_name> Da die Connection hier conn "pfsense" heisst lautet das Kommando also ipsec up pfsense !
Ein Funktions- und Verbindungs Check sieht dann so aus:
root@raspberrypi:/etc# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.5.1 IPsec [starter]...
root@raspberrypi:/etc# 
--------------------------------------
root@raspberrypi:/etc# ipsec up pfsense
initiating IKE_SA pfsense[1] to 10.99.1.99
EAP method EAP_MSCHAPV2 succeeded, MSK established
authentication of 'pfsense' with EAP successful
IKE_SA pfsense[1] established between 192.168.100.159[192.168.100.159]...10.99.1.99[pfsense]
installing new virtual IP 10.111.222.2
connection 'pfsense' established successfully
(>> Output aus Platzgründen gekürzt ! <<)
root@raspberrypi:/etc# 
-------------------------------------
root@raspberrypi:/etc# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.85 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.47 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
root@raspberrypi:/etc# 
Anhand der Meldung connection 'pfsense' established successfully kann man sofort erkennen das der Tunnel sauber aufgebaut wurde.
Es liegt dann auf der Hand das ein Ping Check auf das lokale LAN Interface der pfSense Firewall (192.168.1.1) erfolgreich ist !


Damit deckt die pfSense Firewall alles an Clients und Betriebssystemen ab.
Die letzten Punkte des Tutorials beschäftigen sich mit dem Optimieren der Firewall Hardware in Bezug auf Verschlüsselung und dem Betrieb der Firewall mit einer sog. "Router Kaskade" als als kaskadiertes System hinter einem bestehenden NAT Router.


VPN Hardware der pfSense tunen:

Wer APU Boards oder aktuelle CPUs mit der pfSense nutzt sollte in jedem Falle die Hardware Unterstützung AES-NI der CPU aktivieren um die Gesamtperformance und den Durchsatz zu steigern.
Das macht man in den Miscellaneous Settings unter Cryptographic Hardware:

aesni - Klicke auf das Bild, um es zu vergrößern


Firewall hinter einem NAT Router betreiben (sog. "Router Kaskade"):

Wie im unten zitierten pfSense_Tutorial schon beschrieben, ist die technisch beste Lösung die Firewall mit dem Internet Port immer direkt mit einem "Nur" Modem an einem xDSL, TV-Kabel oder Glasfaseranschluß zu betreiben. "Nur" Modem bedeute hier KEINEN Router sondern nur ein nacktes Modem, also ein reines Layer 2 Gerät was NICHT am Layer 3 Forwarding (IP Routing) aktiv beteiligt ist wie z.B. ein vollständiger Router mit integriertem Modem wie im unten gezeigten Beispiel (Kaskade).
Letzterer wird leider hier in Foren Threads sehr oft fälschlicherweise als "Modem" bezeichnet was er technisch gar nicht ist ! Das führt leider dann sehr häufig zu Missverständnissen bei der Technik.

Die Verwendung eines reinen NUR Modems verhindert aufwändige Konfiguration mit Port Forwarding und ist aus Performance Sicht immer vorzuziehen wann immer das umsetzbar ist.
In einigen Situationen ist es allerdings nicht möglich das zu realisieren. Z.B. Nutzern von sog. Provider "Zwangsroutern" mit minderer Qualität. Ihnen bleibt dann meist nichts anderes übrig als in den sauren Apfel einer Router Kaskade zu beissen wenn man auf erhöhte Sicherheit und Schutz seines eigenen Netzes entsprechenden Wert legt.
Bei Firmenkunden ist allein aus rechtlichen Gründen diese Sicherheit immer obligatorisch, will man als Netzwerker verantwortungsvoll handeln.
Generell gesehen ist die oben im Tutorial beschreibene VPN Client Funktion zum Zugriff auf ein lokales Heim- oder Firmennetz auch immer mit einer Kaskade möglich, wenn man mit den o.g. Nachteilen leben kann oder auch muß.
Ein Kaskaden Design erfordert deshalb ein klein wenig mehr Konfigurations Aufwand insbesondere des davorliegenden Routers, hat aber immer das gleiche Resultat, nämlich den geschützten Zugriff auf lokale und private Daten.

Ein vor der Firewall kaskadierter NAT (IP Adress Translation) Router verhindert ja durch das NAT Firewalling per se erstmal den direkten Zugang der mobilen Internet VPN Clients auf die dahinterliegende Firewall. Die Firewall agiert ja im o.g. Design als VPN Server.
Der Hinderungsgrund ist, das der NAT Prozess im davor kaskadierten Router eingehende VPN Pakete dort blockiert, so das diese Pakete die Firewall erst gar nicht mehr erreichen können.
Effekt ist dann die klassische Fehlermeldung das der Server nicht erreichbar ist bzw. entspr. Fehlercode.
Die IP Adresse der Firewall im Koppelnetz oder ein DynDNS Name der darauf verweist, kann man im mobilen VPN Client nicht angeben. Klar, denn im Koppelnetz verwendet man ja in der Regel ebenfalls private_IP_Adressen nach RFC 1918 die im Internet gar nicht geroutet werden. Ein DynDNS Verweis darauf ist also sinnfrei.
Fürs Erste bleibt so die VPN Firewall also unerreichbar von außen ohne eine entsprechende Port Weiterleitungs Konfiguration.
Diese Lösung ist aber kinderleicht und schnell gemacht...

Man muss lediglich nur dafür sorgen das der davor kaskadierte Router die entsprechenden, eingehenden VPN Pakete einfach 1:1 an die VPN Firewall weiterreicht.
Das erreicht man mit der Port Forwarding oder auch Port Freigabe oder auch Port Weiterleitungs Funktion im Router !
Diese hat heutzutage jeder handelsübliche Router mit an Bord.
Diese Weiterleitungs Funktion "sagt" dem Router mit einer statischen Anweisung in der Konfiguration das bestimmte, aus dem Internet eingehende Pakete, mit entsprechenden TCP oder UDP Ports oder anderen Protokollkomponenten, einfach an eine im dahinter liegenden lokalen LAN erreichbare IP Adresse weitergeleitet werden. Diese Ziel IP Adresse für die Weiterleitung ist dann natürlich die der dahinter kaskadierten Firewall oder Router der diese VPN Pakete ja erhalten soll.
Damit ist dann die fehlerfreie VPN Funktion trotz NAT Router davor wieder gegeben. Ein Klassiker in solchen Router Kaskaden.
Viele Router biten auch die Funktion eines sog. "Exposed Hosts". Das ist dann eine IP Adresse an die im Schrotschuss Verfahren ALLES weitergeleitet wird. Da man ja zum eigentlichen Schutz die Firewall hat ist auch diese Funktion nutzbar. Sie macht die Firewall dann aber auch angreifbarer.

Im VPN Client selber muss dann natürlich die WAN / Internet IP Adresse des davorliegenden Routers als VPN Gateway Zieladresse angegeben werden ! Klar, denn dieser hält ja die öffentliche Internet IP die weltweit erreichbar ist. Auch muss hier ggf. ein DynDNS Client aktiviert werden wenn statt IP Adresse ein Hostname wie meinvpn.meindyndns.org fürs VPN verwendet wird bei wechselnder Internet IP Adresse. (z.B. Zwangstrennung)
Hat man das alles richtig gemacht, sieht ein dazu passendes Router Kaskaden Design immer so aus:

pfsense-kaskade - Klicke auf das Bild, um es zu vergrößern

Die entsprechenden Port Forwarding bzw. Weiterleitungs Einstellungen für IPsec VPN sieht man hier am Beispiel einer FritzBox die analog auch für alle anderen Router am Markt gilt:
fbipsec - Klicke auf das Bild, um es zu vergrößern

An der pfSense Firewall sollte man am WAN Port noch den Haken entfernen bei "Block private networks" denn in einem Kaskaden Design befindet sich der Firewall WAN Port ja in der Regel in einem privaten IP Adressbereich (Koppelnetz):

pfsensewan - Klicke auf das Bild, um es zu vergrößern
ACHTUNG !: Das gilt ausschliesslich nur für ein Kaskaden Design !
Arbeitet die pfSense mit einem "Nur" Modem direkt im Internet (öffentliche Provider IP direkt am WAN Port der pfSense) MUSS dieser Haken unbedingt gesetzt sein !


Diese Port Forwarding ToDos gelten ganz generell auch für andere VPN Protokolle wie...
  • OpenVPN = UDP 1194
  • L2TP = UDP 1701, UDP 500, UDP 4500, ESP Protokoll (IP50)
  • PPTP = TCP 1723, GRE Protokoll (IP47)
wenn diese Protokolle in solchen Router Kaskaden Konfigurationen verwendet werden.

Generell sollte man dem WAN Port eines hinter einem Router kaskadierten Systems, egal ob Router oder Firewall, immer eine feste statische IP Adresse geben ! Diese muss außerhalb des DHCP Bereichs des davor liegenden NAT Routers liegt ! (IP Adresskonflikt !)
Praktisch ginge auch die automatische Vergabe per DHCP. Allerdings kann es dann durch die Dynamik von DHCP IP Adressen möglich sein, das Port Forwarding Einstellungen dann irgendwann einmal ins Leere laufen wenn diese IP sich einmal ändern sollte. Dann geht das eingestellte Port Forwarding ins Nirwana sprich auf eine dann möglicherweise inexistente IP Adresse !
Alternative wäre, wenn man bei DHCP bleiben möchte, dann die statische DHCP Vergabe anhand der Layer 2 Mac Adresse (DHCP Reservierung auf Mac Basis) was dann quasi einer statischen IP entspricht. Die FritzBox und auch andere Router supportet so etwas z.B. in ihren DHCP Server Einstellungen. Damit wäre auch eine quasi "feste" Vergabe mit DHCP möglich und sinnvoll.
Auch beim Server Zertifikat oben mit Angabe der IP statt Name ist eine statische IP dann immer die bessere Lösung als DHCP.


Weiterführende Links:

Aufbau einer pfSense Firewall mit PCengines APU Minimainboard:
https://www.administrator.de/contentid/149915
Dobby's Hardware Tips:
https://www.administrator.de/wissen/pfsense-supermicro-intel-xeon-d-15x8 ...
https://www.administrator.de/link/pfsense-arm-marvell-armada-385-2nd-edi ...

Modem für Kabel-TV Provider an der pfSense:
https://www.heise.de/ct/ausgabe/2018-20-Netze-4159238.html?wt_mc=print.c ...

IPsec Praxis Tutorial: Standort Vernetzung:
https://www.administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-c ...

IPsec VPNs unterschiedlicher Hersteller:
https://www.administrator.de/wissen/ipsec-vpns-einrichten-cisco-mikrotik ...

VPN IPsec Standort Kopplung mit Cisco VTI Tunnel Interface:
https://www.administrator.de/content/detail.php?id=332230&token=14#c ...

Windows 10 VPN Powershell Syntax:
https://technet.microsoft.com/de-de/library/dn262642(v=wps.630).aspx

Automatisiertes VPN "on Demand" für iOS Apple Endgeräte über XML Templates:
https://www.administrator.de/content/detail.php?id=378502&token=736

Windows 10: Schneller VPN Aufbau per einfachem Mausklick:
https://www.heise.de/ct/ausgabe/2017-19-VPN-und-Remote-Desktop-Verbindun ...

Aktuelle IKEv2 VPN Konfig für iPhone, Mac OS und IPsec native Clients:
https://forum.pfsense.org/index.php?topic=106433.0

Client Troubleshooting:
https://administrator.de/content/detail.php?id=420788&token=78#comme ...

pfSense Firewall auf Watchguard Hardware:
https://doc.pfsense.org/index.php/PfSense_on_Watchguard_Firebox

IPsec Grundlagen und Aufbau:
https://www.administrator.de/contentid/73117

VPN Vernetzung mit GRE Tunnel und IPsec und dynamischem Routing mit OSPF auf Mikrotik Routern:
https://administrator.de/content/detail.php?id=396127&token=466#comm ...
https://administrator.de/content/detail.php?id=397059&token=646

Wer lieber OpenVPN als IPsec als VPN möchte:
https://www.administrator.de/wissen/openvpn-server-installieren-pfsense- ...

Werbung zentral im Netz blocken mit der pfSense:
https://www.administrator.de/forum/pfsense-werbung-blocken-383472.html

Gastnetz mit einem Login Portal und Einmalpasswort auf pfSense einrichten:
https://www.administrator.de/wissen/wlan-lan-gastnetz-einrichten-captive ...
https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt64/BT64_Mobile ...
39 Kommentare
Mitglied: the-buccaneer
05.09.2017 um 00:33 Uhr
Danke! Habs jetzt erst gesehen
Sollte mit Win8.1 natürlich genauso gehen. Da ich mich von der PfSense 2.2x nicht trennen kann, bleibt das für mich Zukunftsmusik...
LG
Buc
Bitte warten ..
Mitglied: Spitzbube
20.09.2017 um 20:26 Uhr
Erst mal vielen Dank für diese tolle Anleitung. Alles sehr gut und übersichtlich erklärt, aber was ist für den Fall, wenn ich hinter einem NAT Router wie der Fritzbox sitze. Muss da die Option NAT/BINAT translation nicht konfiguriert werden?
Bitte warten ..
Mitglied: aqui
21.09.2017, aktualisiert 29.09.2017
Das ist auch kein Problem !
Du musst ja nur dafür sorgen das die dann an der FritzBox eingehenden IPsec Pakete auf der IP Adresse der dahinter kaskadierten pfSense Firewall an deren WAN Port landen.
Sprich in der FritzBox muss dann wie immer bei solchen Kaskaden ein Port Forwarding für das verwendete VPN Protokoll, was hier die IPsec Protokollkomponenten sind, eingerichtet werden als da sind:
UDP 500 (IKE)
UDP 4500 (NAT Traversal)
ESP Protokoll mit der IP Nummer 50 (Achtung kein UDP oder TCP 50, ESP ist ein eigenes IP Protokoll!)
Dann funktioniert das auch in einer Kaskade fehlerlos.
Oder....man terminiert das IPsec nicht auf der Firewall sondern auf der FritzBox davor selber.
Ich nehme das mal als Anregung das Tutorial zu erweitern für so ein Kaskadendesign
<edit>Ist erledigt...</edit>
Bitte warten ..
Mitglied: Spitzbube
21.09.2017 um 11:57 Uhr
Das Tutorial zu erweitern für so ein Kaskadendesign wäre eine Spitzensache. Zumal ich das nicht nur hier sondern auch in anderen Foren immer häufiger lese.

Was ich nicht verstehe ist IP Nummer 50:

ESP Protokoll mit der IP Nummer 50 (Achtung kein UDP oder TCP 50, ESP ist ein eigenes IP Protokoll!)

-> Bei der Fritzbox hab ich halt die Möglichkeit, die Portfreigabe direkt im Heimnetzgerät (Pfsense) einzutragen oder über die Freigabe dem Netzwerkgerät das Protokoll zu zuordnen. Mehr kann ich hier nicht einstellen.
Bitte warten ..
Mitglied: aqui
21.09.2017, aktualisiert um 15:27 Uhr
Das Tutorial zu erweitern für so ein Kaskadendesign wäre eine Spitzensache.
Schon erledigt !
Was ich nicht verstehe ist IP Nummer 50:
Guckst du hier:
https://de.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload_.28ES ...
Wie alle Protokolle im IP Stack hat ESP auch eine dedizierte Protokoll Nummer, eben die 50.
Nummer 80 ist z.B. das IP Protokoll selber und 84 TCP.
Nimm einen Wireshark Sniffer und sie es dir selber schwarz auf weiß an !
Mehr kann ich hier nicht einstellen.
Das stimmt wenigstens für die FritzBox de facto nicht !
Du kannst es am obigen Screenshot im Tutorial sehen.

Hier auch nochmal am Beispiel eines PPTP VPN Protokoll dessen Protokollkomponenten in der FB ebenfalls dediziert einstellbar sind. PPTP besteht aus:
GRE IP Protokoll Nummer 47
TCP 1723

fbvpn - Klicke auf das Bild, um es zu vergrößern
Entweder redest du von was anderem oder suchst an der falschen Stelle im FB Setup ?!
Bitte warten ..
Mitglied: Spitzbube
21.09.2017 um 16:09 Uhr
Achso, das meinst du! Ja klar ESP IP Nummer 50. Nee alles gut. So hab ich das auch. Was ich nicht so habe wie bei dir in der Grafik, ist die Adressierung. Bei der Fritzbox wird mir die Pfsense als XX.XX.XX.42 angezeigt, da ich wie in anderen Beiträgen geschrieben einen Business Vertrag von Unity Media habe. Zu diesem gehören 5 feste IP Adressen. Die erste IP also XX.XX.XX.41 hat die Fritzbox automatisch vom Provider bekommen und die XX.XX.XX.42 Pfsense. Am WAN Interface der Pfsense habe ich die XX.XX.XX.42 statisch und das Upstream GW auch statisch auf XX.XX.XX.41 zugewiesen. Internet hab ich.

Werde das aber mal um konfigurieren, dann hat halt die Pfsense die 192.168.178.254 und die Fritzbox 192.168.178.1. So spare ich mir die eine statische Adresse.

Diese Aussage fand ich auch noch sehr interessant:

Im VPN Client selber muss natürlich dann die WAN / Internet IP Adresse des davorliegenden Routers als VPN Gateway Zieladresse angegeben werden oder ggf. dort ein DynDNS Client aktiviert werden wenn ein Hostname verwendet wird bei wechselnder Internet IP Adresse.

Da dachte ich immer, muss ich die IP der Pfsense eingeben und nicht die der Fritzbox.

Frage: Mit welchem Tool machst du deine Grafiken?

Werde das heute Abend mal so konfigurieren und dann nochmals berichten.

Vielen Dank für deine Mühe
Bitte warten ..
Mitglied: aqui
21.09.2017 um 17:48 Uhr
Bei der Fritzbox wird mir die Pfsense als XX.XX.XX.42 angezeigt
Wie es angezeigt wird ist erstmal völlig egal das ist kosmetisch.
Einzig wichtig ist in den Einstellungen an der FB das das Port Forwarding auf die WAN IP der pfSense zeigt die dort kaskadiert ist !
In der Kaskadenkonfig muss dann am pfSense WAN Port der Haken "Block private networks) entfernt werden.
Achtung !: Nur in einer Kaskaden Konfig NIEMALS mit einem "Nur" Modem am öffentlichen Internet.
Am WAN Interface der Pfsense habe ich die XX.XX.XX.42 statisch
OK, dann hast du ein eigenes öffentliches Subnetz. Dann kannst du den ganz Kram in einer Kaskaden Konfig natürlich vergessen. Dann hast du ja kein NAT Router davor und die öffentliche IP direkt an der pfSense.
Damit ist das ganze Kaskaden Kram für dich ja vollkommen überflüssig !
dann hat halt die Pfsense die 192.168.178.25
Häää ??? Ja was denn nun ?? Oben schreibst du die pfSense hat die öffentliche IP XX.XX.XX.42 am WAN Port ?!?
Bahnhof, ? Ägypten ?
Da dachte ich immer, muss ich die IP der Pfsense eingeben und nicht die der Fritzbox.
Nicht denken sondern mal nachdenken !!
Wie sollte das denn bitte gehen wenn die pfSense in so einer Kaskade arbeitet mit einem privaten IP Netz und somit auch privaten IP Adresse die im Internet NICHT geroutet werden ?!
Nicht nur das der VPN Client diese IP Adressen niemals im Leben erreichen könnte (...da nicht geroutet) zusätzlich könnte er auch niemals die dvorliegende NAT Firewall des Routers überwinden ohne Port Freigabe.
Doppelter grund also warum es nicht geht !
In so einem Kaskaden Design ist doch immer der davorliegende Router und dess IP Adresse der einzige Zugang zum Internet ! Logisch ! ...denn er hält ja die öffentliche IP Adresse des Providers ! Die pfSense dahinter ist ja im lokalen LAN, sprich Koppelnetz mit einer privaten nicht gerouteten RFC 1918 IP Adresse.
Folglich kann man aus dem Internet ja einzig und allein die pfSense nur über den davorliegenden Router und logischerweise dessen IP am WAN Port erreichen.
Wie sollte das deiner Meinung denn sonst anders gehen ???
Fazit: Einfach mal logisch nachdenken
Und kläre mal das Mysterium deiner unterschiedlichen WAN IP Adressierung, das versteht keiner hier...
Bitte warten ..
Mitglied: Spitzbube
21.09.2017, aktualisiert um 21:50 Uhr
Jetzt mal langsam mit der Braut

Und kläre mal das Mysterium deiner unterschiedlichen WAN IP Adressierung, das versteht keiner hier...

Hab ja nix umgestellt. Das war nur von mir falsch verstanden! Dachte, das ist bei mir kaskatiert. Aber wie du ja schreibst ist das ein eigenes öffentliches Subnetz und nicht kaskatiert!

OK, dann hast du ein eigenes öffentliches Subnetz. Dann kannst du den ganz Kram in einer Kaskaden Konfig natürlich vergessen. Dann hast du ja kein NAT Router davor und die öffentliche IP direkt an der pfSense.
Damit ist das ganze Kaskaden Kram für dich ja vollkommen überflüssig !


Aber warum sagt das IPSec Log dann: 14[IKE] <5> remote host is behind NAT? Das verstehe ich nicht!

Hab dir mal meine Settings als Anhang hochgeladen:

aktuelle Portfreigaben der Fritzbox

fritzbox_ohne - Klicke auf das Bild, um es zu vergrößern

Vorbereiten der pfSense für die Basiskonfiguration:

cas - Klicke auf das Bild, um es zu vergrößern

Server Zertifikat erstellen:

certificates - Klicke auf das Bild, um es zu vergrößern

Mobiles Client IPsec auf der pfSense einrichten:

mobile clients - Klicke auf das Bild, um es zu vergrößern

IPsec Phase 1 Konfiguration:

phase1 - Klicke auf das Bild, um es zu vergrößern

IPsec Phase 2 Konfiguration:

phase2 - Klicke auf das Bild, um es zu vergrößern

VPN Einstellungen:

tunnels - Klicke auf das Bild, um es zu vergrößern

Pre Shared Key:

pre-shared keys - Klicke auf das Bild, um es zu vergrößern


Firewall Rules:

firewall rules - Klicke auf das Bild, um es zu vergrößern

VPN Log:

01.
Sep 21 21:01:27 	charon 		14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
02.
Sep 21 21:01:27 	charon 		14[IKE] <6> received retransmit of request with ID 0, retransmitting response
03.
Sep 21 21:01:27 	charon 		14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
04.
Sep 21 21:01:27 	charon 		14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
05.
Sep 21 21:01:24 	charon 		14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
06.
Sep 21 21:01:24 	charon 		14[IKE] <6> received retransmit of request with ID 0, retransmitting response
07.
Sep 21 21:01:24 	charon 		14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
08.
Sep 21 21:01:24 	charon 		14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
09.
Sep 21 21:01:21 	charon 		14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
10.
Sep 21 21:01:21 	charon 		14[IKE] <6> received retransmit of request with ID 0, retransmitting response
11.
Sep 21 21:01:21 	charon 		14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
12.
Sep 21 21:01:21 	charon 		14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
13.
Sep 21 21:01:18 	charon 		14[NET] <6> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
14.
Sep 21 21:01:18 	charon 		14[ENC] <6> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
15.
Sep 21 21:01:18 	charon 		14[IKE] <6> sending cert request for "C=DE, ST=BW, L=GP, O=Home, E=user@gmail.com, CN=vpnca, OU=Home"
16.
Sep 21 21:01:18 	charon 		14[IKE] <6> remote host is behind NAT
17.
Sep 21 21:01:18 	charon 		14[IKE] <6> 80.187.115.140 (IP der des iPhones T-Mobile LTE) is initiating an IKE_SA
18.
Sep 21 21:01:18 	charon 		14[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
19.
Sep 21 21:01:18 	charon 		14[NET] <6> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes)
20.
Sep 21 21:01:14 	charon 		14[NET] <bypasslan|5> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[4500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[17675] (80 bytes)
21.
Sep 21 21:01:14 	charon 		14[ENC] <bypasslan|5> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
22.
Sep 21 21:01:14 	charon 		14[IKE] <bypasslan|5> peer supports MOBIKE
23.
Sep 21 21:01:14 	charon 		14[IKE] <bypasslan|5> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
24.
Sep 21 21:01:14 	charon 		14[CFG] <bypasslan|5> no alternative config found
25.
Sep 21 21:01:14 	charon 		14[IKE] <bypasslan|5> peer requested EAP, config inacceptable
26.
Sep 21 21:01:14 	charon 		14[CFG] <bypasslan|5> selected peer config 'bypasslan'
27.
Sep 21 21:01:14 	charon 		14[CFG] <5> looking for peer configs matching XX.XX.XXX.42 (IP der Pfsense)[pfsense]...80.187.115.140 (IP der des iPhones T-Mobile LTE)[10.25.123.172]
28.
Sep 21 21:01:14 	charon 		14[ENC] <5> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6 (25)) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
29.
Sep 21 21:01:14 	charon 		14[ENC] <5> unknown attribute type (25)
30.
Sep 21 21:01:14 	charon 		14[NET] <5> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[17675] to XX.XX.XXX.42 (IP der Pfsense)[4500] (496 bytes)
31.
Sep 21 21:01:14 	charon 		14[NET] <5> sending packet: from XX.XX.XXX.42 (IP der Pfsense)[500] to 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] (473 bytes)
32.
Sep 21 21:01:14 	charon 		14[ENC] <5> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
33.
Sep 21 21:01:14 	charon 		14[IKE] <5> sending cert request for "C=DE, ST=BW, L=GP, O=Home, E=user@gmail.com, CN=vpnca, OU=Home"
34.
Sep 21 21:01:14 	charon 		14[IKE] <5> remote host is behind NAT
35.
Sep 21 21:01:14 	charon 		14[IKE] <5> 80.187.115.140 (IP der des iPhones T-Mobile LTE) is initiating an IKE_SA
36.
Sep 21 21:01:14 	charon 		14[ENC] <5> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
37.
Sep 21 21:01:14 	charon 		14[NET] <5> received packet: from 80.187.115.140 (IP der des iPhones T-Mobile LTE)[500] to XX.XX.XXX.42 (IP der Pfsense)[500] (604 bytes) 
Hoffe, es ist alles soweot ersichtlich.

Grüße
Spitzbube
Bitte warten ..
Mitglied: aqui
22.09.2017 um 10:39 Uhr
Aber wie du ja schreibst ist das ein eigenes öffentliches Subnetz und nicht kaskatiert!
Warum schreibst du dann das du eine Kaskade benutzt
Zitieren tut man übrigens immer mit einer spitzen Klammer vor dem Zitat und nicht mit Doppelsternchen. Dann wird es nur fett...
Aber warum sagt das IPSec Log dann: 14[IKE] <5> remote host is behind NAT? Das verstehe ich nicht!
Mal nachdenken.... Der VPN Client nutzt NAT Traversal (UDP 4500). Dadurch erkennt der Server das NAT im Spiel ist auch wenn es das nicht ist. Kann ja aber mal sein das der Client hinter einem NAT Router ist wie im Hotel, Hotspot usw. oder einen Provider nutzt der Carrier Grade NAT macht. Das machen meist die Billig Provider mit einfachen nur Surf Accounts weil sie keine freien IPv4 Adressen mehr haben....
aktuelle Portfreigaben der Fritzbox
Wäre ja wenn du NICHT in einer Kaskade arbeitest absolut sinnfrei und auch kontraproduktiv !
Erschwerend kommt dazu das die FB selber VPN Router ist und "denkt" das eingehende IPsec ist für sie selber. Hier muss man also in der FB IPsec deaktivieren bzw. es darf keinerlei VPN Konfig vorhanden sein. Ansonsten forwardet die FB die IPsec Frames nicht und blockt sie !
Das bekommst du übrigens ganz einfach raus indem du mal einen Laptop statt der pfSense anschliesst am gleichen Port. Laptop mit gleicher IP wie die pfSense und pfSense abgezogen.
Dann startest du einen Wireshark Sniffer auf dem Laptop
Jetzt aktivierst du den VPN Client und checkst ob dort eingehende IPsec Pakete (IKE, ESP) ankommen !
Ist das der Fall klappt das Forwarding. Kommen sie nicht blockt die FB.
Ohne Wioreshark geht das auch sehr einfach mit der Paket Sniffer Funktion direkt in der pfSense unter "Diagnostics" !!
Wie gesagt...eigentlich alles sinnfrei denn du arbeitest ja eben NICHT in einer NAT Kaskade wie du selber sagst. Folglich ist dann auch Port Forwarding im Router davor sinnlos. Deine FB arbeizet dann vermutlich nur als reines Modem.
Vorbereiten der pfSense für die Basiskonfiguration:
Was ist das für ein merkwürdiges GUI ?? Farben sind nicht pfSense Default ?
Die Email Adresse ist fehlerhaft ! Aber wohl gewollt anonymisiert ?!
Sonst sieht das soweit gut aus wenn du dich explizit ans o.a. Tutorial gehalten hast.

Wenn das ein längerer "Akt" hier wird solltest du einen separaten Thread aufmachen mit einem hiesigen Verweis darauf um das Tutorial hier nicht unnötig aufzublähen.
Bitte warten ..
Mitglied: Spitzbube
24.09.2017, aktualisiert um 08:27 Uhr
Moin hab das mal in diesem Thema (Mobile Einwahl IPSec VPN von iPhone iPad T-Mobile zur Pfsense)neu zusammen gepackt.

Was ist das für ein merkwürdiges GUI ?? Farben sind nicht pfSense Default ? Nein, dass ist ein mitgeliefertes anderes Theme angenehmer für meine Augen.

Die Email Adresse ist fehlerhaft ! Aber wohl gewollt anonymisiert ?! Ja, anonymisiert!
Bitte warten ..
Mitglied: PRO4NETWORK
04.03.2018 um 19:42 Uhr
Hallo aqui,

vielen Dank für Ihre super Anleitung.
Ich habe diese entsprechende Umgesetzt und konfiguriert.

Leider stelle ich nach zwei Tagen fest, das keine VPN Einwahl mehr stattfinden kann.
Im Windows komme folgende Fehlermeldung.

"Die Netzwerkverbindung zwischen Ihrem Computer und dem VPN Server konnte nicht hergestellt werden, da der Remoteserver nicht antwortet.
Das Verbindungsproblem wird möglicherweise verursacht, weil eins der Netzwerkgeräte (zum Beispiel Firewall, NAT, Router usw.) zwischen Ihrem Computer und dem Remoteserver nicht für das Zulassen von VPN-Verbindungen konfiguriert ist."

Haben Sie da eine erklärung für.
Ich habe keine Änderungen vorgenommen, die WAN Anbindung beider Netze (pfsense / Remote) haben sich nicht geändert.
Würde mich über eine Idee der Problemlösung sehr freuen....

Vielen Dank
Bitte warten ..
Mitglied: aqui
05.03.2018, aktualisiert 26.03.2018
Der VPN Server antwortet nicht oder nicht mehr auf dort eingehende Client VPN Pakete.
Ohne weitere konkrete Tests, kann man da jetzt nur spekulieren woran das liegt, denn es gibt ja 2 Optionen:
  • Entweder die Client Pakete bleiben irgendwo hängen und es kommt gar nichts am VPN Server an
  • Es kommt was an am Server aber die Firewall blockt es
Hier wäre am Client mal ein Wireshark Trace sehr hilfreich gewesen oder am Server einmal ein Paket Trace über das Diagnostics Menü am WAN Port.
So bleibt jetzt nur spekulieren...
Bleiben wir mal bei den Standard Fehlern:
  • Von wo kommen die VPN Clients ? Falls Mobilfunk, filtert der Provider hier ggf. oder nutzt er RFC 1918 Netze mit CGN (Provider NAT) ?
  • NAT Traversal am VPN Client aktiviert ?
  • Auf der Firewall mit einer WAN Regel die Ports UDP 500, 4500 und das ESP Protokoll auf die WAN Port IP Adress der pfSense als Ziel freigegeben ?
  • Unter Diagnostics -> Packet Capture am WAN Port checken ob dort IPsec Pakete eingehen. Hier mal auf die Absender IP, ESP, UDP 500, 4500 den Traffic einschränken um nicht alles mitzusniffern.
  • WAS sagt das VPN Log der pfSense (wichtig !) ?
  • Was sagt das Log des Clients ?
Etwas mehr Detailinfos und Tests wären sehr hilfreich hier für eine zielführende Hilfe.
Bitte warten ..
Mitglied: Xplosive
28.03.2018, aktualisiert um 13:17 Uhr
Hallo aqui und der Rest ;)

danke für das tolle VPN Tutourial. Ich hab mal ne Frage zu IPTV von der Telekom und VPN:

Ist es gernell möglich, dass man quasi in einem öffentlichen WLAN sich ins VPN einloggt, um dann das IPTV der Telekom zu streamen?

Leider klappt das bei mir nicht, obwohl ich im IGMP Proxy die Adresse 10.98.1.0/24 eingetragen habe (siehe VPN > IPsec -> Mobile Clients: Virtual Adress pool) und unter Firewall -> Rules -> IPsec auch die IP-Pakete-Option bei einer "allow all" Regel aktiviert habe.

Hab ich noch etwas vergessen oder einen Denkfehler?
Lieben Dank und viele Grüße
Bitte warten ..
Mitglied: aqui
28.03.2018, aktualisiert um 13:41 Uhr
Ja, das sollte gehen. Voraussetzung dafür ist aber das der VPN Router/Firewall PIM Routing supportet. PIM muss dann auch für das virtuelle VPN Interface aktiviert sein.
Bevor du das angehst solltest du testen ob IP-TV im lokalen LAN fehlerfrei rennt ?! Ist das denn der Fall ?
Infos zu Multicast und PIM findest du hier:
https://www.youtube.com/watch?v=AvbSMBKBZgY

Ein sehr einfaches und effizentes lokales Testsetup findest du hier:
https://www.administrator.de/content/detail.php?id=362413&token=462# ...
Bitte warten ..
Mitglied: Xplosive
28.03.2018, aktualisiert um 14:50 Uhr
Hi aqui,

ja bisher rennt das IPTV im LAN fehlerfrei. Als Router kommt das apu2 Board mit der aktuellen pfsense zum Einsatz. Wird hier PIM-Routing unterstützt? Ein virtuelles Interface habe ich für VPN noch nicht. Wie wird das eingerichtet?

Grüße
Bitte warten ..
Mitglied: aqui
28.03.2018 um 14:52 Uhr
Wird das eingerichtet?
Ja, automatisch wenn du dein VPN ein richtest. Was auch immer du da machst PPTP, IPsec, OpenVPN, L2TP usw.
Das rennt dann schon so bei dir:
https://blog.tausys.de/2014/10/16/telekom-iptv-mit-pfsense/
bzw.
https://forum.pfsense.org/index.php?topic=122731.0
PIM kann die pfSense nicht aber das lässt sich mit IGMP Proxy lösen.
Praktisch hab ich das noch nicht getestet. Wäre aber mal ein Aufbau wert
Bitte warten ..
Mitglied: Xplosive
28.03.2018, aktualisiert um 15:12 Uhr
Ja die Anleitungen habe ich bei der Einrichtung auch benutzt. Wie gesagt im LAN funktioniert das IPTV. Nur eben nicht über VPN (IPSec)

Ein weiteres Downstream-Interface (auf LAN Interface) hab ich im IGMP Proxy bereits angelegt mit der Adresse 10.98.1.0/24 aus der IPSec Konfiguration (siehe VPN > IPsec -> Mobile Clients: Virtual Adress pool) Was muss ich sonst noch aktivieren?
Bitte warten ..
Mitglied: juergwin
19.08.2018 um 16:36 Uhr
danke für die super Anleitung.

ich nutze den Windows 10 VPN-Client.
Bei mir funktioniert der Verbindungsaufbau jedoch nur, wenn ich die
VPN Verbindung mittels der 3 Befehle mit PowerShell anlege.

Wenn ich die VPN-Verbindung mittels Client-Setup im Windows
Netzwerk- und Freigabecenter erstelle schlägt der Verbindungsaufbau
mit folgender Fehlermeldung fehl:
"Verbindung mit VPN-Verbindung nicht möglich
Fehler in Richtlinienübereinstimmung",

Die im Client-Setup einsehbaren Einstellungen sind für die mittels PowerShell
und für die mittels Client-Setup erstellte Verbindung identisch.

Mein Problem ist, dass ich von einem Windows 7-Client ebenfalls eine
Verbindung zur PFSense erstellen möchte. Hier ist jedoch die Erstellung
der Verbindung mittels PowerShell nicht möglich ist.

Ich habe auch deshalb eine Verbindung mittels Client-Setup erstellt und
erhalte hier beim Verbindungsaufbau folgende Fehlermeldung:
"Fehler 13801: IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel"



Gruß

Jürgen
Bitte warten ..
Mitglied: aqui
19.08.2018 um 17:51 Uhr
Windows 7 supportet m.E. kein IKEv2 oder nur mit einem Einfriff in die Registry. Deshalb schlägt die Verbindung auf einen IKEv2 VPN Server fehl. Hier musst du vermutlich den Shrew Soft Client verwenden.
Alternativ müsstest du den VPN Server mit IKEv1 aufsetzen dann rennt der Win 7 Client aber Win 10 nicht mehr denn der bordeigene Client supportet m.E. nur noch IKEv2.
Microsoft Dilemma...
Bitte warten ..
Mitglied: juergwin
20.08.2018 um 11:31 Uhr
danke für die schnelle Antwort.

Den erforderliche DWORD-Eintrag in die Registry hatte ich bereits vorgenommen.

Ich verstehe noch nicht weshalb es bei Win 10 nur bei Erstellung der Verbindung
mittels Powershell funkioniert.

Gruß

Jürgen
Bitte warten ..
Mitglied: aqui
21.08.2018, aktualisiert um 12:27 Uhr
Ich verstehe noch nicht weshalb es bei Win 10 nur bei Erstellung der Verbindung mittels Powershell funkioniert.
Das versteht wohl auch nur MS selber....oder ggf. einer der Winblows Gurus hier
Bitte warten ..
Mitglied: pipen1976
09.10.2018 um 13:32 Uhr
Vielen Dank für die Super Anleitung. Ich habe die Anleitung befolgt, bekomme aber leider bei der VPN Verbindung mit Windows 10 eine Fehlermeldung. Mit einem Android Handy und StrongSwan funktioniert es ohne Probleme. Die Fehlermeldung am Client ist:

ike authentifizierung anmeldeinformationen sind nicht akzeptabel

Der Log in der pfSense sieht so aus:

Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid d5:2e:13:c1:ab:e3:49:da:e8:b4:95:94:ef:7c:38:43:60:64:66:bd
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 59:79:12:de:61:75:d6:6f:c4:23:b7:77:13:74:c7:96:de:6f:88:72
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid d3:94:8a:4c:62:13:2a:19:2e:cc:af:72:8a:7d:36:d7:9a:1c:dc:67
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 6c:ca:bd:7d:b4:7e:94:a5:75:99:01:b6:a7:df:d4:5d:1c:09:1c:cc
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid ab:30:d3:af:4b:d8:f1:6b:58:69:ee:45:69:29:da:84:b8:73:94:88
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 42:32:b6:16:fa:04:fd:fe:5d:4b:7a:c3:fd:f7:4c:40:1d:5a:43:af
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid f0:63:ba:7c:9a:16:74:4a:9c:db:54:ec:23:cd:67:29:8e:7c:49:4d
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid a5:06:8a:78:cf:84:bd:74:32:dd:58:f9:65:eb:3a:55:e7:c7:80:dc
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid e2:7f:7b:d8:77:d5:df:9e:0a:3f:9e:b4:cb:0e:2e:a9:ef:db:69:77
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 5f:f3:24:6c:8f:91:24:af:9b:5f:3e:b0:34:6a:f4:2d:5c:a8:5d:cc
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 6d:aa:9b:09:87:c4:d0:d4:22:ed:40:07:37:4d:19:f1:91:ff:de:d3
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 83:31:7e:62:85:42:53:d6:d7:78:31:90:ec:91:90:56:e9:91:b9:e3
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 7e:95:9f:ed:82:8e:2a:ed:c3:7c:0d:05:46:31:ef:53:97:cd:48:49
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 3e:51:59:8b:a7:6f:54:5c:77:24:c5:66:eb:aa:fb:3e:2b:f3:ac:4f
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 3e:18:e5:44:f6:bd:4d:77:50:28:c9:40:3e:5c:74:f5:4c:d9:60:29
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 3e:22:d4:2c:1f:02:44:b8:04:10:65:61:7c:c7:6b:ae:da:87:29:9c
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid b1:81:08:1a:19:a4:c0:94:1f:fa:e8:95:28:c1:24:c9:9b:34:ac:c7
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 21:0f:2c:89:f7:c4:cd:5d:1b:82:5e:38:d6:c6:59:3b:a6:93:75:ae
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 23:4b:71:25:56:13:e1:30:dd:e3:42:69:c9:cc:30:d4:6f:08:41:e0
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid bb:c2:3e:29:0b:b3:28:77:1d:ad:3e:a2:4d:bd:f4:23:bd:06:b0:3d
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid b0:19:89:e7:ef:fb:4a:af:cb:14:8f:58:46:39:76:22:41:50:e1:ba
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid ee:e5:9f:1e:2a:a5:44:c3:cb:25:43:a6:9a:5b:d4:6a:25:bc:bb:8e
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 90:2f:82:a3:7c:47:97:01:1e:0f:4b:a5:af:13:13:c2:11:13:47:ea
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 22:f1:9e:2e:c6:ea:cc:fc:5d:23:46:f4:c2:e8:f6:c5:54:dd:5e:07
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 67:ec:9f:90:2d:cd:64:ae:fe:7e:bc:cd:f8:8c:51:28:f1:93:2c:12
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 17:4a:b8:2b:5f:fb:05:67:75:27:ad:49:5a:4a:5d:c4:22:cc:ea:4e
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 68:33:0e:61:35:85:21:59:29:83:a3:c8:d2:d2:e1:40:6e:7a:b3:c1
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 9c:a9:8d:00:af:74:0d:dd:81:80:d2:13:45:a5:8b:8f:2e:94:38:d6
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid 4f:9c:7d:21:79:9c:ad:0e:d8:b9:0c:57:9f:1a:02:99:e7:90:f3:87
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid da:67:aa:54:74:54:9c:0e:6f:bc:92:f2:fa:97:9a:1a:93:62:d1:13
Oct 9 13:27:32 charon 15[IKE] <16> received cert request for unknown ca with keyid ce:89:a4:e6:01:85:b1:71:4a:a7:10:db:d7:f4:7a:f3:0b:b4:cb:72
Oct 9 13:27:32 charon 15[IKE] <16> received 58 cert requests for an unknown ca
Oct 9 13:27:32 charon 15[CFG] <16> looking for peer configs matching 192.168.0.152[%any]...192.168.0.123[192.168.0.123]
Oct 9 13:27:32 charon 15[CFG] <16> candidate "bypasslan", match: 1/1/24 (me/other/ike)
Oct 9 13:27:32 charon 15[CFG] <16> candidate "con-mobile", match: 1/1/1052 (me/other/ike)
Oct 9 13:27:32 charon 15[CFG] <con-mobile|16> selected peer config 'con-mobile'
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> initiating EAP_IDENTITY method (id 0x00)
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> processing INTERNAL_IP4_ADDRESS attribute
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> processing INTERNAL_IP4_DNS attribute
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> processing INTERNAL_IP4_NBNS attribute
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> processing INTERNAL_IP4_SERVER attribute
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> peer supports MOBIKE
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> authentication of 'pfSense' (myself) with RSA signature successful
Oct 9 13:27:32 charon 15[IKE] <con-mobile|16> sending end entity cert "CN=pfSense, C=DE, ST=Bayern, L=Bodenmais, O=Weikl"
Oct 9 13:27:32 charon 15[ENC] <con-mobile|16> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Oct 9 13:27:32 charon 15[NET] <con-mobile|16> sending packet: from 192.168.0.152[4500] to 192.168.0.123[4500] (1488 bytes)
Oct 9 13:27:35 charon 12[JOB] <con-mobile|15> deleting half open IKE_SA with 192.168.0.123 after timeout
Oct 9 13:27:35 charon 12[IKE] <con-mobile|15> IKE_SA con-mobile[15] state change: CONNECTING => DESTROYING
Oct 9 13:28:02 charon 12[JOB] <con-mobile|16> deleting half open IKE_SA with 192.168.0.123 after timeout
Oct 9 13:28:02 charon 12[IKE] <con-mobile|16> IKE_SA con-mobile[16] state change: CONNECTING => DESTROYING

Hat jemand eine Idee?

Gruß Christian
Bitte warten ..
Mitglied: aqui
11.10.2018, aktualisiert 21.10.2018
Er meckert eine "unknown" CA vom Client an.
So wie es aussieht hast du vergessen auf dem Winblows 10 Rechner das mit der pfSense generierte Zertifikat einzuspielen:
https://www.administrator.de/content/detail.php?id=337198&token=414# ...
Kann das sein ??
Lösung: Zertifikat vergessen als Server Zertifikat zu deklarieren !
Bitte warten ..
Mitglied: pipen1976
11.10.2018 um 12:50 Uhr
Hallo aqui,

eigentlich ist es drin.
certmgr - Klicke auf das Bild, um es zu vergrößern

Gruß Christian
Bitte warten ..
Mitglied: 137443
11.10.2018, aktualisiert um 13:02 Uhr
Zitat von pipen1976:

Hallo aqui,

eigentlich ist es drin.
certmgr - Klicke auf das Bild, um es zu vergrößern

Gruß Christian
Ein CA-Zertifikat gehört in den ComputerStore, nicht in den des aktuellen Benutzers.

Gruß l
Bitte warten ..
Mitglied: aqui
11.10.2018, aktualisiert um 13:08 Uhr
Ja, das wird sicher der Fehler sein !!!
Siehe Tutorial: "Dann "Lokale Computer" und "Weiter" auswählen und Security Abfrage abnicken."
Denn wenn es mit Strongswan funktioniert dann ist das ein Indiz das alles richtig gemacht wurde mit dem Zertifikat, denn sonst würde das dort auch nicht klappen logischerweise.
Unbedingt dann das Zertifikat wieder aus dem Aktuellen Benutzer löschen !
Gib mal ein Feedback ob es das war...
Bitte warten ..
Mitglied: pipen1976
11.10.2018, aktualisiert um 14:06 Uhr
Genau so ist es. Das CA-Zertifikat gehört in den ComputerStore. Dannach funktioniert auch sofort die VPN Verbindung.
Wer lesen kann ist klar im Vorteil......
Vielen Dank aqui und lummel.
Bitte warten ..
Mitglied: Green14
21.10.2018 um 13:16 Uhr
Hi,

vielleicht noch ein kurzer Hinweis zu diesem Fehler. Ich hatte den auch. Mit meinem Android und StronSwan funktioniert dann deine tolle Anleitung wunderbar. Ich habe sogar 2 Verbindungen, die in unterschiedliche Netze geroutet werden hinbekommen.

Auf dem Windows 10 Client bekomme ich dann aber genau den gleichen Fehler wie pipen1976. Das Zertifikat ist unter ComputerKonto entsprechend der Anleitung hinterlegt.

Der Client gibt in der GUI IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel als Fehlermeldung aus. Im Windows-Log steht "Ursachencode" 13801.

Nach einer kurzen Google-Suche findet man folgendes:
We may check it by the following steps: On VPN server, run mmc, add snap-in “certificates”, expand certificates-personal-certificates, double click the certificate installed, click detail for “enhanced key usage”, verify if there is “server authentication” below.

Quelle: Antwort von Anne He https://social.technet.microsoft.com/Forums/ie/en-US/771bf5ec-7017-4fd3- ...

Lösung war, das das Zertifikat bei der pfsense nicht, wie in deiner Anleitung beschrieben, auf Server-Zertifikat gestellt war. (kann ja mal schnell passieren, dass man sich verklickt ;) )

VG
Green14

PS: Ich hatte auch den Fehler "Fehler 633 - das Modem (oder ein anderes Gerät) wird bereits verwendet". Lösung: https://support.microsoft.com/de-de/help/885959/error-633-the-modem-or-o ... (ist ein reines Windows-Problem). Auch wenn laut netstat nichts auf dem Port war, habe ich es eingerichtet und hatte den Fehler nicht mehr.
Bitte warten ..
Mitglied: aqui
21.10.2018, aktualisiert 23.02.2019
Danke für das Feedback !
Ich habe das Tutorial oben nochmal entsprechend angepasst und es dicker gekennzeichnet das das Zertifikat als Server Zertifikat zu deklarieren ist !
Bitte warten ..
Mitglied: pipen1976
13.11.2018 um 11:32 Uhr
Hallo,

so pfSense ist installiert. Alles funktioniert so wie es sein sollte, bis auf ein kleines DNS Problem. Wenn ich jetzt mit einem Mobilen Gerät (Notebook Win10) eine VPN Verbindung aufbaue dann habe ich ein DNS Problem. Die Netzlaufwerke sind mit DNS Namen gemappt. Das mobile Gerät kann bei Verbindung nicht richtig auflösen. Per IP Adresse ist das Laufwerk erreichbar. Das mobile Gerät bekommt ein Virtuelles Netz 10.98.1.0/24. Mein LAN hat 192.168.0.0/24. Wie bekomme ich das jetzt am elegantesten hin das bei der VPN Verbindung die Laufwerke aufgelöst werden können?

Gruß Christian
Bitte warten ..
Mitglied: aqui
16.11.2018, aktualisiert 23.02.2019
Das kommt daher das dein DNS Server vermutlich noch der ist, der am Client aktiv ist. Das ist dann ganz sicher wohl ein Internet DNS eines Providers, der logischerweise dann deine internen DNS Namen nicht kennt. Woher auch ?
Deshalb laufen die ins Nirwana und es gehen nur IPs.
Fazit:
Du musst entweder beim Dialin auf den remoten DNS mit den lokalen Namen umstellen oder...
Die Hostnamen der lokalen Rechner/Server auf die du zugreifen musst ganz einfach in die lokale hosts oder lmhosts Datei des Rechners statisch eintragen.
http://www.administrator.de/index.php?content=104978#396040
Beides fixt das "Problem" !
Bitte warten ..
Mitglied: pipen1976
20.11.2018 um 11:30 Uhr
Danke für die Lösung meines Problem´s.
Bitte warten ..
Mitglied: aqui
20.11.2018 um 13:13 Uhr
Immer gerne wieder....
Interessant (und auch hilfreich) wäre es für die Forums Community gewesen mal ein Feedback zu geben WIE du es denn nun final gelöst hast ?!
Bitte warten ..
Mitglied: Datax87
10.03.2019 um 15:41 Uhr
Hallo,

versuche mich gerade an der hier gezeigten IPSec-Konfiguration.

Bin gerade bei dem Schritt,
wo man die Phase 1 konfiguriert (ein "Proposal" für die Phase 1 festlegen).

Bei "Phase 1 Proposal (Authentication)" beim Punkt "Authentication Method" soll “EAP-MSChapv2” ausgewählt werden,
leider gibt es diesen Punkt bei mir gar nicht.

Ich nutze die aktuelle Version der "pfsense"-Firewall (Version 2.4.4 Release p1),
habe von dem genannten Problem auch einen Screenshot mit angehängt.

Bei mir sind bei "Authentication Method" lediglich die Optionen "Mutual RSA" sowie "Mutual PSK" auswählbar ^^.

Woran kann das liegen?

Ist "“EAP-MSChapv2” inzwischen aus der "pfsense"-Firewall entfernt worden (ggf. zu unsicher!?)
oder könnte ich einen Fehler bei der Konfiguration gemacht haben?
phase_1_konfiguration - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
11.03.2019, aktualisiert um 01:23 Uhr
Kann das sein das vergessen hast zuerst die Mobile Clients zu aktivieren und dort die entsprechenden Parameter zu setzen und in der Phase 1 dann oben die “Key Exchange version” vergessen hast auf IKEv2 zu setzen ??
Irgendwas hast du auf alle Fälle vergessen !
Also bitte nochmal alle Schritte in Ruhe ansehen und Schritt für Schritt abarbeiten !
Die Auswahl gibt es dort natürlich definitiv ! Guckst du hier:
ike - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: mtb931
16.03.2019, aktualisiert um 18:37 Uhr
Erst einmal ein dickes Dankeschön für die detaillierten Tutorials zur pfsense. Ich bin Netzwerkanfänger und hoffe dass Ihr mich nicht gleich zerreist.
Die pfSens Firewall habe ich aqui's Tutorial erfolgreich eingerichtet.
Das VPN Tutorial hier habe ich mehrmals einschließlich auch der Kommentare von pipen1976, der ein auf den ersten Blick ähnlich gelagertes Problem hatte, durchgearbeitet. Leider ohne Erfolg. Nun brauche ich glaube ich Eure Hilfe.

Problem:
Keine VPN-Verbindung mit WIN 10 - Fehlermeldung IKE-Authentifizierung - Anmeldeinformationen sind nicht akzeptabel / ABER VPN-Verbindung über Androidgeräte Strong Swan Client und identischem Zertifikat funktioniert perfekt

System:
pfsense 2.4.4 rel p2 als Kaskade hinter fritzbox 7490, Client WIN10 1803

Mit meinem laienhaften Verständnis meine ich aus dem IPSEC Log (siehe unten) der pfsense zu erkennen, dass es am Zertifikat hängt.

Das Zertifikat wurde unter LokalerComputer installiert:
k-zertifikat in compustore - Klicke auf das Bild, um es zu vergrößern


Die alternativen DNS Namen habe ich gem. Anleitung versucht einzutragen (durchgestrichen ist Adresse unter der die Fritzbox von außen erreichbar ist):
k-zertifikat_02 - Klicke auf das Bild, um es zu vergrößern

k-zertifikat_01 - Klicke auf das Bild, um es zu vergrößern

pfSense Name:
k-pfsense_name - Klicke auf das Bild, um es zu vergrößern

Zertifikat in der pfsense aktiv:
k-pfsense_certificate - Klicke auf das Bild, um es zu vergrößern

Die VPN Verbindung wurde wie hier in der Anleitung beschrieben mit der powershell ohne splittunneling eingerichtet.

Hat von Euch jemand eine Idee was ich bei der WIN10 VPN Konfiguration falsch mache ?

pfsense Log:
Mar 16 10:34:09 charon 12[NET] <con-mobile|33> sending packet: from 10.19.8.254[4500] to xxx [24198] (484 bytes)
Mar 16 10:34:09 charon 12[NET] <con-mobile|33> sending packet: from 10.19.8.254[4500] to xxx [24198] (1236 bytes)
Mar 16 10:34:09 charon 12[ENC] <con-mobile|33> generating IKE_AUTH response 1 [ EF(2/2) ]
Mar 16 10:34:09 charon 12[ENC] <con-mobile|33> generating IKE_AUTH response 1 [ EF(1/2) ]
Mar 16 10:34:09 charon 12[ENC] <con-mobile|33> splitting IKE message (1648 bytes) into 2 fragments
Mar 16 10:34:09 charon 12[ENC] <con-mobile|33> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> sending end entity cert "CN=pfsense, C=GE, ST=Germany, L=Ingolstadt, O=mm, OU=m"
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> authentication of 'pfsense' (myself) with RSA signature successful
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> peer supports MOBIKE
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP6_SERVER attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP6_DNS attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP6_ADDRESS attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP4_SERVER attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP4_NBNS attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP4_DNS attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> processing INTERNAL_IP4_ADDRESS attribute
Mar 16 10:34:09 charon 12[IKE] <con-mobile|33> initiating EAP_IDENTITY method (id 0x00)
Mar 16 10:34:09 charon 12[CFG] <con-mobile|33> selected peer config 'con-mobile'
Mar 16 10:34:09 charon 12[CFG] <33> candidate "con-mobile", match: 1/1/1052 (me/other/ike)
Mar 16 10:34:09 charon 12[CFG] <33> candidate "bypasslan", match: 1/1/24 (me/other/ike)
Mar 16 10:34:09 charon 12[CFG] <33> looking for peer configs matching 10.19.8.254[%any]...xxx [192.168.43.71]
Mar 16 10:34:09 charon 12[IKE] <33> received 51 cert requests for an unknown ca
...
5c:b8:69:fe:8d:ef:c1:ed:66:27:ee:b2:12:0f:72:1b:b8:0a:0e:04
Mar 16 10:34:09 charon 12[IKE] <33> received cert request for unknown ca with keyid 4a:5c:75:22:aa:46:bf:a4:08:9d:39:97:4e:bd:b4:a3:60:f7:a0:1d
Mar 16 10:34:09 charon 12[IKE] <33> received cert request for "CN=pfsense, C=GE, ST=Germany, L=Ingolstadt, O=mm, OU=m"
...
Mar 16 10:34:09 charon 12[IKE] <33> received cert request for unknown ca with keyid 87:c1:62:a6:79:1e:bb:b9:37:a8:fe:4e:2f:35:0e:ff:00:4b:eb:e0
Mar 16 10:34:09 charon 12[ENC] <33> parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
Mar 16 10:34:09 charon 12[ENC] <33> received fragment #3 of 3, reassembled fragmented IKE message (1344 bytes)
Mar 16 10:34:09 charon 12[ENC] <33> parsed IKE_AUTH request 1 [ EF(3/3) ]
Mar 16 10:34:09 charon 12[NET] <33> received packet: from xxx [24198] to 10.19.8.254[4500] (356 bytes)
Mar 16 10:34:09 charon 12[ENC] <33> received fragment #2 of 3, waiting for complete IKE message
Mar 16 10:34:09 charon 12[ENC] <33> parsed IKE_AUTH request 1 [ EF(2/3) ]
Mar 16 10:34:09 charon 12[NET] <33> received packet: from xxx [24198] to 10.19.8.254[4500] (580 bytes)
Mar 16 10:34:09 charon 12[ENC] <33> received fragment #1 of 3, waiting for complete IKE message
Mar 16 10:34:09 charon 12[ENC] <33> parsed IKE_AUTH request 1 [ EF(1/3) ]
Mar 16 10:34:09 charon 12[NET] <33> received packet: from xxx [24198] to 10.19.8.254[4500] (580 bytes)
Mar 16 10:34:09 charon 16[JOB] next event in 19s 998ms, waiting
Mar 16 10:34:09 charon 16[JOB] next event in 19s 998ms, waiting
Mar 16 10:34:09 charon 12[NET] <33> sending packet: from 10.19.8.254[500] to xxx [12513] (473 bytes)
Mar 16 10:34:09 charon 12[ENC] <33> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Mar 16 10:34:09 charon 12[IKE] <33> sending cert request for "C=GE, ST=Germany, L=Ingolstadt, O=mm, E=m-my@online.de, CN=vpnca, OU=m"
Mar 16 10:34:09 charon 16[JOB] next event in 19s 999ms, waiting
Mar 16 10:34:09 charon 16[JOB] next event in 19s 999ms, waiting
Mar 16 10:34:09 charon 12[IKE] <33> remote host is behind NAT
Mar 16 10:34:09 charon 12[IKE] <33> local host is behind NAT, sending keep alives
Mar 16 10:34:08 charon 12[CFG] <33> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Mar 16 10:34:08 charon 12[CFG] <33> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Mar 16 10:34:08 charon 12[CFG] <33> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Mar 16 10:34:08 charon 12[CFG] <33> proposal matches
Mar 16 10:34:08 charon 12[CFG] <33> selecting proposal:
Mar 16 10:34:08 charon 12[IKE] <33> IKE_SA (unnamed)[33] state change: CREATED => CONNECTING
Mar 16 10:34:08 charon 12[IKE] <33> xxx is initiating an IKE_SA
Mar 16 10:34:08 charon 12[ENC] <33> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
Mar 16 10:34:08 charon 12[IKE] <33> received Vid-Initial-Contact vendor ID
Mar 16 10:34:08 charon 12[IKE] <33> received MS-Negotiation Discovery Capable vendor ID
Mar 16 10:34:08 charon 12[IKE] <33> received MS NT5 ISAKMPOAKLEY v9 vendor ID
Mar 16 10:34:08 charon 12[CFG] <33> found matching ike config: 10.19.8.254...%any with prio 1052
Mar 16 10:34:08 charon 12[CFG] <33> candidate: 10.19.8.254...%any, prio 1052
Mar 16 10:34:08 charon 12[CFG] <33> candidate: %any...%any, prio 24
Mar 16 10:34:08 charon 12[CFG] <33> looking for an IKEv2 config for 10.19.8.254...xxx
Mar 16 10:34:08 charon 12[ENC] <33> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
Mar 16 10:34:08 charon 12[NET] <33> received packet: from xxx [12513] to 10.19.8.254[500] (544 bytes)
k-zertifikat_01 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
16.03.2019, aktualisiert um 15:52 Uhr
Ich bin Netzwerkanfänger und hoffe dass Ihr mich nicht gleich zerreist.
Keine Sorge, alles gut
Keine VPN-Verbindung mit WIN 10 - Fehlermeldung IKE-Authentifizierung - Anmeldeinformationen sind nicht akzeptabel
Das ist die typische Fehlermeldung wenn du das exportierte Zertifikat nicht oder nicht richtig in Windows mit dem Cert Manager importiert hast !! Oder generell bei der Erstellung ein Fehler gemacht wurde.
Genau dann kommt diese Fehlermeldung !
Möglich auch das du das Zertifikat vor der Umstellung auf ein eigenes exportiert hast und dann ein neues erstellt hast und vergessen hast das neue zu importieren oder vergessen hast das alte importierte zu löschen !
Das ist sehr wichtig sonst kommt der Win Client ins Straucheln und quittiert das mit dieser Fehlermeldung !
Beachtet man das, klappt es fehlerlos...!
meine ich aus dem IPSEC Log (siehe unten) der pfsense zu erkennen, dass es am Zertifikat hängt.
So ist es !!
Und zwar ist deine CA unbekannt ! Irgend etwas ist also mit der Erstellung oder dem Export bzw. Import des Zertifikats schiefgelaufen. DA solltest du nochmal ansetzen.
Vermutlich wie oben das du mal das Zertifikat gewechselt hast oder sowas....
Lösche das importierte Zertifikat nochmal komplett raus aus Windows und exportiere und importiere es neu.
Das sollte das Problem fixen.
mit der powershell ohne splittunneling eingerichtet.
Dann mit einem Gateway Redirect so das sämtlicher Traffic in den Tunnel geroutet wird ?? Oder wie ist das zu verstehen.
So oder so hast du ein Problem mit dem Zertifikat was du erstmal fixen musst !

(P.S.: Editiere bitte mal das obige Posting und lösche die ganzen "received cert request for unknown ca with keyid " Zeilen bis auf 2oder 3 weg. Es reicht wenn man das einmal sieht. Nur um das Tutorial hier nicht unnötig aufzublähen ! Ggf. auch etwas anonymisieren http://www.utrace.de/?query=109.41.194.92 )
Bitte warten ..
Mitglied: mtb931
16.03.2019 um 22:45 Uhr
Danke für's Verständnis. Log hab ich gekürzt und etwas anonymisiert.
Um sicher zugehen habe ich das Zertifikat in WIN mit der certmgr gelöscht. In der pfsense das Zertifikat unter "certivicates" und die CA unter "CAs" gelöscht und nach Anleitung noch einmal erstellt.
Unter "CAs" wie beschrieben den Export der .crt durchgeführt und in WIN importiert - Lokaler Computer - das neue Zertifikat steht jetzt wie im Bild der Anleitung drin.
Phase 1 angepasst - das neu erstellte Server-Zertifikat ausgewählt.
VPN Verbindung wie beschrieben mit Powershell erstellt.

Ergebnis:
Die Android Geräte mit Strong Swan funktionieren erwartungsgem. nach dem Wechsel auf das neue Zertifikat einwandfrei.
WIN10 --> Fehlermeldung - ungültiges Aufkommen erhalten

Im pfsense LOG gibt es immer noch die die "received cert request for unknown ca" Zeilen, welche auf ein Problem mit dem Zertifikat hindeuten.
Danach hat sich aber etwas verändert - ich gehe jedoch davon aus, dass es mit dem Zertifikat immer noch nicht passt.
Bin etwas ratlos.
LOG pfsense:
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> lease 172.19.8.1 by 'vpnuser' went offline
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> IKE_SA con-mobile[1] state change: DELETING => DESTROYING
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (80 bytes)
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> generating INFORMATIONAL response 6 [ ]
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> IKE_SA deleted
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> IKE_SA con-mobile[1] state change: ESTABLISHED => DELETING
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> deleting IKE_SA con-mobile[1] between 10.19.8.254[pfsense]...xxx[192.168.43.71]
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> received DELETE for IKE_SA con-mobile[1]
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> parsed INFORMATIONAL request 6 [ D ]
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> received packet: from xxx[26163] to 10.19.8.254[4500] (80 bytes)
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (256 bytes)
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR SUBNET U_BANNER) N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(NO_PROP) ]
Mar 16 21:10:25 charon 13[CHD] <con-mobile|1> CHILD_SA con-mobile{1} state change: CREATED => DESTROYING
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> failed to establish CHILD_SA, keeping IKE_SA
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> no acceptable proposal found
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> configured proposals: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_8_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_8_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_8_256/MODP_2048/NO_EXT_SEQ
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> no acceptable ENCRYPTION_ALGORITHM found
...
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> no acceptable ENCRYPTION_ALGORITHM found
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> selecting proposal:
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> found matching child config "con-mobile" with prio 12
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> candidate "con-mobile" with prio 10+2
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> 172.19.8.1/32|/0
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> proposing traffic selectors for other:
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> 0.0.0.0/0|/0
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> proposing traffic selectors for us:
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> looking for a child config for 0.0.0.0/0|/0 ::/0|/0 === 0.0.0.0/0|/0 ::/0|/0
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> building UNITY_BANNER attribute
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> building INTERNAL_IP4_SUBNET attribute
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> no virtual IP found for %any6 requested by 'vpnuser'
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> peer requested virtual IP %any6
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> assigning virtual IP 172.19.8.1 to peer 'vpnuser'
Mar 16 21:10:25 charon 13[CFG] <con-mobile|1> assigning new lease to 'vpnuser'
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> peer requested virtual IP %any
Mar 16 21:10:25 charon 02[JOB] next event in 19s 646ms, waiting
Mar 16 21:10:25 charon 02[JOB] next event in 19s 646ms, waiting
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> maximum IKE_SA lifetime 28745s
Mar 16 21:10:25 charon 02[JOB] next event in 19s 646ms, waiting
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> scheduling reauthentication in 28205s
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> IKE_SA con-mobile[1] state change: CONNECTING => ESTABLISHED
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> IKE_SA con-mobile[1] established between 10.19.8.254[pfsense]...xxx[192.168.43.71]
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> authentication of 'pfsense' (myself) with EAP
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> authentication of '192.168.43.71' with EAP successful
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> parsed IKE_AUTH request 5 [ AUTH ]
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> received packet: from xxx[26163] to 10.19.8.254[4500] (112 bytes)
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (80 bytes)
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> generating IKE_AUTH response 4 [ EAP/SUCC ]
Mar 16 21:10:25 charon 13[IKE] <con-mobile|1> EAP method EAP_MSCHAPV2 succeeded, MSK established
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> received packet: from xxx[26163] to 10.19.8.254[4500] (80 bytes)
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (144 bytes)
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Mar 16 21:10:25 charon 13[ENC] <con-mobile|1> parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Mar 16 21:10:25 charon 13[NET] <con-mobile|1> received packet: from xxx[26163] to 10.19.8.254[4500] (144 bytes)
Mar 16 21:10:25 charon 11[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (112 bytes)
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> initiating EAP_MSCHAPV2 method (id 0xEC)
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> received EAP identity 'vpnuser'
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Mar 16 21:10:25 charon 11[NET] <con-mobile|1> received packet: from xxx[26163] to 10.19.8.254[4500] (96 bytes)
Mar 16 21:10:25 charon 11[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (276 bytes)
Mar 16 21:10:25 charon 11[NET] <con-mobile|1> sending packet: from 10.19.8.254[4500] to xxx[26163] (1236 bytes)
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> generating IKE_AUTH response 1 [ EF(2/2) ]
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> generating IKE_AUTH response 1 [ EF(1/2) ]
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> splitting IKE message (1440 bytes) into 2 fragments
Mar 16 21:10:25 charon 11[ENC] <con-mobile|1> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> sending end entity cert "CN=pfsense, C=DE, L=Ingolstadt"
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> authentication of 'pfsense' (myself) with RSA signature successful
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> peer supports MOBIKE
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP6_SERVER attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP6_DNS attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP6_ADDRESS attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP4_SERVER attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP4_NBNS attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP4_DNS attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> processing INTERNAL_IP4_ADDRESS attribute
Mar 16 21:10:25 charon 11[IKE] <con-mobile|1> initiating EAP_IDENTITY method (id 0x00)
Mar 16 21:10:25 charon 11[CFG] <con-mobile|1> selected peer config 'con-mobile'
Mar 16 21:10:25 charon 11[CFG] <1> candidate "con-mobile", match: 1/1/1052 (me/other/ike)
Mar 16 21:10:25 charon 11[CFG] <1> candidate "bypasslan", match: 1/1/24 (me/other/ike)
Mar 16 21:10:25 charon 11[CFG] <1> looking for peer configs matching 10.19.8.254[%any]...xxx[192.168.43.71]
Mar 16 21:10:25 charon 11[IKE] <1> received 52 cert requests for an unknown ca
Bitte warten ..
Mitglied: aqui
16.03.2019, aktualisiert um 23:05 Uhr
Das Tutorial hatte nach einem kosmetischen Update noch ein paar Fehler. Die sind aber mit neuen Bildern und Text jetzt korrigiert.
Habe das eben auf 2 verschiedenen pfSense HW Plattformen und jeweils 4 Clients aller Betriebssysteme nochmal getestet.
Funktioniert absolut fehlerlfrei. Der Fehler liegt irgendwo in deinem Zertifikat.
Im Zweifel löschst du die CA nochmal komplett und erstellst die neu. Die IPsec VPN Konfig musst du nicht ändern.
Bitte warten ..
Ähnliche Inhalte
Netzwerke

IPsec VPN Praxis mit Standort Kopplung zw. Cisco, IPCop, pfSense, FritzBox und mehr

Anleitung von aquiNetzwerke20 Kommentare

Allgemeine Einleitung Das folgende Tutorial ist eine Erweiterung des hier bei Administrator.de schon bestehenden IPsec_VPN_Grundlagen_Tutorials und soll in loser ...

Router & Routing

Routed IPsec in pfSense 2.4.4

Tipp von C.R.S.Router & Routing1 Kommentar

Sehr schöne Möglichkeit in pfSense, die ich bislang ganz übersehen hatte: Hat das schon jemand im Einsatz, z.B. für ...

Router & Routing

PfSense Routing durch VPN-Tunnel

Tipp von FA-jkaRouter & Routing2 Kommentare

Ich hatte vorhin das Problem, dass eine pfSense keine Route auf einen OpenVPN-Client setzen kann. In der Sense war ...

Router & Routing

VPN hinter Fritzboxen - neue Erkenntnisse

Tipp von HenereRouter & Routing16 Kommentare

Hallo, vielleicht interessiert es ja den einen oder anderen. Jedenfalls strotzt das Netz nur voller "Geheimtipps" wie man ein ...

Neue Wissensbeiträge
Windows Server
Windows Backup - FilterManager Event 3
Tipp von NixVerstehen vor 2 StundenWindows Server

Hallo zusammen, ich bin kein gelernter ITler und auch beruflich nicht in dem Feld tätig. Wir setzen in unserem ...

Windows 10

Windows 10 - Programme laufen schneller, wenn Sie mit Administratorrechten ausgeführt werden

Erfahrungsbericht von 1Werner1 vor 1 TagWindows 1011 Kommentare

Moin, das wollte ich erst nicht glauben, aber es ist so. Wenn Ihr ein Programm mit Administratorrechten unter Windows ...

Sicherheits-Tools
Putty hat heftige Bugs korrigiert!
Information von Lochkartenstanzer vor 2 TagenSicherheits-Tools8 Kommentare

Moin, Wie man aus herauslesen kann, sind in den Versionen vor 0.71 gravierende Bugs, die es angeraten erscheinen lassen, ...

Off Topic
Sachen die die Welt nicht braucht - Platz 1
Tipp von brammer vor 5 TagenOff Topic21 Kommentare

Hallo, ich habs als Tipp angelegt als Erfahrungsbericht nein Danke brammer

Heiß diskutierte Inhalte
Hardware
Telefonanlagen - Welche gibt es
Frage von Xaero1982Hardware26 Kommentare

Nabend Zusammen, ich suche eine neue TK Anlage und mein Auftraggeber will jetzt was völlig neues - State of ...

Outlook & Mail
Office 365 mit Email-Profil installieren
Frage von Carat2121Outlook & Mail18 Kommentare

Hallo, kurz zu meiner Person: Vor ungefahr 10 Jahren habe ich eine Umschuldung zum Fachinformatiker für Systemintegration gemacht aber ...

LAN, WAN, Wireless
Intel(R) PRO Wireless 3945ABG
gelöst Frage von Leon509LAN, WAN, Wireless15 Kommentare

Hallo, habe ein Laptop Fujitsu (Intel, 4GB, 2GHz, Windos10, Intel(R) PRO/Wireless 3945ABG ) ein O2 DSL Anschluss Home50. Leider ...

Microsoft Office
Excel Such- und Vergleichsfunktion
gelöst Frage von oesi1989Microsoft Office15 Kommentare

Hallo zusammen, ich habe 2 Tabellen mit Name, Vorname und Arbeitgeber. 1. Tabelle Name Vorname Geb-Datum Arbeitgeber Straße Ort ...