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

Mitglied: aqui

back-to-topAllgemeine Einleitung


Das folgende Tutorial beschreibt die VPN Anbindung von mobilen Benutzern oder Homeoffice Nutzern 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.
Der VPN Zugang erfolgt vollständig mit den bordeigenen VPN Clients auf den Endgeräten und OHNE extra Installation von VPN Client Zusatzsoftware.
Entsprechende Hardware bieten diverse Händler an bzw. ist hier im Forum mit einem eigenen_Tutorial beschrieben.
Das Tutorial 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 Firewall 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, Tablet 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.
OPNsense Nutzer finden die Screenshots zu den folgenden Konfig Schritten HIER
Los gehts....


back-to-topVorbereiten 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 solch ein entsprechendes Zertifikat.
Man-in-the-Middle Attacken sicher auszuschließen bedingt bei IKEv2, dass sich das VPN-Gateway vorab mit einer RSA-Signatur und einem vertrauenswürdigen X.509-Zertifikat ausweisen muss. Es dient also dazu das VPN wirklich sicher zu machen.
Aus naheliegenden Gründen sollte niemals das per Default installierte (US) Zertifikat der pfSense oder OPNsense verwendet werden !
Zur Sicherheit ist also immer ein eigenes Zertifikat 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 der CA. Man kann ihn frei wählen z.B. pfSense CA. Hier gilt es keine Leer- und Sonderzeichen zu verwenden. Binde- und Unterstrich sind erlaubt.
  • Method: "Create an internal Certificate Authority"

  • Key length: 2048

  • Digest Algorithm: sha256
  • Lifetime: Gültigkeitszeit in Tagen wählen (z.B. 3 Jahre = 1095)
  • Den Rest füllt man entsprechend seiner Daten aus, Ländercode etc. Der Inhalt ist nicht wichtig für die Funktion
  • "Common Name”: MUSS ein eindeutiger Name sein z.B. pfsense-ca . Der Common Name sollte identisch zum Descriptive Name oben sein. Es kann auch ein Domain Name sein.
  • Länder Code und Standort spezifische Eintragungen entsprechend dein eigenen Vorgaben ergänzen. (ist optional)
  • Save klicken zum Sichern

back-to-topServer 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. "pfSense SRV".
  • 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. Die Lifetime wie in Schritt 1 auf den dort definierten Wert 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 bereits eingegeben wurden.
  • Common und Alternative Names: Hier nimmt man den pfSense Hostnamen im DNS wie er als Hostnamen angezeigt wird, die WAN IP Adresse (geht nur wenn diese statisch ist !) oder einen dediziert Text String. Dieser Punkt ist extrem wichtig für den Onboard Windows 10 IKEv2 VPN Client, denn dieser prüft das Zertifikat darauf ! Hat man nur einen Common Name eingegeben und connected mit der IP Adresse verweigert der Windows 10 Client die VPN Verbindung ! Mac OS, iOS oder StrongSwan sind da erheblich toleranter. Der folgende Konfig Schritt deckt alle 3 Optionen ab, so das man immer auf Nummer sicher geht das es später auch mit wirklich allen Clients verlässlich klappt:
  • “Common Name”: Der Hostname dieser pfSense Firewall wie im General Setup oder im DNS Setting als Hostname konfiguriert mit Domain Suffix, also z.B. "pfsense.meine.domain") Achtung: Auch ein Unterschied in der Groß- Kleinschreibung führt zu einem Fehler ! Eine genaue Kontrolle zahlt sich also später aus !
setupname
Bzw. im Dashboard unter "System Information"
certneu2
  • Unter Alternative Names jetzt “Add” klicken, “FQDN or Hostname” auswählen und nochmals den als Common Name gesetzten Hostnamen der pfSense eingeben 
wie oben mit Domain Suffix. (z.B. "pfsense.meine.domain")
  • Nochmals “Add” klicken, “FQDN or Hostname” auswählen und den FQDN Hostnamen jetzt ohne Domain Suffix eingeben. (z.B. "pfsense")
  • Hilfreich aber optional bei einigen Win 10 Installationen ist auch noch zusätzlich die "kurze" Variante ohne den Root Suffix z.B. "pfsense.meinedomain" hinzuzufügen.
  • Wer mit DynDNS Namen am WAN Port der pfSense arbeitet gibt zusätzlich mit FQDN Hostnamen auf den DynDNS Hostnamen der pfSense hier an. Z.B. "meinepfsense.dnshome.de" (Hier im Beispiel durch 0a630163.nip.io (10.99.1.99) symbolisiert)
  • (Optional) Nochmals “Add” klicken, “IP Adress” auswählen und die WAN IP Adresse eingeben sofern eine feste, statische IP vorhanden ist. Achtung: Ohne feste Internet IP am pfSense WAN Port entfällt dieser Schritt !! In einem Router Kaskaden Setup, wie weiter unten beschrieben, setzt man hier die statische WAN IP der pfSense ein.)
certsrv
  • Save zum Sichern klicken.
Ein Klick auf das Info "i" des Server Zertifikats sollte diese SAN Namen dann anzeigen.
certneu

back-to-toppfSense CA Zertifikat für VPN Clients exportieren


Zum Schluss muss noch das CA Zertifikat für die Installation bei den Clients exportiert werden :
  • Menü: System > Cert Manager und dort den CA 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 Zertifikats 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 weiter unten im Verlauf der Einrichtung der diversen VPN Clients.

Damit ist die Zertifikatserstellung auf der Firewall abgeschlossen...

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

pfssl
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" was anzeigt das es nun löschbar ist.
Nach einem Reboot sollte dann alles sauber sein und ein Login dann mit dem eigenen Zertifikat problemlos klappen. Im Browser muss man dann ggf. einer neuen Ausnahme zustimmen, da ja auch dies ein selbstgeneriertes Zertifikat ist und die meisten Browser dafür eine Ausnahme anfordern !

Es ist sehr sinnvoll und hilfreich 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

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


back-to-topMobiles Client VPN auf der pfSense einrichten


In diesem Schritt wird der eigentliche IPsec IKEv2 Tunnel für die mobilen Benutzer eingerichtet. Dazu sind folgende Punkte der Reihe nach einzugeben:

  • 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 sonst im gesamten Netzwerk auftaucht ! Auch nicht in VM Umgebungen usw. (Beispiel hier 10.98.1.0 /24).
ipsec1b
  • Haken setzen bei: “Provide a list of accessible networks to clients". 

  • Wer einen lokalen DNS Server (z.B. Windows DNS) an die Clients senden will um lokale DNS Namen auflösen zu können setzt hier den entsprechenden Haken und trägt die Server IP ein.
dns
  • Der Rest bleibt ohne Haken (Default).
  • Save und dann Apply klicken

back-to-topIPsec 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 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 zuvor erstellte Server Zertifikat aus dem ersten Schritt auswählen.
  • “Encryption algorithm”: “AES” und “256
  • “Hash algorithm”: SHA256
  • DH key group auf: 2 (1024 bit) (Windows 10 macht im Default nur DH Group 2 ! (Ggf. mit Power Shell anpassen wer mehr will))
  • 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
p1_neu
pfmob2

back-to-topIPsec 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, dann werden sie hier eingetragen. (Bsp: 192.168.0.0 /16 routet alle 192.168er Netze in den VPN Tunnel)
  • 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”: SHA1, SHA256, SHA384, SHA512 anhaken.
  • “PFS Key Group”: 2(1024 bit)
  • “Lifetime”: 3600
  • “Automatically ping host”: leer lassen.
  • Save und dann Apply klicken
p2_neu

Im Überblick sehen die Phase 1 und Phase 2 Parameter dann so aus:
ipsec_neu1

back-to-topBenutzername und Passwörter für den VPN Zugriff einrichten


  • Menü: VPN > IPsec -> Pre-Shared Keys Reiter wählen. Hier “Add” (Hinzufügen) klicken um einen neuen VPN Benutzer mit Usernamen und Passswort 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 !
  • Optionale Felder leer lassen
  • Save klicken zum sichern und ggf. für weitere Benutzernamen wiederholen
  • Dann “Save” und“Apply” klicken

back-to-topFirewall 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 Testbetrieb. Diese sollte man nachher etwas dichter ziehen auf die IP Adressen des Clients und Zielnetzes und ggf. der Anwendungen (TCP/UDP Protokollports) sofern hier eine höhere Zugangskontrolle für den VPN Zugang gewünscht ist.

Die IPsec WAN Port Regeln (ESP, UDP 500 und UDP 4500 für den Zugriff auf die WAN IP Adresse der pfSense passieren lassen) sollte die pfSense schon automatisch eingerichtet haben aber eine Kontrolle kann wie immer nicht schaden !

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

back-to-topVPN 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 oder OPNsense zu etablieren !! :-) face-smile
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 Rechnern, immer noch eine separate, extra zu installierende IPsec Clientsoftware erzwingt. Dies entfällt hier.
Die Installation klappt auch mit älteren Windows 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 parallel zusammen mit dem IPsec VPN bedienen möchte. (iOS und Mac lässt aus Sicherheitsgründen nur noch AES 256 zu) (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters erfordert ein zusätzliches DWORD NegotiateDH2048_AES256 mit dem Wert 1)

back-to-topZertifikat in Windows 10 importieren


  • Jetzt kommt das oben exportierte Server Zertifikat in Form der .crt Datei wieder ins Spiel ! Dieser Schritt ist sehr wichtig. Wird er vergessen kann der Client den VPN Tunnel nicht aufbauen ! Diese Zertifikats Datei 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 kopieren und <name>.crt doppelklicken und "Öffnen".
  • "Zertifikat installieren" klicken.
  • Dann "Lokaler Computer" und "Weiter" auswählen und die 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 Fenster: "Der Importvorgang war erfolgreich".
  • Fertig...
Im Windows certmgr sieht das so aus:
winzert

back-to-topVPN Verbindung unter Windows 10 anlegen


Der Client wird ganz normal über das Windows Netzwerk Setup -> VPN hinzugefügt:
winpf

back-to-topVPN Verbindung automatisieren per Script


Für mehr Bedienungskomfort kann man z.B. den VPN Aufruf in ein einfaches .bat Skript verpacken und per Doppelklick ausführen:

back-to-topVPN Verbindung unter Windows 10 mit Power Shell anpassen


Bei Bedarf kann man mit der Power Shell die IPsec Phase 1 oder Phase 2 Standard Parameter des Clients anpassen sofern stärkere Verschlüsseltung gewünscht ist. Windows Default nutzt z.B. nur DH Group 2. Hier kann man mit der Powershell nacharbeiten und DH Group 14 aktivieren.
Analog MUSS das aber dann oben immer auch in den IPsec P1 und P2 Settings der Firewall angepasst werden.
Das Folgende ist also nicht zwingend und nur gedacht für dijenigen die die Verschlüsselung anpassen möchten. Die Windows Default Einstellungen gelten derzeit als sicher.

Dazu öffnet man mit einem Rechtsklick a.d. Powershell Icon die Powershell mit Administratorrechten oder als Administrator ausführen 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 mit dem Text Editor oder Notepad++ editieren ! und auf seine persönlichen IP Adress Belange anpassen !
  • Den Parameter "-Name" kann man frei wählen. Es ist der Name der VPN Verbindung wie er in der Auswahl erscheint. Dieser gewählte Name MUSS bei den 2 folgenden Kommandos unter ConnectionName absolut identisch sein !
  • "-ServerAddress" bestimmt die WAN IP Adresse oder Hostname (DynDNS) 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 (siehe Kapitel "Router-Kaskade" unten), ist natürlich die dortige Router WAN IP Adresse (oder Hostname) das Ziel !)

Das nächste Powershell Kommando setzt z.B. die IPsec Schlüssel Parameter:
Die Abfrage zum Ändern beantwortet man mit "Ja" und überprüft nochmals die Parameter:
psoutput
Last but not least das letzte Win10 PS Kommando um das VPN Routing zu aktivieren mit:
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 bzw. muss man mit der Subnetzmaske spielen sofern man mehrere IP Netze oder einen ganzen Bereich oder auch alles in den Tunnel routen will.
Z.B. routet "-DestinationPrefix 192.168.0.0/16" alle 192.168er Netze in den VPN 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 alle diese Netze.

Wer die Powershell fürchtet kann natürlich das VPN Client Setup auch im Windows Netzwerk- und Freigabecenter über die VPN Konfig zusammenklicken wie oben schon beschrieben:
ipsecw10a

Den VPN Login Usernamen und Passwort kann man unter Windows 10 speichern damit man ihn nicht immer neu eingeben muss:
win10user

Noch eleganter ist es natürlich statt eines separaten VPN Users gleich den lokalen Usernamen des Windows Logons zu verwenden:
ikeuserlogin

Ändern sich diese Daten kann man sie im Setup unter Netzwerk und Internet nach Auswahl der VPN Verbindung in den erweiterten Optionen auch wieder löschen und neu setzen.

back-to-topGesamten 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 schlicht und einfach den Parameter -SplitTunneling im Add-VpnConnection Kommando oben weg oder trägt ihn explizit als false ein (-SplitTunneling --> -SplitTunneling:False). Siehe dazu auch HIER.
Der Default Gateway Redirect ist dann Default und sämtlicher Traffic geht in den VPN Tunnel.

WICHTIG!:
Man muss, wenn man so den gesamten Datenverkehr 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.
Desweiteren ist auf der pfSense in der Mobile Client Konfig noch ein Haken zu setzen wenn man kein Split Tunneling sondern den gesamten Client Netzwerk Traffic in den Tunnel routen will.
In der Phase 1 unter Mobile Clients ist das der Haken bei "Netzwerk-Liste >>x<< Liste mit zugänglichen Netzwerken dem Gerät zur Verfügung stellen" aktivieren:
dgw
Damit geht dann der gesamte Client Verkehr in den VPN Tunnel.
Der Thread_Hinweis des Kollegen @justas unten in den weiterführenden Links hat weitere Infos dazu.


back-to-topVPN 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
  • Schlüsselbundverwaltung schliessen
  • Unter Apfel -> Systemeinstellungen -> Netzwerk und + das VPN mit der Funktion "IKEv2" hinzufügen:
vpnmac4
..und die VPN Parameter eintragen:
vpnmac3
Die "Entfernte ID" entspricht wieder dem Common Name des Server Zertifikats.
Lokale ID bleibt leer.
Mit Klick auf "Authentifizierungseinstellungen" konfiguriert man abschliessend 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.

back-to-topVPN 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
(Der Menüpunkt Allgemein -> Profile erscheint nur wenn mindestens ein Profil (Zertifikat) importiert wurde !)
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

Aktiviert man jetzt das VPN ist es sofort verbunden:
ios2
Ein sehr hilfreiches Tool bzw. App um die Verbindung ins remote Netz zu testen (Ping etc.) sind die kostenlosen HE-Tools aus dem Apple App Store.


back-to-topVPN 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 wiederum 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.
Empfehlenswert ist VPNcilla was auch bei FritzBox VPNs eine gute Figur macht, allerdings ist es kostenpflichtig.
Als kostenfreie Alternative bietet sich als Klassiker natürlich der bekannte 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. Zudem nutzt auch die weiter unten beschriebene Linux Variante StrongSwan.
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 so erfolgreich importiert, kann und sollte man das unter Sicherheit -->Vertrauenswürdige Anmeldedaten (Zertifikate ansehen) bei den Nutzer Zertifikaten kontrollieren.

andr1

back-to-topAndroid VPN Client konfigurieren


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

andr2

Wer es etwas strikter haben will weist das Zertifikat fest zu statt der automatischen Auswahl:
andr5

Nach dem Einrichten kommt auch hier die VPN Verbindung sofort zustande:
andr6
Auch hier helfen wieder die kostenlosen HE-Tools aus dem Google Play Store um die Verbindung ins remote Netz zu testen (Ping etc.)

Soll das VPN permanent aktiv sein auf das Zielnetz, also quasi ein "allways on", kann man das im StrongSwan Client entsprechend einstellen:
immervpn


back-to-topLinux VPN Client einrichten


Am einfachsten klappt die Linux Client Einrichtung über das grafische GUI Management des Network Managers wie z.B. bei Ubuntu:
https://docs.opnsense.org/manual/how-tos/ipsec-rw-linux.html

Ohne GUI macht man es über das klassische Setup mit dem Strongswan Package.

Grundeinrichtung:
Die Einrichtung eines Linux Clients wird hier am Beispiel eines Raspberry Pi geschildert und gilt damit grundsätzlich für alle Debian basierten Installationen wie Ubuntu, Mint usw. als auch für alle anderen Distributionen wie Red Hat, CentOS, SuSE, Feodora usw. Natürlich ist sie auch auf "großen" Rechnern identisch zur RasPi Konfig.
Auch hier kommt wieder das StrongSwan IPsec Package zum Einsatz was in allen Linux Distributionen enthalten ist.
Das StrongSwan Packet installiert man aus der Package Verwaltung (Debian) mit dem folgenden Kommando:
sudo apt install strongswan libstrongswan-extra-plugins libcharon-extra-plugins

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

StrongSwan Konfiguration:
Zuerst kopiert man, wie schon von den anderen Clients gewohnt, z.B. mit WinSCP oder per USB Stick das oben exportierte CA Zertifikat der pfSense in das StrongSwan Zertifikatsverzeichnis /etc/ipsec.d/certs
Die zentrale Konfigurations Datei für den StrongSwan IPsec Client findet man unter /etc/ipsec.conf.
Diese Konfig Datei ist eine simple Text Datei und hat den folgenden Inhalt, bzw. passt man auf diesen mit dem nano Editor an.
(Die u.a. Beispiel Konfig geht davon aus, das das lokale LAN an der pfSense 192.168.1.0 /24 ist und die erreichbare WAN IP 88.1.2.3. Dies muss ggf. entsprechend angepasst werden wenn man eine andere, eigene IP Adressierungen verwendet !):
Anzupassen sind die folgenden Parameter der Datei an die eigenen IP Adressierungs Einstellungen und benutzen IP Netzwerke:
  • right = VPN WAN/Internet Ziel IP Adresse oder Host Name der Firewall (Hier im Beispiel: simuliertes Internet im 88er Netz).
  • rightsubnet = Lokales LAN an der pfSense Firewall. Hat man mehrere, kann man diese Komma getrennt angeben.
