wusldusl
Goto Top

PFsense IPSec VPN Mobile Client Tunnel zu ShrewSoft Client: Verbindung ist aufgebaut, aber sonst "keine Reaktion"

Hallo Admin-Mitglieder.
Ich hab ein Problem mit der VPN IPSec:
Ausgangssituation:
Standort 1.: Win10 PC - mit ShrewSoft (einfach über eine Internetverbindung über Router Kabel Deutschland)
Standort 2.: der Serverstandort!!!
Internet wird über Fritzbox aufgebaut! WAN-Network 192.168.0.1 (Fritzbox - auch als Gateway) - leitet das Signal an die Firewall (PF-Sense 192.168.0.10
LAN-Network über Firewall 192.168.1.10.! In dieses LAN-Netzwerk will ich über IPSec einen Tunnel aufbaun.

Nun zu meiner Config:
Ich habe meine Firewall so konfiguriert, wie es aus dem Tutorial (siehe Video https://www.youtube.com/watch?v=kFCe5AdhFyU) beschrieben ist.
Den Win10-PC habe ich auch mit den entsprechenden Eintragungen konfiguriert.
Als IPSec-Range wäre bei mir 192.168.70.10 angedacht.
Der IPSec-Client bekommt 192.168.70.1.
So, das ist meine Ausgangssituation.
Verbinde ich mich über ShrewSoft, bekomme ich mittlerweile auch eine stehende Leitung zusammen.
Leider kann ich mit der Verbindung sonst nichts anfangen (kein Zugriff auf Laufwerke in Standort 2 - keine Pings, nichts).
Versuche ich vom PFSense einen Ping an 192.168.70.1 zu senden, kommt auch kein Signal zurück.

meine CMD-ipconfig gibt mir für den Adapter folgende Infos zurück
Ethernet-Adapter LAN-Verbindung* 13:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Shrew Soft Virtual Adapter
Physische Adresse . . . . . . . . : AA-AA-AA-2C-AD-00
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::28f8:cde8:293c:9359%14(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 198.168.70.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 246065834
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1F-C3-A5-82-C8-0A-A9-DF-55-0B
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS über TCP/IP . . . . . . . : Deaktiviert

Was habe ich vergessen?

(da ich nach langem Suchen im Internet herausgefunden habe, dass Win IPSec wegen NAT nicht funktioniert)

Content-Key: 336974

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

Ausgedruckt am: 19.03.2024 um 04:03 Uhr

Mitglied: Kraemer
Kraemer 05.05.2017 um 20:27:44 Uhr
Goto Top
Moin,

Zitat von @Wusldusl:
Was habe ich vergessen?

wahrscheinlich das Routing

Gruß
Mitglied: Wusldusl
Wusldusl 06.05.2017 um 08:00:18 Uhr
Goto Top
Moin.
Hätte ich zuerst auch vermutet, darum hab ich zuerst mal vom pfsense nen Ping losgeschickt zum vpn-getunnelten win10. Die Firewall müsste die Route auch so wissen oder?
Da gabs auch keine Reaktion
Mitglied: aqui
aqui 06.05.2017 aktualisiert um 09:35:43 Uhr
Goto Top
Nein, vermutlich nicht das Routing, denn das macht die pfSense ja sowieso. Er hat mit an Sicherheit grenzender Wahrscheinlichkeit die FW Regeln auf dem virtuellen VPN Adapter vergessen...
Dieses Tutorial hat wie immer die Lösung für dich:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
oder auch
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Beim WIN 10 Client lauern noch besondere Gefahren.
Zuallererst das das ICMP Protokoll (Ping) in der lokalen Firewall seit Windows 7 deaktiviert ist:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Hier muss man also Hand anlegen...
Zweitens klappt durch das fehlende Gateway die leidige Windows Autoerkennung des Netzwerktyps nicht und Winblows deklariert das Interface als Public (Öffentlich) was natürlich die Firewall umso dichter schnürt.
In Richtng Win10 Client funktioniert dann inbound so gut wie gar nchts mehr.
Outbound hingegen schon.
Hier muss man dann ggf. auch nochmal Hand an die Firewall mit erweiterten Eigenschaften legen.
Dann klappt das auch sofort face-wink

Eine weitere Gefahr ist die FritzBox die IPsec per Port Forwarding weiterleiten soll....
Internet wird über Fritzbox aufgebaut!
Das tut sie nämlich in der regel nicht. Warum ist auch kein Wunder, da sie ja selber IPsec VPN Gateway spielen kann durch ihre VPN Funktion.
Da der Win10 Shrew Client aber die aktuelle DSL IP der FritzBox als Ziel hat "denkt" die FB diese IPsec Pakete sind für sie selber und leitet sie nicht weiter auch wenn sie eine Port Weiterleitung der IPsec Ports UDP 500, UDP 4500 und dem ESP Protokoll hat auf die pfSense WAN IP (diese 3 sind zwingend nötig !)
Es muss zuerst die IPsec Funktion deaktiviert werden in der FB ansonsten leitet sie kein IPsec weiter an die pfSense und es kommt gar nicht erst zum Tunnelaufbau.
Ob es dazu kommt und ob das erfolgreich ist kann man wie immer im VPN Log der pfSense Firewall sehen. Das ist also immer erste Anlaufstelle beim Troubleshooting !!

Diese beiden Fallen Win10 und deren lokale Firewall und auch die FritzBox im IPsec Tunnelpfad gilt es also zu beachten und genau zu überprüfen damit sich Erfolg einstellt !
Mitglied: Edelweis
Edelweis 06.05.2017 um 18:38:32 Uhr
Goto Top
Zitat von @Wusldusl:
Ausgangssituation:
(einfach über eine Internetverbindung über Router Kabel Deutschland)
Wenn sich bei Kabel Deutschland nichts geändert hat, dürfte das sein Problem sein, da seine Fritte auf der "öffentlichen" Seite eine private IP-Adresse vermutlich hat.
Mitglied: aqui
aqui 06.05.2017 aktualisiert um 20:22:01 Uhr
Goto Top
Ja, ist zu befürchten das das ein DS-Lite Anschluss mit Carrier NAT ist aber das müsste der TO mal verifizieren. Das wäre dann das Aus für IPsec. Leider sagt er dazu oben nix face-sad
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Mitglied: Wusldusl
Wusldusl 07.05.2017 um 10:57:15 Uhr
Goto Top
Wow, ich bin begeistert von deiner sehr ausführlichen Antwort.
Erst einmal vielen Dank an die Hilfe-Gemeinde.

Zurück zum Thema:
Fritzbox!!! Also wenn mein PFSense bereits eine stehende Verbindung hat, ist dann das Troubleshooting bezüglich Fritzbox nicht schon erledigt?
So ganz 100% verstanden hab ich die Arbeitsweise von IPSec in Verbindung mit PFSense noch nicht. Ich versuch ja ein IPSec Mobile zum Laufen zu bringen. DHCP wurde dort niergends eingestellt.
Ein IT-Kumpel hat auch mal über die CMD-Netzwerkconfig (siehe oben) darübergeschaut: Dem ist das Problem "Gateway" sofort ins Auge gestochen. Klar dass das dann schon mal ein Problem ist.
Thema Ports: Sind alle konfiguriert.
Ich hab auch mit dem Link IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a bei meiner ganzen Odyssee begonnen mit den Einstellungen. Aber die Kombi mit IPSec Mobile über FB ist dort nicht detailliert beschrieben.

Ich hab mit PPTP sehr viel Erfahrung - also Prinzipiell ist VPN keine Neuheit für mich.
Da ich mit Applegräte auf mein Netzwerk zugreifen will/muss, und diese seit IOS10 keine PPTP mehr unterstützt (schon klar warum Apple das antiquierte Protokoll eliminiert hat), bin ich auf die Alternativen angewiesen und muss es auch in Kombi mit Win-Rechnern zum Laufen bringen.
Was kann ich noch zur Verfügung stellen, damit euch der Support für mich in meinem Fall leichter fällt?
PS: Vielen Dank euch allen - 1000000 Credits für euch
Mitglied: transocean
transocean 07.05.2017 um 11:07:47 Uhr
Goto Top
Moin,

Ich hab mit PPTP sehr viel Erfahrung

Dann lass aus Sicherheitsgründen besser die Finger davon.

https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...

Gruß

Uwe
Mitglied: aqui
aqui 07.05.2017 um 11:53:25 Uhr
Goto Top
eine stehende Verbindung hat,
Kommt drauf an was man unter stehender Verbindung dann versteht. Da bist du ja leider recht unspezifisch und oberflächlich face-sad
  • einen einfachen physischen Ethernet Link ?
  • eine PPPoE verbindung ?
  • einen laufenden IPsec Tunnel ?
Sollte es letzteres sein und das VPN Log der pfSense meldet einen IPsec Tunnal als established dann hast du zweifelsohne Recht, dann hast du auf der FB alles richtig gemacht. Aber auch nur dann...
So ganz 100% verstanden hab ich die Arbeitsweise von IPSec in Verbindung mit PFSense noch nicht
Das hat auch nichts speziell mit der pfSense zu tun ! IPsec ist ein weltweiter Standard also wenn dann musst du deine Frage umformulieren das du vielleicht IPsec in Summe noch nicht ganz verstanden hast.
Aber dazu gibt es hier ein sehr gutes Forentutorial:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Das sollte alle deinen Fragen klären.
Ipsec ist IPsec da gibt es kein mobile oder andere Spekulationen !
DHCP wurde dort niergends eingestellt.
Benötigt IPsec auch gar nicht.
Aber die Kombi mit IPSec Mobile über FB ist dort nicht detailliert beschrieben.
Du hast Recht.... Da wird das Tutorial noch demnächst ein Kapitel zu bekommen. Es ist aber nicht groß anders als die Einstellungen die auch AVM auf seiner Seite propagiert:
https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-mit- ...
Denn ob das IPsec von einer FritzBox oder einer pfSense kommt ist herzlich egal denn IPsec ist wie gesagt ein weltweiter Standard.
Ansonsten bist du aber auf dem richtigen Weg.
Für uns ist ein Screenshot der Firewall Regeln auf dem IPsec Interface wichtig. Daran scheitern viele, weil diese Firewall Regeln oft falsch sind oder eben ganz fehlen.
Ein Posting des VPN Logs beim Aufbau einer IPsec Verbindung wäre ebenfalls hilfreich. Nur um zu sehen das der Tunnel wirklich zustande kommt.
Am besten das Log vorher löschen damit nicht überflüssiger Mist drinsteht und das Logging so einstellen das die neuesten Meldungen immer oben sind:
log
Bei dir sind es vermutlich nur Kleinigkeiten....wie so oft face-wink
Mitglied: Wusldusl
Wusldusl 07.05.2017 um 18:46:05 Uhr
Goto Top
Ok - also hier jetzt erstmal die Logs für IPSec
May 7 18:23:51 charon: 10[ENC] <53> received unknown vendor ID: f1:4b:94:b7:bf:f1:fe:f0:27:73:b8:c4:9f:ed:ed:26
May 7 18:23:51 charon: 10[ENC] <53> received unknown vendor ID: 16:6f:93:2d:55:eb:64:d8:e4:df:4f:d3:7e:23:13:f0:d0:fd:84:51
May 7 18:23:51 charon: 10[ENC] <53> received unknown vendor ID: 84:04:ad:f9:cd:a0:57:60:b2:ca:29:2e:4b:ff:53:7b
May 7 18:23:51 charon: 10[IKE] <53> received Cisco Unity vendor ID
May 7 18:23:51 charon: 10[IKE] <53> 95.90.194.201 is initiating a Aggressive Mode IKE_SA
May 7 18:23:51 charon: 10[CFG] <53> looking for XAuthInitPSK peer configs matching 192.168.0.10...95.90.194.201[Monkeys]
May 7 18:23:51 charon: 10[CFG] <53> selected peer config "con2"
May 7 18:23:51 charon: 10[ENC] <con2|53> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
May 7 18:23:51 charon: 10[NET] <con2|53> sending packet: from 192.168.0.10[500] to 95.90.194.201[19272] (436 bytes)
May 7 18:23:51 charon: 10[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (108 bytes)
May 7 18:23:51 charon: 10[ENC] <con2|53> parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
May 7 18:23:51 charon: 10[IKE] <con2|53> local host is behind NAT, sending keep alives
May 7 18:23:51 charon: 10[IKE] <con2|53> remote host is behind NAT
May 7 18:23:51 charon: 10[ENC] <con2|53> generating TRANSACTION request 3380093452 [ HASH CPRQ(X_USER X_PWD) ]
May 7 18:23:51 charon: 10[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (76 bytes)
May 7 18:23:51 charon: 10[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (108 bytes)
May 7 18:23:51 charon: 10[ENC] <con2|53> parsed TRANSACTION response 3380093452 [ HASH CPRP(X_TYPE X_USER X_PWD) ]
May 7 18:23:52 charon: user 'host_vpn_jsigl' authenticated
May 7 18:23:52 charon: 10[IKE] <con2|53> XAuth-SCRIPT succeeded for user 'host_vpn_jsigl'.
May 7 18:23:52 charon: 10[IKE] <con2|53> XAuth authentication of 'host_vpn_jsigl' successful
May 7 18:23:52 charon: 10[ENC] <con2|53> generating TRANSACTION request 1855140183 [ HASH CPS(X_STATUS) ]
May 7 18:23:52 charon: 10[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (76 bytes)
May 7 18:23:52 charon: 10[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (60 bytes)
May 7 18:23:52 charon: 10[ENC] <con2|53> parsed TRANSACTION response 1855140183 [ HASH CP ]
May 7 18:23:52 charon: 10[IKE] <con2|53> IKE_SA con2[53] established between 192.168.0.10[192.168.0.10]...95.90.194.201[Monkeys]
May 7 18:23:52 charon: 10[IKE] <con2|53> scheduling reauthentication in 85353s
May 7 18:23:52 charon: 10[IKE] <con2|53> maximum IKE_SA lifetime 85893s
May 7 18:23:58 charon: 06[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (236 bytes)
May 7 18:23:58 charon: 06[ENC] <con2|53> parsed QUICK_MODE request 373026153 [ HASH SA No ID ID ]
May 7 18:23:58 charon: 06[IKE] <con2|53> no matching CHILD_SA config found
May 7 18:23:58 charon: 06[ENC] <con2|53> generating INFORMATIONAL_V1 request 1537452427 [ HASH N(INVAL_ID) ]
May 7 18:23:58 charon: 06[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (76 bytes)
May 7 18:23:58 charon: 13[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (236 bytes)
May 7 18:23:58 charon: 13[ENC] <con2|53> parsed QUICK_MODE request 1105186230 [ HASH SA No ID ID ]
May 7 18:23:58 charon: 13[IKE] <con2|53> no matching CHILD_SA config found
May 7 18:23:58 charon: 13[ENC] <con2|53> generating INFORMATIONAL_V1 request 2829574050 [ HASH N(INVAL_ID) ]
May 7 18:23:58 charon: 13[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (76 bytes)
May 7 18:24:03 charon: 13[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (236 bytes)
May 7 18:24:03 charon: 13[IKE] <con2|53> received retransmit of request with ID 1105186230, but no response to retransmit
May 7 18:24:03 charon: 04[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (236 bytes)
May 7 18:24:03 charon: 04[ENC] <con2|53> parsed QUICK_MODE request 373026153 [ HASH SA No ID ID ]
May 7 18:24:03 charon: 04[ENC] <con2|53> received HASH payload does not match
May 7 18:24:03 charon: 04[IKE] <con2|53> integrity check failed
May 7 18:24:03 charon: 04[ENC] <con2|53> generating INFORMATIONAL_V1 request 364345327 [ HASH N(INVAL_HASH) ]
May 7 18:24:03 charon: 04[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (76 bytes)
May 7 18:24:03 charon: 04[IKE] <con2|53> QUICK_MODE request with message ID 373026153 processing failed
May 7 18:24:06 charon: 04[NET] <con2|53> received packet: from 95.90.194.201[19230] to 192.168.0.10[4500] (92 bytes)
May 7 18:24:06 charon: 04[ENC] <con2|53> parsed INFORMATIONAL_V1 request 4001725473 [ HASH N(DPD) ]
May 7 18:24:06 charon: 04[ENC] <con2|53> generating INFORMATIONAL_V1 request 2735549986 [ HASH N(DPD_ACK) ]
May 7 18:24:06 charon: 04[NET] <con2|53> sending packet: from 192.168.0.10[4500] to 95.90.194.201[19230] (92 bytes)

Und hier die Firewall-Rule
snipping
Zum Testen darf die IPSec einfach mal alles.

Und die Rule vom WAN-Netzwerk
snipping2

Nat-Regel hab ich keine definiert.

Unter dem Reiter "Interface" gibt es bei mir kein IPsec - kann ich auch nicht via assign hinzufügen - aber bei den Rules taucht ja ipsec-Reiter wieder auf - also müsste das schon passen.
Siehe Foto
snipping3
Mitglied: aqui
aqui 08.05.2017 aktualisiert um 10:50:35 Uhr
Goto Top
Einen Kardinalsfehler hast begangen:
  • In der WAN Rule fehlt das ESP Protokoll !! ESP transportiert die VPN Produktivdaten im IPsec und das fehlt.
1723 ist Quatsch gehört zum PPTP Protoll, entsprechen 1701 ist L2TP und 10000 ist Unsinn das nutzt kein VPN Protokoll.
Hat alles nix mit IPsec zu tun
Mitglied: Wusldusl
Wusldusl 08.05.2017 um 22:43:22 Uhr
Goto Top
Hallo Aqui.
Das hatte ich als Rule noch nicht - also schon mal ein Punkt beseitigt.
Jetzt versuchte ich voller Hoffnung einen erneuten Anlauf - aber wieder "Stille".

ESP ist im WAN für alle Netzwerke freigegeben für den Test.
Das jetzige Protokoll zeigt keine großen Veränderungen:

May 8 22:35:12 charon: 08[ENC] <59> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V ]
May 8 22:35:12 charon: 08[IKE] <59> received XAuth vendor ID
May 8 22:35:12 charon: 08[IKE] <59> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
May 8 22:35:12 charon: 08[ENC] <59> received unknown vendor ID: 16:f6:ca:16:e4:a4:06:6d:83:82:1a:0f:0a:ea:a8:62
May 8 22:35:12 charon: 08[IKE] <59> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
May 8 22:35:12 charon: 08[IKE] <59> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
May 8 22:35:12 charon: 08[IKE] <59> received NAT-T (RFC 3947) vendor ID
May 8 22:35:12 charon: 08[IKE] <59> received FRAGMENTATION vendor ID
May 8 22:35:12 charon: 08[IKE] <59> received DPD vendor ID
May 8 22:35:12 charon: 08[ENC] <59> received unknown vendor ID: 3b:90:31:dc:e4:fc:f8:8b:48:9a:92:39:63:dd:0c:49
May 8 22:35:12 charon: 08[ENC] <59> received unknown vendor ID: f1:4b:94:b7:bf:f1:fe:f0:27:73:b8:c4:9f:ed:ed:26
May 8 22:35:12 charon: 08[ENC] <59> received unknown vendor ID: 16:6f:93:2d:55:eb:64:d8:e4:df:4f:d3:7e:23:13:f0:d0:fd:84:51
May 8 22:35:12 charon: 08[ENC] <59> received unknown vendor ID: 84:04:ad:f9:cd:a0:57:60:b2:ca:29:2e:4b:ff:53:7b
May 8 22:35:12 charon: 08[IKE] <59> received Cisco Unity vendor ID
May 8 22:35:12 charon: 08[IKE] <59> 95.90.194.201 is initiating a Aggressive Mode IKE_SA
May 8 22:35:12 charon: 08[CFG] <59> looking for XAuthInitPSK peer configs matching 192.168.0.010...95.90.194.201[Monkeys]
May 8 22:35:12 charon: 08[CFG] <59> selected peer config "con2"
May 8 22:35:12 charon: 08[ENC] <con2|59> generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
May 8 22:35:12 charon: 08[NET] <con2|59> sending packet: from 192.168.0.010[500] to 95.90.194.201[19250] (436 bytes)
May 8 22:35:12 charon: 08[NET] <con2|59> received packet: from 95.90.194.201[19226] to 192.168.0.010[4500] (108 bytes)
May 8 22:35:12 charon: 08[ENC] <con2|59> parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
May 8 22:35:12 charon: 08[IKE] <con2|59> local host is behind NAT, sending keep alives
May 8 22:35:12 charon: 08[IKE] <con2|59> remote host is behind NAT
May 8 22:35:12 charon: 08[ENC] <con2|59> generating TRANSACTION request 2899821770 [ HASH CPRQ(X_USER X_PWD) ]
May 8 22:35:12 charon: 08[NET] <con2|59> sending packet: from 192.168.0.010[4500] to 95.90.194.201[19226] (76 bytes)
May 8 22:35:12 charon: 08[NET] <con2|59> received packet: from 95.90.194.201[19226] to 192.168.0.010[4500] (108 bytes)
May 8 22:35:12 charon: 08[ENC] <con2|59> parsed TRANSACTION response 2899821770 [ HASH CPRP(X_TYPE X_USER X_PWD) ]
May 8 22:35:13 charon: user 'host_vpn_jsigl' authenticated
May 8 22:35:13 charon: 08[IKE] <con2|59> XAuth-SCRIPT succeeded for user 'host_vpn_jsigl'.
May 8 22:35:13 charon: 08[IKE] <con2|59> XAuth authentication of 'host_vpn_jsigl' successful
May 8 22:35:13 charon: 08[ENC] <con2|59> generating TRANSACTION request 3994559811 [ HASH CPS(X_STATUS) ]
May 8 22:35:13 charon: 08[NET] <con2|59> sending packet: from 192.168.0.010[4500] to 95.90.194.201[19226] (76 bytes)
May 8 22:35:13 charon: 08[NET] <con2|59> received packet: from 95.90.194.201[19226] to 192.168.0.010[4500] (60 bytes)
May 8 22:35:13 charon: 08[ENC] <con2|59> parsed TRANSACTION response 3994559811 [ HASH CP ]
May 8 22:35:13 charon: 08[IKE] <con2|59> IKE_SA con2[59] established between 192.168.0.010[192.168.0.010]...95.90.194.201[Monkeys]
May 8 22:35:13 charon: 08[IKE] <con2|59> scheduling reauthentication in 85596s
May 8 22:35:13 charon: 08[IKE] <con2|59> maximum IKE_SA lifetime 86136s
May 8 22:35:18 charon: 08[NET] <con2|59> received packet: from 95.90.194.201[19226] to 192.168.0.010[4500] (236 bytes)
May 8 22:35:18 charon: 08[ENC] <con2|59> parsed QUICK_MODE request 2939535598 [ HASH SA No ID ID ]
May 8 22:35:18 charon: 08[IKE] <con2|59> no matching CHILD_SA config found
May 8 22:35:18 charon: 08[ENC] <con2|59> generating INFORMATIONAL_V1 request 567124705 [ HASH N(INVAL_ID) ]
May 8 22:35:18 charon: 08[NET] <con2|59> sending packet: from 192.168.0.010[4500] to 95.90.194.201[19226] (76 bytes)
May 8 22:35:23 charon: 08[NET] <con2|59> received packet: from 95.90.194.201[19226] to 192.168.0.010[4500] (236 bytes)
May 8 22:35:23 charon: 08[ENC] <con2|59> parsed QUICK_MODE request 3752579178 [ HASH SA No ID ID ]
May 8 22:35:23 charon: 08[IKE] <con2|59> no matching CHILD_SA config found
May 8 22:35:23 charon: 08[ENC] <con2|59> generating INFORMATIONAL_V1 request 3286601377 [ HASH N(INVAL_ID) ]
May 8 22:35:23 charon: 08[NET] <con2|59> sending packet: from 192.168.0.010[4500] to 95.90.194.201[19226] (76 bytes)


Aber eine Verbindung besteht ja aus deiner Sicht oder gibts da noch Zweifel?
snipping4

Woran kanns noch liegen?
Mitglied: aqui
aqui 09.05.2017 um 13:52:04 Uhr
Goto Top
Vielleicht hilft dir das:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Damit funktioniert es auf Anhieb und ohne Zusatz Software face-wink
Mitglied: Wusldusl
Wusldusl 10.05.2017 um 23:49:18 Uhr
Goto Top
Hallo aqui.
Vielen Dank.
Also ich hab jetzt alles nochmal gelöscht und deinen Link von a bis z durchgespielt.
Und wieder scheint da irgendetwas nicht zu stimmen:

Also jetzt hab ich zur Problemlösung ein paar Fragen:
1. Zum Schritt "Server Zertifikat erstellen" - Punkt "Common und Alternative Names: Was genau ist da gemeint? Ich hab ja die Konfig mit "Internet" - "Fritzbox" - "PFsense" mal im 1. Post beschrieben. Also was genau wird dort von mir verlangt? Die DynDNS? Oder 192.168.0.10 für die WAN IP PFsense?

2. was ist die alternative Names FQDN or Hostname??? das ist mir auch nicht ganz klar

3. zum Schritt "Mobiles Client IPsec auf der pfSense einrichten": Ich hab ja die Version 2.2.6. Dort wird in der Config noch General Configs verlangt. Dort kann ich zwischen LAN und WAN wählen. Was wird dort verlangt? Von welchem Netz ich eine IPsec-Anfrage erwarte (also WAN) oder wohin ich diese leiten will (LAN)???

4. Zum Schritt "IPsec Phase 1 konfiguration": Ich betreibe einen Server im LAN. Muss ich in dem Schritt die Server-DNS mit angeben (also nicht PFsense sondern die MS-Servermaschine)? In der Erklärung heißt es, dass alle Häkchen raus müssen.

Nun zur meiner Fehlermeldung:
Also die Anmeldung wird versucht aufzubauen. Dort kommt folgendes Benutzerfenster:
fehler1
Dort gebe ich den Namen und das Passwort ein, welches ich im PFsense bei IPSec als User angelegt habe
dann kommt diese Meldung:
fehler2
Schau ich die logs an, scheint zumindest ein Versuch unternommen worden zu sein, eine Verbindung aufzubauen.
Wo´s scheitert, ist mir wieder nicht ganz klar.

Fehlerprotokoll
May 10 23:37:50 charon: 06[NET] <8> received packet: from 95.90.194.201[19236] to 192.168.0.010[500] (616 bytes)
May 10 23:37:50 charon: 06[ENC] <8> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
May 10 23:37:50 charon: 06[IKE] <8> received MS NT5 ISAKMPOAKLEY v9 vendor ID
May 10 23:37:50 charon: 06[IKE] <8> received MS-Negotiation Discovery Capable vendor ID
May 10 23:37:50 charon: 06[IKE] <8> received Vid-Initial-Contact vendor ID
May 10 23:37:50 charon: 06[ENC] <8> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
May 10 23:37:50 charon: 06[IKE] <8> 95.90.194.201 is initiating an IKE_SA
May 10 23:37:50 charon: 06[IKE] <8> local host is behind NAT, sending keep alives
May 10 23:37:50 charon: 06[IKE] <8> remote host is behind NAT
May 10 23:37:50 charon: 06[IKE] <8> sending cert request for "C=DE, ST=xxx, L=xxx, O=xxx, E=xxx, CN=vpnpfsense"
May 10 23:37:50 charon: 06[ENC] <8> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
May 10 23:37:50 charon: 06[NET] <8> sending packet: from 192.168.0.010[500] to 95.90.194.201[19236] (337 bytes)
May 10 23:37:50 charon: 06[NET] <8> received packet: from 95.90.194.201[19248] to 192.168.0.010[4500] (1264 bytes)
May 10 23:37:50 charon: 06[ENC] <8> parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
May 10 23:37:50 charon: 06[IKE] <8> received 46 cert requests for an unknown ca
May 10 23:37:50 charon: 06[CFG] <8> looking for peer configs matching 192.168.0.010[%any]...95.90.194.201[192.168.0.244]
May 10 23:37:50 charon: 06[CFG] <con1|8> selected peer config 'con1'
May 10 23:37:50 charon: 06[IKE] <con1|8> initiating EAP_IDENTITY method (id 0x00)
May 10 23:37:50 charon: 06[IKE] <con1|8> peer supports MOBIKE, but disabled in config
May 10 23:37:50 charon: 06[IKE] <con1|8> authentication of 'C=DE, ST=xxx, L=xxx, O=xxx, E=xxx, CN=xxx' (myself) with RSA signature successful
May 10 23:37:50 charon: 06[IKE] <con1|8> sending end entity cert "C=DE, ST=xxx, L=xxx, O=xxx, E=jeason@gmx.de, CN=xxx"
May 10 23:37:50 charon: 06[ENC] <con1|8> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
May 10 23:37:50 charon: 06[NET] <con1|8> sending packet: from 192.168.0.010[4500] to 95.90.194.201[19248] (1696 bytes)
May 10 23:38:10 charon: 06[IKE] <con1|8> sending keep alive to 95.90.194.201[19248]
May 10 23:38:20 charon: 06[JOB] <con1|8> deleting half open IKE_SA after timeout
May 10 23:40:59 charon: 06[KNL] interface pptpd0 activated
May 10 23:40:59 charon: 06[KNL] 192.168.60.100 appeared on pptpd0

Vielen dank für deine Hilfe
Mitglied: aqui
aqui 11.05.2017 um 10:08:36 Uhr
Goto Top
Also was genau wird dort von mir verlangt?
Die FritzBox ist ja nur Durchlauferhitzer, hat also mit dem VPN mehr oder minder außer Port Forwarding gar nix zu tun !
Die WAN IP 192.168.0.10 ist ein privates RFV 1918 IP Netzwerk was es im Internet gar nicht gibt, da nicht geroutet.
Dein VPN Client "weiss" also gar nichts von diesem Netz bzw. IP, da er ja als Zieladresse immer die WAN IP der FritzBox hat bzw. den DynDNS Namen.
Ebenso die pfSense. Die "ahnt" nicht das vor ihr nochwas sitzt was ihr die Pakete forwardet.
Wenn du einen Wireshark nimmst, dann siehts du auch das die Client Absender IP eine öffentliche IP ist and die Ziel IP auch eine öffentliche (die der FB)
Würde man jetzt die Authentisierung auf Basis der IP vornherein scheitert das an der Diskrepanz der IPs sofort. Zusätzlich noch weil sich die WAN IP der FB immer ändert.
Fazit: IP geht nicht da variable, es muss ein konstanter String sein zw. Client und Server.
Folglich bleibt dir also nur der eigentliche Hostname die du der FW im Setup vergeben hast, der DynDNS FQDN Name und ggf. noch deine IP.
Damit deckst du dann alle diese 3 Optione beim Generieren des Server Zertifikats ab:
cn
2. was ist die alternative Names FQDN or Hostname??? das ist mir auch nicht ganz klar
Wenn du deinen FW also pfsense.wusldusl.intern genannt hast ist der CN pfsense
Dann als Alternative der DynDNS FQDN z.B. meinepfsense.dyndns.org und als 3te Option um sicherzugehen noch deine Email wusldusl@email.de

Jetzt benötigst du diesen CN auch noch in der Phase 1 Konfig !
Hier muss also unter My Identifier der Eintrag auf "Distinguised name" gesetzt sein und der Hostname dort eingetragen sein. Das ist dann bei dir meinpfsense.dyndns.org oder eben pfsense oder die Email. Preferred der DynDNS FQDN.
cn2

Ich hab ja die Version 2.2.6.
Ganz schlecht !!! Damit geht das generell nicht !
Du musst zwingend auf die aktuelle 2.3.4 updaten !
Warum arbeitest du noch mit so einer Uralt Version ?? Date das umgehend up über das Dashboard !
Mitglied: Wusldusl
Wusldusl 14.05.2017 um 09:02:56 Uhr
Goto Top
Hallo aqui
Vielen Dank für deine genaue Beschreibung und Erklärung. Also damit kann ich wirklich sehr gut arbeiten.
Ich melde mich erst jetzt, weil sich diese Woche meine Prioritätsliste etwas verschoben hat.
Zur IPSec-Problematik:
Ich habe jetzt deinen Rat befolgt. Das Update auf Version 2.3.3 ist durchgeführt. 2.3.4 lässt mich pfsense (warum auch immer) nicht updaten. Darum werde ich die Tage mal ne Cleaninstall machen.
Aber Abgesehen von der Updateproblematik sind ja alle Klicks und Schritte, die du beschrieben hast, auf der 2.3.3 auch durchgeführt worden.
Und leider ergibt sich erneut das gleich Bild, wie bereits beschrieben. Ich sehe in den Protokollen, dass IPSec-Anfragen an die Box ankommen, aber beim Verbindungsaufbau kommt das selbe Bild wie oben / als wäre etwas mit dem Zertifikat nicht ok - ich kann das Problem nicht herausfinden, dazu fehlt mir die Routine mit den Fehlerprotokollen.
Ich weiß keinen Ausweg mehr!
Hilfe an alle
Mitglied: aqui
aqui 14.05.2017, aktualisiert am 15.05.2017 um 10:45:03 Uhr
Goto Top
Darum werde ich die Tage mal ne Cleaninstall machen.
Das musst du nicht unbedingt !
Du kannst den Update auf die aktuelle 2.3.4 auch erzwingen.
Dazu aktivierst du den SSH Zugang und gehst mit PuTTY oder TeraTerm auf die Shell (8).
Alternativ geht das auch über den seriellen Port wenn du ein APU Mainboard benutzt.
In der Shell führst du die folgenden Befehle der Reihe nach aus:
pkg-static update -f
pkg install pfSense-base
pfSense-upgrade -d

Danach sollte dann die 2.3.4 drauf sein !

Wenn es dennoch nicht gehen sollte hast du mit Sicherheit eins der beiden Fehler gemacht:
  • Die Phase 1 und 2 Credentials FALSCH gemacht !! Dazu müsstest du mal deine Phase 1 und 2 Screenshots der FW und die Win10 PS Kommandos hier posten.
  • Das Zertifikat falsch exportiert und vergessen ins richtige Verzeichnis zu setzen
Sehr hilfreich ist hier immer das IPsec Status Log der Firewall und das Log des Win 10 Clients.
Beides hast du leider auch nicht gepostet hier face-sad

Zudem ist das mobile VPN Client Tutorial überarbeitet mit detailierteren Beschreibungen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Mitglied: Wusldusl
Wusldusl 25.05.2017 um 11:07:19 Uhr
Goto Top
Also hier nochmal mein Aufbau
img_0864
Mitglied: aqui
aqui 25.05.2017 aktualisiert um 12:33:11 Uhr
Goto Top
OK, ein simpler Klassiker mit einer Router Kaskade.
Hier die Dinge die zu beachten sind und die wir hier noch brauchen zum Troubleshooting:
  • Auf der FritzBox MUSS ein Port Forwarding eingerichtet sein für die Ports: UDP 500, UDP 4500 und das ESP Protokoll (IP Nummer 50, nicht UDP oder TCP 50 !!) auf die WAN IP der FW 192.168.0.10. Da die FritzBox selber IPsec kann muss die VPN Funktion zwingend deaktiviert sein ansonsten forwardet die FB kein IPsec !
  • In der pfSense muss der Haken am WAN Port entfernt sein der Private Netze (RFC 1918) blockt:
rgcnets
  • Dann müssen am WAN Port die Regeln eingetragen sein die IPsec Protokollkomponenten auf die WAN IP Adresse erlauben (UDP500, 4500 und ESP):
ipsecrule

Das ist alles was zu tun ist um die Konfiguration lauffähig zu machen.
Sollte es wider Erwarten nicht klappen brauchen wir hier folgende Outputs:
  • IPsec Log der Firewall. Bitte hier VORHER löschen bevor man einen Client Connect Versuch startet um das Log von überflüssigen Messages zu befreien UND in den Log Settings oben das reverse Logging aktivieren, damit die aktuellsten Log Messages gleich am Anfang stehen !
log
  • Sinnvoll wäre auch ein Log Output vom Client
  • Ganz wichtig: Wenn du mit den bordeigenen VPN Clients arbeitest dann MUSS zwingend der Shrew oder andere VPN Clients vollständig entfernt sein vom Rechner ! Wenn mehrere IPsec Clients parallel installiert sind funktioniert das IPsec gar nicht oder nicht störungsfrei. Achte also darauf das alle diese Programme dann sauber entfernt sind und der Rechner danach rebootet wurde !
Mitglied: Wusldusl
Wusldusl 25.05.2017 um 13:02:12 Uhr
Goto Top
Ok, so wie es aussieht hat es nun geklappt. Verbindung steht.
Ich komm zwar noch nicht auf die LAN-Netzwerkfreigaben - aber das wird wahrscheinlich ein static-route-problem sein.
Das bekomm ich bestimmt hin.
Hey Aqui - 1000000000 Sterne für dich - du bist der Hammer.
Merci merci merci.
VG
Wusldusl
Mitglied: aqui
aqui 26.05.2017 aktualisiert um 15:51:52 Uhr
Goto Top
Tadaaaa !!! Glückwunsch. So sollte es sein !! face-smile (Wo war denn der Fehler ???)
Ich komm zwar noch nicht auf die LAN-Netzwerkfreigaben
Das ist kein Problem der pfSense und Clients mehr, sondern einzig der lokalen Windows Firewall des Rechners wenn die Freigabe auf einem Windows Rechner ist !
Die lokale Win Firewall blockt alles was Absender IPs aus anderen Netzen hat wie deine VPN Clients.
Das sind 3 Minuten Mausklick und Anpassen der lokalen Windows Firewall vom Freigaberechner, dann klappt auch das sofort !