14
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
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: 578122
Url: https://administrator.de/contentid/578122
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
14 Kommentare
Neuester Kommentar
Hi,
Hast du auf beiden Firewalls auf der WAN Seite ESP und UDP/500 eingehend erlaubt ?
ggf. mal auf dem WAN Interface von auto negotiation auf einen manuellen Wert ändern.
poste mal die Einstellungen P1 und P2 beiden Seiten.
"Eigentlich" ist IPsec Site 2 Site zwischen zwei pfSensen sehr stabil.
CH
Hast du auf beiden Firewalls auf der WAN Seite ESP und UDP/500 eingehend erlaubt ?
ggf. mal auf dem WAN Interface von auto negotiation auf einen manuellen Wert ändern.
poste mal die Einstellungen P1 und P2 beiden Seiten.
"Eigentlich" ist IPsec Site 2 Site zwischen zwei pfSensen sehr stabil.
CH
WAN Seitig sollte das passen. So sieht es auf der Seite A aus.
Seite A Phase 1:
Seite A Phase 2:
Seite B Phase 1:
Seite B Phase 2:
Seite A Phase 1:
Seite A Phase 2:
Seite B Phase 1:
Seite B Phase 2:
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. ?
Ich wollte nur nochmal nachfolgendes erwähnen.
Wenn ich egal von Seite A oder B einen Client im Dauerping auf die andere Seite laufen lasse, dann bleibt die Verbindung 3, 4, 5, 6, 7......... Tage stabil. Erst wenn ich dann den Dauerping raus nehme, ist in unterschiedlichen Abständen von A nach B nichts mehr zu machen. B nach A geht immer.
Wenn ich egal von Seite A oder B einen Client im Dauerping auf die andere Seite laufen lasse, dann bleibt die Verbindung 3, 4, 5, 6, 7......... Tage stabil. Erst wenn ich dann den Dauerping raus nehme, ist in unterschiedlichen Abständen von A nach B nichts mehr zu machen. B nach A geht immer.
Crypto Support war nur in Standort B aktiv.
Link Loss kann ich ausschließen. Dauerping über mehrere Tage hat keine Verluste.
Version ist auf beiden 2.4.5.
Link Loss kann ich ausschließen. Dauerping über mehrere Tage hat keine Verluste.
Version ist auf beiden 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.
Dann schaltet den Hearth beat für die Verbindung ein und pinge jeweils das andere Gateway durch den Tunnel.
Wäre zumindest eine Option.
Wäre zumindest eine Option.
Zitat von @ChriBo:
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
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
Der Haken bedeutet Keep Source Port Static und die Pfeile Randomize Source Port. Die Regel ist im NAT/Ausgehend eingetragen.
Ich habe folgende Umstellung gemacht:
- Standort A Power D aktiviert und Crypto auf AES_NI CPU-basierte Beschleunigung mit AMD Sensor
- Standort A + B IKEv1 Modus Main
- Standort A + B AES 256, Hash: SHA256, DH Gruppe 14
Zitat von @aqui:
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.
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.
Die Rule ist nicht im WAN. Das habe ich falsch dargestellt. Die Rule ist im NAT/Ausgehend eingetragen.
IPSec ist derzeit noch offen mit der Scheunentor Regel
Die Verbindung läuft jetzt seit Vormittag mit den oben genannten Änderungen stabil.
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.
👍
Eieiei, der "Haken" daran war mein Finger. Der war zu schnell
Dafür gibts ja immer den "Bearbeiten" Knopf !!
Tip: Der liegt rechts unten unter "Mehr" und kaschiert auch nachträglich noch !
Tip: Der liegt rechts unten unter "Mehr" und kaschiert auch nachträglich noch !
Erledigt. Vielen Dank für die Hilfe.
