22.02.2019

6667

Pfsense VPN - 1. Client OK - 2. will nicht

Moin,

und schon jetzt Danke für euere Antworten! Also:

Ich habe nach der Anleitung von aqui (IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten) einen Tunnel für einen mobilen Benutzer gebastelt. Alles gut der läuft!

Aber kaum kommt der zweite Rechner ins Spiel passiert das:

Nicht das ich das Teil nicht schon kenne - Aber da waren eben auch Fehler drin, die ich entdecken und beheben konnte! Nun läuft der erste Rechner und belegt das Gegenteil.... Dabei habe ich als einzige Abweichung in der pfSense unter VPN / IPsec / Pre-Shared Keys einen weiteren Benutzer nach dem selben Muster hinzugefügt. Testweise nutzen sogar beide Rechner den gleichen Internetzugang! Auch der funktionierende Benutzer des ersten Rechners geht auf den 2. nicht.

Ist meine Herangehensweise so richtigt? Also jeder User einen Eintrag unter Pre-Shared Keys? ...oder benötigt sogar jeder User die ganze Config (Cert, P1, P2, usw.) einzeln?

und noch was (wenn ich schon mal dabei bin

):
Wie bekomme ist es hin das jeder VPN-User eine eigene IP bekommt? Wenn ich unter VPN / IPsec / Pre-Shared Keys eine Virtuelle IP eintrage, hat dies keine Wirkung und es wird immer die aus dem Pool von VPN / IPsec / Mobile Clients verwendet. Ich möchte später damit über die Regelsätze bestimmen wer wo hin darf...

Danke, das Ihr einen sense-Greenhorn auf´s Fahrrad helft!

Viel Grüße
Giraffe

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 420788

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

Ausgedruckt am: 22.11.2024 um 11:11 Uhr

24 Kommentare

Neuester Kommentar

Im Tutorial hatte ich im Testbetrieb die gleichen Credentials bei allen Clients und OS benutzt.
Du hast aber Recht was deine Anforderung angeht, die macht Sinn.
Normal sollte nur User und Passwort reichen. Das Zertifikat gilt zentral für den Dialin Server, sprich die VPN.
Du musst das Server Zertifikat aber auch beim User 2 importieren, das ist klar. Hast du vermutlich auch gemacht, oder ?
Siehst du irgendwas im IPsec Log wenn der 2te User sich einloggt ?? (Vorher ggf. löschen wegen der Übersichtlichkeit)
Auch das Client Log vom Windows wäre interessant.
Ich teste das hier ebenfalls mal.

Hi aqui,
ja, das Zetifikate habe ich drin! Sogar extra auch nochmal "frisch" exportiert...

Was mich so irritiert ist, dass auch genau die selbe Config, also sogar mit dem User vom 1. Rechner, nicht geht. Würde eigentlich für ein Fehler an Nr. 2 sprechen! Aber was?

Sorry, wegen der Logs, die gehören eigentlich gleich dazu. Ich dachte eigenlich eher das meine Herangehensweise gundlegend falsch ist und habe es mir daher erstmal geschenkt... Dat Zeug steht in der Firma - Liefere ich später nach!

Wegen der IP reagiert Nr. 1 schon auf Änderungen unter mobiler Client, was ja schon mal belegt das die IP-Vergabe über die pfsense grundlegend geht. Aber wenn ich beim User eine Adresse eintrage, scheint diese nicht zu gelten und der Client bekommt trotzdem unverändert die aus dem Client-Pool. Ich habe auch schon versucht unter mobile Clients den Pool auszuschalten (und die Adresse aus dem User gewissermaßen zu erzwingen), aber dann geht leider gar nichts mehr. Ist eben vermutlich die Frage welche Einstellung wann greift.... Wie ist das überhaupt? Hat der Tunnel dann sowas wie seinen eigenen DHCP? ...wie die anderen Schnittstellen? oder macht das IPsec das irgendwie "intern" ?

DANKE!

Grüße
Giraffe

SO!!!

Hier mal das log aus der pfsense:

Feb 23 10:32:39 	charon 		12[NET] <con-mobile|22> sending packet: from 192.168.6.100[4500] to 109.41.64.65[4609] (644 bytes)
Feb 23 10:32:39 	charon 		12[NET] <con-mobile|22> sending packet: from 192.168.6.100[4500] to 109.41.64.65[4609] (1236 bytes)
Feb 23 10:32:39 	charon 		12[ENC] <con-mobile|22> generating IKE_AUTH response 1 [ EF(2/2) ]
Feb 23 10:32:39 	charon 		12[ENC] <con-mobile|22> generating IKE_AUTH response 1 [ EF(1/2) ]
Feb 23 10:32:39 	charon 		12[ENC] <con-mobile|22> splitting IKE message (1808 bytes) into 2 fragments
Feb 23 10:32:39 	charon 		12[ENC] <con-mobile|22> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> sending end entity cert "CN=192.168.6.100, C=DE, ST=Schleswig-Holstein, L=Eutin, O=Zobels Computerdienste, OU=IT"  
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> authentication of 'CN=192.168.6.100, C=DE, ST=Schleswig-Holstein, L=Eutin, O=Zobels Computerdienste, OU=IT' (myself) with RSA signature successful  
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> peer supports MOBIKE
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP6_SERVER attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP6_DNS attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP6_ADDRESS attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP4_SERVER attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP4_NBNS attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP4_DNS attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> processing INTERNAL_IP4_ADDRESS attribute
Feb 23 10:32:39 	charon 		12[IKE] <con-mobile|22> initiating EAP_IDENTITY method (id 0x00)
Feb 23 10:32:39 	charon 		12[CFG] <con-mobile|22> selected peer config 'con-mobile'  
Feb 23 10:32:39 	charon 		12[CFG] <22> candidate "con-mobile", match: 1/1/1052 (me/other/ike)  
Feb 23 10:32:39 	charon 		12[CFG] <22> candidate "bypasslan", match: 1/1/24 (me/other/ike)  
Feb 23 10:32:39 	charon 		12[CFG] <22> looking for peer configs matching 192.168.6.100[%any]...109.XX.XX.XX[192.168.43.224]
Feb 23 10:32:39 	charon 		12[IKE] <22> received 36 cert requests for an unknown ca
Feb 23 10:32:39 	charon 		12[IKE] <22> 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 

...und hier dann die Events von Nr.2:

Protokollname: Application
Quelle:        RasClient
Datum:         23.02.2019 10:32:41
Ereignis-ID:   20227
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DESKTOP-5MNEGP1
Beschreibung:
CoID={AF22274B-C43E-47ED-B835-4CDFFEF17D6E}: Der Benutzer "DESKTOP-5MNEGP1\User" hat eine Verbindung mit dem Namen "pfSense" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 13801.  
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">  
  <System>
    <Provider Name="RasClient" />  
    <EventID Qualifiers="0">20227</EventID>  
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-02-23T09:32:41.114318100Z" />  
    <EventRecordID>5258</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-5MNEGP1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{AF22274B-C43E-47ED-B835-4CDFFEF17D6E}</Data>
    <Data>DESKTOP-5MNEGP1\User</Data>
    <Data>pfSense</Data>
    <Data>13801</Data>
  </EventData>
</Event>

Protokollname: Application
Quelle:        RasClient
Datum:         23.02.2019 10:32:40
Ereignis-ID:   20224
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DESKTOP-5MNEGP1
Beschreibung:
CoID={AF22274B-C43E-47ED-B835-4CDFFEF17D6E}: Die Verbindung mit dem RAS-Server wurde von Benutzer "DESKTOP-5MNEGP1\User" hergestellt.  
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">  
  <System>
    <Provider Name="RasClient" />  
    <EventID Qualifiers="0">20224</EventID>  
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-02-23T09:32:40.473732900Z" />  
    <EventRecordID>5257</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-5MNEGP1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{AF22274B-C43E-47ED-B835-4CDFFEF17D6E}</Data>
    <Data>DESKTOP-5MNEGP1\User</Data>
  </EventData>
</Event>

Protokollname: Application
Quelle:        RasClient
Datum:         23.02.2019 10:32:40
Ereignis-ID:   20223
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DESKTOP-5MNEGP1
Beschreibung:
CoID={AF22274B-C43E-47ED-B835-4CDFFEF17D6E}: Der Benutzer "DESKTOP-5MNEGP1\User" hat eine Verbindung mit dem RAS-Server hergestellt, verwendet wurde das Gerät: "  
Server address/Phone Number = 1XX.XX.XX.XX
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN".  
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">  
  <System>
    <Provider Name="RasClient" />  
    <EventID Qualifiers="0">20223</EventID>  
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-02-23T09:32:40.473732900Z" />  
    <EventRecordID>5256</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-5MNEGP1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{AF22274B-C43E-47ED-B835-4CDFFEF17D6E}</Data>
    <Data>DESKTOP-5MNEGP1\User</Data>
    <Data>
Server address/Phone Number = 1XX.XX.XX.XX
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN</Data>
  </EventData>
</Event>

