frosch2
Goto Top

IPsec VPN für mobile Benutzer auf der pfSense Firewall einrichten - es funktioniert bei mir nicht - vielleicht sehe ich den Wald vor lauter Bäumen nicht mehr

Hallo

Ich beziehe mich auf: IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

es ist mir peinlich zugeben zu müssen das bei mir das nicht geht , bestimmt ist es nur eine Kleinigkeit (sagen alle erstmal) die ich nicht beachtet habe.Bestimmt sehe ich den Wald vor lauter Bäumen nicht.

Ich habe dies tutorial bestimmt jetzt 10-20 mal gelesen, aber anscheinend hat meine Fritte die den Internetzugang bereitstellt zu der pfsense ein Problem. Das System ist eine Kaskade.

Ich versuche mal den Aufbau darzustellen.

  • Telekom kommt mit DSL rein
  • dann kommt meine FB7590, diese macht VOIP deswegen kaskade
  • dann die pfsense (Rechner Corei3 3xxx 8GB RAM) version 2.4.4 64bit
  • Internetzugang funktioniert einwandfrei am Netz

Jetzt will ich eine VPN installieren, damit ich Mobil auf den Rechner dahinter zugreifen kann. Aber anscheinend bin ich zu blöd das zum fliegen zu bringen face-wink

Ich bekomme immer wieder die Fehlermeldung per strongswan Fehler beim aufsetzen des VPN. Benutzer authenfizierung fehlgeschlagen.

Hier noch ein Auszug aus der pfsense (oben der letzte eintrag)

Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> IKE_SA bypasslan[14] state change: CONNECTING => DESTROYING
Dec 7 15:33:42 	charon 		06[NET] <bypasslan|14> sending packet: from 192.168.178.20[4500] to 77.3.234.61[43107] (80 bytes)
Dec 7 15:33:42 	charon 		06[ENC] <bypasslan|14> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> peer supports MOBIKE
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> processing INTERNAL_IP6_DNS attribute
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> processing INTERNAL_IP4_DNS attribute
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> processing INTERNAL_IP6_ADDRESS attribute
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> processing INTERNAL_IP4_ADDRESS attribute
Dec 7 15:33:42 	charon 		06[CFG] <bypasslan|14> no alternative config found
Dec 7 15:33:42 	charon 		06[IKE] <bypasslan|14> peer requested EAP, config inacceptable
Dec 7 15:33:42 	charon 		06[CFG] <bypasslan|14> selected peer config 'bypasslan'  
Dec 7 15:33:42 	charon 		06[CFG] <14> candidate "bypasslan", match: 1/1/24 (me/other/ike)  
Dec 7 15:33:42 	charon 		06[CFG] <14> looking for peer configs matching 192.168.178.20[pfsense]...77.3.234.61[testuser1]
Dec 7 15:33:42 	charon 		06[IKE] <14> received 1 cert requests for an unknown ca
Dec 7 15:33:42 	charon 		06[IKE] <14> received cert request for unknown ca with keyid 7c:ec:15:be:98:9d:fd:13:78:3c:c2:99:65:38:3f:0c:c4:64:ce:20
Dec 7 15:33:42 	charon 		06[ENC] <14> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Dec 7 15:33:42 	charon 		06[NET] <14> received packet: from 77.3.234.61[43107] to 192.168.178.20[4500] (480 bytes)
Dec 7 15:33:42 	charon 		06[NET] <14> sending packet: from 192.168.178.20[500] to 77.3.234.61[38247] (489 bytes)
Dec 7 15:33:42 	charon 		06[ENC] <14> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
Dec 7 15:33:42 	charon 		06[IKE] <14> sending cert request for "CN=ca04, C=DE, ST=Schleswig, L=Hanerau, O=Schettler, OU=EDV"  
Dec 7 15:33:42 	charon 		06[CFG] <14> sending supported signature hash algorithms: sha256 sha384 sha512 identity
Dec 7 15:33:42 	charon 		06[IKE] <14> remote host is behind NAT
Dec 7 15:33:42 	charon 		06[IKE] <14> local host is behind NAT, sending keep alives
Dec 7 15:33:42 	charon 		06[CFG] <14> received supported signature hash algorithms: sha256 sha384 sha512 identity
Dec 7 15:33:42 	charon 		06[CFG] <14> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Dec 7 15:33:42 	charon 		06[CFG] <14> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