(rightsubnet 0.0.0.0/0 nur dann konfigurieren wenn alles in den Tunnel soll (Gateway Redirect, Dank an @Ricky99 in den weiterführenden Links))
  • rightid = Common Name der Firewall.
  • leftcert = Dateiname des exportierten pfSense Zertifikats.
  • eap_identity = Username (Beispiel: testuser)

Als letzten Schritt editiert man die User / Passwort Datei /etc/ipsec.secrets und trägt dort den Usernamen und Passwort ein:
Fertig... !
Nun steht einem finalen Test des Linux Clients nichts mehr im Wege.

Funktions Check:
Um die Konfigurations Datei neu einzulesen muss man den IPsec Stack neu starten was mit ipsec restart auf der Kommandozeile (Terminal) erledigt wird. Den Client startet man dann mit ipsec up <conn_name> Da die Connection hier in der Konfig Datei conn "pfsense" heisst lautet das Kommando also ipsec up pfsense !
Ein Funktions- und Verbindungs Check sieht dann so aus:
Anhand der Meldung connection 'pfsense' established successfully kann man sofort erkennen das der VPN 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 und OPNsense Firewall alles an onboard VPN Clients auf allen gängigen Betriebssystemen ab. Ein großer Vorteil wie auch bei der L2TP_Variante die vom zusätzlichen Handling und Management externer VPN Clients befreit.

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". Also als kaskadiertes System hinter einem bestehenden NAT Router.


back-to-topVPN 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


back-to-topFirewall hinter einem NAT Router betreiben (sog. "Router Kaskade")


Wie im unten zitierten pfSense_Tutorial schon beschrieben, ist die technisch beste Lösung die Firewall an deren WAN/Internet Port immer direkt mit einem "NUR" Modem an einem xDSL, TV-Kabel oder Glasfaseranschluß zu betreiben.
"Nur" Modem bedeutet in diesem Kontext ein reines, 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 zu sehen (Kaskade).
Das Internet wird so direkt und performant an der Firewall terminiert und nicht am davor liegenden NAT Router, der quasi dann nur Performance fressender "Durchlauferhitzer" ist.
Klassische Consumer NAT Router werden hier in Foren Threads leider sehr oft fälschlicherweise als "Modem" bezeichnet was so ein Router technisch gar nicht ist ! Dieser Umstand führt dann sehr häufig zu Missverständnissen bei der Technik und Troubleshooting Threads im hiesigen Forum.

Reine Modems für den xDSL Bereich mit denen man nichts falsch macht sind die folgenden:
VDSL/ADSL Hybrid Modems:
https://www.draytek.de/vigor165.html
https://www.zyxel.com/de/de/products_services/vmg3006modem/
https://www.reichelt.de/vdsl2-modem-zte-h186-p254352.html
https://www.reichelt.de/vdsl2-adsl-modem-annex-b-und-j-allnet-allbm200v- ...
(FritzBox als Modem) https://www.heise.de/select/ct/2020/2/1578238295698254
Reine ADSL2+ Modems:
https://www.reichelt.de/adsl2-ethernet-modem-annex-b-und-j-d-link-dsl321 ...
https://www.reichelt.de/adsl2-ethernet-modem-annex-b-und-j-allnet-all033 ...
TV Kabel Modems:
https://shop.wernerelectronic.de/antennen-und-kabelfernsehtechnik/catv-m ...
https://www.heise.de/tests/Schnelles-Kabelmodem-fuer-DOCSIS-3-1-4241602. ...
https://shop.wernerelectronic.de/antennen-und-kabelfernsehtechnik/kabelm ...

Oft lassen sich auch vorhandene Telekom Speedport Router im reinem Modem Betrieb nutzen inkl. dem Tagging bei VDSL:
speedpomodem

Die Verwendung eines reinen NUR Modems verhindert gerade im VPN Umfeld aufwändige Konfigurationen mit Port Forwarding und ist aus Performance Sicht immer vorzuziehen wenn immer das umsetzbar ist.

back-to-topLösung mit Router Kaskade


In einigen Situationen ist es allerdings nicht möglich so ein Setup zu realisieren. Z.B. Nutzer die trotz EU weiter freier Routerwahl sog. Provider "Zwangsroutern" mit minderer Qualität und Performance betreiben müssen.
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 dieses Designs leben kann oder auch muß.
Ein Kaskaden Design erfordert deshalb ein klein wenig mehr Konfigurations Aufwand, insbesondere des davorliegenden Routers.

Ein vor der Firewall kaskadierter NAT Router (IP Adress Translation) verhindert durch das NAT Firewalling erst einmal per se den direkten Zugang der mobilen Internet VPN Clients auf die dahinterliegende Firewall. Nur die Firewall agiert hier im Kaskaden Design als VPN Server.
Der Hinderungsgrund ist, das der NAT Prozess im davor kaskadierten Router generell aus dem Internet eingehende IP Pakete blockiert, so das diese Pakete die Firewall erst gar nicht mehr erreichen können. Ein gewollter Schutzeffekt, aber nachteilig für den VPN Zugang, denn die VPN Pakete werden natürlich dort ebenso geblockt.
Effekt ist dann die klassische Log Fehlermeldung "Timeout..." das der VPN Server nicht erreichbar ist. Klassisches Tagesgeschäft hier beim VPN Troubleshooting im Forum... ;-) face-wink
Die WAN Port IP Adresse der Firewall im Koppelnetz oder ein DynDNS Name der darauf verweist, kann man im mobilen VPN Client nicht als Ziel 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 auf solch eine IP Adresse ist also sinnfrei da unroutebar.
Fürs Erste bleibt so die VPN Firewall mit dem davor liegenden Router von außen also erstmal unerreichbar 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, aus dem Internet eingehenden VPN Pakete, einfach 1:1 an die dahinter liegende VPN Firewall (WAN Port) "durchreicht".
Das erreicht man mit der Funktion Port Forwarding/Weiterleitung oder auch Port Freigabe in Router oder Firewall !
Diese Funktion hat heutzutage ausnahmslos jeder handelsübliche Internet Router mit an Bord.
Die 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 lokale LAN IP Adresse weitergeleitet werden sollen statt sie zu verwerfen.
Diese Ziel IP Adresse für die Weiterleitung ist in einer Kaskaden Anordnung natürlich dann die dahinter kaskadierte Firewall oder auch Router der diese aus dem Internet weitergeleiteten VPN Pakete ja erhalten sollen.
Damit ist dann die fehlerfreie VPN Funktion, trotz blockierendem NAT Router davor, wieder gegeben. Ein simpler Klassiker in solchen Router Kaskaden.
Viele Router bieten auch die Funktion eines sog. "Exposed Hosts".
Das ist eine lokale 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 insgesamt angreifbarer weil man so alles an eingehenden Traffic forwardet statt nur die Dinge die man von außen auch wirklich durchlassen möchte.

Im mobilen VPN Client selber muss dann natürlich immer die WAN / Internet IP Adresse des VOR der Firewall liegenden Routers als VPN Gateway Zieladresse angegeben werden ! Klar, denn dieser hält ja die öffentliche Internet IP die weltweit erreichbar ist.
Wenn der Provider wechselnde Internet IP Adressen verwendet. (z.B. Zwangstrennung usw.) muss entsprechend hier ggf. ein DynDNS Client aktiviert werden wenn statt IP Adresse ein fester Hostname wie meinvpn.meindyndns.de fürs VPN verwendet wird. Mit einem festen DynDNS Hostnamen erreicht man so auch immer eine wechselnde IP an Router oder Firewall.
Hat man das alles richtig gemacht, sieht ein dazu passendes Router Kaskaden Design immer so aus:

pfsense-kaskade


Die entsprechenden Port Forwarding bzw. Weiterleitungs Einstellungen für IPsec VPN zeigt das nächste Bild am Beispiel einer FritzBox. Dies analog auch für alle anderen Router am Markt gilt:
fbipsec

back-to-topFirewall WAN Port Regel anpassen (nur Kaskade !)


An der Firewall muss man in Kaskaden Designs am WAN Port immer den Haken entfernen bei "Block private networks" denn in einem Kaskaden Design befindet sich der Firewall WAN Port ja in der Regel immer in einem privaten _IP_Adressbereich (LAN Koppelnetz) des davor liegenden Routers. IP Pakete die der vorgelagerte Router weiterleitet würden ansonsten geblockt und verworfen, sollte diese Firewall Blocking Regel der privaten IPs aktiv sein.

wan1918

ACHTUNG !:
Das Entfernen gilt ausschliesslich NUR für ein Kaskaden Design (pfSense/OPNsense hinter NAT Router) !
Arbeitet die Firewall mit einem "NUR" Modem oder ganz ohne Modem direkt im öffentlichen Internet (öffentliche Provider IP direkt am WAN Port der Firewall !) MUSS dieser Haken unbedingt gesetzt bleiben und darf keinesfalls entfernt werden !


Die Port Forwarding ToDos für häufig genutzte VPN Protokolle hier nochmals in einer Übersicht:
  • IPsec = UDP 500, UDP 4500, ESP Protokoll (IP50)
  • OpenVPN = UDP 1194 (Default Port, ist beliebig konfigurierbar)
  • L2TP = UDP 1701, UDP 500, UDP 4500, ESP Protokoll (IP50)
  • PPTP = TCP 1723, GRE Protokoll (IP47)
  • SSTP = TCP 443
  • WireGuard = UDP 51820 (Default Port, ist beliebig konfigurierbar)
...sofern diese VPN Protokolle in solchen Router Kaskaden Konfigurationen im Port Forwarding verwendet werden.

Bei der FritzBox und anderen aktiven VPN Routern sollte man unbedingt beachten das die VPN Nutzung für eingerichtete User deaktiviert werden muss. (Siehe dazu auch HIER).
Geschieht das nicht, reicht die FritzBox die IPsec VPN Ports nicht per Port Forwarding weiter, da sie ja selber auch aktiver VPN Router ist.

Generell ist es Best Practice dem WAN Port eines hinter einem Router kaskadierten Systems, egal ob Router oder Firewall, immer eine feste, statische IP Adresse zu geben !
Diese IP Adresse muss immer außerhalb des LAN Port DHCP Bereichs des davor liegenden NAT Routers liegen ! Andernfalls droht ein 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 sich diese IP einmal ändern sollte ! Freie DHCP Vergabe birgt also immer die latente Gefahr das deshalb das VPN über kurz oder lang nicht mehr funktioniert.
Dann geht das vorab eingestellte Port Forwarding natürlich ins Nirwana, sprich auf eine dann möglicherweise inexistente IP Adresse !

Eine gute Alternative, wenn man bei DHCP bleiben möchte, wäre dann immer die statische DHCP Vergabe anhand der Hardware Layer 2 Mac Adresse (DHCP Reservierung auf Mac Basis) zu realisieren.
Das entspricht dann quasi einer statischen IP Adresse, da die DHCP IP immer fest auf Basis der Hardware Adresse des Gerätes (Mac Adresse) zugewiesen wird.
Die FritzBox und auch andere Consumer oder Profi Router supporten so eine feste Reservierung in ihren DHCP Server Einstellungen. Man trägt dann einfach die Geräte spezifische Hardware Adresse (Mac Adresse) des kaskadierten WAN Ports im DHCP Server ein und weist dieser damit immer eine feste IP Adresse zu.
Mit diesem "Trick" ist eine quasi "feste" IP Vergabe auch mit DHCP möglich und auch sinnvoll.
(AVM beschreibt die ToDo's dafür HIER).
Als generelles Beispiel sähe es z.B. auf einem Router internen DHCP Server so aus:

fbdhcp
(Hier im Beispiel teilt der DHCP Server auf dem Router einem Gerät mit der Mac Adresse 00:C0:EB:85:4D:DA immer fest die IP Adresse 192.168.178.254 zu)
Oder hier bei einem anderen Router Modell
dhcp-mac
(Hier im Beispiel teilt der DHCP Server auf dem Router einem Gerät mit der Mac Adresse 00:43:5A:3F:01:22 immer fest die IP Adresse 192.168.8.173 zu)

Die Hardware- oder Mac Adresse eines Endgerätes ist entweder auf einem externen Aufkleber zu erkennen oder über das interne Setup. Bei einem Windows Rechner z.B. mit dem Kommando ipconfig -all oder bei Linux und Mac Rechnern mit ifconfig.
Auch beim Server Zertifikat oben ist die Angabe dieser festen IP statt eines Namens technisch die bessere Lösung.


back-to-topWeiterführende Links zum Tutorial


Originale Anleitung in der NetGate Doku und Forum:
https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-cl ...
https://forum.netgate.com/topic/113227/ikev2-vpn-for-windows-10-and-osx- ...
Dito. für OPNsense Variante:
https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-mschapv2.html

Seriellen Terminal Anschluss der pfSense richtig handhaben:
https://administrator.de/content/detail.php?id=620563&token=523#comm ...

Aufbau einer pfSense Firewall mit PCengines APU Mini Mainboard:
https://www.administrator.de/contentid/149915
Weitere Hardware:
https://www.varia-store.com/de/produkt/36843-pc-engines-apu2e4-bundle-bo ...
https://www.amazon.de/HUNSN-Firewall-Mikrotik-Security-Appliance/dp/B07D ...
https://www.amazon.de/HUNSN-Firewall-Mikrotik-Rackmount-Appliance/dp/B07 ...
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 ...

Reine NUR xDSL Modems für pfSense/OPNsense:
https://administrator.de/content/detail.php?id=291077&token=52
https://administrator.de/content/detail.php?id=983417183#comment-1049325 ...

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

FritzBox 7412 als preiswertes VDSL "nur" Modem für pfSense/OPNsense:
https://www.spiegel.de/netzwelt/gadgets/fritzbox-7412-als-dsl-modem-dect ...
https://www.heise.de/select/ct/2020/2/1578238295698254

DNS Forwarding (Name Server) auf der pfSense richtig einstellen !:
https://administrator.de/forum/pfsense-web-de-aktiver-scheunentor-regel- ...

Verlässlicher Speedtest auf der pfSense:
https://www.andysblog.de/pfsense-wan-geschwindigkeit-direkt-am-router-me ...
https://github.com/sivel/speedtest-cli

pfSense OPNsense auf VmWare ESXi 6 und 7:
https://administrator.de/content/detail.php?id=639239&nid=1030243#co ...
https://administrator.de/forum/sophos-software-appliance-utm-vlan-cisco- ...
https://administrator.de/contentid/1072629127

DS-Lite Anschluss und VPN: Lösung mit VPS Vermittlungsserver und fester IP:
https://administrator.de/forum/zwei-mobilfunkrouter-tp-link-mr200-vpn-ve ...
https://administrator.de/tutorial/feste-ips-zuhause-in-pfsense-via-wireg ...
https://administrator.de/tutorial/feste-ips-zuhause-pfsense-tunnel-56761 ...
NAT Tücken bei remotem Port Forwarding in den VPN Tunnel beachten !!:
https://administrator.de/contentid/1161214871#comment-1280687176

https://administrator.de/tutorial/feste-ips-zuhause-pfsense-tunnel-56761 ...
https://administrator.de/tutorial/feste-ips-zuhause-in-pfsense-via-wireg ...

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

Mehrere lokale und remote IP Netze für den VPN Client erreichbar machen:
https://administrator.de/content/detail.php?id=559328&token=338#comm ...

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

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

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

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

FritzBox Port Forwarding in remote IP Netze:
https://administrator.de/content/detail.php?id=327703&token=860#comm ...


back-to-topWeiterführende Links zum Thema VPN Vernetzung


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

pfSense L2TP VPN für alle onboard VPN Clients::
https://administrator.de/wissen/pfsense-opnsense-client-vpn-l2tp-protoko ...

Mikrotik L2TP VPN für alle onboard VPN Clients:
https://administrator.de/content/detail.php?id=562927&token=111#comm ...

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 ...

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

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

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

FritzBox Port Forwarding auf fremde IPs hinter kaskadiertem Router ohne NAT:
https://administrator.de/content/detail.php?id=327703&token=860#comm ...

IPv6 mit FritzBox Router Kaskade auf pfSense:
https://www.altmetaller.de/ipv6-pfsense-hinter-fritzbox-6360-kabel-deuts ...

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

Glasfaser VLAN 7 Tagging am WAN Port pfSense:
https://www.heise.de/ct/artikel/pfSense-als-VDSL-Router-221500.html?seit ...

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 ...

Beachten wenn zu IPsec noch Proxy Dienste wie Squid etc. aktiv sind !:
https://administrator.de/content/detail.php?id=529949&token=469

Wer statt IPsec lieber OpenVPN als VPN möchte:
https://www.administrator.de/wissen/openvpn-server-installieren-pfsense- ...
https://administrator.de/tutorial/merkzettel-vpn-installation-openvpn-56 ...

L2TP VPN mit Linux StrongSwan:
https://administrator.de/content/detail.php?id=665167&token=647#comm ...

IP-TV (Magenta TV) auf pfSense und OPNsense:
https://www.heise.de/ct/artikel/MagentaTV-auf-pfSense-Co-4698826.html
https://administrator.de/content/detail.php?id=595937&token=206
https://administrator.de/forum/ipv6-fuer-bestimmte-domain-od-geraet-umge ...

AdGuard DNS Filter auf pfSense/OPNsense installieren:
https://broadbandforum.co/t/205884/

Content-Key: 337198

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

Ausgedruckt am: 19.10.2021 um 14:10 Uhr

Mitglied: the-buccaneer
the-buccaneer 05.09.2017 um 00:33:00 Uhr
Goto Top
Danke! Habs jetzt erst gesehen ;-) face-wink
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
Mitglied: Spitzbube
Spitzbube 20.09.2017 um 20:26:04 Uhr
Goto Top
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?
Mitglied: aqui
aqui 21.09.2017, aktualisiert am 29.09.2017 um 10:58:16 Uhr
Goto Top
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 ;-) face-wink
<edit>Ist erledigt...</edit>
Mitglied: Spitzbube
Spitzbube 21.09.2017 um 11:57:04 Uhr
Goto Top
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.
Mitglied: aqui
aqui 21.09.2017 aktualisiert um 15:27:34 Uhr
Goto Top
Das Tutorial zu erweitern für so ein Kaskadendesign wäre eine Spitzensache.
Schon erledigt ! :-D face-big-smile
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 ! ;-) face-wink
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
Entweder redest du von was anderem oder suchst an der falschen Stelle im FB Setup ?!
Mitglied: Spitzbube
Spitzbube 21.09.2017 um 16:09:57 Uhr
Goto Top
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 :) face-smile
Mitglied: aqui
aqui 21.09.2017 um 17:48:57 Uhr
Goto Top
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 ;-) face-wink
Und kläre mal das Mysterium deiner unterschiedlichen WAN IP Adressierung, das versteht keiner hier... :-( face-sad
Mitglied: Spitzbube
Spitzbube 21.09.2017 aktualisiert um 21:50:31 Uhr
Goto Top
Jetzt mal langsam mit der Braut :) face-smile

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

