PfSense Site2Site sporadisch kein Zugriff von A nach B
Hallo,
ich habe mit 2 pfSense Firewalls eine Site2Site Verbindung erstellt. Momentan steht die Hardware noch im Labor und ist an den WAN Schnittstellen mit einem Patchkabel verbunden.
Mir ist jetzt aufgefallen, das nach einer gewissen Zeit, nicht mehr von Standort A nach Standort B zugegriffen werden kann. In Standort A war aber der Tunnel aktiv. Im Status -> IPSec war ebenfalls Established. Aufgefallen war mir da allerdings, dass 26 child sa Einträge aufgelistet waren. Ich habe dann IPSec getrennt und neu verbunden. Der Status ist dann auch gleich wieder verbunden und es ist ein child sa Eintrag aufgelistet. Auch auf dem Dashboard steht der Tunnel auf aktiv. Aber ich kann immer noch nicht von A nach B. Darauf habe ich auf der Seite B den Client gestartet und auf die Seite A einen Ping ausgelöst. Das funktionierte auf Anhieb und sofort konnte ich auch wieder von A nach B zugreifen. Die Einstellungen sind auf beiden Seiten komplett identisch. An was könnte das liegen?
Gruß Christian
ich habe mit 2 pfSense Firewalls eine Site2Site Verbindung erstellt. Momentan steht die Hardware noch im Labor und ist an den WAN Schnittstellen mit einem Patchkabel verbunden.
Mir ist jetzt aufgefallen, das nach einer gewissen Zeit, nicht mehr von Standort A nach Standort B zugegriffen werden kann. In Standort A war aber der Tunnel aktiv. Im Status -> IPSec war ebenfalls Established. Aufgefallen war mir da allerdings, dass 26 child sa Einträge aufgelistet waren. Ich habe dann IPSec getrennt und neu verbunden. Der Status ist dann auch gleich wieder verbunden und es ist ein child sa Eintrag aufgelistet. Auch auf dem Dashboard steht der Tunnel auf aktiv. Aber ich kann immer noch nicht von A nach B. Darauf habe ich auf der Seite B den Client gestartet und auf die Seite A einen Ping ausgelöst. Das funktionierte auf Anhieb und sofort konnte ich auch wieder von A nach B zugreifen. Die Einstellungen sind auf beiden Seiten komplett identisch. An was könnte das liegen?
Gruß Christian
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 578122
Url: https://administrator.de/forum/pfsense-site2site-sporadisch-kein-zugriff-von-a-nach-b-578122.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
14 Kommentare
Neuester Kommentar
An den Crypto Credentials solltest du mal etwas schrauben. Es macht ja sehr wenig Sinn mit schwacher 128 Bit Verschlüsselung zu arbeiten und dann die DH Gruppen unendlich hoch zu setzen.
Nimm da mal einen moderaten Mittelwert und die DH Gruppen immer gleich in P1 und P2 also:
Hast du den Crypto Support in den Advanced Settings aktiviert ?
Kannst du einen Link Loss auf der derzeit direkten Verbindung ausschliessen ?
Wenn ja solltest du testweise mal statt IKEv2 auf IKEv1 (Main Mode) gehen und checken ob das Tunnel Verhalten da anders bzw. stabiler ist.
Nutzt du die aktuelle Version 2.4.5. ?
Nimm da mal einen moderaten Mittelwert und die DH Gruppen immer gleich in P1 und P2 also:
- AES 256
- Hash: SHA256
- DH Gruppe 14
Hast du den Crypto Support in den Advanced Settings aktiviert ?
Kannst du einen Link Loss auf der derzeit direkten Verbindung ausschliessen ?
Wenn ja solltest du testweise mal statt IKEv2 auf IKEv1 (Main Mode) gehen und checken ob das Tunnel Verhalten da anders bzw. stabiler ist.
Nutzt du die aktuelle Version 2.4.5. ?
Crypto Support war nur in Standort B aktiv.
Böses Faul ! Das sollte natürlich nicht sein, denn dann rennt alles in Software mit entsprechenden Verlusten. Letztlich merkst du das aber erst wenn wirklich Traffic auf den Tunnel kommt und das wird es im Testsetup nicht sich nicht sein.Setze also die Crypto Credentials mal auf sinnvolle Werte und teste die IKEv1 Version mal zum Vergleich im Main Mode.
Hi,
4erlei:
1. Wie @aqui schrieb: nimm seine Vorschläge bzgl. Crypto Credentials.
2. Hast du "Block RFC networks" auf dem WAN interface enabled ? muß disabled sein
3. Gib mir mal nen Tip: Was bedeuten die Symbole vor der Beschreibung in den Regeln (Häckchen bzw. zwei gekreuzte Pfeile)
4. in Phase 1: anstelle von "Meine Identifizierungsart" und "Gegenstellen Identifizierungsart" nimm mal "IP Adresse" und setzte die IP Adresse der Gegenstelle ein, muß nicht helfen, kann aber helfen.
CH
4erlei:
1. Wie @aqui schrieb: nimm seine Vorschläge bzgl. Crypto Credentials.
2. Hast du "Block RFC networks" auf dem WAN interface enabled ? muß disabled sein
3. Gib mir mal nen Tip: Was bedeuten die Symbole vor der Beschreibung in den Regeln (Häckchen bzw. zwei gekreuzte Pfeile)
4. in Phase 1: anstelle von "Meine Identifizierungsart" und "Gegenstellen Identifizierungsart" nimm mal "IP Adresse" und setzte die IP Adresse der Gegenstelle ein, muß nicht helfen, kann aber helfen.
CH
Etwas Kosmetik...
ad 2.
Das aber nur für den Test und auch nur wenn du RFC 1918 IPs für die WAN Testadressierung genommen hast. Mit "quasi realen" IPs muss das nicht sein bzw. ist später auch gefährlich wenn die Firewalls direkt (ohne Kaskade) im Internet hängen.
ad 3.
Die WAN Rule ist definitiv FALSCH und auch Quatsch. Hatte ich fast übersehen. Dort fehlen die RFC 1918 und Bogus Blocks. Für IPsec muss UDP 500, 4500 und ESP auf die WAN IP erlaubt sein und die "VLAN" Regel da ist völlig falsch. VLANs haben am WAN nix zu suchen. Es sei denn man hat ein altes xDSL Modem was kein Tagging kann. Und auch nur dann.
An den Default WAN Regeln muss man niemals was rumfummeln außer eben Zugang rein auf die WAN IP erlauben.
ad 4.
Das ist eher kosmetisch. Ggf. muss er das nachher so oder so ändern auf FQDN wenn er Anschlüsse mit wechselnden IPs hat.
ad 2.
Das aber nur für den Test und auch nur wenn du RFC 1918 IPs für die WAN Testadressierung genommen hast. Mit "quasi realen" IPs muss das nicht sein bzw. ist später auch gefährlich wenn die Firewalls direkt (ohne Kaskade) im Internet hängen.
ad 3.
Die WAN Rule ist definitiv FALSCH und auch Quatsch. Hatte ich fast übersehen. Dort fehlen die RFC 1918 und Bogus Blocks. Für IPsec muss UDP 500, 4500 und ESP auf die WAN IP erlaubt sein und die "VLAN" Regel da ist völlig falsch. VLANs haben am WAN nix zu suchen. Es sei denn man hat ein altes xDSL Modem was kein Tagging kann. Und auch nur dann.
An den Default WAN Regeln muss man niemals was rumfummeln außer eben Zugang rein auf die WAN IP erlauben.
ad 4.
Das ist eher kosmetisch. Ggf. muss er das nachher so oder so ändern auf FQDN wenn er Anschlüsse mit wechselnden IPs hat.
Der Hacken bedeutet
Hacken ??Sowas benutzt man aber nicht in der IT sondern nur im Garten oder hat es unten am Fuß:
https://de.wikipedia.org/wiki/Hacke_(Werkzeug)
https://de.wikipedia.org/wiki/Ferse
Oder meintest du einen Haken ?!:
https://www.duden.de/rechtschreibung/Haken
Die Verbindung läuft jetzt seit Vormittag mit den oben genannten Änderungen stabil.
👍