Protokollname: Application
Quelle:        RasClient
Datum:         23.02.2019 10:32:40
Ereignis-ID:   20222
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DESKTOP-5MNEGP1
Beschreibung:
CoID={AF22274B-C43E-47ED-B835-4CDFFEF17D6E}: Der Benutzer "DESKTOP-5MNEGP1\User" versucht, eine Verbindung zum RAS-Server für die Verbindung mit dem Namen "pfSense" mit dem folgenden Gerät herzustellen:   
Server address/Phone Number = 18X.XX.XX.XX
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">  
  <System>
    <Provider Name="RasClient" />  
    <EventID Qualifiers="0">20222</EventID>  
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-02-23T09:32:40.473732900Z" />  
    <EventRecordID>5255</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-5MNEGP1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{AF22274B-C43E-47ED-B835-4CDFFEF17D6E}</Data>
    <Data>DESKTOP-5MNEGP1\User</Data>
    <Data>pfSense</Data>
    <Data>
Server address/Phone Number = 18X.XX.XX.XX
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN</Data>
  </EventData>
</Event>

Protokollname: Application
Quelle:        RasClient
Datum:         23.02.2019 10:32:40
Ereignis-ID:   20221
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DESKTOP-5MNEGP1
Beschreibung:
CoID={AF22274B-C43E-47ED-B835-4CDFFEF17D6E}: Der Benutzer "DESKTOP-5MNEGP1\User" hat eine VPN-Verbindung mit einem all-user-Verbindungsprofil mit dem Namen "pfSense" angewählt. Die Verbindungseinstellungen lauten:   
Dial-in User = rz
VpnStrategy = IKEv2
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = EAP <Microsoft: Gesichertes Kennwort (EAP-MSCHAP v2)>
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = No
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = 
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">  
  <System>
    <Provider Name="RasClient" />  
    <EventID Qualifiers="0">20221</EventID>  
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2019-02-23T09:32:40.458109200Z" />  
    <EventRecordID>5254</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-5MNEGP1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{AF22274B-C43E-47ED-B835-4CDFFEF17D6E}</Data>
    <Data>DESKTOP-5MNEGP1\User</Data>
    <Data>VPN</Data>
    <Data>all-user</Data>
    <Data>pfSense</Data>
    <Data>
Dial-in User = rz
VpnStrategy = IKEv2
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = EAP &lt;Microsoft: Gesichertes Kennwort (EAP-MSCHAP v2)&gt;
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = No
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = 
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes</Data>
  </EventData>
</Event>

13801 ist glaube ich ein Problem mit dem Zertifikat. Was aber doch auch nicht passen kann, denn Nr.1 geht doch mit em selben Cert...

Was mich dann noch umtreibt ist dies:

aqui hatte in der Anleitung hier testuser eingetragen (und ich rz). Aber dies passt doch nach den Hinweis der pfsense-Entwickler nicht dazu. Ein Fehler hier könnte evtl. doch auch in einem Cert-Fehler am Client auffallen, oder nicht? Anderer Seites ist es ja "nur" das Login.... Dann fragt sich wieder wieso es dafür eine IP brauchen soll... und warum geht Nr.1?

Braucht Nr.2 evtl ein eigenes Server-Cert? - mit dem entsprechendem Eintrag im SAN? Sollte unter "Identifikator" die IP stehen die der Client erhalten soll? ...und dann im dem seperanten Server-Cert vorhanden sein muss?

Leider kann ich das jetzt nicht Testen - mache ich dann mal nach dem Wochenende...

DANKE!

VG Giraffe

Du solltest oben die Logs etwas anonymisieren wegen der CN Einträge !

Hat der Tunnel dann sowas wie seinen eigenen DHCP?

Ja, so ähnlich.
Was den Identifier anbetrifft ist das ein Textstring also eine einzigartige Identifikation. IP ist da immer gefährlich wenn man am Mobilclient mit wechselnden IPs arbeitet. Besser ist dann FQDN oder Email String.
Mal sehen was der Test sagt...

Du solltest oben die Logs etwas anonymisieren wegen der CN Einträge !

Recht hast du! Jedoch seht Ihr auch nur die Adresse hinter dem ersten Router! Mit war es lieber nicht soviel zu ändern und den Fehler auf die Spur zu kommen.

Ich habe nun mal zur selben CA ein weiters Cert angelegt und dieses in P1 getauscht. In dem neuen Cert habe ich eine E-Mail-Adresse eingebaut. Diese Adresse habe ich dann auch als Username (bei den Keys) eingetragen. Das CA-Cert dann neu importiert und: Fehler immernoch da!

VG
Giraffe

Nein, das ist auch klar. Die Email dient zum verifizieren der IPsec Verbindung an sich, mit dem User Login (Xauth) hat das nichts zu tun, das ist separat zu sehen.
Ich teste das heute oder morgen mal genau.

