lernsaft
Goto Top

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

Content-Key: 22526051837

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

Printed on: July 24, 2024 at 15:07 o'clock

Mitglied: 8585324113
8585324113 Dec 29, 2023 at 05:37:19 (UTC)
Goto Top
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.
Member: aqui
aqui Dec 29, 2023 updated at 09:43:56 (UTC)
Goto Top
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. face-sad
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. face-sad
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
Member: Lernsaft
Lernsaft Jan 11, 2024 at 09:54:50 (UTC)
Goto Top
Hallo Zusammen,

vielen Dank schon mal für die Antworten und den Artikel.
Ich möchte mich daher nochmal für sehr flache Beschreibung entschuldigen und reiche diese für einen evtl. zielführenden Denkanstoß nach. Daher habe ich nochmal eine kleine Skizze mit angefügt, wie das Konstrukt aktuell aussieht und auch läuft, aber wie schon erwähnt nicht sehr stabil.
Ziel ist immer noch, dass der gesamte Traffic aus dem LAN zum Root-Server über den IPsec-Tunnel läuft (siehe Skizze).
Und dass die Dienste (Docker-Apps) auf dem Root-Server das interne Netzwerk erreichen können.
oculus-vpn


Die Idee mit dem Transfernetzwerk hatte ich auch schon, aber leider komme ich nicht darauf, wie ich das Netzwerk routen soll? Denn wenn ich eine statische Route "44.55.66.77/32 -> Tunnel-Interface" auf der Sophos anlege, kann diese den IPsec-Tunnel nicht mehr aufbauen, da die Sophos die Gegenstelle nicht mehr finden kann. Weil das Tunnel-Interface immer verfügbar ist, sobald der Tunnel aktiviert wurde.

Nun zur Konfiguration
Es wird zwar strongswan genutzt, aber noch mit /etc/ipsec.conf welche auf dem Root-Server wie folgt aussieht:
ipsec.conf
config setup
        charondebug="all"  
        uniqueids=yes
conn Ipsec-Tunnel
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=secret
        left=44.55.66.77
        leftsubnet=44.55.66.77/32
        right=33.44.55.66
        rightsubnet=192.168.xxx.xxx/xx
        ike=aes256-sha256-modp2048
        esp=aes256-sha256
        aggressive=no
        keyingtries=%forever
        ikelifetime=28800s
        lifetime=3600s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

Sophos IPsec-Konfiguration:
oculus-vpn_sophos
oculus-vpn_sophos_ipsecprofile

Solltet ihr noch mehr Informationen brauchen, einfach melden.
Bis dahin schon mal vielen Dank.

Grüßli Lernsaft
Member: aqui
Solution aqui Jan 11, 2024 updated at 10:03:53 (UTC)
Goto Top
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
Member: Lernsaft
Lernsaft Jan 11, 2024 at 10:04:53 (UTC)
Goto Top
Ok, dann werde ich das mal migrieren.
Ist dir sonst noch etwas aufgefallen oder ist die Konfig für das gewünschte Konstrukt i.O.?
Member: Lernsaft
Lernsaft Jan 16, 2024 at 09:13:23 (UTC)
Goto Top
Jetzt habe ich einen stabilen Tunnel, danke schon einmal für den Denkanstoß aqui.

Zitat von @aqui:

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

Jedoch war der Tunnel nach der Migration auf die vici-Config immer noch nicht stabil und ich musste weiter suchen. Erst nach ich die Local und Remote ID auf der Sophos auf Auto gestellt habe, war der Tunnel stabil. Was sich mir aber nicht erschließt, denn ich hatte die IP-Adressen der Endpoint dafür genutzt und diese werden jetzt bei der automatisch ebenfalls genutzt. Denn jetzt habe ich auch keine Fehlermeldung mehr im Log der Sophos, dass das Remote-Gateway nicht gefunden werden kann.

Vielleicht habt ihr mir da noch eine kurze Erklärung?

Grüßli
Member: aqui
aqui Jan 16, 2024 at 11:23:20 (UTC)
Goto Top
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?