Vorbereiten der pfSense für die Basiskonfiguration:

cas

Server Zertifikat erstellen:

certificates

Mobiles Client IPsec auf der pfSense einrichten:

mobile clients

IPsec Phase 1 Konfiguration:

phase1

IPsec Phase 2 Konfiguration:

phase2

VPN Einstellungen:

tunnels

Pre Shared Key:

pre-shared keys


Firewall Rules:

firewall rules

VPN Log:


Hoffe, es ist alles soweot ersichtlich.

Grüße
Spitzbube
Mitglied: aqui
aqui 22.09.2017 um 10:39:35 Uhr
Goto Top
Aber wie du ja schreibst ist das ein eigenes öffentliches Subnetz und nicht kaskatiert!
Warum schreibst du dann das du eine Kaskade benutzt :-( face-sad
Zitieren tut man übrigens immer mit einer spitzen Klammer vor dem Zitat und nicht mit Doppelsternchen. Dann wird es nur fett... :-( face-sad
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.
Mitglied: Spitzbube
Spitzbube 24.09.2017 aktualisiert um 08:27:27 Uhr
Goto Top
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!
Mitglied: PRO4NETWORK
PRO4NETWORK 04.03.2018 um 19:42:12 Uhr
Goto Top
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
Mitglied: aqui
aqui 05.03.2018, aktualisiert am 26.03.2018 um 11:19:21 Uhr
Goto Top
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... :-( face-sad
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.
Mitglied: Xplosive
Xplosive 28.03.2018 aktualisiert um 13:17:13 Uhr
Goto Top
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
Mitglied: aqui
aqui 28.03.2018 aktualisiert um 13:41:08 Uhr
Goto Top
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# ...
Mitglied: Xplosive
Xplosive 28.03.2018 aktualisiert um 14:50:22 Uhr
Goto Top
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
Mitglied: aqui
aqui 28.03.2018 um 14:52:51 Uhr
Goto Top
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 ;-) face-wink
Mitglied: Xplosive
Xplosive 28.03.2018 aktualisiert um 15:12:16 Uhr
Goto Top
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?
Mitglied: juergwin
juergwin 19.08.2018 um 16:36:20 Uhr
Goto Top
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
Mitglied: aqui
aqui 19.08.2018 um 17:51:21 Uhr
Goto Top
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... :-( face-sad
Mitglied: juergwin
juergwin 20.08.2018 um 11:31:08 Uhr
Goto Top
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
Mitglied: aqui
aqui 21.08.2018 aktualisiert um 12:27:43 Uhr
Goto Top
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 ;-) face-wink
Mitglied: pipen1976
pipen1976 09.10.2018 um 13:32:44 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.10.2018, aktualisiert am 21.10.2018 um 13:51:50 Uhr
Goto Top
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 !
Mitglied: pipen1976
pipen1976 11.10.2018 um 12:50:01 Uhr
Goto Top
Hallo aqui,

eigentlich ist es drin.
certmgr

Gruß Christian
Mitglied: 137443
137443 11.10.2018 aktualisiert um 13:02:00 Uhr
Goto Top
Zitat von @pipen1976:

Hallo aqui,

eigentlich ist es drin.
certmgr

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

Gruß l
Mitglied: aqui
aqui 11.10.2018 aktualisiert um 13:08:10 Uhr
Goto Top
Ja, das wird sicher der Fehler sein !!!
Siehe Tutorial: "Dann "Lokale Computer" und "Weiter" auswählen und Security Abfrage abnicken." ;-) face-wink
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...
Mitglied: pipen1976
pipen1976 11.10.2018 aktualisiert um 14:06:57 Uhr
Goto Top
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.
Mitglied: 135624
135624 21.10.2018 um 13:16:55 Uhr
Goto Top
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.
Mitglied: aqui
aqui 21.10.2018, aktualisiert am 23.02.2019 um 11:47:02 Uhr
Goto Top
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 !
Mitglied: pipen1976
pipen1976 13.11.2018 um 11:32:09 Uhr
Goto Top
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
Mitglied: aqui
aqui 16.11.2018, aktualisiert am 23.02.2019 um 11:46:31 Uhr
Goto Top
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" !
Mitglied: pipen1976
pipen1976 20.11.2018 um 11:30:58 Uhr
Goto Top
Danke für die Lösung meines Problem´s.
Mitglied: aqui
aqui 20.11.2018 um 13:13:07 Uhr
Goto Top
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 ?!
Mitglied: Datax87
Datax87 10.03.2019 um 15:41:49 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.03.2019 aktualisiert um 01:23:09 Uhr
Goto Top
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
Mitglied: mtb931
mtb931 16.03.2019 aktualisiert um 18:37:25 Uhr
Goto Top
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


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

k-zertifikat_01

pfSense Name:
k-pfsense_name

Zertifikat in der pfsense aktiv:
k-pfsense_certificate

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
Mitglied: aqui
aqui 16.03.2019 aktualisiert um 15:52:39 Uhr
Goto Top
Ich bin Netzwerkanfänger und hoffe dass Ihr mich nicht gleich zerreist.
Keine Sorge, alles gut ;-) face-wink
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 !! ;-) face-wink
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 ;-) face-wink http://www.utrace.de/?query=109.41.194.92 )
Mitglied: mtb931
mtb931 16.03.2019 um 22:45:05 Uhr
Goto Top
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
Mitglied: aqui
aqui 16.03.2019 aktualisiert um 23:05:32 Uhr
Goto Top
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.
Mitglied: mtb931
mtb931 27.03.2019 um 22:36:30 Uhr
Goto Top
Danke für die Unterstützung. Habe Konfiguration aus dem Tutorial noch einmal gelöscht und von vorne mit dem Einrichten der CA bis zur WIN10 Client Konfiguration durchgearbeitet.
Verflixt - ich komm nicht weiter.
Die Fehlermeldung WIN10 VPN Verbindung : "Fehlermeldung IKE-Authentifizierung - Anmeldeinformationen sind nicht akzeptabel" belibt.
Der StrongSwan VPN Client auf den Androiden funktioniert wie einwandfrei.
Um das Tutorial Posting nicht weiter aufzublähen - gibt es vielleicht eine Chance für eine direkte Hilfe ?
Mitglied: aqui
aqui 28.03.2019 um 10:39:47 Uhr
Goto Top
Diese Fehlermeldung kommt wenn man das Zertifikat NICHT oder falsch importiert !!
Irgendwas machst du da noch falsch.
Hab es gerade hier testweise mit aktueller pfSense Firmware und aktuellem Win10 aufgesetzt.... Funktioniert fehlerfrei auf 3 ! Windows 10 Rechnern !
Mitglied: gublgubl
gublgubl 27.04.2019 um 23:17:43 Uhr
Goto Top
Vielen Dank fuer diese super Anleitung. Es hat alles auf anhieb funktioniert, da alles gut erklaert ist.

Ein kleines Problem habe ich allerdings nun, was ich nicht beheben kann.
Die Verbindung wird aufgebaut und ich kann das remote netzwerk von windows 10 aus erreichen.
Nach einer gewissen Zeit geht diese allerdings verloren, der Tunnelstatus bleibt aber auf aktiv. Da das ganze Neuland fuer micht ist, weis ich nicht, wo ich anfangen soll zu suchen. Ich habe mal versucht die Timeouts hochzusetzen, das hatte allerdings keinen Effekt. Nach einigem Lesen vermute ich, dass die Neuaushandlung der Phase 2 nicht funktioniert?


Mitglied: aqui
aqui 28.04.2019, aktualisiert am 29.04.2019 um 08:13:41 Uhr
Goto Top
Es hat alles auf anhieb funktioniert, da alles gut erklaert ist.
Danke für die Blumen :-) face-smile
Was böse ist: no acceptable ENCRYPTION_ALGORITHM found
Da stimmt irgendwas mit deinen angebotenen Encryption Optionen nicht bzw. ein Mismatch der zum Abbruch führt.
Auch die DH Group stimmt nicht.
Du solltest nochmal ganz genau überprüfen das du auch wirklich überall die Group 14 verwendest in Client UND Server ! Du hast definitiv einen Fehler in der Eingabe der Schlüsselparameter gemacht ! Das zeigen die IPsec Fehlermeldungen deutlich !
Eine saubere Einwahl sähe im pfSense Log unter "IPsec" so aus:
Beachte oben die Aushandlung der Proposals !
Deine o.a Fehlermeldungen sind wenigstens nicht normal und sollten NICHT auftauchen !
Mitglied: gublgubl
gublgubl 02.05.2019 um 19:37:27 Uhr
Goto Top
Danke fuer den Hinweis
Ich habe die logs durchgeschaut und bekomme genau die gleichen Angaben, nur beim "Rekey" geht was schief denke ich.
Es sieht bei der ersten Einwahl genau so aus und da funktioniert auch alles wunderbar. Alle Parameter stimmen mit dem Log ueberein.
active_connection

Habe schon einiges ausprobiert, wie z.B. DPD disabled

Ist es sinnvoll den rekey zu disablen? Fuer Windows 7 wird es anscheinen empfohlen
https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#CHIL ...


Mitglied: mrsunfire
mrsunfire 07.06.2019 aktualisiert um 09:28:43 Uhr
Goto Top
Bei mir hat die Anleitung bis einschließlich Windows 10 1809 einwandfrei funktioniert. Mit 1903 jedoch wird keine Verbindung mehr aufgebaut. Auf der pfSense sieht man auch erst gar keinen Verbindungsversuch. Hat sich hier also etwas geändert? Habe es nun auf 2 Systemen getestet, bei beiden das selbe Problem.

EDIT: ok das Problem liegt wirklich an 1903, aber nicht an der Konfiguration. Man darf die Verbindung nicht über die Taskleiste herstellen, sondern muss es über Einstellungen machen. Dann klappt es.
Mitglied: DasBrot
DasBrot 08.06.2019 aktualisiert um 11:55:19 Uhr
Goto Top
Kann ich bestätigen. Mit 1903 geht es nicht mehr.
Unter welchen Einstellungen klappt bei dir die Verbindung ?
Unter Netzwerkverbindungen öffnet sich bei mir auch nur wieder das Kontext Menu aus der Taskleiste, mit welchem es nicht geht.

Eventuell wäre dies auch ein Frage für einen Baum höher. Hier wird ja ein anderes Problem besprochen.


Edit
Ok auch wenn ich den Kommentar oben absetze ist er in diesem Thema .... Mein Fehler. Habe den "Baum" falsch verstanden.
Mitglied: aqui
aqui 08.06.2019 aktualisiert um 11:59:36 Uhr
Goto Top
Ja was denn nun ?? Der eine sagt 1809, der andere 1903....sehr verwirrend. :-( face-sad
Fakt ist das es mit allen Win 10 Versionen bis 1809 einschliesslich fehlerlos funltioniert ! Getestet an 5 unterschiedlichen HW Plattformen.
Wenn man die Verbindung nicht über die Taskleiste herstellen kann, sondern nur über Einstellungen, dann ist das ja wohl ganz klar ein Bug in dieser Windows Version. Zeigt aber auch das es grundsätzlich ja mit dieser Version klappt und nur der Aufruf intern in Win 10 (1903) Fehler behaftet ist. Also kein Fehler des IPsec Protokolls oder der Firewall selber.
1903 ist ja so oder so die "Skandalversion" mit der man vermutlich generell vorsichtig sein sollte und das Update zurückstellen sollte in den Update Settings.
Mitglied: DasBrot
DasBrot 08.06.2019 um 12:05:39 Uhr
Goto Top
Ja ich habe es korrigiert. Ich meinte natürlich die 1903 .... Habe einen weiteren Client getestet. Ab 1903 lässt sich die Verbindung nicht mehr via Taskleiste aufbauen.
Das es an Windows liegt ist unstrittig. Sie werden es aber genau so unstrittig nicht für uns ändern, so das wir einen anderen Weg finden müssen.
Mitglied: aqui
aqui 08.06.2019 aktualisiert um 12:13:51 Uhr
Goto Top
Na ja Shortcut auf die Einstellungen oder kleine Batch geht ja auch ;-) face-wink
Oder warten auf den ersten Patch für 1903...
https://social.technet.microsoft.com/Forums/en-US/821b5675-743b-4d52-87a ...
Mitglied: DasBrot
DasBrot 08.06.2019 um 12:40:28 Uhr
Goto Top
Ja so geht es ja erst mal.
Beim Erstellen kannte ich diese Möglichkeit noch nicht. Da bekommt man etwas Bammel ;) Der Link scheint aber nicht direkt mit der 1903 zu tun zu haben, scheinbar hatten einige wenige das Problem schon vorher. Hoffen wir mal auf einen Bug nicht das es ein wie auch immer entartetes neues Win 10 Feature ist. welches das Menu verhindert.
Mitglied: aqui
aqui 08.06.2019, aktualisiert am 19.06.2019 um 18:05:38 Uhr
Goto Top
Bei MS weiss man nie ob das "Bug oder Feature" ist ! ;-) face-wink
Ist aber wohl sicher ein Bug den andere Komponenten anderer Hersteller haben die gleiche Problematik mit der 1903:
https://administrator.de/content/detail.php?id=463391&nid=764817
Mitglied: aqui
aqui 27.06.2019, aktualisiert am 10.07.2019 um 16:05:40 Uhr
Goto Top
Update:
Heute einmal 2 Winblows 10 Pro Rechner über das Media Creation Tool von einer bestehenden 1809 auf die aktuelle 1903 upgedatet um den Fehler zu reproduzieren. Und siehe da....
Es funktioniert mit aktuellen (Stand heute) 1903 auch über die Taskleiste fehlerfrei !! Das o.a. Problem lässt sich nicht mehr reproduzieren !
Vermutlich hat M$ es in der Zwischenzeit gepatcht....

1902-3

Dashboard mit aktivem VPN User:
1902-2

Ping des lokalen USB LAN Interfaces der pfSense:
1902-1
(Das LAN Interface klappt selbstredend auch !)