So, was lange währt....
Testaufbau im Grunde wie hier. Internet simuliert wieder das 10er Netz.
pfSense Standard Konfig mit NAT am WAN Port usw. alles nach Tutorial.
Im lokalen LAN der pfSense ist ein Raspberry Pi mit der IP 192.168.1.106 als Testhost.
Im IPsec User Setup 3 User eingerichtet:

User1 und User3 sind zwei Windows 10 Rechner, User2 ist ein MacBook mit MacOS.
Der Moment der Wahrheit...

User1 eingeloggt vom Win10 PC... Fehlerlos !
User2 MacBook... Fehlerlos !

Check im GUI der pfSense:

Fehlerlos....

User3 eingeloggt vom Win10 PC... Fehlerlos !

Windows 10 PC:

Ping Check W10:

Dito. MacBook: (mit user2 Credentials !)

Ping Check MacBook:

 MacBook:~ user$ ping 192.168.1.106
PING 192.168.1.106 (192.168.1.106): 56 data bytes
64 bytes from 192.168.1.106: icmp_seq=0 ttl=63 time=3.195 ms
64 bytes from 192.168.1.106: icmp_seq=1 ttl=63 time=9.110 ms
64 bytes from 192.168.1.106: icmp_seq=2 ttl=63 time=9.052 ms 

Verwendete Windows 10 PS Kommandos zum Einrichten der VPN Verbindung:

Add-VpnConnection -Name "Lab-pfSense" -ServerAddress "10.99.1.99" -TunnelType IKEv2 -EncryptionLevel Required -AuthenticationMethod EAP -SplitTunneling -AllUserConnection

Set-VpnConnectionIPsecConfiguration -ConnectionName "Lab-pfSense" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru

Add-VpnConnectionRoute -ConnectionName "Lab-pfSense" -DestinationPrefix 192.168.1.0/24 -PassThru 

Die Win 10 Checks des User3 sind analog. Alles problemlos.
Zusätzlich wurde noch ein User4 eingerichtet und auf einem iPhone installiert und ein Ping Check mit den HE-Tools zeigte ebensowenig Auffälligkeiten wie oben.

Fazit:
Dein Fehler lässt sich absolut nicht nachvollziehen und man kann hier nur vermuten das du irgendwo einen Fehler in der Einrichtung der VPN Verbindung auf den Win 10 Rechnern gemacht hast !

Moin aqui,

erstmal danke das du dir die Mühe gemacht hast und das ganze sogar nochmal nachgebaut hast.

Zitat von @aqui:
Fazit:
Dein Fehler lässt sich absolut nicht nachvollziehen und man kann hier nur vermuten das du irgendwo einen Fehler in der Einrichtung der VPN Verbindung auf den Win 10 Rechnern gemacht hast !

