39
Nach PFSense 2.5.2 Update IPSec Tunnel "kaputt" (nur zu anderer PFSense)
Hallo liebe Leute.
Habe ein kurioses Problem.
Situation:
Zwei APU Boards mit PFSense. Eine hat eine dynamische, öffentliche IP und die andere eine statische IP.
Beide sind der erste Router im Netzwerk (kein doppeltes NAT) und auf Version 2.5.2 aktualisiert worden. Eine Box von Version 2.5.1 und die andere Box von 2.4.5.
Es lief seit November, quasi im Dauerbetrieb, ein IPSec Tunnel mit IKEv2 zwischen den beiden PFSense Standorten ohne Probleme.
Bisher war es nach jedem Update so, dass die VPN Tunnel nicht mehr funktioniert haben und neu eingerichtet werden mussten.
An Box Nr. 1 (die mit dynamischer IP) sind noch zwei weitere IPSec IKEv2 Tunnel je zu einer Sonicwall.
Diese beiden Tunnel haben sofort nach dem Upgrade, zu meiner Überraschung, funktioniert. Tunnel kamen normal hoch und Traffic lief auch ungehindert durch (ICMP, RDP, SMB).
Der andere Tunnel zur PFSense Box Nr. 2 (mit statischer IP) war auch sofort "verbunden". Hier kam jedoch nichts mehr durch. Weder ein Ping von der PFSense auf das Gateway der Gegenseite, noch von einem Client.
Gut dachte ich, dann eben auf beiden Seiten löschen und neu einrichten. War mir ja durchaus bekannt. Tunnel wird aufgebaut > kein Traffic. Regelwerke hatte ich bis dato nicht angepasst. Nach den ersten fehlgeschlagenen Versuchen dann mal auf beiden Seiten Any to Any Regeln (auf den jeweiligen IPSec Interfaces und den Ziel-Netzen) ganz nach oben gepackt und aktiviert. Immer noch nischt.
Die möglichen IPSec Einstellungen habe ich inzwischen alle durch. Probiert mit IKEv1 und v2.
Erfolglos getestet wurden bisher die folgenden Algorithmen:
Phase 1: Mutual PSK / My Identifier: Key ID Tag / Distinguished Name < für Box Nr. 1 (mit dynamischer IP) / Peer Identifier: IP-Address < für Box Nr. 2 (mit statischer IP)
AES 128 / 192 / 256 mit SHA 1 / 256 / 512 und DH Group 1 / 2 / 14
Phase 2:
AES 128 / 192 / 256 / AES-GCM 128 / 192 / 256 mit SHA 1 / 256 / 512 und DH Group 1 / 2 / 14
Hier mal ein Auszug aus dem IPSec LOG der Box Nr. 2 mit nur dem einen Tunnel (1.2.3.4 = Box Nr. 1 mit dynamischer IP und 5.6.7.8 = Box Nr.2 mit statischer IP):
Was mich an der Sache total stutizig macht sind eben die beiden anderen Tunnel, welche sich komplett normal verhalten.
Ich habe den leisen Verdacht, dass eine alte Konfig noch irgendwo herumschwebt.
Leider haben diverse Tipps aus dem Netz nicht geholfen.
Mehere Neustarts beider APU Boards wurden durchgeführt, IPSec Dienste neugestartet, Lifetimes auf der Responding Seite hoch gesetzt, Child SA Actions auf Restart / Reconnect auf Responding Seite eingestellt und auch wieder zurück auf Default.
Mehrere Male habe ich die VPN Konfiguration gelöscht, die Boards neu gestartet und alles noch einmal von vorne eingerichtet 🤷♂️
Danke für euren Input. Hier stehe ich eventuell auf dem Schlauch. Sagt Bescheid, falls noch was an Infos fehlt.
Gruß
Marc
Habe ein kurioses Problem.
Situation:
Zwei APU Boards mit PFSense. Eine hat eine dynamische, öffentliche IP und die andere eine statische IP.
Beide sind der erste Router im Netzwerk (kein doppeltes NAT) und auf Version 2.5.2 aktualisiert worden. Eine Box von Version 2.5.1 und die andere Box von 2.4.5.
Es lief seit November, quasi im Dauerbetrieb, ein IPSec Tunnel mit IKEv2 zwischen den beiden PFSense Standorten ohne Probleme.
Bisher war es nach jedem Update so, dass die VPN Tunnel nicht mehr funktioniert haben und neu eingerichtet werden mussten.
An Box Nr. 1 (die mit dynamischer IP) sind noch zwei weitere IPSec IKEv2 Tunnel je zu einer Sonicwall.
Diese beiden Tunnel haben sofort nach dem Upgrade, zu meiner Überraschung, funktioniert. Tunnel kamen normal hoch und Traffic lief auch ungehindert durch (ICMP, RDP, SMB).
Der andere Tunnel zur PFSense Box Nr. 2 (mit statischer IP) war auch sofort "verbunden". Hier kam jedoch nichts mehr durch. Weder ein Ping von der PFSense auf das Gateway der Gegenseite, noch von einem Client.
Gut dachte ich, dann eben auf beiden Seiten löschen und neu einrichten. War mir ja durchaus bekannt. Tunnel wird aufgebaut > kein Traffic. Regelwerke hatte ich bis dato nicht angepasst. Nach den ersten fehlgeschlagenen Versuchen dann mal auf beiden Seiten Any to Any Regeln (auf den jeweiligen IPSec Interfaces und den Ziel-Netzen) ganz nach oben gepackt und aktiviert. Immer noch nischt.
Die möglichen IPSec Einstellungen habe ich inzwischen alle durch. Probiert mit IKEv1 und v2.
Erfolglos getestet wurden bisher die folgenden Algorithmen:
Phase 1: Mutual PSK / My Identifier: Key ID Tag / Distinguished Name < für Box Nr. 1 (mit dynamischer IP) / Peer Identifier: IP-Address < für Box Nr. 2 (mit statischer IP)
AES 128 / 192 / 256 mit SHA 1 / 256 / 512 und DH Group 1 / 2 / 14
Phase 2:
AES 128 / 192 / 256 / AES-GCM 128 / 192 / 256 mit SHA 1 / 256 / 512 und DH Group 1 / 2 / 14
Hier mal ein Auszug aus dem IPSec LOG der Box Nr. 2 mit nur dem einen Tunnel (1.2.3.4 = Box Nr. 1 mit dynamischer IP und 5.6.7.8 = Box Nr.2 mit statischer IP):
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> nothing to initiate
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> activating new tasks
Aug 11 08:48:01 charon 83437 15[ENC] <con1000|31> parsed INFORMATIONAL response 175 [ ]
Aug 11 08:48:01 charon 83437 15[NET] <con1000|31> received packet: from 1.2.3.4[500] to 5.6.7.8[500] (80 bytes)
Aug 11 08:48:01 charon 83437 15[NET] <con1000|31> sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (80 bytes)
Aug 11 08:48:01 charon 83437 15[ENC] <con1000|31> generating INFORMATIONAL request 175 [ ]
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> activating IKE_DPD task
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> activating new tasks
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> queueing IKE_DPD task
Aug 11 08:48:01 charon 83437 15[IKE] <con1000|31> sending DPD request
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> nothing to initiate
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> activating new tasks
Aug 11 08:47:01 charon 83437 15[ENC] <con1000|31> parsed INFORMATIONAL response 174 [ ]
Aug 11 08:47:01 charon 83437 15[NET] <con1000|31> received packet: from 1.2.3.4[500] to 5.6.7.8[500] (80 bytes)
Aug 11 08:47:01 charon 83437 15[NET] <con1000|31> sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (80 bytes)
Aug 11 08:47:01 charon 83437 15[ENC] <con1000|31> generating INFORMATIONAL request 174 [ ]
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> activating IKE_DPD task
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> activating new tasks
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> queueing IKE_DPD task
Aug 11 08:47:01 charon 83437 15[IKE] <con1000|31> sending DPD request
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> nothing to initiate
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:46:01 charon 83437 13[ENC] <con1000|31> parsed INFORMATIONAL response 173 [ ]
Aug 11 08:46:01 charon 83437 13[NET] <con1000|31> received packet: from 1.2.3.4[500] to 5.6.7.8[500] (80 bytes)
Aug 11 08:46:01 charon 83437 13[NET] <con1000|31> sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (80 bytes)
Aug 11 08:46:01 charon 83437 13[ENC] <con1000|31> generating INFORMATIONAL request 173 [ ]
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> activating IKE_DPD task
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> queueing IKE_DPD task
Aug 11 08:46:01 charon 83437 13[IKE] <con1000|31> sending DPD request
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> nothing to initiate
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:45:01 charon 83437 13[ENC] <con1000|31> parsed INFORMATIONAL response 172 [ ]
Aug 11 08:45:01 charon 83437 13[NET] <con1000|31> received packet: from 1.2.3.4[500] to 5.6.7.8[500] (80 bytes)
Aug 11 08:45:01 charon 83437 13[NET] <con1000|31> sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (80 bytes)
Aug 11 08:45:01 charon 83437 13[ENC] <con1000|31> generating INFORMATIONAL request 172 [ ]
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> activating IKE_DPD task
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> queueing IKE_DPD task
Aug 11 08:45:01 charon 83437 13[IKE] <con1000|31> sending DPD request
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> nothing to initiate
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:44:01 charon 83437 13[ENC] <con1000|31> parsed INFORMATIONAL response 171 [ ]
Aug 11 08:44:01 charon 83437 13[NET] <con1000|31> received packet: from 1.2.3.4[500] to 5.6.7.8[500] (80 bytes)
Aug 11 08:44:01 charon 83437 13[NET] <con1000|31> sending packet: from 5.6.7.8[500] to 1.2.3.4[500] (80 bytes)
Aug 11 08:44:01 charon 83437 13[ENC] <con1000|31> generating INFORMATIONAL request 171 [ ]
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> activating IKE_DPD task
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> activating new tasks
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> queueing IKE_DPD task
Aug 11 08:44:01 charon 83437 13[IKE] <con1000|31> sending DPD request Was mich an der Sache total stutizig macht sind eben die beiden anderen Tunnel, welche sich komplett normal verhalten.
Ich habe den leisen Verdacht, dass eine alte Konfig noch irgendwo herumschwebt.
Leider haben diverse Tipps aus dem Netz nicht geholfen.
Mehere Neustarts beider APU Boards wurden durchgeführt, IPSec Dienste neugestartet, Lifetimes auf der Responding Seite hoch gesetzt, Child SA Actions auf Restart / Reconnect auf Responding Seite eingestellt und auch wieder zurück auf Default.
Mehrere Male habe ich die VPN Konfiguration gelöscht, die Boards neu gestartet und alles noch einmal von vorne eingerichtet 🤷♂️
Danke für euren Input. Hier stehe ich eventuell auf dem Schlauch. Sagt Bescheid, falls noch was an Infos fehlt.
Gruß
Marc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1143768991
Url: https://administrator.de/forum/nach-pfsense-2-5-2-update-ipsec-tunnel-kaputt-nur-zu-anderer-pfsense-1143768991.html
Ausgedruckt am: 21.01.2025 um 04:01 Uhr
39 Kommentare
Neuester Kommentar
Hallo Radiogugu
Wieso machst du keinen Wireguard Tunnel?
Ich persönlich habe sämtliche Tunnels auf Wireguard umgestellt, ausser mit Standorten welche kein Wireguard unterstützen.
Gruss
adminst
Wieso machst du keinen Wireguard Tunnel?
Ich persönlich habe sämtliche Tunnels auf Wireguard umgestellt, ausser mit Standorten welche kein Wireguard unterstützen.
Gruss
adminst
Tunnel kommen nur dann hoch wenn auch relevanter Traffic vorhanden ist. Welcher das ist wird durch die Phase 2 Definition bestimmt. Man sollte also nicht gleich in Panik ausbrechen wenn nach einem Reboot ein Tunnel nicht gleich etabliert wird, das ist mehr oder minder normal.
Ein Ping mit entsprechend gesetzter Absender und Ziel IP sollte das aber dann bewirken.
Ansonsten ist das Firewall IPsec bzw. VPN Log immer erste Anlaufstelle.
Bei der Box mit dynamischer WAN IP sollte man zwingend darauf achten das diese nur Initiator ist.
Sinnvoll ist zudem beide FWs auf dem gleichen Release Stand zu betreiben !
Ein Ping mit entsprechend gesetzter Absender und Ziel IP sollte das aber dann bewirken.
Ansonsten ist das Firewall IPsec bzw. VPN Log immer erste Anlaufstelle.
Bei der Box mit dynamischer WAN IP sollte man zwingend darauf achten das diese nur Initiator ist.
Sinnvoll ist zudem beide FWs auf dem gleichen Release Stand zu betreiben !
Zitat von @adminst:
Wieso machst du keinen Wireguard Tunnel?
Ich persönlich habe sämtliche Tunnels auf Wireguard umgestellt, ausser mit Standorten welche kein Wireguard unterstützen.
Wieso machst du keinen Wireguard Tunnel?
Ich persönlich habe sämtliche Tunnels auf Wireguard umgestellt, ausser mit Standorten welche kein Wireguard unterstützen.
Habe ich auch vor, nur wollte ich gerne dieses Phänomen verstanden haben
Zitat von @aqui:
Tunnel kommen nur dann hoch wenn auch relevanter Traffic vorhanden ist. Welcher das ist wird durch die Phase 2 Definition bestimmt. Man sollte also nicht gleich in Panik ausbrechen wenn nach einem Reboot ein Tunnel nicht gleich etabliert wird, das ist mehr oder minder normal.
Ein Ping mit entsprechend gesetzter Absender und Ziel IP sollte das aber dann bewirken.
Ansonsten ist das Firewall IPsec bzw. VPN Log immer erste Anlaufstelle.
Bei der Box mit dynamischer WAN IP sollte man zwingend darauf achten das diese nur Initiator ist.
Sinnvoll ist zudem beide FWs auf dem gleichen Release Stand zu betreiben !
Tunnel kommen nur dann hoch wenn auch relevanter Traffic vorhanden ist. Welcher das ist wird durch die Phase 2 Definition bestimmt. Man sollte also nicht gleich in Panik ausbrechen wenn nach einem Reboot ein Tunnel nicht gleich etabliert wird, das ist mehr oder minder normal.
Ein Ping mit entsprechend gesetzter Absender und Ziel IP sollte das aber dann bewirken.
Ansonsten ist das Firewall IPsec bzw. VPN Log immer erste Anlaufstelle.
Bei der Box mit dynamischer WAN IP sollte man zwingend darauf achten das diese nur Initiator ist.
Sinnvoll ist zudem beide FWs auf dem gleichen Release Stand zu betreiben !
Deswegen hatte ich beide FWs auch aktualisiert.
Es ist halt extrem seltsam, dass zwei andere Tunnel zu "Dritt-Anbietern" gehen, dieser jedoch nicht.
Zusätzlich verwirrt mich, dass in der IPSec Übersicht Pakete anscheinend registriert werden, aber nichts beantwortet wird.
Box Nr. 1:
Box Nr. 2:
Box Nr. 1 (mit dynamischer IP) ist als Initiator und Box Nr. 2 ist als Responder konfiguriert (Child SA Start + Close Action).
Gruß
Marc
Ich flipp noch aus.
Wollte gerade mal das mit dem Wireguard Tunnel ausprobieren. Tunnel und Peer schön konfiguriert und gesehen, dass der Wireguard Dienst nicht läuft.
Naja erst einmal alles zu Ende eingerichtet.
Nun stellt es sich so dar, dass beim Start des Wireguard Dienstes entweder der Unbound DNS Resolver oder der DHCP Dienst beendet werden 🤦♂️
Ich beginne daran zu zweifeln, dass die aktuelle Version von PFSense nicht so das Wahre ist, wenn man dahin aktualisiert.
Leider habe ich momentan nicht die Möglichkeit eine separate Box aufzustellen und diese von grund auf neu zu installieren.
Gruß
Marc
Wollte gerade mal das mit dem Wireguard Tunnel ausprobieren. Tunnel und Peer schön konfiguriert und gesehen, dass der Wireguard Dienst nicht läuft.
Naja erst einmal alles zu Ende eingerichtet.
Nun stellt es sich so dar, dass beim Start des Wireguard Dienstes entweder der Unbound DNS Resolver oder der DHCP Dienst beendet werden 🤦♂️
Ich beginne daran zu zweifeln, dass die aktuelle Version von PFSense nicht so das Wahre ist, wenn man dahin aktualisiert.
Leider habe ich momentan nicht die Möglichkeit eine separate Box aufzustellen und diese von grund auf neu zu installieren.
Gruß
Marc
Wireguard ist aus der aktuellen Version wieder entfernt worden wie du sicher selber weisst.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
Du kannst das derzeit ausschliesslich nur über die Package Verwaltung nachinstallieren mit einem externen Package.
https://www.netgate.com/blog/pfsense-wireguard-returns-as-an-experimenta ...
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
Du kannst das derzeit ausschliesslich nur über die Package Verwaltung nachinstallieren mit einem externen Package.
https://www.netgate.com/blog/pfsense-wireguard-returns-as-an-experimenta ...
Zitat von @aqui:
Wireguard ist aus der aktuellen Version wieder entfernt worden wie du sicher selber weisst.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
Du kannst das derzeit ausschliesslich nur über die Package Verwaltung nachinstallieren mit einem externen Package.
https://www.netgate.com/blog/pfsense-wireguard-returns-as-an-experimenta ...
Wireguard ist aus der aktuellen Version wieder entfernt worden wie du sicher selber weisst.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
Du kannst das derzeit ausschliesslich nur über die Package Verwaltung nachinstallieren mit einem externen Package.
https://www.netgate.com/blog/pfsense-wireguard-returns-as-an-experimenta ...
Absolut.
Habe ich schön über den Package Manager installiert.
Auf beiden Boxen war Wireguard nie aktiv, bzw. nie eine Version aktiv, welche Wireguard integriert hatte.
Gruß
Marc
Hi radioguru!
Deswegen fürchte ich PfSense Updates wie der Teufel das Weihwasser...
Jedesmal wirklich JEDES MAL Trouble, Downtime und Nervenkrise. Aber: Immer lösbar.
Dein Log sagt zu dem Problem leider nix aus. Kannst du die anderen beiden Tunnel deaktivieren und nur den "Problemtunnel" loggen? Evtl. Loglevel höher drehen. Auf beiden Seiten. Dann den Verbindungsaufbau Schritt-für-Schritt abgleichen.
Ich tippe, dass die Phase 1 durchläuft und in der Phase 2 irgendwo der Hase im Pfeffer liegt. (Gruss an den "Sonnenbebrillten"!)
Hast du evtl die alte Konfiguration gesichert und kannst den IPSec-Teil nochmal rücksichern? Oder dir ansehen und vergleichen? Ist halt auch viel Handarbeit.
Könnten aber auch die Firewallregeln sein. Any --> Any sicher in die richtigen Netze? Alles 3x gecheckt? Meistens hat man irgendwas völlig triviales übersehen, aber das weisst du...
An einem Punkt muss ich dem alten Hasen aber widersprechen: Hatte gerade den Fall, dass eine VPN-Verbindung PfSense (feste IP) -->FB (dyn. IP) nur stabil wieder aufgebaut wird, wenn ich den Verbindungsaufbau auf beiden Seiten zulasse, d.h. die PfSense "renegotiated". Warum auch immer. Wie das nach einem nächtlichen IP-Wechsel abgeht habe ich noch nicht gecheckt. Zwischen 3 und 5 hat das aber auch ein paar Minuten Zeit...
VG
Buc
Bisher war es nach jedem Update so, dass die VPN Tunnel nicht mehr funktioniert haben und neu eingerichtet werden mussten.
Deswegen fürchte ich PfSense Updates wie der Teufel das Weihwasser...
Jedesmal wirklich JEDES MAL Trouble, Downtime und Nervenkrise. Aber: Immer lösbar.Dein Log sagt zu dem Problem leider nix aus. Kannst du die anderen beiden Tunnel deaktivieren und nur den "Problemtunnel" loggen? Evtl. Loglevel höher drehen. Auf beiden Seiten. Dann den Verbindungsaufbau Schritt-für-Schritt abgleichen.
Ich tippe, dass die Phase 1 durchläuft und in der Phase 2 irgendwo der Hase im Pfeffer liegt. (Gruss an den "Sonnenbebrillten"!)
Hast du evtl die alte Konfiguration gesichert und kannst den IPSec-Teil nochmal rücksichern? Oder dir ansehen und vergleichen? Ist halt auch viel Handarbeit.
Könnten aber auch die Firewallregeln sein. Any --> Any sicher in die richtigen Netze? Alles 3x gecheckt? Meistens hat man irgendwas völlig triviales übersehen, aber das weisst du...
An einem Punkt muss ich dem alten Hasen aber widersprechen: Hatte gerade den Fall, dass eine VPN-Verbindung PfSense (feste IP) -->FB (dyn. IP) nur stabil wieder aufgebaut wird, wenn ich den Verbindungsaufbau auf beiden Seiten zulasse, d.h. die PfSense "renegotiated". Warum auch immer. Wie das nach einem nächtlichen IP-Wechsel abgeht habe ich noch nicht gecheckt. Zwischen 3 und 5 hat das aber auch ein paar Minuten Zeit...
VG
Buc
Zitat von @the-buccaneer:
Deswegen fürchte ich PfSense Updates wie der Teufel das Weihwasser... Jedesmal wirklich JEDES MAL Trouble, Downtime und Nervenkrise. Aber: Immer lösbar.
Deswegen fürchte ich PfSense Updates wie der Teufel das Weihwasser...
Jedesmal wirklich JEDES MAL Trouble, Downtime und Nervenkrise. Aber: Immer lösbar.Bis jetzt 😉
Dein Log sagt zu dem Problem leider nix aus. Kannst du die anderen beiden Tunnel deaktivieren und nur den "Problemtunnel" loggen? Evtl. Loglevel höher drehen. Auf beiden Seiten. Dann den Verbindungsaufbau Schritt-für-Schritt abgleichen.
Hatte ich schon mal gemacht. Sieht haar genauso aus, wie der obige Screenshot. Ich hatte auch immer gehofft irgendwo ein "denied", "couldn't find", "not matching" oder "rejected" zu lesen, aber leider nicht.
Ich tippe, dass die Phase 1 durchläuft und in der Phase 2 irgendwo der Hase im Pfeffer liegt. (Gruss an den "Sonnenbebrillten"!)
Hast du evtl die alte Konfiguration gesichert und kannst den IPSec-Teil nochmal rücksichern? Oder dir ansehen und vergleichen? Ist halt auch viel Handarbeit.
Hast du evtl die alte Konfiguration gesichert und kannst den IPSec-Teil nochmal rücksichern? Oder dir ansehen und vergleichen? Ist halt auch viel Handarbeit.
Die Rücksicherung habe ich auch schon gemacht, allerdings mit dem selben Ergebnis.
Könnten aber auch die Firewallregeln sein. Any --> Any sicher in die richtigen Netze? Alles 3x gecheckt? Meistens hat man irgendwas völlig triviales übersehen, aber das weisst du...
Absolut richtig. Habe alle any to any Regeln mal in allen betreffenden Netzen ganz nach oben gelegt, die Kisten beide neu gestartet, trotzdem nix.
An einem Punkt muss ich dem alten Hasen aber widersprechen: Hatte gerade den Fall, dass eine VPN-Verbindung PfSense (feste IP) -->FB (dyn. IP) nur stabil wieder aufgebaut wird, wenn ich den Verbindungsaufbau auf beiden Seiten zulasse, d.h. die PfSense "renegotiated". Warum auch immer. Wie das nach einem nächtlichen IP-Wechsel abgeht habe ich noch nicht gecheckt. Zwischen 3 und 5 hat das aber auch ein paar Minuten Zeit...
Auch da hatte ich, wie eingangs erwähnt, alle Varianten durch. Nichtsdestotrotz ein GROßES DANKE an alle Mitdenkenden
Ich werde mir mal eine kleine Testbox bauen, die PFSense 2.5.2 neu installieren und dann die entsprechenden Konfigurationen vornehmen, von gaaaaaanz von vorne. Eventuell lässt das meine Befürchtung bestätigen, dass der Update Prozess ein Problem hat.
Netgate hat viel an den VPNs gebastelt. Auch hatte ich mal das Phänomen, dass das KeyIDTag nicht angenommen wurde. Selbst wenn es nur ein Zeichen war. Die IP Adressen als Identifier immer sofort. Dies war auch ein Bug, der gefixt wurde.
Die Suche geht weiter.
Gruß
Marc
Hallo Marc,
ich teste gerade mein IPSEC-VPN bzgl. Datendurchsatz zwischen einer Netgate SG-2100 (pfsense+ 21.05 = vorletzte Version) und einem alten PC mit pfsense 2.5.2. Der Tunnel klappt prinzipiell gut, wenn ich als Phase 2 Verschlüsselung AES 128 bit verwende. Sobald ich auf eine andere Verschlüsselung wechsle, ist der Tunnel extrem instabil (manchmal kommen ein paar Bytes beim pingen durch, manche mit 20 !! Sekunden Verspätung). Jetzt hilft kein Rückstellen der Konfiguration und auch kein Restart des IPSEC-Service mehr, sondern nur noch ein kompletter Reboot auf der SG-2100. Danach geht AES 128 wieder klaglos.
Vielleicht hilft es Dir bei der Fehlersuche, meine Logs machen zumindest mich nicht schlauer (bin aber absoluter Amateur!).
LG,
Philipp
ich teste gerade mein IPSEC-VPN bzgl. Datendurchsatz zwischen einer Netgate SG-2100 (pfsense+ 21.05 = vorletzte Version) und einem alten PC mit pfsense 2.5.2. Der Tunnel klappt prinzipiell gut, wenn ich als Phase 2 Verschlüsselung AES 128 bit verwende. Sobald ich auf eine andere Verschlüsselung wechsle, ist der Tunnel extrem instabil (manchmal kommen ein paar Bytes beim pingen durch, manche mit 20 !! Sekunden Verspätung). Jetzt hilft kein Rückstellen der Konfiguration und auch kein Restart des IPSEC-Service mehr, sondern nur noch ein kompletter Reboot auf der SG-2100. Danach geht AES 128 wieder klaglos.
Vielleicht hilft es Dir bei der Fehlersuche, meine Logs machen zumindest mich nicht schlauer (bin aber absoluter Amateur!).
LG,
Philipp
und einem alten PC mit pfsense 2.5.2.
In den Advanced Settings hast du am PC dann hoffentliche die AES NI Unterstützung mit dem entsprechenden Haken aktiviert ?!
Damit klappt dann auch IPsec mit AES 256 und SHA256er Hashing.
Interessant wäre auch mal zu wissen ob du das alte IKEv1 einsetzt oder das neue IKEv2. Leider machst du dazu keinerlei Angaben.
Bei der PC Hardware wäre IKEv2 only (Kein Mischbetrieb mit v1 !) immer die bessere Alternative weil es weniger Protokoll Overhead hat ! Siehe dazu auch:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Zitat von @aqui:
und einem alten PC mit pfsense 2.5.2.
In den Advanced Settings hast du am PC dann hoffentliche die AES NI Unterstützung mit dem entsprechenden Haken aktiviert ?!Ist bei meinen beiden APU Boards jeweils auf Maximum gestellt.
Daher sollte das nicht der Grund bei mir zumindest sein.
Ich verstehe einfach nicht, dass zwei IPSec Tunnel zu anderer Hardware fehlerlos funktionieren und zu einer anderen PFSense nix geht.
Naja habe mir nun ein weiteres APU Board bestellt, um das mal zu testen. Schadet nicht so eine kleine Kiste als Spielwiese herumfliegen zu haben
Gruß
Marc
Ging auch nur um den Kollegen @noesel und seinen obigen Kommentar... 😉
und zu einer anderen PFSense nix geht.
Manchmal hilft es beideseitig die Tunnel zu entfernen und neu aufzusetzen.Schadet nicht so eine kleine Kiste als Spielwiese herumfliegen zu haben
👍 ...absolut richtig !
Hallo aqui,
danke für die Tipps! AES-NI war aktiviert, auch alles auf Hiadaptive gesetzt. PowerD hatte ich nicht aktiviert, das hat aber in meinem Versuchsaufbau keinen Unterschied gemacht. Der Tunnel crasht weiterhin.
Meine Config auf beiden Maschinen (kurz zusammengefasst):
Phase1:
Phase 2:
Damit habe ich einen funktionierenden Tunnel mit ca. 300 Mbit (iperf3 mit 1 Stream).
Wenn ich jetzt auf beiden Seiten in Phase 2 auf AES-GCM 256bit wechsle, baut sich einmal der Tunnel auf.
Erster Ping:
PING 192.168.175.100 (192.168.175.100): 56 data bytes
64 bytes from 192.168.175.100: icmp_seq=0 ttl=62 time=1.603 ms
64 bytes from 192.168.175.100: icmp_seq=1 ttl=62 time=1.275 ms
64 bytes from 192.168.175.100: icmp_seq=2 ttl=62 time=1.153 ms
64 bytes from 192.168.175.100: icmp_seq=3 ttl=62 time=1.333 ms
64 bytes from 192.168.175.100: icmp_seq=4 ttl=62 time=1.402 ms
64 bytes from 192.168.175.100: icmp_seq=5 ttl=62 time=1.168 ms
64 bytes from 192.168.175.100: icmp_seq=6 ttl=62 time=1.105 ms
... geht so weiter - völlig stabil
dann wieder iperf3:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 4.20 MBytes 35.1 Mbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
da gehen immer ein paar MByte drüber und dann Ende der Vorstellung.
nochmals ping:
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 192.168.175.100: icmp_seq=0 ttl=62 time=3009.650 ms
Request timeout for icmp_seq 4
64 bytes from 192.168.175.100: icmp_seq=5 ttl=62 time=1.204 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.175.100: icmp_seq=18 ttl=62 time=1.552 ms
Request timeout for icmp_seq 19
64 bytes from 192.168.175.100: icmp_seq=4 ttl=62 time=16022.334 ms
64 bytes from 192.168.175.100: icmp_seq=6 ttl=62 time=14021.861 ms
64 bytes from 192.168.175.100: icmp_seq=7 ttl=62 time=13021.037 ms
64 bytes from 192.168.175.100: icmp_seq=11 ttl=62 time=9010.764 ms
64 bytes from 192.168.175.100: icmp_seq=13 ttl=62 time=7009.662 ms
64 bytes from 192.168.175.100: icmp_seq=12 ttl=62 time=8009.836 ms
64 bytes from 192.168.175.100: icmp_seq=14 ttl=62 time=6009.051 ms
64 bytes from 192.168.175.100: icmp_seq=15 ttl=62 time=5004.109 ms
64 bytes from 192.168.175.100: icmp_seq=16 ttl=62 time=4003.964 ms
64 bytes from 192.168.175.100: icmp_seq=17 ttl=62 time=3003.261 ms
64 bytes from 192.168.175.100: icmp_seq=19 ttl=62 time=1002.875 ms
64 bytes from 192.168.175.100: icmp_seq=20 ttl=62 time=2.258 ms
Was mich nun irritiert: Die Netgate SG2100 (aktuelle Software) spinnt jetzt. Das LAN (!!) bricht immer wieder ab - "Netzwerkkabel nicht verbunden"; wenn sie reagiert, dann nur mit Verzögerung. Auch wenn ich den Tunnel deaktiviere. Nach einem Reboot und Umstellung auf AES geht alles wieder wie am Beginn.
Ich bin zwar wirklich kein Experte und suche den Fehler natürlich zuerst bei mir, aber das ist schon wirklich seltsam ...
LG,
Philipp
danke für die Tipps! AES-NI war aktiviert, auch alles auf Hiadaptive gesetzt. PowerD hatte ich nicht aktiviert, das hat aber in meinem Versuchsaufbau keinen Unterschied gemacht. Der Tunnel crasht weiterhin.
Meine Config auf beiden Maschinen (kurz zusammengefasst):
Phase1:
- IKEv2
- alles auf default gelassen (AES 128bit, SHA256, DH14)
Phase 2:
- Local und Remote Netzwerke definiert
- Encryption: AES 128 bit
- Hash: SHA256
- PFS key group: 14
Damit habe ich einen funktionierenden Tunnel mit ca. 300 Mbit (iperf3 mit 1 Stream).
Wenn ich jetzt auf beiden Seiten in Phase 2 auf AES-GCM 256bit wechsle, baut sich einmal der Tunnel auf.
Erster Ping:
PING 192.168.175.100 (192.168.175.100): 56 data bytes
64 bytes from 192.168.175.100: icmp_seq=0 ttl=62 time=1.603 ms
64 bytes from 192.168.175.100: icmp_seq=1 ttl=62 time=1.275 ms
64 bytes from 192.168.175.100: icmp_seq=2 ttl=62 time=1.153 ms
64 bytes from 192.168.175.100: icmp_seq=3 ttl=62 time=1.333 ms
64 bytes from 192.168.175.100: icmp_seq=4 ttl=62 time=1.402 ms
64 bytes from 192.168.175.100: icmp_seq=5 ttl=62 time=1.168 ms
64 bytes from 192.168.175.100: icmp_seq=6 ttl=62 time=1.105 ms
... geht so weiter - völlig stabil
dann wieder iperf3:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 4.20 MBytes 35.1 Mbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
da gehen immer ein paar MByte drüber und dann Ende der Vorstellung.
nochmals ping:
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 192.168.175.100: icmp_seq=0 ttl=62 time=3009.650 ms
Request timeout for icmp_seq 4
64 bytes from 192.168.175.100: icmp_seq=5 ttl=62 time=1.204 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.175.100: icmp_seq=18 ttl=62 time=1.552 ms
Request timeout for icmp_seq 19
64 bytes from 192.168.175.100: icmp_seq=4 ttl=62 time=16022.334 ms
64 bytes from 192.168.175.100: icmp_seq=6 ttl=62 time=14021.861 ms
64 bytes from 192.168.175.100: icmp_seq=7 ttl=62 time=13021.037 ms
64 bytes from 192.168.175.100: icmp_seq=11 ttl=62 time=9010.764 ms
64 bytes from 192.168.175.100: icmp_seq=13 ttl=62 time=7009.662 ms
64 bytes from 192.168.175.100: icmp_seq=12 ttl=62 time=8009.836 ms
64 bytes from 192.168.175.100: icmp_seq=14 ttl=62 time=6009.051 ms
64 bytes from 192.168.175.100: icmp_seq=15 ttl=62 time=5004.109 ms
64 bytes from 192.168.175.100: icmp_seq=16 ttl=62 time=4003.964 ms
64 bytes from 192.168.175.100: icmp_seq=17 ttl=62 time=3003.261 ms
64 bytes from 192.168.175.100: icmp_seq=19 ttl=62 time=1002.875 ms
64 bytes from 192.168.175.100: icmp_seq=20 ttl=62 time=2.258 ms
Was mich nun irritiert: Die Netgate SG2100 (aktuelle Software) spinnt jetzt. Das LAN (!!) bricht immer wieder ab - "Netzwerkkabel nicht verbunden"; wenn sie reagiert, dann nur mit Verzögerung. Auch wenn ich den Tunnel deaktiviere. Nach einem Reboot und Umstellung auf AES geht alles wieder wie am Beginn.
Ich bin zwar wirklich kein Experte und suche den Fehler natürlich zuerst bei mir, aber das ist schon wirklich seltsam ...
LG,
Philipp
Mmmmhhh lässt sich hier auf 2 pfSense mit APU2 Hardware und 2.5.2 nicht reproduzieren. Ein IKEv2 Tunnel ist über Wochen und Monate stabil.
Mit den LAN Problemen die du oben schilderst keimt da eher der Verdacht auf einen Hardware Defekt auf....
Mit den LAN Problemen die du oben schilderst keimt da eher der Verdacht auf einen Hardware Defekt auf....
Ich habe die Situation unzureichend beschrieben. Ich glaube, dass die LAN-Abbrüche Ausdruck eines Fast-Crashes des gesamten Systems ist. Es geht dann einfach fast nichts mehr. Nach dem Reboot ist wieder alles ok.
Nachdem es eine Netgate-Appliance ist und somit auch eine pfsense+ Version 21.05, tippe ich auf einen Softwarefehler.
Jedenfalls kann ich OpenVPN bis zum Anschlag belasten (z.B. AES256-CBC) und es funktioniert gut. Die gleiche Verschlüsselung mit IPSEC geht eben nicht.
Und wenn Du schreibst, dass es bei Dir mit der Community Edition funktioniert, erhärtet das meinen Verdacht.
Nachdem es eine Netgate-Appliance ist und somit auch eine pfsense+ Version 21.05, tippe ich auf einen Softwarefehler.
Jedenfalls kann ich OpenVPN bis zum Anschlag belasten (z.B. AES256-CBC) und es funktioniert gut. Die gleiche Verschlüsselung mit IPSEC geht eben nicht.
Und wenn Du schreibst, dass es bei Dir mit der Community Edition funktioniert, erhärtet das meinen Verdacht.
Ja, die aktuelle Community Edition 2.5.2 macht das hier in Wirespeed mit IPsec AES256 / SHA256 auf einem APU2.
Das sowohl mit IKEv1 als auch IKEv2 only.
Das sowohl mit IKEv1 als auch IKEv2 only.
Zitat von @aqui:
Ja, die aktuelle Community Edition 2.5.2 macht das hier in Wirespeed mit IPsec AES256 / SHA256 auf einem APU2.
Das sowohl mit IKEv1 als auch IKEv2 only.
Ja, die aktuelle Community Edition 2.5.2 macht das hier in Wirespeed mit IPsec AES256 / SHA256 auf einem APU2.
Das sowohl mit IKEv1 als auch IKEv2 only.
Sind das Boards, welche auf die 2.5.2 aktualisiert wurden oder haben die ein frisches System mit frischer, manueller Config?
Habe nun IPU 662 System vorliegen.
Dort habe ich zum schnellen Test einmal die PFSense 2.5.2 installiert und mit der Config meines APU2 Boards betankt.
Selbes Spiel. Die beiden Tunnel zu den SonicWalls (eine in DE und eine in PL) waren sofort funktional.
Der problematische Tunnel zu der anderen APU3 PFSense wurde aufgebaut, aber ohne ein Paket durchzulassen.
Werde als nächstes das IPU System neu installieren und die Config ohne irgendeines Imports neu erstellen.
Mal schauen, was dabei rumkommt.
Gruß
Marc
Hab es hier gerade mal zw. einem APU2 und einem APU3 ausprobiert mit Ver. 2.5.2. Sowohl IKEv1 als auch IKEv2 Tunnel stabil und ohne jegliche Beantstandung.
Testweise auf dem APU3 auch mal eine OPNsense gebootet und die v1 und v2 Tunnels mal in einer Mischkonstellation betrieben. Auch völlig fehlerlos...
Zumindestens in einer reinen xSense Umgebung ist das also nicht reproduzierbar.
Nächster Test jetzt mal mehr zu deinem Setup orientiert mit einem v1 und v2 Tunnel zu einem Cisco IOS und einem zu einem Mikrotik und dem 3ten dann bestehen lassen zur pfSense.
Es bleibt spannend...
Testweise auf dem APU3 auch mal eine OPNsense gebootet und die v1 und v2 Tunnels mal in einer Mischkonstellation betrieben. Auch völlig fehlerlos...
Zumindestens in einer reinen xSense Umgebung ist das also nicht reproduzierbar.
Nächster Test jetzt mal mehr zu deinem Setup orientiert mit einem v1 und v2 Tunnel zu einem Cisco IOS und einem zu einem Mikrotik und dem 3ten dann bestehen lassen zur pfSense.
Es bleibt spannend...
Nabend.
Kein Tunnel kommt zustande, obwohl eine komplett neu eingerichtete PFSense 2.5.2 auf einem anderen Board (das angesprochene IPU662 System) zum Einsatz kommt.
Leider kann ich die andere Seite nicht einfach so mit einem neuen Gerät ausstatten.
Die beiden Tunnel zu den Sonicwalls kamen ohne Probleme hoch.
Ich werde noch mit ein paar Einstellungen hantieren, aber meine Hoffnung ist gleich 0 an dieser Stelle.
Es gibt für mich keine Erklärung für das Verhalten der beiden PFSense Boxen. Ich werde an anderer Stelle eine PFSense von null auf einrichten und schauen, ob sich das dann wieder erfolgreich bewerkstelligen lässt.
Neue Kenntnisse teile ich mit und gebe erst einmal auf an dieser Stelle.
Einen schönen Sonntag euch noch.
Gruß
Marc
Gruß
Marc
Kein Tunnel kommt zustande, obwohl eine komplett neu eingerichtete PFSense 2.5.2 auf einem anderen Board (das angesprochene IPU662 System) zum Einsatz kommt.
Leider kann ich die andere Seite nicht einfach so mit einem neuen Gerät ausstatten.
Die beiden Tunnel zu den Sonicwalls kamen ohne Probleme hoch.
Ich werde noch mit ein paar Einstellungen hantieren, aber meine Hoffnung ist gleich 0 an dieser Stelle.
Es gibt für mich keine Erklärung für das Verhalten der beiden PFSense Boxen. Ich werde an anderer Stelle eine PFSense von null auf einrichten und schauen, ob sich das dann wieder erfolgreich bewerkstelligen lässt.
Neue Kenntnisse teile ich mit und gebe erst einmal auf an dieser Stelle.
Einen schönen Sonntag euch noch.
Gruß
Marc
Gruß
Marc
Checke mal dediziert beide IKE Versionen ! Sprich setze den Tunnel mal dediziert auf IKEv1 und auch IKEv2 und prüfe mal ob das einen Unterschied macht.
Problematik lässt sich hier an 2 APU2 pfSense jeweils mit 2.5.2 nicht reproduzieren. Weder mit v1 noch v2 noch im Auto Mode. Sogar eine mal mit OPNsense gebootet. Ebenso fehlerlos in v1 und v2.
Ggf. ist es also irgendwas mit einer Wechselwirkung von anderen Konfig Settings.
Problematik lässt sich hier an 2 APU2 pfSense jeweils mit 2.5.2 nicht reproduzieren. Weder mit v1 noch v2 noch im Auto Mode. Sogar eine mal mit OPNsense gebootet. Ebenso fehlerlos in v1 und v2.
Ggf. ist es also irgendwas mit einer Wechselwirkung von anderen Konfig Settings.
Einstellungen für IKE habe ich alle Varianten getestet.
Es wäre super, wenn das IPSec Log einen Hinweis geben würde, wo etwas hakt.
Ich hatte zwar auch schon NMAP Captures auf beiden Seiten laufen lassen, welche nichts ergaben, außer, dass die Pings oder RDP Zugriff einfach nicht durchgeleitet werden
Das werde ich jetzt mit der neuen Box wiederholen.
Eventuell wird irgendwo ein Unterschied ersichtlich.
Gruß
Marc
Es wäre super, wenn das IPSec Log einen Hinweis geben würde, wo etwas hakt.
Ich hatte zwar auch schon NMAP Captures auf beiden Seiten laufen lassen, welche nichts ergaben, außer, dass die Pings oder RDP Zugriff einfach nicht durchgeleitet werden
Das werde ich jetzt mit der neuen Box wiederholen.
Eventuell wird irgendwo ein Unterschied ersichtlich.
Gruß
Marc
@radiogugu
Hast du das jemals lösen können? Wenn ja, wie? Habe gerade ein ähnliches Phänomen.
Hast du das jemals lösen können? Wenn ja, wie? Habe gerade ein ähnliches Phänomen.
Wie oben schon bei 2.5.2 erwähnt lässt sich das auch nach einem Update auf die aktuelle 2.6.0 nicht nachvollziehen.
Sowohl IKEv1 als auch IKEv2 Tunnel zu OPnsense, Cisco, Mikrotik, FritzBox, Bintec, Strongswan, Lancom u.a. laufen absolut fehlerlos. Gleiches gilt bei Client Tunnel mit IKEv2 und L2TP mit IKEv1 bei Windows, Apple und Smartphones.
Sowohl IKEv1 als auch IKEv2 Tunnel zu OPnsense, Cisco, Mikrotik, FritzBox, Bintec, Strongswan, Lancom u.a. laufen absolut fehlerlos. Gleiches gilt bei Client Tunnel mit IKEv2 und L2TP mit IKEv1 bei Windows, Apple und Smartphones.
Zitat von @Kuemmel:
@radiogugu
Hast du das jemals lösen können? Wenn ja, wie? Habe gerade ein ähnliches Phänomen.
@radiogugu
Hast du das jemals lösen können? Wenn ja, wie? Habe gerade ein ähnliches Phänomen.
Habe zuhause jetzt mal auf die PFSense+ Edition "aufgerüstet".
Es ließen sich alle IPSec Tunnel problemlos einrichten und alle kamen hoch und "überlebten" auch einen Neustart.
Nach ein paar Wochen, war dann keiner der Tunnel zu einer der beiden eingerichteten Sonicwalls mehr "kooperativ".
Auch nach Löschung und neuem Erstellen kam keine Verbindung mehr zu Stande. Der Wireguard Tunnel zu einer anderen PFSense läuft ohne Mucken seit Monaten.
Zitat von @aqui:
Wie oben schon bei 2.5.2 erwähnt lässt sich das auch nach einem Update auf die aktuelle 2.6.0 nicht nachvollziehen.
Sowohl IKEv1 als auch IKEv2 Tunnel zu OPnsense, Cisco, Mikrotik, FritzBox, Bintec, Strongswan, Lancom u.a. laufen > absolut fehlerlos. Gleiches gilt bei Client Tunnel mit IKEv2 und L2TP mit IKEv1 bei Windows, Apple und Smartphones.
Wie oben schon bei 2.5.2 erwähnt lässt sich das auch nach einem Update auf die aktuelle 2.6.0 nicht nachvollziehen.
Sowohl IKEv1 als auch IKEv2 Tunnel zu OPnsense, Cisco, Mikrotik, FritzBox, Bintec, Strongswan, Lancom u.a. laufen > absolut fehlerlos. Gleiches gilt bei Client Tunnel mit IKEv2 und L2TP mit IKEv1 bei Windows, Apple und Smartphones.
Ich finde nix darüber, welche Einstellungen dafür sorgen könnten, dass IPSec Tunnel gestört werden.
Aber selbst nachdem ich die PFSense vollkommen neu installiert hatte, wollten die Tunnel nicht mehr funktionieren, ohne, dass irgendetwas umgestellt wurde.
Das der Provider (Glasfaser von lokalen Stadtwerken) IPSec blockt halte ich für unwahrscheinlich. Zumal ja L2TP Verbindungen zu den angesprochenen Sonicwalls ohne Probleme stabil rennen.
Gruß
Marc
Hat dir pfSense+ dann noch irgendeinen Vorteil gebracht? Rein aus Interesse: Hast du es mal Alternativ mit OPNSense probiert?
Zitat von @Kuemmel:
Hat dir pfSense+ dann noch irgendeinen Vorteil gebracht? Rein aus Interesse: Hast du es mal Alternativ mit OPNSense probiert?
Hat dir pfSense+ dann noch irgendeinen Vorteil gebracht? Rein aus Interesse: Hast du es mal Alternativ mit OPNSense probiert?
Vorteile hat es für mich jetzt nicht die Plus Variante zu fahren.
OPNSense hatte vor einigen Jahren Mucken gemacht bei den damals vorliegenden USB Sticks.
Daher gab ich PFSense eine Chance und das klappte sofort
Aufgrund der inzwischen erreichten Komplexität zuhause, habe ich auch weniger Lust das alles boch einmal umzubauen.
Habe mich damit abgefunden.
PFSense ist für mich aber aus diesem Grund raus, wenn es um den professionellen Einsatz ginge.
Hatte noch mal überlegt, ob es an der Hardware liegt. Da aber @aqui und Andere aber keine Probleme mit APU und IPU Boards haben, zweifle ich daran.
Eventuell würde mich noch reizen ein original Netgate Gerät anzuschaffen, um damit entsprechend Versuche zu starten.
Gruß
Marc
Was nutzt du jetzt an den Standorten wenn pfSense für dich nicht mehr in Frage kommt?
Zitat von @Kuemmel:
Was nutzt du jetzt an den Standorten wenn pfSense für dich nicht mehr in Frage kommt?
Was nutzt du jetzt an den Standorten wenn pfSense für dich nicht mehr in Frage kommt?
Das kommt auf das Budget und die Anforderungen an.
Darf es etwas kosten und soll performant sein > SonicWall / Sophos
Soll es einfach gehalten und erschwinglich sein > Draytek / Mikrotik (wobei ich bei Mikrotik noch in der Testphase / Proof of Concept Erstellung bin)
Wenn keine Site 2 Site Tunnel gebraucht werden, dann würde ich wahrscheinlich trotzdem PFSense auf einem APU / IPU Board empfehlen, bzw. ins Rennen werfen. Denn die verschiedenen VPN Möglichkeiten sind einfach sehr gut implementiert und schnell zum Fliegen zu bekommen.
Gruß
Marc
Es wird etwas Off Topic aber: Kannst du dein MikroTik Proof of Concept etwas näher erläutern? Wo hast du da Bauchschmerzen? Gerne auch per PN. Denke über Ähnliches nach.
Es geht mir darum, dass ich noch nicht viel mit Mikrotik in Kontakt gekommen bin.
Ein flaches Netz habe ich schon mal realisiert, aber noch nüschte mit VLANs oder LACP oder eben Site 2 Site VPNs.
Also eine persönliche Erfahrungsreise, welche mich befähigen soll Mikrotik meinem Portfolio hinzuzufügen.
Werde mir mal so einen kleinen Hex schnappen und lernen
Gruß
Marc
Ein flaches Netz habe ich schon mal realisiert, aber noch nüschte mit VLANs oder LACP oder eben Site 2 Site VPNs.
Also eine persönliche Erfahrungsreise, welche mich befähigen soll Mikrotik meinem Portfolio hinzuzufügen.
Werde mir mal so einen kleinen Hex schnappen und lernen
Gruß
Marc
dass ich noch nicht viel mit Mikrotik in Kontakt gekommen bin.
25 Euronen Taschengeld investieren und etwas zum Üben damit anschaffen. 😉Ist sogar besser als der hEX weil er gleich ein Dual Radio WLAN mit an Bord hat!
Zitat von @aqui:
Ist sogar besser als der hEX weil er gleich ein Dual Radio WLAN mit an Bord hat!
dass ich noch nicht viel mit Mikrotik in Kontakt gekommen bin.
25 Euronen Taschengeld investieren und etwas zum Üben damit anschaffen. 😉Ist sogar besser als der hEX weil er gleich ein Dual Radio WLAN mit an Bord hat!
Goldrichtig.
Eventuell kommt noch ein cAP mit AC dazu und dann hat man das Ökosystem quasi zusammen und kann Szenarien aufbauen und testen
Gruß
Marc
@aqui
Im Jahr 2022 ein Gerät mit FastEthernet-Ports kaufen.. ich weiß nicht Wäre mir selbst zum basteln zu schade. Dann lieber den hAP oder den Hex.. der 5009 kommt irgendwann von ganz alleine
Im Jahr 2022 ein Gerät mit FastEthernet-Ports kaufen.. ich weiß nicht
Wäre mir selbst zum basteln zu schade. Dann lieber den hAP oder den Hex.. der 5009 kommt irgendwann von ganz alleine
...wie z.B. das Radius Authentisierung! 😉
Und wenn er MT Profi ist kann er das Teil immer noch als reinen AP verwenden. Auch dafür reicht 100Mbit völlig.
Aber alles, wie immer, Geschmacks und Budgetsache!
Wäre mir selbst zum basteln zu schade
Zum Lernen ist das doch völlig Wumpe und für Labortraffic allemal ausreichend. Der deutliche Preisunterschied für so eine eierlegende Wollmilchsau wiegt das für den Lerneffekt allemal auf.Und wenn er MT Profi ist kann er das Teil immer noch als reinen AP verwenden. Auch dafür reicht 100Mbit völlig.
Aber alles, wie immer, Geschmacks und Budgetsache!
Mahlzeit zusammen.
Nochmal ein kleines Update.
Es funktionieren aktuell alle Tunnel. Egal ob von der PFSense+ 22.05er zu einer 2.5.2 oder zu einem Draytek 3910 oder zu einer SonicWall TZ470.
Sobald ich die Perfect Forward Secrecy einschalte ist der Tunnel nicht mehr zu etablieren. Ist die Einstellung auf beiden Seiten wieder auf "Off" gestellt, geht der Tunnel sofort wieder.
Keinen Plan, was hier los ist an der Stelle.
Gruß
Marc
Nochmal ein kleines Update.
Es funktionieren aktuell alle Tunnel. Egal ob von der PFSense+ 22.05er zu einer 2.5.2 oder zu einem Draytek 3910 oder zu einer SonicWall TZ470.
Sobald ich die Perfect Forward Secrecy einschalte ist der Tunnel nicht mehr zu etablieren. Ist die Einstellung auf beiden Seiten wieder auf "Off" gestellt, geht der Tunnel sofort wieder.
Keinen Plan, was hier los ist an der Stelle.
Gruß
Marc
Einer deiner Tunnelpartner Partner supportet kein PFS und damit scheitert dann die Phase1 oder auch Phase2 Negotiation! Nutzt du AES und SHA2 ? Wenn Ja CBC oder GCM Verfahren?
Lesenswert dazu: https://www.heise.de/hintergrund/Der-Krypto-Wegweiser-fuer-Nicht-Kryptol ...
Lesenswert dazu: https://www.heise.de/hintergrund/Der-Krypto-Wegweiser-fuer-Nicht-Kryptol ...
Morschen @aqui.
Es kommt sowohl AES-192 CBC als auch AES-192 GCM zum Einsatz. Beide mit SHA256 Hash.
Dann wird es meine PFSense Konfiguration sein. Liegt es eventuell an der obigen Einstellung bezüglich Cryptographic Hardware?
Edit:
Darf dort das BSD Crypto Device eventuell nicht drin vorkommen? Denn sobald ich da nur AES-NI aktiviere, kommt der Tunnel tatsächlich auch hoch.
Welche Einstellungen hast du bei deinen APU Boards unter System > Advanced > Miscellaneous hinterlegt?
Gruß
Marc
Es kommt sowohl AES-192 CBC als auch AES-192 GCM zum Einsatz. Beide mit SHA256 Hash.
Dann wird es meine PFSense Konfiguration sein. Liegt es eventuell an der obigen Einstellung bezüglich Cryptographic Hardware?
Edit:
Darf dort das BSD Crypto Device eventuell nicht drin vorkommen? Denn sobald ich da nur AES-NI aktiviere, kommt der Tunnel tatsächlich auch hoch.
Welche Einstellungen hast du bei deinen APU Boards unter System > Advanced > Miscellaneous hinterlegt?
Gruß
Marc
Darf dort das BSD Crypto Device eventuell nicht drin vorkommen?
Ja, das ist falsch. Es darf nur AES NI sein! Die BSD Devices sind spezielle Crypto HW die natürlich im APU Board nicht enthalten ist. Zudem ist das meist auch alt.So sähe das richtige Setup fürs APU Board (und alle AES/NI fähigen CPUs) aus:
Jetzt ist alles in Butter und die IPSec Tunnel fliegen.
Seltsam, dass Wireguard davon nicht betroffen ist.
Egal, es läuft und ich hab wieder etwas gelernt
Gruß
Marc
Seltsam, dass Wireguard davon nicht betroffen ist.
Egal, es läuft und ich hab wieder etwas gelernt
Gruß
Marc
1
