Nach PFSense 2.5.2 Update IPSec Tunnel "kaputt" (nur zu anderer PFSense)

radiogugu
Goto Top
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.

ipsec_tunnel

ping

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

Content-Key: 1143768991

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

Ausgedruckt am: 13.08.2022 um 05:08 Uhr

Mitglied: adminst
adminst 11.08.2021 um 09:26:43 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.08.2021 aktualisiert um 10:54:02 Uhr
Goto Top
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 !
Mitglied: radiogugu
radiogugu 11.08.2021 aktualisiert um 11:45:28 Uhr
Goto Top
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.

Habe ich auch vor, nur wollte ich gerne dieses Phänomen verstanden haben face-smile

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 !

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:

ipsec_tunnel

Box Nr. 2:

screenshot 2021-08-11 114450

Box Nr. 1 (mit dynamischer IP) ist als Initiator und Box Nr. 2 ist als Responder konfiguriert (Child SA Start + Close Action).

Gruß
Marc
Mitglied: radiogugu
radiogugu 11.08.2021 um 12:18:48 Uhr
Goto Top
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
Mitglied: aqui
aqui 11.08.2021 um 12:21:40 Uhr
Goto Top
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 ...
Mitglied: radiogugu
radiogugu 11.08.2021 um 12:30:41 Uhr
Goto Top
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 ...

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
Mitglied: the-buccaneer
the-buccaneer 11.08.2021 um 23:48:10 Uhr
Goto Top
Hi radioguru!

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... face-wink 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
Mitglied: radiogugu
radiogugu 12.08.2021 aktualisiert um 08:39:10 Uhr
Goto Top
Zitat von @the-buccaneer:
Deswegen fürchte ich PfSense Updates wie der Teufel das Weihwasser... face-wink 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.

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 face-smile

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
Mitglied: noesel
noesel 15.08.2021 um 22:51:49 Uhr
Goto Top
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
Mitglied: aqui
aqui 16.08.2021 aktualisiert um 11:17:26 Uhr
Goto Top
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 ?!
pfaes

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. face-sad

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:
https://administrator.de/tutorial/ipsec-ikev2-standort-vpn-vernetzung-mi ...
Mitglied: radiogugu
radiogugu 16.08.2021 aktualisiert um 13:10:07 Uhr
Goto Top
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 face-smile

Gruß
Marc
Mitglied: aqui
aqui 16.08.2021 um 13:01:18 Uhr
Goto Top
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 !
Mitglied: noesel
noesel 18.08.2021 um 23:16:11 Uhr
Goto Top
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:
  • 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
Mitglied: aqui
aqui 19.08.2021 um 09:16:25 Uhr
Goto Top
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....
Mitglied: noesel
noesel 19.08.2021 um 20:58:59 Uhr
Goto Top
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.
Mitglied: aqui
aqui 20.08.2021 aktualisiert um 12:36:05 Uhr
Goto Top
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.
Mitglied: radiogugu
radiogugu 22.08.2021 um 12:29:33 Uhr
Goto Top
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.

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
Mitglied: aqui
aqui 22.08.2021 aktualisiert um 12:52:55 Uhr
Goto Top
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... face-wink
Mitglied: radiogugu
radiogugu 29.08.2021 um 17:10:22 Uhr
Goto Top
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
Mitglied: aqui
aqui 29.08.2021 um 17:53:07 Uhr
Goto Top
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.
Mitglied: radiogugu
radiogugu 29.08.2021 um 18:18:05 Uhr
Goto Top
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