Würde ich auch sagen! Und wenn einer geht und einer nicht, du dann deine Anleitung nun auch noch bestätigst hast du mehrfach recht! Aber trozdem wird es langsam dünne... Was solls! Also habe ich auf dem Rechner nochmal die Verbindung rausgeschmissen, das Cert gelöscht. Dann das Cert neu aus der Firewall geholt und deine 3 Shell-Befehle 1:1 reinkopiert. Einizige Abweichung zu deiner Version ist die IP-Adresse. Hier meine "Arbeitsnachweise" (-; :

Mehr kann man doch nun nicht falsch machen, oder? Einzige Fehlerquelle ist nun noch das Passwort - Aber da schwöre ich jetzt mal!!!

Nun, ist guter Rat, mal wieder Teuer! Wat, nu?

Steht der Versuchsaufbau noch? Das mit den unterschiedlichen IPs (zugewiesen beim UserKey) würde mich auch nochmal interessieren.... Ich mag dich ja schon gar nicht mehr danach Frage, aber könntest du bitte da auch noch mal nachschauen??? DANKE!

Ich gehe jetzt mal grübeln...

DANKE, für deine wirklich fachkundige Hilfe!

VG
Giraffe

Steht der Versuchsaufbau noch?

Ja steht noch ! Hab ihn gerade dazu benutzt das Tutorial jetzt noch mit dem Linux Client abzuschliessen.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Und....
Nicht das du denkst ich führ dich hinters Licht:

OK ich werde jetzt nochmal einen 2ten Windows Client aufsetzen und dann mit 2 Win 10 Clients und unterschiedlichen Usernamen testen inklusive einem parallelen Login mit Apple und Linux mit User 3 und 4
Mal sehen....

Nicht das du denkst ich führ dich hinters Licht:

wieso sollte ich? Kenne wir das nicht alle - Es sollte gehen, tut es aber nicht...

2 Win-Clients sollen nicht gehen? Trotzdem, die Idee ist gut....

Ich habe eben übrigens in meiner pfSense dies hier entdeckt:

Es ist von den Clients keiner aktiv und diesen Eintrag bekomme ich auch mit neu starten nicht weg... Hat das was zu bedeuten?

VG
Giraffe

2 Win-Clients sollen nicht gehen? Trotzdem, die Idee ist gut....

Also wenn 3 unterschiedliche Clients gehen, dann gehen auch 2 oder 10 Winblows Clients, da hab ich keinerlei Zweifel !

Es ist von den Clients keiner aktiv

Wie meinst du das ??
Wenn einer eingeloggt ist und das LAN Interface der pfSense erforlgreich dauerpingt wird der da nicht angezeigt ??
Kann eigentlich nicht sein ! Nur wenn das VPN gar nicht aufgebaut ist ?!

> Es ist von den Clients keiner aktiv
Wie meinst du das ??

NEIN! - In dem Bild ist doch die eine Zeile drin mit dem Status - warte auf Verbindung.... Und diese Zeile ist immer da, eben auch wenn die Client (auch der einer der geht) nicht aktiv versuchen eine Verbindung herzustellen. Nicht mal durch einen Neustart der pfSense werde ich diesen Eintrag los! Ich schreib dir das, weil dein Sense diesen Eintrag nicht hat...

Inzwischen habe ich übrigens auch nochmal das Cert von Nr. 1 exportiert (also von dem Rechner) und in Nr. 2 importiert. Weiterhin habe ich es auch noch mal mit einen neuen User getestet. Ergebnis: ...frag nicht!

VG
Giraffe

Hast du die aktuelle FW drauf ?

SOOOO!!!!!

Nach dem mir einige Zeit der Kopf rauchte, habe ich ganz einfach mal eine andere Frage auf mich wirken lassen. Bis hier habe ich gebrütet wieso Nr. 1 geht und Nr. 2 nicht. Dann habe ich es etwas "sportlicher" gesehen und den Wettbewerb mit dir, lieber aqui eröffnet. Neue Frage:

Warum geht es beim aqui und bei mir nicht? (nicht das ich da irgendwie neidisch währe)

Also, wollte ich mal so sein wie du:
Vor die Firewall einen Switch (ganz einfach - ist ja eh ein Router vor) und da dann per Kabel die geliebte Nr. 2 dran. Dem dann eine passende IP gegeben und noch kurz in der VPN-Verbindung die öffentliche IP gegen die interne getauscht. Ein aqui sein ist doch so toll - Der Tunnel steht und geht!

Dann zurück mit dem Notebook an den Adroid-Hotspot - und schon geht nichts mehr! - An dem selben Hotspot ging Nr. 1 (auch bereits mit anderen Anschlüssen getestet) allerdings problemlos!

Nu, kommst du!

DANKE....

VG
Giraffe

An dem selben Hotspot ging Nr. 1 (auch bereits mit anderen Anschlüssen getestet) allerdings problemlos!

Kann das sein das da irgendwas mit deinen FW Regeln am WAN Interface nicht stimmt oder die falsch sind ?
Häng doch mal einen Switch an den WAN Port und schliesse da deine beiden Rechner an mit entsprechender WAN IP !
Dann versuchst du mal beide parallel mit unterschiedlichen Usernamen. Das sollte in jedem Falle klappen.
Beachte wenn du in einer Router Kaskade arbeitetst das du das Filtern der RFC1918 IPs dann deaktivierst (Haken entfernen)
Der Haken darf bzw. muss nur drin sein wenn die FW direkt am Internet hängt.
UDP 500, UDP 4500 und ESP müssen auf die WAN IP freigegeben sein.
Siehe auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Ich teste das jetzt auch mal.

So, auch mit 2 Windows 10 Clients Ergebnis wie erwartet. Hätte sicher auch mit 20 oder 200 Windows Clients so geklappt...

1.) Erster Schritt Zertifikat importiert auf dem 2ten Windows Client !

2.) Zweiter Schritt VPN mit der Powershell eingerichtet per Cut and Paste der obigen Zeilen:

4 Usernamen waren schon eingerichtet auf der pfSense.

3.) Client auf Windows Rechner 1 und Windows Rechner 2 gestartet !
(Username: user4 und user2)
Und....damit es auch gleich richtig spannend wird zusätzlich parallel Den Linux StronSwan Client (Username: user3) und das MacBook (Username: user1)

Das der Prozess unten mit Awaiting Connections angezeigt wird ist normal bei einem VPN Client Dialin.

Bzw. im Dashboard:

Das IPsec Log unter Status --> System Logs zeigt auch alles mit "Success" an und keinerlei Fehler !
Works as designed !

Nebenbei gefragt:
Das Zertifikat hast du auch auf deinem 2ten Client installiert, oder ?
Ich hatte das auch erst im Eifer des Gefechts vergessen und dann ist natürlich Nada mit Login, klar !

Häng doch mal einen Switch an den WAN Port und schliesse da deine beiden Rechner an mit entsprechender WAN IP !

wie schon geschrieben habe ich das mit Nr.2 gemacht. Nr.1 ist in zwischen beim Anwender, weshalb ich das nun nicht mehr testen kann.

Beachte wenn du in einer Router Kaskade arbeitetst das du das Filtern der RFC1918 IPs dann deaktivierst (Haken entfernen).

hab ich

UDP 500, UDP 4500 und ESP müssen auf die WAN IP freigegeben sein.

war ganz am Anfang. Dann stellte ich fest das Nr. 1 auch ohne geht und habe Sie dann (sicherer) wieder entfernt. Testweise habe ich die WAN nun mit einer Scheunentourregel aufgesperrt: Nix mit VPN bei Nr. 2! Währe auch unlogisch, den Nr. 1 belegt inzwischen täglich das zumindest ich diese Regeln nicht brauche. Übrigens geht Nr. 1 auch wenn der RFC1918 - Harken drin ist! Was ist nur soooo anders im Giraffe-Land???

Nebenbei gefragt:
Das Zertifikat hast du auch auf deinem 2ten Client installiert, oder ?

100x neu installiert - und sogar (wie heute mittag schon geschrieben) auch von Nr. 1 exportiert und dann auf Nr. 2 imporiert

Hätte sicher auch mit 20 oder 200 Windows Clients so geklappt...

ohne Internet dazwischen geht das bei mir auch - ist aber nicht so ganz Ziel der Übung...

Das Ganze hat irrendwie was damit zu tun, dass das Internet dazwischen ist. Ich habe Nr. 2 nun mal mit nach Hause genommen um einfach auch mal mit einem anderen Internetanschluss zu testen - na, ja, ist ja klar das eben auch nicht am Hotspot lang...

VG
Giraffe

Dann stellte ich fest das Nr. 1 auch ohne geht und habe Sie dann (sicherer) wieder entfernt.

Hast Recht, die FW legt diese automatisch an intern.
Der Haken mit den RFC1918 IPs MUSS aber in jedem Falle weg wenn du eine Router Kaskade mit der PfSense betreibst !!

auch wenn der RFC1918 - Harken drin ist!

Harken ?? https://de.wikipedia.org/wiki/Harke_(Werkzeug)

Das Ganze hat irrendwie was damit zu tun, dass das Internet dazwischen ist.

Sorry, aber das ist Unsinn. Das Internet ist IP und ein weltweiter Standard. Übrigens ist das obige Live übers Internet getestet. Das siehst du an den Client Absender IPs, denn das 192er Netz ist nicht das 10er Testnetz.
Das geht aus einem lokalen LAN via FritzBox an eine pfSense die direkt im Internet hängt. Keine Kaskade !
Einer der 4 Clients (MacBook) hat dann via VPN Tunnel das Webinterface der pfSense auf dem LAN Port (192.168.1.1) auf

Du kannst das ja auch Live selber testen.
Mache mit Tethering auf deinem Smartphone einen Hotspot auf, verbinde deinen Windows Rechner damit und logge dich dann via Mobilnetz auf deiner pfSense ein.
So hast du ein Live Szenario. Hast du ja vermutlich auch schon gemacht.
Fakt ist das dieses Setup wasserdicht funktioniert. Und das auch ganz sicher mit mehreren Clients. Die Ziel PfSense ist übrigens ein älteres APU Board was noch keine AES-NI HW Unterstützung hat wie die neueren Boards. Trotzdem schafft das Teil mit iPerf3 gemessen fast Wirespeed auf dem VPN.

Dein Client 2 hat irgendwo einen Fehler in der Einrichtung das ist klar. Vermutlich vergessen das Zertifikat zu importieren oder sowas.
Siehst du denn einen Fehler im IPsec Log ?

Harken ??

Wieso? gehst du nicht mit deiner Firewall an die Gartenarbeit?

ist jetzt raus, die Harke! geholfen hat es nichts...

Sorry, aber das ist Unsinn. Das Internet ist IP und ein weltweiter Standard.

Stimmt! Die Praxis beweiß was anderes! Wie geschrieben: Rechner am WAN geht - Über das Internet nicht!