Case closed ! ;-) face-wink
Mitglied: mrsunfire
mrsunfire 16.07.2019 um 12:59:59 Uhr
Goto Top
Bei meiner 1903 geht es noch immer nicht über die Taskleiste. Weiterhin bekomme ich auch nicht mehr als 30 MBit/s netto Datendurchsatz und das trotz i5 CPU und AES-NI crypto unter den Advanced Settings.
Mitglied: aqui
aqui 17.07.2019 aktualisiert um 09:26:18 Uhr
Goto Top
Welchen 1903er Build nutzt du ? So ist die Aussage logischerweise wenig hilfreich.
Was den Durchsatz angeht gibt es 2 Faktoren. Bandbreite der Internet Anbindung des Clients und dessen Leistungsfähigkeit. Dazu leider keinerlei Aussage von dir. :-( face-sad
An der Firewall mit der CPU Ausstattung wird es dann ganz sicher nicht liegen. Die kannst du als Ursache sicher ausschließen, denn die schafft Wirespeed.
Mitglied: mrsunfire
mrsunfire 18.07.2019 aktualisiert um 08:09:30 Uhr
Goto Top
Aktuellste Version, siehe Bild. Klicke ich via Taskleiste auf die VPN Verbindung, bleibt es bei "Verbindung wird hergestellt" hängen und es kommt keine Anmeldemaske. Interessanterweise bekomme ich aktuell auf meiner Hauptmaschine nun auch die Meldung "Falscher Parameter", obwohl die Verbindung mal funktioniert hat. Im Log der pfSense bleibt es dann hier hängen:

unbenannt2


Die Anbindung hat einen Upstream von 40 MBit/s. Zuvor gingen auch via LAN nicht mehr durch. Habe dann MSS Clamping in den Advanced Options von IPsec auf 1350 gesetzt. Damit schaffe ich via LAN nun knapp 200 MBit/s, was aber auch zu wenig ist. Die CPU ist dabei nicht mal 30% ausgelastet. Es ist übrigens inzwischen eine i7 CPU. WAN aber weiterhin je nach Anwendung maximal 25-30, meist eher 10-15 MBit/s. TCP/UDP ist dabei egal.
unbenannt
Mitglied: aqui
aqui 18.07.2019 aktualisiert um 10:42:29 Uhr
Goto Top
Schon komisch, denn hier klappt es mit 5 Rechnern unterschiedlicher Hardware völlig fehlerlos mit der o.a. Build Nummer.
Sieht dann wohl doch eher so aus als ob es doch eine Stellschraube unter Winblows 1903 ist. Nur welche...??? Das ist die große Frage...
Ist die Pest mit diesen Updates...
Mitglied: mrsunfire
mrsunfire 18.07.2019 um 14:30:47 Uhr
Goto Top
Auch ein anderes System mit gleichem Build hat das selbe Problem.

Kannst Du zum Geschwindigkeitsthema oder dem Parameterfehler etwas sagen?
Mitglied: aqui
aqui 19.07.2019 um 10:16:40 Uhr
Goto Top
Was meinst du mit Parameterfehler ? Hier rennt ein APU3 mit aktiviertem AES NI Support mit guten 550 MBit was auch ein realistischer Wert ist. Mit deiner CPU sollten noch mehr drin sein.
Mitglied: mrsunfire
mrsunfire 19.07.2019 um 11:38:37 Uhr
Goto Top
Siehe meinen Post darüber. Windows 10 sagt "Falscher Parameter". Ich habe mich genau an die Anleitung gehalten. Auf einer anderen Maschine geht es problemlos. Wie kann ich untersuchen warum die Geschwindigkeit so gering ist? Alle Einstellungen sind der Anleitung hier identisch.
Mitglied: mrsunfire
mrsunfire 20.07.2019 um 07:49:56 Uhr
Goto Top
Habe die VPN Verbindung auf dem Windows 10 Client noch mal neu angelegt. Nun bekomme ich "Fehler in Richtlinienübermittlung" mit dem Code 13868. Verstehe es nicht mehr...
Mitglied: aqui
aqui 20.07.2019, aktualisiert am 07.10.2019 um 11:48:50 Uhr
Goto Top
Habe es gerade mal nachgestellt auf einem frisch installierten 1903. Klappt fehlerlos auch aus der Taskleiste. Exakt wie oben beschrieben.
Sieht doch nach irgendeiner Stellschraube im 1903 aus....
Am Windows 10 wurde nur Cortana totgelegt, der Sperrschirm deaktiviert:
https://www.heise.de/select/ct/2019/13/softlinks/yqbc?wt_mc=pred.red.ct. ...
Sowie alle überflüssige Software deinstalliert.
Nach o.a. Tutorial das VPN angelegt und klappt auf Anhieb.
Was gerne mal vergessen wird ist das Zertifikat, was sich dann in den o.a. Fehlern äußert.
Allerdings scheint es wohl trotzdem noch manchmal unerklärliche Aussetzer bei der VPN Taskleiste zu geben.
Auch das ct' Magazin empfiehlt dann den Standard Workaround:
https://www.heise.de/select/ct/2019/21/1570459863818446#titel_1570459863 ...

Was die Performance angeht kann es nicht an deiner HW liegen. Die CPU hat genügend Reserven sofern der Krypto Support aktiviert ist.
Es kann sein du ggf. Autonegotiation Probleme am LAN oder WAN Port hast. Ggf. MTU bzw. MSS aber das sollte automatisch auf dem richtigen Wert stehen. Wenn nicht kommt es zu Fragmentierung was erheblich an de Performance kratzt. Über die CPU Last kannst du das im Dashboard sehen.
Autonegotiation ggf. an den NIC Port Countern. Dort sollten keine Error Frames zu sehen sein.
Mitglied: mrsunfire
mrsunfire 21.07.2019 um 08:13:19 Uhr
Goto Top
Meine NIC's stehen alle fix auf 1000base-T full-duplex. MTU ist keine gesetzt. Die CPU Last geht nie über 30%, auch wenn der Speed nicht durch kommt.
Mitglied: msense
msense 21.07.2019 um 20:09:27 Uhr
Goto Top
Dank dieser Anleitung kann ich nun eine VPN Verbindung von W10 und IOS mit der pfsense herstellen !
Mitglied: msense
msense 21.07.2019 aktualisiert um 23:29:22 Uhr
Goto Top
Hier noch ergänzende Hinweise:

Powershell Skript
Mit folgendem kann man den Parameter einfach nach Bedarf adaptieren. Ja, $false und nicht vorhanden sind ident, aber man muss suchen wie die Parameter für true sind. Damit wird das aber klar.
-SplitTunneling --> -SplitTunneling:$false

Phase1 - Interface
Das kann tricky sein, folgender Hinweis:
Wenn man mit dem WAN am ISP hängt und man hat zb Domains mit fester IP adresse registiert mit der/denen man per VPN zugreifen will, kann es sein dass die WAN IP und die Domain IP die am WAN mit ankommt NICHT ident sind. Man muss dann das Interface auf die richtige Domain IP stellen. Am besten ist es, wenn man vorher schon mal den Zugriff auf die internen Server via http eingerichtet und getestet hat, denn dann weis man dass das soweit funktioniert. (Hinweis, ein Alias für die zugewiesene statische Domain IP ist da sehr hilfreich).

W10x64 Build 1903
Bei mir kann man über die Taskleiste das VPN nicht starten. Man muss das dz. über die VPN Einstellungen machen. Wann das wieder geht...??
Nachtrag: siehe Manuelle VPN Wahl per Link

IOS12.3.1
Die Einstellungen gehen sehr einfach. Allerdings hat IOS hier auch einen Bug:
Man MUSS dz User und PWD als Parameter fest eintragen, sonst gibt es keinen Connect. Im pfsense log wäre alles ok, nur wird die Verbindung nicht final aufgebaut. Einen Bugreport bei Apple habe ich geschrieben.

Wunsch
Das Einzige was ich mir noch wünschen würde wäre zu wissen wie man das Stammzertifikat so exportiert/verarbeitet dass es mit einem Passwort geschützt ist, es aber genauso eingebunden werden kann wie beschrieben.
Mitglied: aqui
aqui 22.07.2019 um 10:51:04 Uhr
Goto Top
Danke für das Feedback !
Bei mir kann man über die Taskleiste das VPN nicht starten. Man muss das dz. über die VPN Einstellungen machen.
Wie gesagt...hier klappt es bei 5 komplett neu installierten 1903ern Professional und 3 Maschinen die per Update von 1809 auf 1903 gezogen wurden (auch Prof.) fehlerlos !!
Die 5 neuen 1903er mit einem Media Creation Tool mit Auswahl (Edition: May 2019) installiert.
Fragt sich dann nur warum das dann klappt ??
IOS12.3.1
Kann ich auch nicht ganz bestätigen. Aktuelles iPad und iPhone 7 sowie diverse X hier mit 12.3.1. Dort reicht es zumindestens NUR den Usernamen einzutragen. Das Passwort kann man auf abfragen stellen. Auch das klappt fehlerlos ! Egal ob man das nun komplett einträgt oder nur das Passwort abfragt. (pfSense 2.4.4 p3 latest)
Mitglied: mrsunfire
mrsunfire 27.07.2019 um 10:51:46 Uhr
Goto Top
Die Neuinstallation des WAN-Miniport (IKEv2) Treibers hat bei mir geholfen dass es wieder funktioniert!
Mitglied: aqui
aqui 29.07.2019 um 13:06:53 Uhr
Goto Top
Perfekt ! 👍
Mitglied: dschlich
dschlich 06.10.2019 um 14:24:19 Uhr
Goto Top
Hallo aqui,

erstmal danke für das sehr gute tutorial, was mir heute Nacht viele Erfolgserlebnisse während meinen ersten Stunden mit pfSense beschert hat!

Eine Frage habe ich allerdings und ich komme nicht weiter...

Mein Setup..
iphone via LTE -> IP-Speedport -> pfsense.

Was geht....
Ich kann mich via ssh auf meine geräte z.B. Raspberry connecten, aber wenn ich z.b. https://www.wieistmeineip.de/ aufrufe, dann bekomme ich stets die IP, welche mein Iphone vom ISP zugewiesenen bekam gemeldet und nicht wie ich annehmen würde die IP meines meines Speedport-ISP`s, also Tcom....?
Fazit, ich "surfe" also nicht "durch" das VPN...
Kann es irgendwie sein, dass mein iphone (safari) denkt es bekommt alles ausser "meiner" privaten netze nicht aus dem tunnel? Wie kann ich dafür sorgen, dass mein iphone alles, also 0.0.0.0 über den Tunnel abwickelt?

Ich habe die Option "Liste mit zugänglichenNetzwerken dem Gerät zur Verfügung stellen" gecheckt, aber wie / wo konfiguriere ich das , oder bin ich schon auf dem Holzweg?

Wäre cool, wenn du eine idee hättest.

VG Daniel
Mitglied: aqui
aqui 06.10.2019 aktualisiert um 21:25:54 Uhr
Goto Top
viele Erfolgserlebnisse während meinen ersten Stunden mit pfSense beschert hat!
So sollte es sein ! ;-) face-wink
iphone via LTE -> IP-Speedport -> pfsense.
Fazit, ich "surfe" also nicht "durch" das VPN...
Das ist klar, denn die Konfig zeigt eine Split Tunneling Konfig. Sprich nur die remoten LAN Netzwerke werden durch den Tunnel geschickt. Lokaler Internet Traffic bleibt lokal.
Die Lösung alles in den VPN Tunnel zu routen, also ein Gateway Redirect zu machen, ist aber kinderleicht. Du musst nur eine Default Route auf den Tunnel eintragen. Das o.a. Tutorial erklärt diese Option im Detail im Kapitel "Alles in den Tunnel routen...".
Mitglied: dschlich
dschlich 07.10.2019 um 23:36:59 Uhr
Goto Top
Hi aqui,

danke, da war es wohl doch zu spät für mch und ich habe diesen Absatz in der Nacht überlesen.

Ich habs gerade getestet, zuerst hatte ich keinen Erfolg, aber nachdem ich in Phase 1 unter Mobile Clients den Haken bei "Netzwerk-Liste >>x<< Liste mit zugänglichenNetzwerken dem Gerät zur Verfügung stellen" entfernte schnurrte es wie ein Kätzchen, danke!

VG Daniel
Mitglied: aqui
aqui 08.10.2019 aktualisiert um 11:34:20 Uhr
Goto Top
Intuitiv richtig gemacht und danke für das hilfreiche Feedback !
Ich hab das Tutorial entsprechend in diesem Punkt nochmal angepasst. ;-) face-wink
Mitglied: DasBrot
DasBrot 07.11.2019 aktualisiert um 13:48:00 Uhr
Goto Top
Hallo, @mrsunfire
Die hast geschrieben das du nach Neuinstallation des WMiniport treibers die VPN Verbindung wieder aus der Taskleiste heraus benutzen kannst.
Oder habe ich den Post im falschen Kontext gesehen ? Gab es da noch weitere Schritte ?
Ich habe das Problem weiterhin mit 14 Clients. Das Löschen und neustarten aller Miniport treiber aus dem Gerätemanager brachte keinen Erfolg
Gruß
Bernd

EDIT:
Ich bin einen Schritt weiter. Zumindest kommt jetzt die Benutzerauthentifizierung wieder.
Mittels dieser Anleitung :

Am Rechner als Benutzer mit „Administrator-Rechten“ anmelden
Den Registry Edit öffen
Zum Schlüssel „HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Control Panel\Settings\Network“ navigieren
Den Eigentümer des Schlüssel-Ordner „Network“ ändern
Im Berechtigungen-Fenster „Erweitert“ auswählen
Im Fenster „Erweiterte Sicherheitseinstellungen“ bei Besitzer auf „Ändern“ klicken (am oberen Rand des Fensters)
Deinen Benutzernamen eingeben und Änderungen speicheren
Fenster für „Erweiterte Sicherheitseinstellungen“ schließen
Nun „Admininistratoren“ im Berechtigungsfenster auswählen
Sicherstellen, das „Vollzugiff“ ausgewählt ist und die Einstellungen übernehmen.
Doppelklick auf den Schlüssel „ReplaceVan“ und den Wert von 0 auf 2 ändern
Letzteres ist wohl nur die Ansicht. Aber wenn ich es auf 0 belasse kommt die Abfrage nicht

Allerdings erscheint dann eine Fehlermeldung Fehler 87 falscher Parameter.... Ich probiere noch etwas rum.
Mitglied: DasBrot
DasBrot 06.04.2020 um 12:53:54 Uhr
Goto Top
Hallo, Ich nutze die Roadwarrior nach dieser Anleitung bereits länger erfolgreich. (Windows 10 Clients)

Was ich jedoch nicht hin bekomme ist das der Tunnel längere Zeit auch ohne Aktivität bestehen bleibt.

Nach unterschiedlicher Zeit verliert der Client die Verbindung, der Tunnel wird jedoch auf Windows 10 Seite offen angezeigt.
Ich habe Einstellungen seitens Windows auf Standard belassen, und nur die Shell Befehle abgesendet. Ich vermute etwas passt nicht zusammen, das der Tunnel nach einiger Zeit nicht mehr nutzbar ist. Das können 10 Minuten sein, oder auch 20. Grundsätzlich spricht nix dagegen den ungenutzten Tunnel zu beenden. Aber die Zeit bis dahin, womit hängt diese zusammen ? Und warum zeigt die Netzwerkverbindung Windows 10 immer noch verbunden an ?

lg
Bernd.
Mitglied: aqui
aqui 06.04.2020 aktualisiert um 18:19:01 Uhr
Goto Top
Passiert hier nicht. Jedenfalls nicht mit einem Apple VPN Client ! Welchen Client verwendest du ?
Leider sagst du dazu nichts. :-( face-sad Möglich das der kein Rekeying macht wenn die Lifetime abgelaufen ist was eigentlich nicht der Fall sein sollte. Liegt diese Zeit unter 1 Stunde oder genau da ?
Du kannst testweise mal die Lifetime der P2 verdoppeln auf 2 Stunden = 7200 und checken ob sich da was verändert. Wenn ja dann ggf. einen größeren Wert verwenden, der aber nicht größer sein sollte als die 8 Stunden (28800) der P1.
Mitglied: DasBrot
DasBrot 07.04.2020 um 09:55:59 Uhr
Goto Top
Hollo, und vielen Dank.
Sorry nicht ausführlich genug geschrieben. Ich meinte nach Anleitung auf Windows 10, also mit Boardmitteln ohne externen Client.
Mit der Lifetime versuche ich mal. Witzig ist das ich eine pfsense habe wo das Problem nicht auftritt. Ich kann jedoch keinen Unterschied ausmachen in der Config. Ausser das diese Verbindung das Passwort gespeichert hat.

Die Verbindung bricht unterhalb einer Stunde ab. Ich melde mich, wenn ich mehr weis.
Gruß
Bernd.
Mitglied: aqui
aqui 07.04.2020 um 10:00:27 Uhr
Goto Top
Tritt hier wie gesagt auch nirgendwo auf. Kann es sein das der Client der Buhmann ist. Z.B. den Energiesparmodus unter Winblows auf dem VPN Adapter oder dem Primär Adapter der die VPN Verbindung hält aktiv ? Dann deaktiviert der Rechner den Client im Energiesparmode. Das ist vermutlich eher dann die Ursache ?!
Das also auch mal checken in den Energieeinstellungen.
Mitglied: Frank93
Frank93 21.04.2020 um 00:26:51 Uhr
Goto Top
Erstmal vielen Dank für die tolle Anleitung. War auch für mich als Halb Laie gut anwendbar.
Genutzt werden zwei Internetanschlüsse mit Multi-WAN, Failover und Load Balance.

Folgende Fragen hätte ich noch.
1. Wie kann ich Nutzern nur bestimmte Zugangsberechtigungen geben, z. B. nur auf einen Serverdienst?
  • Die ganzen Nutzer für das VPN lege ich unter Pre-Shared-Keys an.
  • Unter "Tunnels" -> "Phase 2" habe ich zwei Einträge. Einmal wie in der Anleitung beschrieben, mit "Scheunentor" (gedacht für Admin) und einen mit einer Adresse der nur auf einen Serverdienst (Nutzer) soll.
Wie kann ich jetzt Nutzer 1 erlauben, dass er ggf. auf das gesamte Netz zugreifen darf. Nutzer 2 jedoch nur auf die Adresse mit den bestimmten Dienst zugreifen darf?
Kann ich das innerhalb der VPN Umgebung machen, muss ich es über Regeln in der FW definieren, muss ich eine neue Phase 1 und 2 aufmachen oder ist das gar nicht möglich?

2. Ich nutze Multi-WAN auf der pfSense. In der Phase 1 kann man ja auch als Interface, eine Gateway Gruppe auswählen. Wenn sich z. B. mehrere Benutzer gleichzeitig aufschalten wollen, kann dann die Last auf beide Anschlüsse verteilt werden oder geht das eigentlich gar nicht und es muss immer eine feste IP des Anschlusses pro Tunnel angegeben werden?
Habe eine Anleitung gefunden, dass mit einem Dyndns Dienst Mulit-WAN möglich wäre.

3. Sollte im Multi-WAN Betrieb für das VPN unter "System / Advanced / Miscellaneous --> Use sticky connections" verwendet werden?
Bei einem Webmail Anbieter hatte ich schon das Problem, dass die Verbindung nicht zustande kam, da anscheinend die Pakete immer über die zwei Leitungen rausgegangen sind. Aktiviere ich den Dienst, halbiert sich im Speedtest aber auch die Geschwindigkeit.. :-( face-sad

Waren jetzt viele Fragen und sage schon einmal vielen Dank vorab.
Mitglied: aqui
aqui 21.04.2020 aktualisiert um 09:29:00 Uhr
Goto Top
Wie kann ich Nutzern nur bestimmte Zugangsberechtigungen geben, z. B. nur auf einen Serverdienst?
Wenn das immer für alle Nutzer gleich ist, z.B. alle dürfen nur RDP auf Server xyz machen, dann machst du das ganz normal über das Firewall Regelwerk auf dem VPN Interface. Das wäre sehr einfach.
Wenn du pro User individuelle regeln setzen wisst, dann wird es etwas aufwendiger, denn dann musst du jedem User immer eine feste IP Adresse zuweisen und dann bezogen auf die individuelle IP Adresse dort ebenso das Regelwerk setzen. Die Vergabe vom individuellen User IPs ist über die Userverwaltung regelbar.
Mit anderen Worten: Es geht immer über die Regeln.
kann dann die Last auf beide Anschlüsse verteilt werden
Das geht nur wenn du den VPN Clients einigermaßen wechselseitig mal die eine, mal die andere WAN IP Adresse konfigurierst und so eine quasi Verteilung über das Dialin machst. Es muss also VPN User getriggert sein, was auch klar ist, denn der VPN User initiiert ja die Verbindung nicht die FW.
dass mit einem Dyndns Dienst Mulit-WAN möglich wäre.
Das wäre auch eine Idee wenn der Dienst sowas supportet. Das wäre ein DNS Balancing. Das der DynDNS Dienst auf einen DNS Anfrage des Hostnamens mal die eine und mal die andere WAN IP im Round Robin Verfahren ausgibt. Das ginge natürlich auch und ist durchaus üblich.
Use sticky connections" verwendet werden?
Müsste nicht zwingend. Es geht ja rein nur um die eingehenden VPN Verbindungen der Clients und NICHT um ausgehende Verbindungen für die das dual WAN Balancing ja eigentlich gilt. Durch die eingehende VPN Session bestimmt man ja fest die IP mit der man arbeitet und die bleibt auch.
da anscheinend die Pakete immer über die zwei Leitungen rausgegangen sind.
Das ist technisch unmöglich und zeugt eher von einer Fehlkonfiguration. Vermutlich hast du damit einen internen Mail Server mit Port Forwarding bedient und dann die outbound Sessions des Mail Servers über den Balancer laufen lassen. Das ist dann natürlich tödlich und ein typischer Anfänger Konfig Fehler. Sowas kann dann logischerweise nicht gehen.
Waren jetzt viele Fragen
Nöö, passt schon... ;-) face-wink
Mitglied: Frank93
Frank93 21.04.2020 um 12:17:17 Uhr
Goto Top
Zitat von @aqui:
Vielen Dank für die rasche Antwort.

Zum Verständnis, ob ich die Ipsec Anleitung vom Prinzip verstanden habe, folgende etwas längere Ausführung. Hoffe dadurch wird ersichtlich, ob ich a) es überhaupt einigermaßen verstanden habe und b) wo mein gedanklicher Knoten liegt. Meine Gedanken sind aus der Anwendersicht beschrieben und anhand der Gliederungspunkte der Anleitung.