Content-ID: 395046

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

Ausgedruckt am: 25.11.2024 um 06:11 Uhr

aqui
Lösung aqui 07.12.2018 aktualisiert um 17:18:24 Uhr
Goto Top
Du hast Recht !!
Wie hier (leider) immer: Das Tutorial nicht richtig gelesen !!!
received 1 cert requests for an unknown ca

Zeigt klar das du einen Fehler bei der Generierung und Portierung des Zertifikats gemacht hast !!
Fazit:
Lies dir also bitte diesne Teil nochmal ganz genau durch und halte dich genau an die dort angegebenen Schritte !!
Dann klappt das auch sofort !

Firewall auf Werksreset und sauber nochmal von vorne anfangen face-wink
frosch2
frosch2 07.12.2018 aktualisiert um 18:19:48 Uhr
Goto Top
Dann nochmal,


danke aqui, manchmal ist ein tritt am ende des Rueckens richtig gut und wirkt Wunder.
frosch2
frosch2 07.12.2018 um 18:44:54 Uhr
Goto Top
face-sad Jetzt aufeinmal bleibt die Anmeldung an der Webgui einfach stehen. Konfigurieren nicht möglich.
Die Konsole sagt das ich successfull eingeloggt bin.
Bisher habe ich ein reboot durchgefuehrt, über die Konsole und auch die Webgui neugestartet über die Konsole, nichts hat geholfen.
Ich melde mich an , es macht piep , laut konsole bin ich eingeloggt
was ist das jetzt ? wie komme ich daraus?

frosch
aqui
Lösung aqui 08.12.2018 aktualisiert um 12:33:49 Uhr
Goto Top
Jetzt aufeinmal bleibt die Anmeldung an der Webgui einfach stehen
Nach der Neuinstallation oder dem Werksreset ??
Ggf. den Browsercache mal VORHER löschen !!

Nachdem Reset oder Neuinstallation spielst du erstmal den Setup Wizzard komplett durch.
Dann setzt du gemäß Tutorial das Zertifikat neu auf und danach löschst das alte Default Zert komplett weg.
ACHTUNG: Denk dran nach dem Löschen des Default Zertifikats unter System --> Advanced das HTTPS Zertifikat auf dein neu generiertes zu setzen !

zert

Dann saven und die FW einmal rebooten lassen.
Ab dann sollte alles sauber funktionieren.
Jetzt bist du wieder dran !
frosch2
frosch2 08.12.2018 um 15:55:17 Uhr
Goto Top
Das passierte nachdem ich

1. ein Werksresett machte
- danach die VPN neuinstalliert
- mit Strongswan vom Smartphone getestet habe
- dann habe ich die anliegende dhcp adresse der pfsense wlan auf statisch angepasst.
- dann nochmals getestet, alles gut
- wollte dann wieder über die Gui in die Firewall und nichts tat sich , auf der Konsole zeigte sich zwar das ich richtig eingeloggt war aber nichts tat sich an der Weboberfläche.
- danach führte ich zuallerst ein neustart per Konsole der webgui durch, ohne erfo.lg
- also fuehrte ich ein reboot durch auch ohne erfolg
- danach schrieb ich
- Internet funktioniert, Die VPN auch nur die Webgui funktionierte nicht
als puren Aktionismus fuehrte ich Option 0 (Logout SSH only) an der Konsole aus, und danach war alles wieder gut. Kann ich nicht nachvollziehen, aber naja wenn es geht face-wink


Danke dir, es funktioniert so wie es sein soll. Nun kommt der Härtetest und das muss sich dann im Einsatz bewähren. Wird es auch.
Ich frage mich wieso eine Hardwarefirewall zertifiziert vom BSI besser sein soll laut externer EDV Firma (Anschaffungs- und Installtions-kosten ca. 1000€ netto und dann jeden Monat 69€ fuer Monitoring und Lizenzen) ?

Wenn die Frage hier nicht richtig ist dann wäre es gut das sie an die richtige Stelle im Forum verschoben wird , oder ist es besser einen neuen Thred dazu zu starten.


- an der
aqui
aqui 08.12.2018 aktualisiert um 16:32:54 Uhr
Goto Top
Kann es sein das du per Zufall unfreiwillig die AntiLockout Rule des GUI deaktiviert hast ?? (Haken entfernt)

antilo