Du kannst das ja auch Live selber testen.
Mache mit Tethering auf deinem Smartphone einen Hotspot auf, verbinde deinen Windows Rechner damit und logge dich dann via Mobilnetz auf deiner pfSense ein.

getestet per Mobile-Hotspot und einen normalen DSL - Es bleibt dabei: Mit Internet dazwischen geht es nicht! - Nur bei Nr. 1

Nun könnte man noch sagen das Nr. 2 Windows-Mäßig (Treiber oder so) nicht richtig läuft. Ich muss wohl mal einen dritten Rechner besorgen...

Siehst du denn einen Fehler im IPsec Log ?

hier mal das log von einen Versuch:

Mar 5 21:04:05 	charon 		09[CFG] vici client 2911 disconnected
Mar 5 21:04:05 	charon 		09[CFG] vici client 2911 requests: list-sas
Mar 5 21:04:05 	charon 		13[CFG] vici client 2911 registered for: list-sa
Mar 5 21:04:05 	charon 		09[CFG] vici client 2911 connected
Mar 5 21:04:00 	charon 		09[CFG] vici client 2910 disconnected
Mar 5 21:04:00 	charon 		13[CFG] vici client 2910 requests: list-sas
Mar 5 21:04:00 	charon 		12[CFG] vici client 2910 registered for: list-sa
Mar 5 21:04:00 	charon 		09[CFG] vici client 2910 connected
Mar 5 21:03:58 	charon 		09[NET] <con-mobile|18> sending packet: from 192.168.6.100[4500] to 84.158.xxx.46[61596] (644 bytes)
Mar 5 21:03:58 	charon 		09[NET] <con-mobile|18> sending packet: from 192.168.6.100[4500] to 84.158.xxx.46[61596] (1236 bytes)
Mar 5 21:03:58 	charon 		09[ENC] <con-mobile|18> generating IKE_AUTH response 1 [ EF(2/2) ]
Mar 5 21:03:58 	charon 		09[ENC] <con-mobile|18> generating IKE_AUTH response 1 [ EF(1/2) ]
Mar 5 21:03:58 	charon 		09[ENC] <con-mobile|18> splitting IKE message (1808 bytes) into 2 fragments
Mar 5 21:03:58 	charon 		09[ENC] <con-mobile|18> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> sending end entity cert "CN=192.168.6.100, C=DE, ST=Schleswig-Holstein, L=Eutin, O=Zobels Computerdienste, OU=IT"  
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> authentication of 'CN=192.168.6.100, C=DE, ST=Schleswig-Holstein, L=Eutin, O=Zobels Computerdienste, OU=IT' (myself) with RSA signature successful  
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> peer supports MOBIKE
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP6_SERVER attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP6_DNS attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP6_ADDRESS attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP4_SERVER attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP4_NBNS attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP4_DNS attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> processing INTERNAL_IP4_ADDRESS attribute
Mar 5 21:03:58 	charon 		09[IKE] <con-mobile|18> initiating EAP_IDENTITY method (id 0x00)
Mar 5 21:03:58 	charon 		09[CFG] <con-mobile|18> selected peer config 'con-mobile'  
Mar 5 21:03:58 	charon 		09[CFG] <18> candidate "con-mobile", match: 1/1/1052 (me/other/ike)  
Mar 5 21:03:58 	charon 		09[CFG] <18> candidate "bypasslan", match: 1/1/24 (me/other/ike)  
Mar 5 21:03:58 	charon 		09[CFG] <18> looking for peer configs matching 192.168.6.100[%any]...84.158.xxx.46[192.168.2.20]
Mar 5 21:03:58 	charon 		09[IKE] <18> received 37 cert requests for an unknown ca
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 55:e4:81:d1:11:80:be:d8:89:b9:08:a3:31:f9:a1:24:09:16:b9:70
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> 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
Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 4a:81:0c:de:f0:c0:90:0f:19:06:42:31:35:a2:a2:8d:d3:44:fd:08
Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 6e:58:4e:33:75:bd:57:f6:d5:42:1b:16:01:c2:d8:c0:f5:3a:9f:6e
Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 87:db:d4:5f:b0:92:8d:4e:1d:f8:15:67:e7:f2:ab:af:d6:2b:67:75
Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 30:a4:e6:4f:de:76:8a:fc:ed:5a:90:84:28:30:46:79:2c:29:15:70 

Spannend finde ich diese Zeilen:

Mar 5 21:03:58 	charon 		09[IKE] <18> received cert request for unknown ca with keyid 30:a4:e6:4f:de:76:8a:fc:ed:5a:90:84:28:30:46:79:2c:29:15:70 

Würde bedeuten das die CA des Clients (also Nr. 2) nicht passt. Kann aber nicht sein, weil ich das Cert nun wirklich x mal imporiert habe.....