Um die Verwirklichung um folgendes Szenario geht es:
Es gibt ein LAN 1 und LAN 2. An "Nutzergruppen" soll es Admins und Nutzer geben. Die Admins sollen auf beide LANs zugreifen dürfen. Die Nutzer jedoch nur auf einen bestimmten Dienst innerhalb des LAN2 (Zugriff auf Dateien auf Server, die im Datei-Explorer angezeigt werden sollen).

Die Einrichtung des VPN hat nach der Erstellung des Zertifikats und Einrichtung der Clients, drei Schritte (entsprechend der Anleitung):

1. Mobiles Client IPsec VPN auf der pfSense einrichten
Hier ermögliche ich überhaupt den Betrieb des VPN und vergebe einen IP-Adressbereich innerhalb der pfSense. Jeder angelegte Nutzer landet ja in diesem Adress-Bereich und die FW vergibt die Adressen nach dem Motto "wer zuerst kommt, malt zuerst".
Habe es so wie in der Anleitung konfiguriert.
2. IPsec Phase 1 Konfiguration:
Hier bestimme ich u. a. über welches Gateway die mobilen Nutzer rein kommen.
Habe es so wie in der Anleitung konfiguriert.
3. IPsec Phase 2 Konfiguration:
A) 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, dann werden sie hier eingetragen. (Bsp: 192.168.0.0 /16 routet alle 192.168er Netze in den VPN Tunnel)
B) 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.


"A" verstehe ich so, dass ich bestimmen kann, welcher Teil meines Netzwerkes von "außen" erreichbar ist.
"B" verstehe ich jedoch so, dass der komplette Traffic des Notebooks über den VPN gelenkt wird. Habe wo gelesen, dass dies sinnig wäre, wenn man z. B. in einem öffentlichen WLAN ist.

Hier habe ich mich dafür entschieden, dass der gesamte Traffic in den Tunnel geroutet werden soll für die Nutzer, da die Zugriffsrechte für die Nutzer "Verwalter" und "Nutzer" ja innerhalb der FW-Regeln-IPsec geregelt werden.

Benutzername und Passwörter für den VPN Zugriff einrichten:
Hier lege ich für jede Person einen Namen (Verwalter 1 bis 4, Nutzer 1 bis XX) und PW an.
Oder müsste hier in der pfSense über "System / User Manager" auch noch eine Anlegung von Benutzern erfolgen?

Firewall Regeln für IPsec einrichten
Entsprechend Ihrer Antwort, definiere ich hier auf welche Ressourcen die "Verwalter" und "Nutzer" Zugriff erlangen.

Hoffe ich habe das Prinzip einigermaßen richtig verstanden und angewandt.

Die offene Frage für mich ist jetzt, wie ich innerhalb der FW-Regeln-Ipsec, die Zugriffe für "Verwalter" und "Nutzer" regle.
Gehe davon aus, dass ich "Aliases" einrichten muss für "Verwalter" und "Nutzer".
Hierfür brauche ich ja aber IP-Adressen. Und die Adressvergabe erfolgt ja nach der ersten Anmeldung (Status / Ipsec / Leases) und bleibt dann gleich, oder?
Kann ich somit die Nutzertrennung erst einrichten, wenn sich alle das 1. Mal angemeldet haben?

Entschuldigung, dass die Ausführung etwas lang geworden ist. Hoffe jedoch es wird dadurch etwas leichter zu erkennen, wo mein gedanklicher Knoten liegt.

Gruß
Mitglied: aqui
aqui 21.04.2020 aktualisiert um 12:33:32 Uhr
Goto Top
Entschuldigung, dass die Ausführung etwas lang geworden ist.
Es ist besser du bewegst das in einen komplett neuen Thread um hier das Tutorial nicht unnötig mit Detailfragen aufzublähen und damit für andere unübersichtlicher zu machen.
"A" verstehe ich so, dass ich bestimmen kann, welcher Teil meines Netzwerkes von "außen" erreichbar ist.
Nein, damit bestimmt man welchen IP Flow mit IPsec encryptet wird und in den Tunnel fliesst.
Die offenen Frage kannst du nur darüber lösen das du den Nutzern feste Absender IP Adressen verteilst. Damit gibt es zu jedem benutzer eine feste IP auf die man dann wieder "Nutzer" und "Verwalter" Regeln anwenden kann.
Aber am besten in einem separaten Thread mit Verweis hier. ;-) face-wink
Mitglied: Frank93
Frank93 22.04.2020 um 12:24:47 Uhr
Goto Top
Hier der Thread zu der Problematik mit fester IP Vergabe.
https://administrator.de/forum/benutzer-zugriffsrechten-ipsec-vpn-pfsens ...
Mitglied: Patrickz
Patrickz 22.04.2020 um 14:58:53 Uhr
Goto Top
Vielen Dank @aqui für das tolle Tutorial.
Ich nutze OPNsense 20.1.4 und konnte erfolgreich eine Split-VPN einrichten.
Allerdings wird bei der Always on VPN nicht ins Internet geroutet. Ich habe wie im Tutorial beschrieben als Netzwerk 0.0.0.0/0 angegeben. Lediglich unter den Firewall Regeln wird die Option Gateway von "Standard" immer wieder nach dem Speichern auf "nothing selected" geändert. Haben Sie eine Idee was ich noch falsch gemacht haben könnte oder handelt es sich hierbei um ein bug?
Dankeschön
Mitglied: aqui
aqui 23.04.2020 aktualisiert um 11:24:39 Uhr
Goto Top
Danke für die Blumen. ;-) face-wink
Die 0.0.0.0/0er Route in der Firewall einzugeben ist nur die halbe Miete. Beim Windows Client musst du das z.B. auch noch zusätzlich customizen. Siehe oben in der Beschreibung des Windows 10 Clients. Dort entweder die 0.0.0.0/0er Route auch eingeben oder SplitTunneling Parameter auf False im PowerShell Setup setzen. Dann klappt das auch fehlerlos.
Wenn du Windows als VPN Client hast hilft immer ein route print in der Eingabeaufforderung um die Routing Tabelle bei aktivem VPN Client zu checken. Dort sollte dann die Default Route auf das Tunnel Interface zeigen.
Mitglied: Patrickz
Patrickz 24.04.2020 um 15:23:48 Uhr
Goto Top
Vielen Dank für die Antwort. Ich habe gestern nochmal probiert mit ihrem Hinweis die Always VPN Lösung unter Windows 10 sowie Android umzusetzen.
Mit dem Befehl route print bekam ich folgende Ausgabe(Per LTE mit dem Internet Verbunden + aktivierte VPN):
Netwerkziel 0.0.0.0 Netzmaske 0.0.0.0 Gateway 10.164.59.XX Schnittstelle 10.164.59.YY Metrik 4536
Netwerkziel 0.0.0.0 Netzmaske 0.0.0.0 Gateway Auf Verbindung Schnittstelle 10.0.100.2 Metrik 46
Für mich sieht das so erstmal korrekt aus. Jedoch habe ich nur Zugriff zum Intranet und nicht zu Internet.
Ich befürchte das bei OPNsense irgendeine route nicht funktioniert. Haben Sie noch einen Tipp für mich?
Mitglied: aqui
aqui 25.04.2020 um 09:50:42 Uhr
Goto Top
mit ihrem Hinweis
In einem Forum duzt man sich in der Regel also bitte nicht so förmlich ! "You can say you to me...!" ;-) face-wink
In der o.a. Routing Tabelle:
Netwerkziel 0.0.0.0 Netzmaske 0.0.0.0 Gateway 10.164.59.XX Schnittstelle 10.164.59.YY Metrik 4536
Netwerkziel 0.0.0.0 Netzmaske 0.0.0.0 Gateway Auf Verbindung Schnittstelle 10.0.100.2 Metrik 46

würde dann die 10.0.100.2 Schnittstelle bevorzugt, da bessere Metrik.
Beim Routing ist es so das der niedrigere Wert die bessere Metrik darstellt und Microsoft sich hoffentlich auch an diesen Standard hält.
Habs hier gerade nochmal mit einer pfSense getestet und damit funktioniert das fehlerlos.
Mitglied: Patrickz
Patrickz 25.04.2020 um 13:16:03 Uhr
Goto Top
Ja ich bin noch nicht so Forum erfahren, in aller Regel Google ich mich tot bis ich es schaffe aber hier kam ich nicht weiter.
Danke für die Erklärung aber nach meinem Verständnis müsste damit die Client Seite richtig eingestellt sein. 10.0.100.2 ist mein VPN Netz. Das Intranet also Webseiten aus dem lokalen Netz funktionieren über die dauerhafte VPN nur nicht das WWW.
Ich muss doch nicht Serverseitig(OPNsense) noch eine eigene Route erstellen?
Mitglied: aqui
aqui 25.04.2020 um 15:05:52 Uhr
Goto Top
nach meinem Verständnis müsste damit die Client Seite richtig eingestellt sein. 10.0.100.2 ist mein VPN Netz.
Nicht nur nach deinem. Dann ist auch alles richtig.
Was sagt denn ein Traceroute z.B. auf die 8.8.8.8 ? Geht das über den VPN Tunnel ins Internet ?
Ich muss doch nicht Serverseitig(OPNsense) noch eine eigene Route erstellen?
Nein, natürlich nicht, denn die hat hat ja schon (hoffentlich) eine Default Route ins Internet ;-) face-wink !
Mitglied: Patrickz
Patrickz 25.04.2020 um 16:58:06 Uhr
Goto Top
Zitat von @aqui:
Nicht nur nach deinem. Dann ist auch alles richtig.
Das beruhigt mich schonmal.
Zitat von @aqui:
Was sagt denn ein Traceroute z.B. auf die 8.8.8.8 ? Geht das über den VPN Tunnel ins Internet ?
Ist mit einem Hop direkt im Intranet.
Gibt 30 Hops a je "Zeitüberschreitung der Anforderung" an.
Über das Webinterface der OPNsense kann ich leider jedoch keine Tests aus dem VPN Netz machen. Oder gibt es da eine Möglichkeit?
Mitglied: aqui
aqui 26.04.2020 um 09:00:25 Uhr
Goto Top
Bitte lagere das Troubleshooting in einen separaten Thread aus mit hiesigem Verweis um das Tutorial hier nicht unnötig aufzublähen und damit unübersichtlich zu machen !
Danke !
Mitglied: 12ha34
12ha34 19.09.2020 um 12:51:41 Uhr
Goto Top
Hallo aqui,

danke für die Anleitung, ich habe diese nachvollzogen und auch eine Verbindung über Android hinbekommen. Bei meinen WIn10 Rechnern bekomme ich allerdings die bekannte Fehlermeldung "ike-authentifizierung-anmeldeinformationen sind nicht akzeptabel" Ich habe die Zertifikate meiner pfSense 2.4.5-Release-p1kontolliert.Die CA in den Computer Store importiert etc..

Auf den Netgate-Seiten habe ich folgenden Workaround gefunden und den Registry Eintrag wie folgt gesetzt:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters\ --> DisableIKENameEkuCheck=1

Damit bekomme ich eine IPSec Verbindung von WIN10 aus. Laut Netgate sollte das mit neueren pfSense Versionen nicht nötig sein. Ich denke ich habe ein EKU Problem. Da aber das Abschalten des EKU Checks ein Sicherheitsrisiko darstellt, möchte ich das ungern tun. Gibt es da eine Lösung wie ich das EKU des Serverzertifikates anpassen kann? Was benötigt WIN 10 überhabt. Mein aktuelles Zertifikat hat folgende Einträge:
eku

Wie sieht das bei Euch aus? Was kann man verändern, damit auch ohne DisableIKENameEkuCheck=1 eine Verbindung aufgebaut wird.

Danke und Grüße ha
Mitglied: aqui
aqui 19.09.2020 aktualisiert um 14:52:00 Uhr
Goto Top
Kann ich bei Windows 10 (1909) hier leider nicht nachvollziehen. Auch auf einem frisch installierten Win 10, 1909 Client funktioniert es fehlerlos.
Ob das bei der 2004er Version auch so ist kann ich in Ermangelung dieser aktuell nicht testen. Leider fehlt bei dir die Win 10 Versionsangabe (Suchfeld und dann winver)
Die Fehlermeldung lässt auch eher auf einen Fehler in den Krypto Credentials schliessen. Hast du die noch einmal wasserdicht gecheckt ? (AES 256 und Hashing)
Mitglied: 12ha34
12ha34 19.09.2020 aktualisiert um 15:20:07 Uhr
Goto Top
Die Windowsversion lautet: 1909 (Build 18363.1082)

Einstellungen sind denke ich korrekt.

p1

p2
Mitglied: aqui
aqui 20.09.2020 um 10:26:50 Uhr
Goto Top
Einstellungen sind denke ich korrekt.
Das ist ja nur eine Seite ! Davon das die korrekt ist gehen wir mal aus. Aber wie sieht es auf dem Windows Client aus ??
Wie gesagt, hier auf einen frisch installierten 1909er Client fehlerlos !
Mitglied: 12ha34
12ha34 20.09.2020 aktualisiert um 11:23:42 Uhr
Goto Top
Ich habe die Einstellungen im Win Client über die PowerShell Befehle gemacht. Ein Test mit einem frischen 2004er brachte auch keinen Erfolg. Ich chaue mal ob ich noch ein 1909er Intsallationsmedium habe und teste das mal mit einer frischen Installation.

