Ipsec Site zu Host für LDAPs Abfrage
Hallo Zusammen,
Vorab kurz zum Hintergrund und die bitte mich nicht wegen der wahl der hersteller zu verurteilen. Ich habe meine alte Sonicwall durch eine sophos XGS ersetzt und stehe nun vor einem Verständnis- Stabilitätsprogramm.
Wir haben einen Root- Server (Debian) bei Herzner gemietet und nutzen diesen als Dockerhost für unsere Entwickler und für das sharing von Daten (nextcloud) mit anderen. Dieser Server ist via Ipsec an die Sonicwall angebunden um die Credentials der Benutzer via LDAPs von unserem DC abzufrage. Ein netter Nebeneffekt ist dass der komplette Trafik zu diesem Server über den IPsec-Tunnel lief.
Nun zum Problem:
Das ganze Konstrukt funktionierte bis zum Tausch der Firewall problemlos, doch jetzt bricht mir der Tunnel immer wieder ab und baut sich nicht auf. Die Fehlermeldung in der Firewall sagt, daß die Gegenstelle nicht erreichbar ist. Das ist logisch da der Server nur eine IP-Adresse hat und diese als Gateway für den IPsec- Tunnel dient und gleichzeitig als remote-Subnetz eingetragen ist. Aus mir nicht ganz ersichtlichen Gründen konnte das Sonicwall mit den Timings besser als die Sophos.
Docker-Container
V
Root-Server xxx.xxx.xxx.xxx/32 (strongswan)
V
IPsec-Tunnel
V
Sophos XGS yy.yy.yy.yy
V
Lan: xx.xx.yy.xx/24
Aktuell wird die Verbindung aufgebaut und es können Daten übertragen werden. Wenn die Verbindung aber abbricht muss man sich auf den root-server schalten und den Tunnel manuell aufbauen.
Denn wenn die Verbindung nicht aktiv ist und nextcloud den DC nicht erreicht kommt zu probleme und die Instanz schmiert ebenfalls ab.
Hätte ihr evtl. eine Idee wie ich das anders lösen könnte oder wie das Timing in der sophos anpassen kann?
Die Verbindung auf Tunnelinterfaces umzubauen habe ich auch schon gedacht aber wieder verworfen, da ich das interne Subnetz zum root-server rooten könnte aber nicht wirklich ein Subnetz zurück!? Evtl. die Docker-Netzwerke dann würde ich nur noch den Verwaltungstrafik über den Tunnel jagen.... wäre auch i.O.
Also wie schon gesagt ich stehe gerade voll auf dem Schlauch und brauche Hilfe.
PS. Ich hätte den Root-Server anders aufgesetzt dann hätte ich solche Probleme jetzt nicht, aber das war leider vor meiner Zeit.
Viele Grüße und schon mal einen guten Rutsch
Vorab kurz zum Hintergrund und die bitte mich nicht wegen der wahl der hersteller zu verurteilen. Ich habe meine alte Sonicwall durch eine sophos XGS ersetzt und stehe nun vor einem Verständnis- Stabilitätsprogramm.
Wir haben einen Root- Server (Debian) bei Herzner gemietet und nutzen diesen als Dockerhost für unsere Entwickler und für das sharing von Daten (nextcloud) mit anderen. Dieser Server ist via Ipsec an die Sonicwall angebunden um die Credentials der Benutzer via LDAPs von unserem DC abzufrage. Ein netter Nebeneffekt ist dass der komplette Trafik zu diesem Server über den IPsec-Tunnel lief.
Nun zum Problem:
Das ganze Konstrukt funktionierte bis zum Tausch der Firewall problemlos, doch jetzt bricht mir der Tunnel immer wieder ab und baut sich nicht auf. Die Fehlermeldung in der Firewall sagt, daß die Gegenstelle nicht erreichbar ist. Das ist logisch da der Server nur eine IP-Adresse hat und diese als Gateway für den IPsec- Tunnel dient und gleichzeitig als remote-Subnetz eingetragen ist. Aus mir nicht ganz ersichtlichen Gründen konnte das Sonicwall mit den Timings besser als die Sophos.
Docker-Container
V
Root-Server xxx.xxx.xxx.xxx/32 (strongswan)
V
IPsec-Tunnel
V
Sophos XGS yy.yy.yy.yy
V
Lan: xx.xx.yy.xx/24
Aktuell wird die Verbindung aufgebaut und es können Daten übertragen werden. Wenn die Verbindung aber abbricht muss man sich auf den root-server schalten und den Tunnel manuell aufbauen.
Denn wenn die Verbindung nicht aktiv ist und nextcloud den DC nicht erreicht kommt zu probleme und die Instanz schmiert ebenfalls ab.
Hätte ihr evtl. eine Idee wie ich das anders lösen könnte oder wie das Timing in der sophos anpassen kann?
Die Verbindung auf Tunnelinterfaces umzubauen habe ich auch schon gedacht aber wieder verworfen, da ich das interne Subnetz zum root-server rooten könnte aber nicht wirklich ein Subnetz zurück!? Evtl. die Docker-Netzwerke dann würde ich nur noch den Verwaltungstrafik über den Tunnel jagen.... wäre auch i.O.
Also wie schon gesagt ich stehe gerade voll auf dem Schlauch und brauche Hilfe.
PS. Ich hätte den Root-Server anders aufgesetzt dann hätte ich solche Probleme jetzt nicht, aber das war leider vor meiner Zeit.
Viele Grüße und schon mal einen guten Rutsch
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 22526051837
Url: https://administrator.de/contentid/22526051837
Ausgedruckt am: 18.11.2024 um 23:11 Uhr
7 Kommentare
Neuester Kommentar
Schwer etwas zu deinem Problem zu sagen, mit den Infos.
Ein "Tunnelinterface" wäre zu bevorzugen. Ansonsten scheinst Du einige Best-Practices nicht zu kennen. Stichwort: Transfernetz
Du erzeugst bevorzugt auf beiden Seiten ein Transfernetz, darüber schiebest Du den Traffic. Dabei kannst du auch auf einzelne Hosts eingehen. wenn das aber ein Problem ist, dann läuft noch einiges anderes falsch.
Ein "Tunnelinterface" wäre zu bevorzugen. Ansonsten scheinst Du einige Best-Practices nicht zu kennen. Stichwort: Transfernetz
Du erzeugst bevorzugt auf beiden Seiten ein Transfernetz, darüber schiebest Du den Traffic. Dabei kannst du auch auf einzelne Hosts eingehen. wenn das aber ein Problem ist, dann läuft noch einiges anderes falsch.
Sinnvoll wäre eine zweite /32er RFC1918 Loopback Adresse auf dem Server zu setzen für die Phase2 Credentials und Keepalive. Die Beschreibung ist leider recht oberflächlich, da man die genauen Strongswan Settings bzw. das Setup nicht kennt.
Hier muss man natürlich aufpassen, das DPD Keepalives, Crypto Lifetimes, IKE Version, usw. mit der Sophos im P1 und P2 Setup korrespondieren. Zu all diesen Dingen fehlen hilfreiche Angaben im Detail um zielführende Tipps zu geben so das man leider wie so oft nur frei raten kann.
Es ist aber davon auszugehen das das Setup fehlerhaft ist und das der Grund der Instabilitäten ist, denn auf der Sophos werkelt im Hintergrund ebenfalls ein Strongswan und solche Peer Connections sind bekanntlich sehr stabil.
Entsprechende Strongswan IPsec Settings zeigen diese Forenthreads zur Orientierung:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Strongswan Site-to-Site mit einer NIC
Hier muss man natürlich aufpassen, das DPD Keepalives, Crypto Lifetimes, IKE Version, usw. mit der Sophos im P1 und P2 Setup korrespondieren. Zu all diesen Dingen fehlen hilfreiche Angaben im Detail um zielführende Tipps zu geben so das man leider wie so oft nur frei raten kann.
Es ist aber davon auszugehen das das Setup fehlerhaft ist und das der Grund der Instabilitäten ist, denn auf der Sophos werkelt im Hintergrund ebenfalls ein Strongswan und solche Peer Connections sind bekanntlich sehr stabil.
Entsprechende Strongswan IPsec Settings zeigen diese Forenthreads zur Orientierung:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Strongswan Site-to-Site mit einer NIC
Du solltest mit Strongswan nicht mehr das völlig veraltete Konfig Konzept verwenden sondern das moderne und aktuelle vici basierte Verfahren via swanctl. Das wird sich auch deutlich auf deine VPN Stabilität auswirken.
Wie das aussieht kannst du hier sehen:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Das Grundsetup für so ein von dir oben beschriebenes Gateway Redirect Setup hat der Kollege @10138557388 hier kürzlich in einem anderen aktuellen Thread beschrieben.
Strongswan Jumphost mit Mikrotik Client als Switch
Wie das aussieht kannst du hier sehen:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Das Grundsetup für so ein von dir oben beschriebenes Gateway Redirect Setup hat der Kollege @10138557388 hier kürzlich in einem anderen aktuellen Thread beschrieben.
Strongswan Jumphost mit Mikrotik Client als Switch
Wenn es einen Mismatch der beidseitigen IDs gibt kommt der Tunnel erst gar nicht zustande. Das kann es eigentlich nicht sein.
Instabilitäten sind in der Regel größere Unterschiede in den Key Lifetimes auf beiden Seiten die dann zu wechselnden Abbrüchen und Neuaufbau führen.
Hast du die mal geprüft und verglichen das die gleich oder annähernd gleich sind?
Instabilitäten sind in der Regel größere Unterschiede in den Key Lifetimes auf beiden Seiten die dann zu wechselnden Abbrüchen und Neuaufbau führen.
Hast du die mal geprüft und verglichen das die gleich oder annähernd gleich sind?