Kann es sein das das Cert irregndwie im Windows hängengeblieben ist? ...oder Windows es irrgenwie überhaupt nicht nutzt?

VG
Giraffe

Ich habe mich nun nochmal um die Certs gekümmert. In deiner Anleitung findest du dazu dies:

Wo soll das Ding den nun hin? Computer oder User?

...überigens habe ich auf meiner Nr. 2 mal das Cert komplett entfernt - Der Fehler ist der selbe! Ergo: Windows berücksichtigt das Cert nicht....

VG
Giraffe

Über das Internet nicht!

Was ist denn DAS Internet ? Kleine Nuancen bei den Consumer Anschlüssen gibts da ja bekanntermaßen schon....
Das kann möglich sein wenn du z.B. einen billigen DS-Lite Anschluss besitzt oder einen Provider hast der CGN macht.
Da hast du dann generelle Probleme mit VPNs weil solche Kunden Anschlusstechniken sowas dann nicht, oder nur mit großen Klimmzügen, supporten.
Wenn du also solch einen Billigprovider hast ist das technisch gar nicht möglich. Guckst du auch hier:
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...

Wo soll das Ding den nun hin? Computer oder User?

Computer !
Steht doch auch so im Tutorial ("Lokaler Computer" !) !!!

Der Fehler ist der selbe! Ergo: Windows berücksichtigt das Cert nicht....

Da hast du dann aber ein ganz anderes Problem.
Dann ist dein Windows Rechner selber vermurkst !
Fakt ist, wie gesag, das das IKEv2 Dialin auf der pfSense fehlerfrei rennt. Millionen solcher Installationen weltweit, wie auch die obige, beweisen das ja.

Wenn du also solch einen Billigprovider hast ist das technisch gar nicht möglich.

Mit Nr. 1 geht es, an dem selben Hotspot... Was dafür spricht das es auch nichts mit dem Anschluss zu tun hat....

Steht doch auch so im Tutorial ("Lokaler Computer" !) !!!

...und im Bild steht "Benutzer" ...ist ja auch nur ein Verbesserungsvorschlag!

Dann ist dein Windows Rechner selber vermurkst !

Dazu passt aber wieder nicht, das es geht wenn der Rechner am WAN hängt...

Fakt ist, wie gesag, das das IKEv2 Dialin auf der pfSense fehlerfrei rennt.

stimmt! Damit ist mein Fehler aber nicht gefunden... Habe ja nun auch nicht gesagt das die Sense IKE v2 nicht kann oder es nicht praxistauglich ist...

Ich werde mal schauen das ich mir eine Nr. 3 besorge, dann sehen wir weiter!

VG
Giraffe

...ist ja auch nur ein Verbesserungsvorschlag!

OK, danke, das korrigiere ich. Das sollte eindeutig sein, da hast du Recht.

Dazu passt aber wieder nicht, das es geht wenn der Rechner am WAN hängt...

Da hast du auch wieder Recht !

Du solltest folgendes machen:
Beide Rechner am WAN Port testen. Das MUSS dann gehen.
Beide Rechner am Hotspot testen. Auch das MUSS gehen.

Wenn es dann an anderen Anschlüssen nicht geht hat man dann ein Problem mit der VPN IP Adressierung. Siehe hier:
VPNs einrichten mit PPTP
Oder damit das es ein DS-Lite oder CGN Anschluss ist.
Andere Optionen gibt es de facto nicht.

eine Nr. 3 besorge, dann sehen wir weiter!

Nimm einen kleinen Raspberry Pi Zero ! Den bekommst du für 5 Euro !
https://buyzero.de/collections/boards-kits/products/raspberry-pi-zero-v1 ...
Einen LAN Adapter nicht vergessen: https://www.amazon.de/Smays-Realtek-Ethernet-compatible-Raspberry/dp/B00 ...
Fertisch ist dein Testsystem

Alternativ einen Zero W dann hast du gleich WLAN dazu:
https://buyzero.de/collections/raspberry-pi-sets-kits-bundles/products/p ...

Ich werde mal schauen das ich mir eine Nr. 3 besorge, dann sehen wir weiter!

Wir sind gespannt !

Frage Netzwerke LAN, WAN, Wireless

Mehr von Giraffe

Pfsense: Verbindungsabbrüche im WLANGiraffe - 4 Kommentare

Outlook 2019 fragt sporadisch nach KontokennwortGiraffe - 4 Kommentare

Office 2007 o. 2010 als ZwischenversionGiraffe - 5 Kommentare

Blob storage - OrdnerwildwuchsGiraffe - 9 Kommentare

Heiß diskutiert