10
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.
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
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)
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 395046
Url: https://administrator.de/contentid/395046
Printed on: April 19, 2024 at 04:04 o'clock
10 Comments
Latest comment
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
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
Dann nochmal,
danke aqui, manchmal ist ein tritt am ende des Rueckens richtig gut und wirkt Wunder.
danke aqui, manchmal ist ein tritt am ende des Rueckens richtig gut und wirkt Wunder.
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
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 !
Dann saven und die FW einmal rebooten lassen.
Ab dann sollte alles sauber funktionieren.
Jetzt bist du wieder dran !
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
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
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
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
Kann es sein das du per Zufall unfreiwillig die AntiLockout Rule des GUI deaktiviert hast ?? (Haken entfernt)
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
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 !
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 !
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
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 !
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.
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.
Eine vielleicht blöde Frage
Gibts ja nicht, nur blöde Antworten 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.
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.
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.
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
Danke dir
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.
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
Danke dir
Das ist übrigens generell bei Firewalls so und auch IP Accesslisten bei Routern und L3 Switches
Reihenfolge und Logik der Regel sollte man also immer genau prüfen !
Reihenfolge und Logik der Regel sollte man also immer genau prüfen !