Die pfSense (2.4.5) hatte ich frisch aufgesetzt und meine alten Einstellungen inklusive OpenVPN Certifikaten (User) über ein Backup zurückgespielt. Könnte das damit zusammenhängen?
Mitglied: aqui
aqui 20.09.2020 aktualisiert um 12:15:33 Uhr
Goto Top
Könnte das damit zusammenhängen?
Eigentlich nicht, denn das Backup stellt ja alles genau so wieder her wie es war inklusive Zertifikaten. Solange die also noch gültig sind (Zeit) und auch Uhrzeit und Datum von Client und Server stimmen sollte es nicht daran liegen.
Was noch hilfreich wäre, wäre das Log der pfSense wenn der Client sich einwählt. Das ist in der Regel erheblich aussagekräftiger als das was Winblows ausgibt. Leider fehlte die Info oben... :-( face-sad
Hilfreich ist es das Log reverse anzuzeigen das die aktuellste Message immer zuerst oben steht und es ggf. zu löschen bevor man mit dem Client den Tunnel aufbaut.
log1
log2
Unter IPsec findet man dann eine meist sinnvollere Debugging Message.
Mitglied: 12ha34
12ha34 20.09.2020 um 13:19:27 Uhr
Goto Top
Das ist der Log mit einem fehlgeschlagenem Anmeldeversuch.


Mitglied: aqui
aqui 20.09.2020 aktualisiert um 13:52:46 Uhr
Goto Top
Mmmhhh.. .Timeout klingt erstmal komisch ?! Bedeutet das dort irgendwas nicht ankommt.
Hast du am WAN Port eine entsprechende Regel eingerichtet die:
  • UDP 500 (IKE/ISAKMP)
  • UDP 4500 (NAT Traversal)
  • und das ESP Protokoll (IP Nummer 50, Achtung kein Port 50 !)
entsprechend auf die WAN IP Adresse der Firewall passieren lässt ?
Zudem wenn die pfSense in einer Router Kaskade arbeitet (und auch nur dann !!) sollte am WAN Port unten der Haken beim Blocken der RFC 1918 IP Netze entfernt werden.
Mitglied: 12ha34
12ha34 20.09.2020 um 15:33:58 Uhr
Goto Top
Die Ports bzw. ESP sind offen, vom Handy kann ich über strongSwan eine Verbindung aufbauen.

Die pfSense baut die Verbindung über PPOE zum Provider selber auf. Sollte also alles passen.

Was ich auch nicht einordnen kann, wenn ich auf dem Windows PC die Prüfung des EKU in der Registry abschalte, wird auch eine Verbindung aufgebaut.

Ich weiß nicht so recht was icht testen und ob ich auf pfSense oder Win Seite suchen soll.
Mitglied: aqui
aqui 20.09.2020 um 17:10:34 Uhr
Goto Top
Vermutlich ist das de facto ein Win 10 Client Problem und auch noch Client spezifisch, denn es lässt sich hier wie gesagt nicht nachstellen in einer frisch aufgesetzten Win 10 Pro Edition 1909.
Hattest du vorher ggf. mal einen anderen bzw. externen IPsec Client installiert und den nicht wieder vollständig entfernt ?
Mitglied: 12ha34
12ha34 20.09.2020 um 20:16:40 Uhr
Goto Top
Einen IPsec nicht aber Openvpn und einen Cisco Client, Cisco kann ich aber nicht deinstallieren.
Ich werde mal weiter forschen und wenn es was zu berichten gibt, posten.

Danke noch mal und Grüße
Mitglied: coloridolo
coloridolo 21.09.2020 um 08:51:57 Uhr
Goto Top
Hallo,

vielen Dank für die präzise Anleitung zur Einrichtung eines VPN mit OPNSense/pfsense! Hat bei mir mit OPNSense fast problemlos funktioniert. Es gab nur zwei kleine Stolpersteine bei der Einrichtung des Windows 10 Clients (Win 10 Pro 2004):

  • ich musste ein P12-Zertifkat (das den User-Key enthält) importieren, damit die Verbindung zustande kommt (nicht die CRT-Datei)
p12-cert
  • der Befehl für die Konfiguration des Routing musste noch den Parameter '-AllUserConnection' enthalten, damit das lokale Netz verfügbar war:

Evtl. ist das in anderen Fällen auch so.
Mitglied: aqui
aqui 21.09.2020 um 09:12:20 Uhr
Goto Top
Einen IPsec nicht aber Openvpn und einen Cisco Client, Cisco kann ich aber nicht deinstallieren.
Bahnhof ?? Was sollen uns diese kryptischen Zeilen sagen ???
Wenn der Cisco IPsec Client drauf ist dann wird es ganz sicher daran liegen. Du kannst aber auch mit dem Cisco Client eine IPsec Verbindung auf die pfSense eröffnen. Du musst da dann nur Xauth aktivieren.
Das sollte dann aber in einem separaten Thread passieren um hier das Tutorial nicht unnötig aufzublähen.

@coloridolo
Danke für das Feedback. Ggf. behandelt das der OPNsense Fork etwas anders ?!
Mitglied: 12ha34
12ha34 02.10.2020 um 16:55:01 Uhr
Goto Top
Ich habe noch ein wenig zum "ike-authentifizierung-anmeldeinformationen sind nicht akzeptabel" Problem gesucht und eine Lösung (zumindest für mich) gefunden, die ich euch nicht vorenthalten will. Ich habe ein Zertifikat erzeugt wie oben in der Anleitung beschreiben erzeugt. Ich habe dann zusätzlich die kürze Variante "pfsense.meinedomain" und den DynDNS-Namen der pfSense als Alternative DNS-Namen ergänzt und konnte mich ohne Fehler von meinem WIN10 einwählen.
Vielleicht hilft es ja auch anderen weiter.

Grüße
Mitglied: aqui
aqui 02.10.2020 um 17:06:37 Uhr
Goto Top
Danke für das Feedback. Hab es oben mal als optional im Tutorial mit hinzugefügt da das bei richtiger und vollständiger DNS Konfig eigentlich nicht nötig ist. Aber sicher ist sicher und wenns geholfen hat ist das ja Beweis genug... ;-) face-wink
Mitglied: 12ha34
12ha34 03.10.2020 um 10:14:53 Uhr
Goto Top
Meinst du die DNS Konfiguration der pfSense? Ich habe noch mal Kombinationen mit und ohne verkürztem DNS Eintarg und DynDNS Hostnamen probiert und tatsächlich hat am Ende der alternative FQDN Eintrag des Hostnamen des DynDNS Service den Erfolg für mich gebracht.

Grüße und danke noch mal für die Anleitung.
Mitglied: aqui
aqui 03.10.2020 um 10:35:16 Uhr
Goto Top
Wichtig ist das man im General Setup einen FQDN Namen vergibt wie pfsense.intern oder wenn man mehr Standard konform sein möchte wie pfsense.meinnetz.home.arpa. (Siehe dazu auch HIER !)
Zudem sollte man den DNS auf der Firewall richtig einstellen. Forwarder (Default) immer deaktivieren, denn der fragt statt den Provider DNS immer die Root Server was sehr ungünstig ist in Bezug auf Antwortszeiten.
Deshalb:
back-to-topDNS Forwarder deaktivieren:
dns1
back-to-topDNS Resolver AKTIVIEREN:
dns2
back-to-top...und dort den Forwarding Mode aktivieren:
dns3

Dann sollte es eigentlich auch immer mit nur Hostname und FQDN laufen. Es schadet aber nicht wenn man deine "kurze" Version zur Sicherheit auch immer mit dazu nimmt um sicher zu gehen das es klappt.
Mitglied: HanDoku
HanDoku 12.10.2020 aktualisiert um 13:17:39 Uhr
Goto Top
Eine Frage zum Abschnitt Mobiles Client IPsec VPN auf der pfSense einrichten: Den Clients wird ja eine IP aus einem ansonsten ungenutzten IP Netzwerk zugewiesen, bspw. die 10.10.10.1. Können Sie dann trotzdem "ganz normal" über die IP-Adressen des LANs, an das sie so angebunden sind auf die anderen Netzwerkteilnehmer zugreifen, also bspw. über 192.168.0.18?

Und über welche IP sind die Clients dann aus dem LAN erreichbar? Bei unserem alten Router haben Sie eine Adresse aus dem IP-Pool des LAN bekommen.
Mitglied: aqui
aqui 12.10.2020 aktualisiert um 13:44:43 Uhr
Goto Top
Den Clients wird ja eine IP aus einem ansonsten ungenutzten IP Netzwerk zugewiesen, bspw. die 10.10.10.1
Das ist richtig ! Das ist quasi das VPN IP Segment. Das kannst du dir so vorstellen als ob das ein weiteres, separates IP Netzwerk ist was noch an der Firewall klemmt und über sie geroutet wird. Genauso wie mit einem Kabel nur das es eben VPN ist. Clients im VPN Netz haben dann also immer eine 10.10.10.0er Absender IP. Was du übrigens auf dem Client auch ganz einfach selber ansehen kannst wenn du dir die NIC IP Adressen einmal ausgeben lässt (ipconfig = Winblows, ifconfig = unixoide OS).
Können Sie dann trotzdem "ganz normal" über die IP-Adressen des LANs, an das sie so angebunden sind auf die anderen Netzwerkteilnehmer zugreifen
Ja natürlich ! Warum sollten sie es deiner Meinung nach denn nicht können ? Wenn du ein WLAN Segment an der Firewall dran hast können diese Clients doch auch auf die LAN Clients zugreifen ?!
Voraussetzung ist natürlich das du entsprechende Firewall Regeln eingerichtet hast, das ist klar.
Und über welche IP sind die Clients dann aus dem LAN erreichbar?
Na komm....diese simple Frage solltest du dir doch eigentlich auch selber beantworten können ! Das hast du ja oben schon gemacht: <Deine eigenen Worte:> "Den Clients wird ja eine IP aus einem ansonsten ungenutzten IP Netzwerk zugewiesen, bspw. die 10.10.10.1" Warum fragst du also ??
Alle VPN Clients kannst du aus dem LAN natürlich auch über ihre 10.10.10.x IP Adresse erreichen. Simplestes IP Routing, Netzwerk Grundschule 1. Klasse. ;-) face-wink
Bei unserem alten Router haben Sie eine Adresse aus dem IP-Pool des LAN bekommen.
Dann hast du aber ganz sicher kein IPsec Native als VPN Protokoll benutzt sondern L2TP mit IPsec. Da sieht die (IP) Welt etwas anders aus.
Mitglied: HanDoku
HanDoku 13.10.2020 um 11:29:00 Uhr
Goto Top
Wir bekommen einen Verbindungsaufbau hin, werden aber regelmäßig nach wenigen Minuten mit der Meldung "failed to establish CHILD_SA, keeping IKE_SA / no acceptable proposal found" wieder rausgekickt. Das betrifft sowohl Mac OS als auch iOS.

Kennst Du den Effekt? So sieht das Log aus:


Mitglied: aqui
aqui 13.10.2020 aktualisiert um 12:02:33 Uhr
Goto Top
Bitte poste hier nur die wirklich relevanten Log Outputs oder eröffne besser einen neuen Thread dafür um das Tutorial hier nicht zu überfrachten.
no acceptable proposal found ist ein sicheres Indiz dafür das die Krypto Credentials, sprich Verschlüsselung und Hashing, NICHT übereinstimmen bei dir zw. Client und Server !
VPN Client und Server können sich nicht auf ein gemeinsames Verfahren einigen. Das zeigt das du irgendwo bei der Einstellung dieser Vorgaben entweder auf dem Client oder dem Server einen Fehler gemacht hast.
Dadurch das du nicht in der Lage warst die relvanten Messages zu filtern muss man jetzt leide raten ob das aktuelle oder ältere sind ! :-( face-sad

Sinnvoll ist es da immer im Logging Setup die Reihenfolge auf Forward/Revers Display zu setzen so das man die aktuellsten Messages OBEN am Anfang sieht und VOR der Einwahl mit "Reset Messages" diese im Settings Menü löscht !
log1
log2
Ein Test mit aktueller Firmware und Windows 10 (2004) sowie Mac mit latest Catalina OS verlief erwartungsgemäß stabil und fehlerfrei.
Mitglied: HanDoku
HanDoku 14.10.2020 um 08:53:46 Uhr
Goto Top
Wenn es bei Dir augenscheinlich geklappt hat, dann hast Du einfach nicht lange genug auf den Verbindungsabbruch gewartet. Es gibt einen lange bekannten Bug unter MacOS und iOS, der bei Einsatz von Perfect Forward Secrecy (PFS) beim ersten Rekey (je nach System nach 8 bis 20 Minuten) für einen Abbruch sorgt.

Da für Phase 2 die PFS key group auf 14 = 2048 bit steht, erwartet die pfSense beim Rekey
bekommt vom Clienten aber nur

Es fehlt also clientseitig MODP_2048 und die Verbindung wird getrennt. Interessant ist auch diese Zusammenfassung des Problems.

Ich habe die PFS key group für Phase 2 testweise mal auf "none" gestellt und siehe da, die Verbindung ist stabil.

Als Lösungsvorschlag werden einige Umstellungen im Apple eigenen VPN-Profil über den Apple Configurator diskutiert. Das ist dann aber eben nicht mehr einfach "out of the box", sondern erfordert manuelle Eingriffe. Das Tutorial ist in diesem Punkt also irreführend.

Wie könnte man das ohne den Apple Configurator elegant lösen?
Mitglied: aqui
aqui 14.10.2020 aktualisiert um 09:36:22 Uhr
Goto Top
Ist ja von 2017 und die Frage ob es in aktuellen Catalina bzw. iOS 13 oder 14 auch noch der Fall ist.
Ansonsten einfach statt native IPsec dann L2TP als VPN Protkoll nutzen:
https://administrator.de/tutorial/pfsense-vpn-l2tp-ipsec-protokoll-mobil ...
Mitglied: HanDoku
HanDoku 14.10.2020 aktualisiert um 09:44:12 Uhr
Goto Top
Unter iOS 13 besteht das Problem noch. Wie "schlimm" wäre es denn, PFS für Phase 2 dauerhaft auszuschalten?
Mitglied: aqui
aqui 14.10.2020 aktualisiert um 09:59:18 Uhr
Goto Top
Bei entsprechend größerer Verschlüsselung 256Bit und höher ist das weniger kritisch. PFS verhindert salopp gesagt das mitgeschnittener Verkehr später doch noch entschlüsselt werden kann wenn man den Sitzungsschlüssel errechnen kann. https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy
Mit 256Bit und einer entsprechend großen DH Group dauert es mit derzeitiger Rechnerhardware mehrere tausend Jahre. Was sich in ferner Zukunft aber ändern könnte.
Mitglied: the-buccaneer
the-buccaneer 15.10.2020 um 22:36:41 Uhr
Goto Top
Man lernt hier immer dazu. ;-) face-wink

@aqui: Würdest du es wagen auch für AES-128 und DH-2 eine Entschlüsselungszeit zu schätzen? ;-) face-wink ;-) face-wink

LG
Buc
Mitglied: aqui
aqui 16.10.2020 um 08:43:57 Uhr
Goto Top
Auch das sind mit mehreren Nvidia GPUs noch Jahre... Aber wer weiss was die CIA und die anderen Sclapphüte so an HW in ihren Rechenzentren haben ?!? Ein Schelm wer Böses dabei denkt... ;-) face-wink
Das es ihnen aber zunehmend Probleme bereitet sieht man daran:
https://www.heise.de/news/Five-Eyes-plus-Durchgehende-Verschluesselung-g ...
Aber solange die halbe Welt RDP weiter ohne VPN ins Internet stellt ist alles OK.
Mitglied: the-buccaneer
the-buccaneer 17.10.2020 um 03:59:25 Uhr
Goto Top
Zitat von @aqui:

Auch das sind mit mehreren Nvidia GPUs noch Jahre...

Definiere bitte "mehrere" ;-) face-wink

Aber wer weiss was die CIA und die anderen Sclapphüte so an HW in ihren Rechenzentren haben ?!? Ein Schelm wer Böses dabei denkt... ;-) face-wink
Seit 2001 haben die quasi unbegrenzte Mittel. Die schicken dir tausende GPU's auf den Hals, wenn denen das wichtig ist, befürchte ich...

Das es ihnen aber zunehmend Probleme bereitet sieht man daran:
https://www.heise.de/news/Five-Eyes-plus-Durchgehende-Verschluesselung-g ...
Jo. So ist das heute.

Aber solange die halbe Welt RDP weiter ohne VPN ins Internet stellt ist alles OK.

Schlimmer noch: "Ungepatcht" ;-) face-wink

CU
Buc
Mitglied: aqui
aqui 17.10.2020 um 09:56:48 Uhr
Goto Top
Thema für einen separaten Thread und wir sollten das Tutorial hier nicht unnötigerweise aufblähen !! ;-) face-wink
Mitglied: the-buccaneer
the-buccaneer 23.10.2020 um 01:34:09 Uhr
Goto Top
Na gut. Aber das prinzipielle Thema "Sicherheit von VPN_Verbindungen in Abhängigkeit von der eingesetzten Verschlüsselungsstärke" tangiert da ja schon. Insbesondere da sich das auf eher schwacher Hardware mit der PfSense schon auf die Performance auswirkt.
All das Recycling und das Energiesparen nützt ja nix mehr wenn die Sicherheit leidet.

Aber die "großen" Fragen gerne woanders. ;-) face-wink

e mare libertas
Buc
Mitglied: aqui
aqui 23.10.2020 um 12:45:14 Uhr
Goto Top
Prinzipiell hast du recht aber "normale" Hardware supportet heute durchgehend AES-NI bzw. sollte dies supporten wenn man VPNs einigermaßen sicher und performant betreiben will.
Aber wie gesagt....andere Baustelle. ;-) face-wink
Mitglied: justas
justas 07.01.2021 um 23:43:07 Uhr
Goto Top
Danke für die tolle Anleitung!

Ich habe seit Jahren eine APU2 mit pfSense (aktuell 2.4.5-p1). OpenVPN-Server läuft stabil, es gibt aber ein bekanntes Problem bei Filetransfers (die Übertragungsrate von SMB über OpenVPN bricht ins Bodenlose ein). In der Hoffnung das Problem mit IPSec-Tunnel zu lösen habe ich nach dieser Anleitung den IPsec-Server konfiguriert.

Verbindung klappte sofort, komme leider mit meinem Halbwissen an einigen Stellen nicht weiter.

Über IP-Adressen komme ich an die lokalen Ressourcen. Aber nicht über DNS.

Problem 1:
-> DNS Resolver kommt nicht ins Spiel. Unter "Mobile Clients" wird der gleiche DNS-Server an die Clients geschickt (192.168.1.1) wie über OpenVPN. Die IP-Adresse läßt sich zwar vom Client anpingen, aber es kommen keine DNS-Einträge

Problem 2: Keine Verbindung vom Windows 10-Client ins Internet. SplitTunneling ist nicht gesetzt, default Gateway in der Windows GUI ist angeklickt. In der Phase2-Entry ist Local Network 0.0.0.0/0. Bei Firewall/NAT/Outbound wurde eine Rule erstellt, die den Zugriff aufs Gateway vom IPSec-Netz erlaubt.