Dann musst du den Zugang über Firewall Regeln entsprechend regeln. Sowas sollte man wasserdicht testen bevor man das aktiviert weil man sich dabei leicht selber den Ast absägt auf dem man logintechnisch sitzt face-wink
Auf alle Fälle VORHER die Konfig sichern OHNE deaktivierte Antilogout Rule um alles schnell wieder rücksichern zu können sollte man die Box resetten müssen !
wieso eine Hardwarefirewall zertifiziert vom BSI besser sein soll
Ist sie natürlich auch nicht aus technischer Sicht. Das ist Blödsinn.
Was man damit macht ist das man sich über einen Vertrag das Recht erkauft auf jemanden zeigen zu können wenn die Firewall mal nicht das tut was sie soll.
Der Knackpunkt da ist aber immer der Administrator der die Firewall konfiguriert, also der Faktor Mensch. Technisch gesehen ist so eine FW natürlich niemals besser. Zumal unter allen heute ja irgendwie immer was Unixoides werkelt.
Man könnte sogar behaupten das ein Bugfixing durch die sehr große weltweite Community schneller und umfassender ist als mit einem langwierigen Lizenzvertrag. Kühn gesagt also letztendlich sicherer.
Mit der pfSense machst du nichts falsch. Zumal du sie mit einem Wartungsvertrag ja auch genauso kommerzialisieren kannst !
Dann viel Erfolg beim Härtetest ! face-wink
frosch2
frosch2 08.12.2018 um 16:46:30 Uhr
Goto Top
Ja sicher kann es sein. Dann eher zufällig, gerade wenn man etwas viele macht mit dem gleichen ergebnis das es nicht geht , schleichen sich auch noch andere Flüchtigkeitsfehler ein.

Eine vielleicht blöde Frage ( sieh sie mir bitte nach da das Thema VPN Neuland für mich ist) Diese VPN wird auf die pfsense geroutet. Diese entscheidet dann wer durch die Firewallregel IPsec Regel darf oder auch nicht.? Durch die entsprechende Port- und Portokollfreigabe freigabe in der Regel mit angabe wohin die Pakete geroutet werden sollen.

Ich werde deine Tipp beherzigen. face-smile
aqui
Lösung aqui 09.12.2018 aktualisiert um 12:25:19 Uhr
Goto Top
Eine vielleicht blöde Frage
Gibts ja nicht, nur blöde Antworten face-wink
Dieses VPN wird auf die pfSense geroutet.
Richtig !
Dessen IP Adresse als VPN Ziel gibst du ja auch in deinen VPN Clients an !
Diese entscheidet dann wer durch die Firewallregel IPsec Regel darf oder auch nicht.?
Auch richtig !
Bzw. die Firewall Regeln machst DU ja, d.h. du entscheidest letztendlich. face-wink
Durch die entsprechende Port- und Portokollfreigabe Freigabe in der Regel
Auch das ist richtig !
Übrigens nicht nur die Freigabe sondern auch das Verbot. Mit der Regel kannst du ja explizit was erlauben und explizit was verbieten.
Default Regel auf einer Firewall ist immer: "Es ist alles verboten was nicht ausdrücklich erlaubt ist !"
Auf einem neuen Interface ist also erstmal alles blockiert !
Und im Regelwerk selber gilt: "First match wins !"
Also beim ersten positiven Hit wird der Rest des Regelwerks NICHT mehr abgearbeitet.
Gerade letzteres sollte man bei der Regelwerk Logik immer auf dem Radar haben.
Auch das Regeln nur Inbound auf dem Interface wirken.
frosch2
frosch2 09.12.2018 um 13:15:02 Uhr
Goto Top
Hallo Aqui,

danke für das Feedback. Das mit dem "First match wins !" war auch etwas , andem ich leidvolle erfahrung gesammelt habe, aber schon einige Zeit her. face-wink
das die Regeln nur Inbound auf dem Interface wirken ist für mich eine sehr gute Info, ich habe mir zwar soetwas gedacht, aber mein Denken und die Realität differieren manchesmal face-wink

Danke dir
aqui
Lösung aqui 10.12.2018 um 13:50:22 Uhr
Goto Top
Das ist übrigens generell bei Firewalls so und auch IP Accesslisten bei Routern und L3 Switches face-wink
Reihenfolge und Logik der Regel sollte man also immer genau prüfen ! face-wink