Die Firewall-Logs haben nichts zu dem Thema. Die IPSec-Logs kann ich noch nicht richtig lesen und weiß nicht, nach welchen Einträgen ich suchen muss.
Mitglied: aqui
aqui 08.01.2021 aktualisiert um 08:39:45 Uhr
Goto Top
Bei Firewall/NAT/Outbound wurde eine Rule erstellt, die den Zugriff aufs Gateway vom IPSec-Netz erlaubt.
Das ist unsinnig und überflüssig. Hier reicht die stinknormale Default NAT Regel. Vermutlich hast du damit den Internet Zugriff "verschlimmbessert". An den Default NAT Regeln muss man nie rumfummeln. :-( face-sad
IPsec Logs sind doch nicht relevant wenn sich deine VPN Clients sauber verbinden können. Wenn das fehlerfrei klappt steht da auch nix relevantes.
Was sagt denn ein route print bei aktivem Win 10 VPN Client ?? Wo zeigt die Default Route hin ? Das ist doch logischerweise das erste was man macht um zu checken wo der Client Traffic hingeht wenn das VPN aktiv ist. Ebenso ein ipconfig -all um zu checken welche DNS Server aktiv sind. 😉
Mitglied: justas
justas 08.01.2021 um 18:35:51 Uhr
Goto Top
Zitat von @aqui:

Bei Firewall/NAT/Outbound wurde eine Rule erstellt, die den Zugriff aufs Gateway vom IPSec-Netz erlaubt.
Das ist unsinnig und überflüssig. Hier reicht die stinknormale Default NAT Regel. Vermutlich hast du damit den Internet Zugriff "verschlimmbessert". An den Default NAT Regeln muss man nie rumfummeln. :-( face-sad

Das ist in meinem Fall vermutlich notwendig, da NAT auf manuell steht. Ich habe noch einen VPN-Client auf der pfSense und nutze diesen z.T. als Gateway. Ich glaube, dieser ist sogar nach Deiner Anleitung konfiguriert :-) face-smile

IPsec Logs sind doch nicht relevant wenn sich deine VPN Clients sauber verbinden können. Wenn das fehlerfrei klappt steht da auch nix relevantes.
Was sagt denn ein route print bei aktivem Win 10 VPN Client ?? Wo zeigt die Default Route hin ? Das ist doch logischerweise das erste was man macht um zu checken wo der Client Traffic hingeht wenn das VPN aktiv ist.
Das kann ich aktuell nicht checken, weil ich irgendwas an der Konfig verdreht habe, die lokalen Geräte sind nicht mehr über IP erreichbar.
Gestern habe die Option "Standard Gateway für das Remotenetzwerk verwenden" mehrfach hin- und her geändert. Bin mir ziemlich sicher, dass bei Aktivierung das ganze Traffic über den VPN-Client geroutet wurde, weil nix kam :-) face-smile

>Ebenso ein ipconfig -all um zu checken welche DNS Server aktiv sind. 😉
Das habe ich gestern als Erstes gemacht, der DNS-Server war korrekt: 192.168.1.1, die lokalen Geräte waren per IP erreichbar, aber nicht per DNS. nslookup hat zwar auch den DNS korrekten DNS-Server gefragt, aber nichts geliefert.

Ich denke, das Problem ist nicht auf dem Client, sondern in der pfSense-Config.
Mitglied: aqui
aqui 08.01.2021 um 18:38:57 Uhr
Goto Top
nslookup hat zwar auch den DNS korrekten DNS-Server gefragt, aber nichts geliefert.
Dann ist es doch aber ein DNS Problem ?!

Wenn das hier länger wird würde ich dich bitten einen separaten Thread zu eröffnen mit Verweis hierauf um das Tutorial hier nicht mit Troubleshooting Threads zu überfrachten.
Mitglied: justas
justas 09.01.2021 um 12:19:23 Uhr
Goto Top
Zitat von @aqui:

nslookup hat zwar auch den DNS korrekten DNS-Server gefragt, aber nichts geliefert.
Dann ist es doch aber ein DNS Problem ?!

Danke für den Tipp! Habe einen Eintrag im DNS-Resolver / Access Lists erstellt und das Problem ist gelöst.

Es wundert mich, dass
- Ich hier als Erster das Problem habe
- Bei OpenVPN-Verbindungen zur gleichen pfSense-Box dieser Eintrag im DNS-Resolver nicht notwendig ist.
Mitglied: aqui
aqui 09.01.2021 aktualisiert um 12:26:04 Uhr
Goto Top
Bei OpenVPN kommt es darauf an WELCHEN oder welche DNS Server du mit der Server Konfig per push an den Client übergibst. In der Regel sind das dann interne DNS um interne bzw. lokale Hostnamen auflösen zu können. Mit Internet DNS geht das natürlich nicht.
Siehe auch HIER dazu.
Das kannst du bei IPsec auch machen. Das geht in den Advanced Settings, dort kann man auch dedizierte DNS an den Client übergeben.
Interessant wäre einmal ein Screenshot deiner Lösung, dann profitieren auch andere hier davon. Der tiefere Sinn eines Forums... ;-) face-wink
Mitglied: justas
justas 12.01.2021 aktualisiert um 10:32:31 Uhr
Goto Top
Zitat von @aqui:

Interessant wäre einmal ein Screenshot deiner Lösung, dann profitieren auch andere hier davon. Der tiefere Sinn eines Forums... ;-) face-wink

Gerne!

Das sind die OpenVPN-Settings.
pfsense - openvpnsettings1

DNS-Settings und Virtual IP in IPSec:
pfsense - ipsec - dns+virtual ip

Virtual IP Settings für Mobile Clients:
pfsense - ipsec - mobile clients

Ich dachte, das müsste reichen, hat es aber nicht!
Die Lösung war eine neue Entry im DNS-Server:
pfsense - dns-resolver - access lists

Hier wird der gleiche VirtualIP-Range angegeben, wie bei Mobile Clients:
pfsense - dns-resolver - access lists entry

Das hat mein Problem gelöst. Man kann sehen, es wird derselbe DNS-Server an OpenVPN- und IPSec-Clients übergeben. Mir ist leider noch nicht klar, warum der Eintrag bei Access Lists nur für IPSec-Clients notwendig ist.
Mitglied: aqui
aqui 12.01.2021 um 12:16:57 Uhr
Goto Top
👍
Mitglied: andrelung
andrelung 28.01.2021 um 23:55:30 Uhr
Goto Top
Ich habe auch das Problem, dass keine DNS-Auflösung für lokale Geräte erfolgt. Das Fehlerbild ist etwas seltsam:

nslookup pcname -> server can't find pcname: NXDOMAIN
nslookup pcname.meinedomain ->
server can't find pcname.meinedomain: NXDOMAIN

Mit Angabe des DNS-Servers funktioniert es dann plötzlich:
nslookup pcname.meinedomain 192.168.88.1

Ich nutze MacOS 11 und habe auch schon versucht DNS-Server und Such-Domain manuell in der VPN-Verbindung hinzuzufügen. Leider ohne Erfolg. Der Kommentarverlauf wurde nach unten immer wärmer - aber leider klappt die Lösung von @justas nicht bei mir. Kann es sein, dass du auf dem Weg dorthin noch eine andere Einstellung gesetzt hast?
Mitglied: aqui
aqui 29.01.2021 um 12:36:04 Uhr
Goto Top
Kommt weil dein lokaler DNS Server nicht an die Clients übergeben wird. Wenn du ein ipconfig -all eingibst zeigt er doch den aktiv genutzten DNS Server des Clients !
Im "Mobile Client" Setup kannst du einen dedizierten DNS Server angeben der bei VPN Einwahl an den Client gesendet werden und dann sein Primary DNS ist. Da sollte dann die IP deines internen DNS Servers rein !
mob
Mitglied: andrelung
andrelung 29.01.2021 um 13:34:56 Uhr
Goto Top
Hi @aqui und danke auch nochmal an dich für die grandiose Anleitung! Die Option "Provide a DNS server list to clients" habe ich bereits gesetzt. Ein
mag mein Mac nicht, aber ein
gibt die aktiven DNS-Settings aus. Ich hab mal versucht alles auf einen Screenshot zu bringen:
dns_screenshot

Mit besagtem Mac bin ich gerade zuhause und wähle mich per IPSEC-VPN ins Remotenetz ein. Ganz rechts im Screenshot sind die (MacOS-)DNS-Settings der VPN-Verbindung, so wie sie nach dem Import des Profils vom ipsec-profile-wizard eingetragen sind. Die dnslookup Ergebnisse sind exakt dieselben, wenn ich dort manuell die DNS-IP und die Suchdomain eintrage.

Deine Tipps zum DNS-Resolver habe ich auch bereits gesetzt (der Service "DNS Forwarder" ist ausgeschaltet):
dns_resolver

Es kommt mir vor als würde ich irgendeinen dummen Fehler machen. Sieht du auf Anhieb etwas oder kannst du mich in die richtige Richtung schupsen?
Mitglied: aqui
aqui 29.01.2021 um 14:03:43 Uhr
Goto Top
mag mein Mac nicht, aber ein
👍 ...würde meiner auch nicht mögen. 🤣
Wie man ja am Screenhot sieht hat der Client ja den richtigen DNS Server auch bekommen so wie es sein soll.
Es kann dann also nicht mehr am VPN selber oder der DNS Weiterleitung liegen, das ist klar.
Das kann dann nur noch die DNS Auflösung in Client oder Server selbst betreffen, die FW ist dann raus.
Bei Winblows gabs mal irgendwas das man irgendwo einen Haken setzen muss das er nicht nur FQDN Namen auflöst sondern auch einfache Hostnamen. Das war irgendwas mit der "Suchdomain" oder sowas. Vermutlich gilt das auch für MacOS was man in den Systemsettings ja auch ein richten kann. Ich bin jetzt aber nicht so der DNS Guru.
Der pfSense eigene DNS ist ja gar nicht involviert wenn der VPN Client primär dann deinen internen DNS Server erhält, denn dann gehen die DNS Requests ja direkt dahin und die Firewall transportiert eben nur die IP Pakete und macht DNS technisch gar nichts.
Der Fehler wäre dann direkt da und nicht mehr am Netz oder Firewall.
Mitglied: kugman
kugman 04.07.2021 um 21:30:02 Uhr
Goto Top
Herzlichen Dank für die Anleitung! Super detailliert und verständlich erklärt!

Ich stolpere über ein Problem. Die Verbindung wird von meinem Windows 10 Client problemlos aufgebaut, ich kann die Verbindung dann auch auf der Pfsense sehen. Das einzige, was ich nicht sehe, sind Datenpakete. Keine.
wenn ich mir auf dem Windows 10 Client die Routingtabelle anschaue ist mir auch klar, warum auf der Pfsense nix ankommt. Ich habe keine Route in das pfsense-LAN.
Ich habe in Phase 2 sowohl "LAN subnet" als auch "Netzwerk" mit dem entsprechenden Netz ausprobiert, ich bekomme keine Route an den Client übermittelt.
Zum Spaß hab ich die Route dann mal manuell gesetzt, dann komm ich sofort durch, aber das ist ja keine Lösung...

wo habe ich meinen Denkfehler?

vielen lieben Dank für Eure Unterstützung
Markus
Mitglied: kugman
kugman 04.07.2021 um 21:39:15 Uhr
Goto Top
Zitat von @kugman:

...ich bekomme keine Route an den Client übermittelt.

ok - kommando zurück: ich hatte einen Zahlendreher in dem dritten Powershell-Command... für nen doofen Admin kann keiner was :-) face-smile Fehler korrigiert und läuft wie ein Örgele :-) face-smile

Gruß Marku
Mitglied: aqui
aqui 05.07.2021 um 10:33:20 Uhr
Goto Top
👍 Perfekt !
Mitglied: Ricky99
Ricky99 07.07.2021 um 13:57:47 Uhr
Goto Top
Hallo zusammen,
hallo aqui,

zunächst vielen Dank für das detaillierte Tutorial. Ich hab' das auf einer pfSense erfolgreich zum Laufen gebracht.
Allerdings hab' ich noch ein kleines Problemchen mit dem Routing des gesamten Verkehrs durch das VPN.
Ich kann mich mit einem Linux-Client auf die pfSense verbinden, allerdings bekomme ich via ipinfo.io trotzdem nur die "öffentliche" IP des jeweiligen Providers (probehalber einen Hotspot mit dem Phone für den PC eröffnet).
In den Einstellungen für die mobilen Clients habe ich mit und ohne die Option "Liste mit zugänglichen Netzwerken dem Gerät zur Verfügung stellen" probiert, beides ohne Erfolg.
In den Phase2-Einstellungen stehen der Modus auf "tunnel" und das lokale Subnetz auf 0.0.0.0/0.
Hat noch jemand eine Idee, wie ich den gesamten Traffic durchs VPN routen kann ?
Grüße

RV.
Mitglied: aqui
aqui 07.07.2021 um 14:43:44 Uhr
Goto Top
mit dem Routing des gesamten Verkehrs durch das VPN.
Was sagt ein ip route show auf deinem Rechner ?
Möglich das er dort 2 Default Routen anzeigt aber die lokale eine bessere Metrik hat als das Tunnelinterface. Dann musst du die Metrik des lokalen Interfaces etwas schlechter machen und dein Linux Client hat dann als primäre Route immer den Tunnel als Default wenn er aktiv ist.
Mitglied: Ricky99
Ricky99 07.07.2021 um 15:09:21 Uhr
Goto Top
Hallo aqui,

danke für die flinke Reaktion.

Die IP aus dem 192.168.43.0/24er-Netz ist diejenige, die der PC aktuell vom Hotspot erhält.
Grüße

RV.
Mitglied: aqui
aqui 07.07.2021 aktualisiert um 17:11:28 Uhr
Goto Top
Mmmh, ist der VPN Client aktiv als du ip route show eingegeben hast ? Man sieht keinerlei Tunnel Interfaces und Adressierung ? :-( face-sad
Was sagt den ip addr bei aktivem VPN ?
Mitglied: Ricky99
Ricky99 08.07.2021 aktualisiert um 09:58:46 Uhr
Goto Top
Hallo aqui,

hier mal alles komplett:

Beste Grüße

RV.
Mitglied: aqui
aqui 08.07.2021 aktualisiert um 12:15:41 Uhr
Goto Top
Mmmhhh...aus irgendeinem Grund wird die Default Route nicht übernommen. Ich müsste das nachstellen. Ein ipsec statusall wäre ggf. noch ganz hilfreich.
Mit welchem IPsec Client machst du den Zugang ? Sollte es Strongswan sein kannst du dein Setup posten ?
Das hier ist lesenswert dazu: https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitT ...
P.S.:
Wenn das mehr werden sollte wäre es besser du eröffnest einen separaten Thread mit Verweis hier um das Tutorial hier nicht unnötig weiter mit Troubleshooting Threads aufzublähen.
Mitglied: Ricky99
Ricky99 08.07.2021 um 12:38:22 Uhr
Goto Top
Hallo aqui,

hier das von Dir geforderte Log bzw. die Config:


StrongSwan Conf:


Falls wir hier nicht weiter kommen, eröffne ich natürlich einen separaten Thread.
Besten Dank schon mal für Deine Bemühungen.
Grüße

RV.
Mitglied: aqui
aqui 08.07.2021 um 12:43:23 Uhr
Goto Top
Du könntest testweise mal rightsubnet auf 0.0.0.0/0 setzen aber vermutlich führt das dazu das der Tunnel dann nicht mehr hochkommt ?!
Mitglied: Ricky99
Ricky99 08.07.2021 aktualisiert um 13:12:56 Uhr
Goto Top
Hallo aqui,

nach dem Studium Deines Doku-Tips habe ich genau das versucht, Ergebnis:

Der Tunnel startet normal, allerdings habe ich keinerlei Kontakt zum Internet.

Grüße

JD.
Mitglied: aqui
aqui 08.07.2021 um 15:51:40 Uhr
Goto Top
allerdings habe ich keinerlei Kontakt zum Internet.
Was heisst das jetzt genau ?? Kannst du rein nur DNS Hostnamen nicht auflösen (nslookup, dig). Sprich also nur DNS schlägt fehl oder kannst du auch nackte Internet IP Adressen wie z.B. 8.8.8.8 nicht pingen ? Oder beides ?
Der etwas laienhafte Ausdruck "Internet" ist für ein zielführendes Troubleshooting leider immer etwas nichtssagend. :-( face-sad
Mitglied: Ricky99
Ricky99 08.07.2021 um 18:21:07 Uhr
Goto Top
Hallo aqui,

entschuldige, die Fehlerbeschreibung war ausreichend behämmert, mea culpa.
Nach erneutem Versuch mit
auf dem Client läuft alles Bestens, möglicherweise hatte ich beim letzten Versuch schlicht kein GSM-Netz am Hotspot.
Ich kann Quad9 pingen, Websites laden und bekomme eine öffentliche IP aus dem GSM-Netz. Danke für Deinen Doku-Tip.
Eine Besonderheit hab' ich noch durch Testen herausgefunden:
Verbinde ich mich mit einem Linux-Client, läuft alles wie gewünscht: Ich habe Zugriff auf das gesamte LAN, ins I-Net und mein gesamter Traffic wird durchs VPN geroutet, abzulesen an der entsprechenden öffentlichen IP.
Versuche ich das Gleiche mit einem Obst-Telefon mittels onboard-VPN-Client, habe ich lediglich Zugriff auf das LAN, nicht ins I-Net.
Beste Grüße und Danke für Deine Geduld

RV:
Mitglied: aqui
aqui 08.07.2021 um 19:02:10 Uhr
Goto Top
Danke für dein Feedback und klasse das es damit klappt am Strongswan. Werde ich gleich im Tutorial nachtragen. ;-) face-wink
Was das Obst Telefon anbetrifft sollte das m.E. generell einen Gateway Redirect machen, sprich also immer alles in den Tunnel routen auch wenn man Split Tunneling konfiguriert hat.
Müsste ich aber auch mal testen. Hilfreich dafür sind die HE.NET Tools:
https://apps.apple.com/de/app/he-net-network-tools/id858241710
Mitglied: coloridolo
coloridolo 03.08.2021 um 17:09:52 Uhr
Goto Top
Hallo,

hab vor einer ganzen Weile mal mit dieser Anleitung ein VPN mit OPNSense installiert. Beim Versuch einen Linux-Client dafür einzurichten, bin ich mit den hier aufgelisteten Schritten nicht weitergekommen, aber hab dann diese Anleitung bei OPNSense gefunden, die für mein Ubuntu-System sehr einfach funktioniert hat:

https://docs.opnsense.org/manual/how-tos/ipsec-rw-linux.html

Vielleicht hilft es ja jemandem weiter.

Schöne Grüße und noch mal danke für das super Tutorial mit long-term-support ;-) face-wink
Mitglied: aqui
aqui 04.08.2021 um 11:46:37 Uhr
Goto Top
Danke für das Feedback. 👍🏻
Habs mal mit in die Linksammlung oben mit aufgenommen !
Mitglied: admNut89
admNut89 02.09.2021 um 22:41:37 Uhr
Goto Top
Hallo zusammen,

erstmal danke für die tolle und detaillierte Anleitung.

Ich denke, dass ich mich korrekt daran habe, dennoch funktioniert mein VPN nicht.

Kurz zu meinem Setup: Das LAN meiner pfsense hat das Netzwerk 10.168.1.0/24. Darüber hinaus ist es in verschiedene VLANs segmentiert. Eines davon heißt VPN und hat das Netzwerk 10.168.30.0/24. Wäre schön, wenn alle aktiven VPN clients dann dort drinne sind.

Ich habe die VPN Verbindung mit Windows und Android versucht. Beides funktioniert nicht.

Android:

Ich habe als Typ "IKEv2/IPSec MSCHAPv2" ausgewählt. Die Serveradresse ist korrekt. Als IPSec-Serverzertifikat habe ich das gemäß der Anleitung Erstellte ausgewählt. Unter "IPSec Identifier" steht "nicht verwendet". Benutzername und Passwort gemäß den Einstellungen unter "Pre-shared secret".
Android zeigt kurz "Verbinden..." an und nach ca. 2s springt es auf "Nicht erfolgreich". Die Logs in der pfsense zeigen folgendes:


Scheint irgnedwas mit der Authentification zu sein, aber meine Zertifikate müssten korrekt sein. Habe mich sklavisch an die Anleitung gehalten.

Windows:

Den client habe ich mit der PowerShell eingerichtet. Die IP Adresse habe ich korrekt angepasst, "-SplitTunneling" weggelassen, um allen Verkehr durch den Tunnel zu leiten, und beim Kommando "Add-VpnConnectionRoute" habe ich das Netzwerk 10.168.30.0/24 angegeben (hier bin ich mir nicht sicher, was genau da rein muss).

Windows sagt bei der Verbindung "IKE-Authentifizierung-Anmeldeinformationen sind nicht aktzeptabel." Laut vorangegangener Kommentare deutet das auf Zertifikat-Probleme hin. Aber nochmal, ich habe es geprüft und weiß nicht, was ich falsch gemacht haben soll.

Das Log der pfsense zeigt folgendes:


Auch hier schein es wieder auf die Zertifikate hinzudeuten. Ich habe diese aber sowohl bei Windows als auch unter Android ordnungsgemäß installiert.

Kann mir jemand weiterhelfen?

Weitere Frage: Welche IP kommt unter "Provide a virtual IP address to clients" genau rein?

Danke für eure Hilfe:) face-smile

Kris

P.S.: In Phase 2 habe ich unter "Local Network", "Network" und "0.0.0.0/0" eingestellt, sodass jeglicher Traffic durch den Tunnel geht. Richtig?
Mitglied: aqui
aqui 03.09.2021 aktualisiert um 09:31:12 Uhr
Goto Top

Ja, da hast du Recht ! Bei deiner Zertifikats Generierung ist gehörig was schief gegangen das zeigt die Meldung "received 45 cert requests for an unknown ca" und die dadrüber liegenden CA Fehler.
CA ist die Certificate Authority !
Man kann nur vermuten das du entweder die CA vergessen hast VORHER anzulegen oder vergessen hast das neue Server Zertifikat auf diese CA zu legen.
Das eine Client Authentisierung mit einem falschen oder fehlerhaften Zertifikat natürlich in die Hose geht und in einer Fehlfunktion endet ist klar.
Du hast sie vermutlich ordnungsgemäß importiert aber bei der Generierung selber einen Kardinalsfehler begangen !
Fazit:
  • Zertifikate komplett löschen.
  • Neue CA anlegen wie im Tutorial beschrieben
  • Server Zertifikat erzeugen auf diese neue CA laut Tutorial
  • Neues Zert. exportieren und in die Clients importieren.
  • Firewall in den Advanced Settings auf die neue CA und Zert. umstellen und alte CA und Zert. löschen dann rebooten
Das sollte es gewesen sein... ;-) face-wink
sodass jeglicher Traffic durch den Tunnel geht. Richtig?
Das ist richtig aber ja auch erstmal nicht dein wirkliches Problem. ;-) face-wink

P.S.: Du solltest ggf. besser deine IP Adressen im Log anonymisieren denn mit https://www.ip-tracker.org/lookup.php sagt das viel über dich... ;-) face-wink
Mitglied: admNut89
admNut89 03.09.2021 um 15:34:17 Uhr
Goto Top
Ich habe es jetzt mehrfach, wie in der Anleitung gemacht, ich habe deine Punkte berücksichtigt, ich habe darauf geachtet, dass der common name korrekt ist, dass die alten Zertifikate gelöscht wurden und dass "Serverzertifikat" eingestellt ist. Dennoch funktioniert es nicht. Ich bin die Anleitung wirklich langsam und gewissenhaft durchgegangen. Ich habe das Gefühl, dass ich einen Fehler mache, der mir nicht bewusst ist oder dass ich die Anleitung an irgendeiner Stelle falsch interpretiere. Die pfsense ist up to date und wurde jedes mal rebootet. Welche Fehler kann man denn, während der Erstellung klassischerweise noch machen?
Mitglied: aqui
aqui 03.09.2021 aktualisiert um 16:26:42 Uhr
Goto Top
Trotzdem meckert er ja die CA an das die ungültig bzw. nicht existent ist was so nicht sein darf und auf einen Fehler hinweist. Da stimmt also etwas nicht.
Du solltest um das Tutorial hier nicht weiter mit Troubleshooting aufzublähen einen seperaten Thread aufmachen und hier darauf referenzieren.
In dem Thread dann mal Screenshots der Zertifikatsverwaltung posten. Irgendwas stimmt da nicht.
Ggf. hast du mit Sonderzeichen da gearbeitet was auch zu Problemen führt aber das kann man dann nur an Screenshots bzw. der genauen Konfig sehen. Ohne diese Infos ist das wenig zielführend.

Alternativ kannst du auch mal die L2TP VPN Option nehmen mit dem bordeigenen Client. L2TP nutzt keine Zertifikate so das das Setup da etwas einfacher ist.
https://administrator.de/tutorial/pfsense-vpn-mit-l2tp-ipsec-protokoll-f ...
Mitglied: LKleemann
LKleemann 18.09.2021 um 16:44:42 Uhr
Goto Top
Hallo @aqui, Hallo zusammen,

vielen Dank für dieses tolle Tutorial @aqui. Einfach und eigentlich auch verständlich 🙈 Leider bekomme ich immer noch folgende Fehlermeldung:


Kann mir bitte jemand bei diesem Problem helfen und mir einen Denkanstoß geben?

Vielen Dank im Voraus und euch noch ein schönes Wochenende
Mitglied: aqui
aqui 18.09.2021 aktualisiert um 19:47:40 Uhr
Goto Top
Leider bekomme ich immer noch folgende Fehlermeldung:
Mit welchem Client denn ?? :-( face-sad
Ich hab es gerade nochmal mit der aktuellsten Ver. 2.5.2 nachgestellt und mit einem Win 10 (21H1), einem Mac Book Pro (latest Big Sur) und einem iPhone X getestet.
Alles fehlerfrei ohne irgendwelche Probleme. Dein Problem lässt sich leider nicht reproduzieren...
In dem Log Schnipsel oben sind auch per se erstmal keine Fehler im Protokoll Handling zu entdecken.
Hast du testweise mal die L2TP Variante probiert ?
Mitglied: LKleemann
LKleemann 19.09.2021 um 14:15:12 Uhr
Goto Top
Bitte entschuldige meine ungenauen Informationen. Anbei genauere Informationen:

Getestet habe ich mit einem Windows 10 Laptop:

Ich würde gerne den VPN-Tunnel mittels Opensense wegen der API-Schnittstelle herstellen, kann ich bei dieser ebenfalls einen L2TP Server einrichten? Dann würde ich einfach einen L2TP Tunnel verwenden :) face-smile

Vielen Dank im Voraus
Mitglied: aqui
aqui 19.09.2021 aktualisiert um 18:34:30 Uhr
Goto Top
Getestet habe ich mit einem Windows 10 Laptop:
Wie bereits oben gesagt. Hier ebenfalls mit genau der Win 10 Version getestet und klappt vollkommen problemlos ! Der o.a. Fehler war auch leider nicht reproduzierbar.
kann ich bei dieser ebenfalls einen L2TP Server einrichten?
Nein, die OPNsense hat leider den L2TP nicht per Default an Bord wie die pfSense.
Ich kann im Moment nicht sagen ob bei der OPNsense der L2TP Server über die Package/Plugin Verwaltung installierbar ist. Müsste ich auch checken...
Mitglied: markushi
markushi 09.10.2021 um 10:26:30 Uhr
Goto Top
Hallo,

ich habe nach der Anleitung gearbeitet und kann mich auch erfolgreich vom (Android) Handy aus mit meinem VPN verbinden. Leider klappt es mit Win10 Pro nicht, da wird folgendes ausgegeben:
IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel

Das Log zeigt folgendes:

Der Import des Zertifikats war erfolgreich und es wird im Zertifikatsspeicher angezeigt. Ich habe auch schon eine CA erstellt sowie ein neues Server Zertifikat. Am Handy gehts auch jetzt wieder (nach dem Import des neuen Zertifikats), aber der Win Fehler ist gleich geblieben.
Hat jemand eine Idee wo das Problem liegen könnte?

Gruß - Markus
Mitglied: aqui
aqui 09.10.2021 um 11:40:15 Uhr
Goto Top
Das Firewall Log (bzw. der obige Auszug) zeigt so erstmal keinerlei Fehler.... Der erfolgreiche Android Login zeigt das du generell erstmal alles richtig gemacht hast so das der Fehler sehr wahrscheinlich am Windows Client liegt.
Hast du den Windows Client über die obigen Powershell_Kommandos entsprechend customized ?
Was sagt das Windows Log ?
Mitglied: markushi
markushi 09.10.2021 um 18:10:46 Uhr
Goto Top
Ich hab die VPN Verbindung nicht über die Powershell angelegt, das kann ich aber mal testen. In das Windows Log hab ich noch gar nicht reingeschaut, steht meist eh nix verwertbares drin...
Ich werde wieder berichten was dabei rausgekommen ist.

Bis dahin: Danke dir! Für dein Tutorial und deine Hilfe 👌👏
Mitglied: aqui
aqui 10.10.2021 aktualisiert um 16:02:32 Uhr
Goto Top
Danke für die 💐
Versuchs mal über die Powershell. Das ist meist wasserdichter und weniger Fehler anfällig...
Mitglied: markushi
markushi 12.10.2021 um 19:09:30 Uhr
Goto Top
Ich habe jetzt mal versucht, die VPN Verbindung unter Linux (Mint) zum Laufen zu bekommen. Da klappts leider auch nicht, aber man sieht jetzt im VPN Log folgendes:


Die * sind von mir. Bei IP-Fritzbox steht die IP (192.168.....), welche opnSense von der Fritzbox bekommen hat. Diese ist natürlich nicht identisch mit meinem DynDNS Einwahlnamen, von daher ist die nächste Meldung "no matching peer config found" nachzuvollziehen. Aber wieso möchte das System jetzt dieses Netz finden? Im Zertifikat ist ja auch der DynDNS Name drin als Referenz.
Das ganze funktioniert unter Android immer noch problemlos. Sehr merkwürdig das Ganze...

Hast du noch eine Idee???
Mitglied: aqui
aqui 13.10.2021 aktualisiert um 18:41:07 Uhr
Goto Top
unter Linux (Mint) zum Laufen zu bekommen.
Wie hast du das gemacht ? Strongswan ? Wenn Strongswan dann dessen Konfig bitte posten. Es wäre dann aber zielführend einen separaten Thread dafür zu eröffnen um das Tutorial nicht weiter unnötig aufzublasen.
Hast du dich ggf. mal an die original OPNsense Anleitung gehalten ?:
https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-mschapv2.html

Ich habe das Setup noch nicht unter OPNsense getestet nur unter pfSense und da rennt es fehlerlos.
Ich werde das unter OPNsense mal aufsetzen, testen und berichten.
Mitglied: markushi
markushi 13.10.2021 um 21:35:51 Uhr
Goto Top
Ja ich hab das mit Strongswan eingerichtet und ich hab auch nach der Anleitung von opnsense die gesamte Einrichtung versucht. Das hab ich gemacht weil deine Anleitung in einigen Punkten doch sehr stark von den Konfigurationsoptionen der opnsense abgewichen ist. Ich werde am Wochenende nochmal alles löschen und es erneut versuchen. Vielleicht habe ich ja doch irgendwo einen Fehler gemacht.
Und ich werde dann einen separaten Thread im Forum eröffnen falls es nicht klappt. Andernfalls schreibe ich hier nochmal kurz rein.
Mitglied: aqui
aqui 14.10.2021, aktualisiert am 15.10.2021 um 09:47:18 Uhr
Goto Top
So, OPNsense Test war, wie zu erwarten, ebenso erfolgreich wie das Setup der pfSense oben.
Hier das Client VPN Setup der OPNsense als kurzes HowTo:

back-to-topZertifikats Einstellungen

Das Erstellen der Zertifikate geht analog zu der der pfSense oben im Menü System --> Trust. Es ist zuerst eine CA zu erstellen und deren Zertifikat als Datei zu sichern
Dann das Server Zertifikat erstellen. Hier gilt wieder aufzupassen das als Common Name der Hostname der OPNsense dort eingesetzt wird z.B. opnsense.test.home.arpa
Wichtig ist hier unbedingt auf die korrekte Schreibweise zu achten. Auch Groß- Kleinschrift ist relevant ! Am besten cut and pastet man den Firewall Hostnamen direkt aus der WebGUI Seite um sicherzugehen.
Unter Alternative Names diesen Hostnamen als DNS nochmals eingeben und zusätzlich die Kurzform nur mit dem Hostnamen ohne Domain Suffix z.B. opnsense
Wer einen DynDNS Hostnamen für den Zugang MUSS diesen hier auch eingeben. (Hier im Beispiel durch "0a630190.nip.io" (10.99.1.144) sympolisiert !)
Wenn du eine feste WAN IP hast sollte diese on Top auch noch mit "IP" angegeben werden.
Ein Klick auf die Zert. Info sollte alle diese SANs immer anzeigen:
opn1
Das ist extrem wichtig für den Windows 10 onboard Client.

back-to-topMobile Client Setup

Auch hier identisch zum obigen pfSense Setup:
mob1
mob2

back-to-topIPsec Phase 1 Setup

Auch das identisch zu oben:
p1-1

back-to-topIPsec Phase 12 Setup

Ebenso identisch:
p2

back-to-topÜbersicht Phase 1 und Phase 2

tunset

back-to-topWindows 10 Client

Auch der wird ganz normal über das Netzwerk Center unter "VPN" als IKEv2 Verbindung hinzugefügt:
opns

Fertisch !
Damit rennt das dann fehlerlos

Fazit:
Works as designed ! 😉
Mitglied: markushi
markushi 18.10.2021 um 11:33:09 Uhr
Goto Top
Hallo aqui,

vielen Dank an dieser Stelle nochmal für deine Bemühungen! Nach dieser Beschreibung funktioniert das Ganze jetzt bei mir auch mit OPNsense!

Gruß - Markus
Mitglied: aqui
aqui 18.10.2021 um 12:21:30 Uhr
Goto Top
👏 👍
Heiß diskutierte Beiträge
question
Windows 11 Upgrade nicht möglichben1300Vor 1 TagFrageWindows 1114 Kommentare

Guten Morgen ! ich habe einen Gaming PC, mit folgende Spezifikationen: Leider kann ich diesen nicht auf Windows 11 upgraden: Welche Optionen bleiben mir, um ...

question
Was ich benötige ist ein guter Wechselrahmen 5,25"Lefty0815Vor 1 TagFrageFestplatten, SSD, Raid8 Kommentare

Hallo an alle, ich such mir noch einen Wolf :-) Was ich benötige ist ein Wechselrahmen 5,25" für eine zwei oder drei 3,5Zoll Festplatten (SATA ...

question
Exchange Server - Wege, anonymes Senden zu verbietenDerWoWussteVor 1 TagFrageExchange Server11 Kommentare

Ich grüße Euch! Ziel 1: Alle PCs sollen Warnmeldungen per E-Mail geskriptet und anonym versenden können. In diesen Skripten handelt das Computerkonto und im Skript ...

question
WLAN Lösung für Gästehaus Vereinjohannes-meyerVor 22 StundenFrageLAN, WAN, Wireless8 Kommentare

Hallo, ich betreue die IT eines Vereins, der zwei Gebäude mit Gästebetrieb betreibt. Es sind regelmäßig an die 30 bis 50 Geräte verbunden. Ich hab ...

question
Neuinstallation NetzwerkBurQueVor 13 StundenFrageNetzwerkgrundlagen13 Kommentare

Hallo ich hab die Aufgabe bekommen ein Netzwerk in einem neuen Gebäude einzurichten bzw. mir dazu Gedanken zu machen. Raumsituation. Im Keller steht ein Serverschrank ...

question
SMTP Relay Server gelöst MacLeodVor 1 TagFrageExchange Server10 Kommentare

Hallo zusammen. Vorwort: Habe das hier bei Exchange eingeteilt, betrifft aber Mailserver Versand allgemein. Bei einem Kunden mit einem Kerio Mailserver werden neben dem üblichen ...

question
Multi-WAN-Netzwerk fürs StudentenwohnheimHutzeljaegerVor 7 StundenFrageLAN, WAN, Wireless17 Kommentare

Hallo allerseits. Für die Internetversorgung unseres Studentenwohnheims muss ich nun sehen, dass ich eine kostengünstige Lösung eines Multi-WAN Netzwerks hinbekomme, wohl am besten per Multi-WAN-Bonding. ...

question
Drei Fragen zum Internet Explorer gelöst UserUWVor 22 StundenFrageWebbrowser4 Kommentare

1) Der IE lässt sich unter Windows 10 deaktivieren, aber nicht physisch deinstallieren. Heißt das, dass IE-Funktionalitäten "unter der Haube" auch von Windows 10 genutzt ...