25.10.2021

6150

Linux End-to-Site VPN mit Sophos SG

Hallo und Hilfe.

Ich habe eine Sophos SG, die unterstützt laut Menü "Remote Access"
SSL
PPTP
L2TP over IPsec
IPsec
Cisco™ VPN Client

Dabei ist SSL die Config für OpenVPN. Das nutzen wir seit Jahren und das möchte ich auch unverändert belassen. Ich kann hier nicht sowas wie Profile anlegen, meine Änderungen wirken sich sofort auf alle Teilnehmer aus.

Jetzt möchte ich von einem Linux Server (Ubuntu 20.04.3), den ich plane in einem "fremden" Netz aufzustellen, eine VPN Verbindung in mein Netzwerk aufbauen. Der Server (Backup Repository) soll also vor Ort über DHCP ins Netz und Internetzugriff haben um dann selbstsändig und nur für sich selbst VPN mit der Firewall machen, über die erreicht er dann seinen Meister (unseren Datensicherungsserver).

Der Datensicherungsserver baut die Verbindung zu seinem Repository auf daher wäre eine feste IP auf Seiten des VPN Interface des Linux Servers aus meiner sicht extrem sinnvoll. Bei OpenVPN lassen sich die IPs nur aus einem Pool vergeben und diese IPv4 stehen dann auch nicht in der DHCP lease table, ich kann also dem Linux Server nicht immer die selbe IP zuordnen. Da alle bisherigen Client VPN Verbindungen über OpenVPN ankommen scheint mir das keine Lösung zu sein.

Leider habe ich von IPsec eigentlich keine Ahnung. Ich bin nichtmal sicher was Sophos unter IPsec versteht, IKEv2 wird von der SG nicht! unterstützt, soviel weiß ich jetzt. L2TP over IPsec ist ein eigener Punkt, kann also der Punkt "IPsec" nur IKEv1 meinen?

Ich habe jedenfalls in der Sophos einen Benutzer angelegt, IPsec unter "Remote Access" konfiguriert und bewusst einen IPv4 Adress-Pool mit einem /31 Subnet gewählt. Hier kann ich auch verschiedene Profile hinterlegen, also z.B. verschiedene IPv4 Pools verwenden, für OpenVPN geht das nicht.

Für IPsec IKEv2 unter Linux hatte ich mir eine Anleitung mit Strongswan raus gesucht und habe den Client Teil umgesetzt.
https://linoxide.com/install-and-configure-strongswan-vpn-on-ubuntu/
Nur leider passiert da so gar nichts. Ich finde auch leider keine Logs und ich stochere eigentlich nur im Nebel, vermutlich habe ich schon lange vorher Probleme eingebaut. Strongswan versucht auch Config-Stand jetzt eine IKEv2 Verbindung aufzubauen.

Ich hoffe ihr könnt mir bei ein paar Fragen helfen:
- Grundsätzlich: Welchen VPN Typ sollte man anstreben für ein möglichst performantes WAN-Backup?
- Kann mein Vorhaben mit Sophos SG gelingen? Muss ich mir hier eventuell mit Site-2-Site behelfen?
- Ist Strongswan unter Linux der richtige Client für mich?

PS: Bei Strongswan kann ich das Wiki grade nicht aufrufen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1429394530

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

Ausgedruckt am: 19.12.2024 um 08:12 Uhr

24 Kommentare

Neuester Kommentar

Mit Strongswan bist du auf alle Fälle auf dem richtigen Weg und damit ist das problemlos zu realisieren.
Bevor wir ins Eingemachte gehen solltest du nur klarstellen ob du Strongswan mit der alten Option und Konfig der Dateien /etc/ipsec.conf und /etc/ipsec.secrets nutzt oder ob du die moderne Variante mit dem VICI Interface und swanctl nutzt.
Die Konfig ist etwas unterschiedlich das Ergebnis gleich.
Grundlegend ist bei beiden das du mit sudo apt install strongswan libstrongswan-extra-plugins libcharon-extra-plugins und ggf. bei der VICI Nutzung noch strongswan-swanctl charon-systemd installierst.
IPv4 Forwarding sollte in der etc/sysctl.conf aktiviert sein.

Das hiesige IKEv2 Beispiel zeigt wie man es recht einfach und unkompliziert mit einer pfSense/OPNsense realisiert. Das dürfte zur Sophos völlig identisch sein, denn die Sophos nutzt ebenso wie Strongswan den Charon Daemon denn beides werkelt unter Linux.

IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das nutzt noch die alte Variante mit den beiden Konf Dateien.

Die Strongswan Seite hat zu beiden Varianten entsprechende Konfigs. Ist aber auch hier derzeit gestört !

Moin ,

was spricht dagegen , am Backup Repo eine Red zu nehmen ? Ist glaube ich in deinem Fall das einfachste.
Da biste auch frei was Netzauswahl / IP Kreise betrifft. Einrichtung 5 Minuten Aufwand.

Servus @ukulele-7 ,
hier mal ein ganz einfaches Remote-Access Szenario (Client-2-Site) mittels IKEv1 und PSK via Strongswan (vici config via swanctl) auf eine Sophos (erfolgreich getestet!). Mit Zertifikaten kann ich nachliefern (#edit#: weiter unten ebenfalls ergänzt) , aber mach erst mal deine ersten Gehversuche hiermit

Client-2-Site IPSec IKEv1 VPN mit PSK via Strongswan(vici) auf eine Sophos

SOPHOS (Responder)

Neue IPSEC-Policy erstellen

Neues IPSec Profil erstellen

LINUX (Initiator)

VPN Konfiguration anlegen (moderne VICI Konfiguration)

Beispiel-Config

/etc/swanctl/conf.d/sophos.conf

Zu ersetzen sind das 99.99.99.99 durch die IP bzw den FQDN der SOPHOS, bei remote_ts = 192.168.100.0/24 sollte das interne Netz der Sophos angegeben werden was auch in der Sophos Config unter Local Networks angegeben wurde. Dann natürlich noch den PreSharedKey unter den Secrets anpassen.

connections {
   sophos {
      local_addrs  = %any
      remote_addrs = 99.99.99.99
      vips = 0.0.0.0

      local {
         auth = psk
      }
      remote {
         auth = psk
         id = 99.99.99.99
      }
      children {
         sophos {
            remote_ts = 192.168.100.0/24
            esp_proposals = aes256-sha256-modp2048
	    rekey_time = 1h
            start_action = start
         }
      }
      version = 1
      proposals = aes256-sha256-modp2048
      rekey_time = 8h
   }
}

secrets {
   ike-sophos {
      id = 99.99.99.99
      secret = "VerySecretKey"  
   }
}

Neuladen der Strongswan-Konfiguration durchführen

swanctl -q

Nun sollte der Tunnel bereits stehen, da durch die Konfigurationsoption start_action und dem Wert start definiert wurde das die Verbindung aktiv automatisch aufgebaut wird. Ist das nicht gewünscht kann das start durch ein trap ersetzt werden falls die Verbindung erst dann aufgebaut werden soll wenn Traffic in das Zielnetz angefordert wird. Wird die Direktive dagegen auf none festgelegt dann lässt sich die Verbindung manuell mittels

swanctl -i sophos -c sophos

aufbauen und mit

swanctl -t -i sophos

wieder trennen.

Status anzeigen lassen

swanctl -l

Sollte ähnlich diesem aussehen

Man sieht das der Client eine virtuelle IP-Adresse aus dem auf der Sophos definierten virtuellen Subnetz 10.242.4.0/24 erhält, und das Zielnetz der Sophos (hier 192.168.100.0/24) als Remote-Netz in der SA aufgeführt sind.
Das Anfordern der virtuellen IP wird in der Config durch das vips = 0.0.0.0 erreicht. Hier lässt sich auch eine feste virtuelle IP festlegen falls benötigt.

Ein Ping in das Zielnetz der Sophos sollte nun sofern die Firewall-Regeln es bereits zulassen erfolgreich sein:

Firewall

Natürlich nicht vergessen entsprechende Firewall-Regeln anzulegen die den Traffic aus dem virtuellen Subnetz in das LAN und umgekehrt erlauben.

Debugging

Sollte etwas nicht so laufen wie vorgesehen lässt sich ein detailliertes Log auf der Sophos aktivieren

Und dann das Livelog öffnen

Client-2-Site IPSec IKEv1 VPN mit Zertifikaten via Strongswan(vici) auf eine Sophos

SOPHOS (Responder)

IPSec Policy erstellen

(bleibt gleich, siehe oben)

Neues IPSec Profil erstellen

Kontrollieren ob das User-Zertifikat korrekt zugewiesen wurde

Neues Server-Zertfikat erstellen

Zuweisen des Server-Zertifikats zum IPSec Dienst

Download des Client-Zertifikates und des CA-Zertifikates

Das Client-Zertifikat als *.pkcs12 Container herunterladen und ein Passwort vergeben

Zertifizierungsstellen Zertifikat der Sophos als PEM herunterladen

LINUX (Initiator)

Importieren des Client- und CA-Zertifikates von der Sophos in die Strongswan-Config

Das Client-Zertifkat kopieren wir nun in das Verzeichnis pkcs12 Verzeichnis von Strongswan

/etc/swanctl/pkcs12/user@domain.tld.p12

Und das CA-Zertifikat dann in das x509ca Verzeichnis

/etc/swanctl/x509ca/sophos_ca.pem

Strongswan-Konfiguration

Neue Konfigurationsdatei anlegen unter: /etc/swanctl/conf.d/sophos.conf

Zu ersetzen sind das 99.99.99.99 durch die IP bzw den FQDN der SOPHOS, bei remote_ts = 192.168.100.0/24 sollte das interne Netz der Sophos angegeben werden was auch in der Sophos Config unter Local Networks angegeben wurde. Bei id = user@domain.tld muss der Common-Name (E-Mailadresse) des Client-Zertifikats angegeben werden. Abschließend natürlich noch den Dateinamen des Client-Zertifikats und dessen Container-Passwort unter den Secrets anpassen.

connections {
    sophos {
      local_addrs  = %any
      remote_addrs = 99.99.99.99
      vips = 0.0.0.0

      local {
         auth = pubkey
	 id = user@domain.tld
      }
      remote {
         auth = pubkey
         id = 99.99.99.99
      }
      children {
         sophos {
            remote_ts = 192.168.100.0/24
            esp_proposals = aes256-sha256-modp2048
            rekey_time = 1h
            start_action = start
         }
      }
      version = 1
      proposals = aes256-sha256-modp2048
      rekey_time = 8h
   }
}

secrets {
   pkcs12-linux_client {
	  file = user@domain.tld.p12
	  secret = "Passw0rd"  
   }
}

Konfigurations von Strongswan neu laden

swanctl -q

Die Hinzugefügten Zertifikate (CA- und Client-Zertfikat) sollten dort aufgeführt werden (evt. aufgetretene Fehler nicht ignorieren!)

Status anzeigen lassen

Abschließend kontrollieren ob die Verbindung erfolgreich aufgebaut wurde:

swanctl -l

So denn, nun bist du am Zug.

Viel Erfolg!
Grüße Uwe

Das sieht schon mal sehr gut aus ich werde das gleich Morgen versuchen, heute klappt warscheinlich nicht mehr.

Bisher habe ich es ohne VICI gemacht, das kenne ich gar nicht

Hier mal Teile aus meiner Doku was ich ungefähr gemacht habe:

sudo apt-get install strongswan libcharon-extra-plugins -y
sudo systemctl stop strongswan-starter

Mit WinSCP als root anmelden und die .pem-Datei in das Verzeichnis kopieren
Zielverzeichnis		/etc/ipsec.d/cacerts/

Setup VPN client authentication
sudo nano /etc/ipsec.secrets
Add the following line:
vpnsecure : EAP "password"  

Edit the strongSwan main configuration file
sudo nano /etc/ipsec.conf
Add the following lines that match your domain and password:
conn ipsec-ikev2-vpn-client
    auto=start
    right=vpn.domain.de
    rightid=vpn.domain.de
    rightsubnet=10.0.254.254/31
    rightauth=pubkey
    leftsourceip=%config
    leftid=vpnsecure
    leftauth=eap-mschapv2
    eap_identity=%identity

Start the StrongSwan VPN service using the following command:
systemctl start strongswan-starter

Verify the VPN connection status using the following command:
ipsec status

Wobei ich das aus einer Anleitung habe, da stand nicht ob ich bei %config und %identitity selbst noch etwas eintragen muss oder ob das einfach Variablen sind.

IKEv2 geht mit Sophos XG, nicht mit SG. Aber colinardo hat es ja mit IPsec der SG gemacht (was ja dann IKEv1 zu seinen scheint), das sieht gut aus das werde ich wie gesagt schnellstens testen.

PS: Ich habe sogar noch eine RED aber ich strebe eine Lösung in einer Box an, die ich dann durch einen GF oder so bei sich zuhause aufstellen lassen kann.

Zitat von @ukulele-7:
Der Datensicherungsserver baut die Verbindung zu seinem Repository auf daher wäre eine feste IP auf Seiten des VPN Interface des Linux Servers aus meiner sicht extrem sinnvoll. Bei OpenVPN lassen sich die IPs nur aus einem Pool vergeben und diese IPv4 stehen dann auch nicht in der DHCP lease table, ich kann also dem Linux Server nicht immer die selbe IP zuordnen. Da alle bisherigen Client VPN Verbindungen über OpenVPN ankommen scheint mir das keine Lösung zu sein.

Interessefrage(ohne Dich kurz vor'm Ziel vom eingeschlagenen Weg abbringen zu wollen):
Den Part oben verstehe ich nicht recht. OpenVPN arbeitet doch transparent zwischen den Netzen. Wenn Du den Rechner in diesen feste IP-Adresse vergeben hast, werden die auch genutzt. D.h. Linux-Server und Datensicherungsserver nutzen bei der Verbindung (Datenübertragung) ihre, im jeweiligen Netz vergebene (ggf. feste) IP. OpenVPN ändert daran nichts.

Viele Grüße, commodity

Chapeau ! Bilderbuchlösung von Uwe ! 👏 👍

Das zuerst zitierte Beispiel oben bezog sich auf ein IKEv2 Client Login mit EAP-MSCHAPv2 wie es ein Windows 10 VPN Client und MacOS bzw. iOS Client benutzt und auf das sich das hiesige_Client_VPN_Tutorial für die pfSense und OPNsense bezieht.
Die EAP spezifische Konfig oben wird also ausschliesslich nur damit laufen und NICHT mit einer klassischen IKEv1 Lösung wie Kollege @colinardo oben vorgestellt hat und welche ganz klar der bessere Weg ist um erfolgreich zum Ziel zu kommen !
Aber mal in die Runde gefragt ohne den Thread hier kapern zu wollen....

Ich habe das eben nochmal mit der modernen VICI Konfig mit einem Strongswan Client probiert auf einer pfSense die (getestet) fehlerlos mit Windows 10 und MacOS mit der o.a. VPN Client Tutorial Konfig rennt. Mit folgender Config (10.99.1.99 ist der WAN Port der pfSense FW):

connections {

   pfsense {
      local_addrs  = 0.0.0.0/0
      remote_addrs = 10.99.1.99

      local {
         auth = eap-mschapv2
         eap_id = user1
      }
      remote {
         auth = pubkey
         id = pfSense
      }
      children {
         pfsense {
            remote_ts = 192.168.1.0/24
            esp_proposals = aes256-sha256-modp1024,default
         }
      }
      version = 2
      proposals = aes256-sha256-modp1024,default
   }
}

secrets {

   eap-user1 {
      id = user1
      secret = test1234
   }
} 

Das exportierte CA Zertifikat das bei Windows und MacOS entsprechend ebenso importiert wurde ins Verzeichnis/etc/swanctl/pubkey kopiert.
Beim Laden der Konfig mit swanctl -q gibt es aber einen Parser Error das das von der pfSense exportierte CA .crt Zertifikat nicht geladen werden kann. 😕
root@host:/etc/swanctl/conf.d# swanctl -q
loading '/etc/swanctl/pubkey/pfsenseCA.crt' failed: parsing PUBKEY certificate failed
loaded eap secret 'eap-user1'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'pfsense'
successfully loaded 1 connections, 0 unloaded
chmod ist 755. Jemand eine Idee ??

Ansonsten rennt auch das von @colinardo oben propagierte Setup mit einer klassichen IKEv1 Konfig auch auf der OPNsense und pfSense mit der oben geschilderten Konfig fehlerlos.
Warum nur nicht mit dem IKEv2 Client VPN... 🤔

Zitat von @aqui:
Warum nur nicht mit dem IKEv2 Client VPN... 🤔

Weil manche Sophos Devices noch eine ziemlich alte Strongswan-Variante im Background einsetzen die IKEv2 nur mit einigen Bugs anbietet und in der GUI nicht nutzbar gemacht wird.

Vielleicht war das missverständlich. Mein Gegenpart ist eine latest pfSense (Ver. 2.5.2) mit der o.a. Windows 10 und MacOS kompatiblen VPN Client Konfig aus dem Tutorial und keine Sophos.
VPN Dialin mit Win10 und MacOS auf EAP Basis rennt darauf (getestet) fehlerfrei aber der Strongswan scheitert leider mit der o.a. Konfig.

Die klassische IKEv1 Konfig mit PSK ohne EAP die du oben nutzt und schilderst funktioniert aber auch mit pfSense und OPNsense fehlerlos !!
Nicht das da ein falscher Eindruck entsteht ! Es geht rein nur um die EAP Variante der onboard Clients bei Win und Mac die mit dem Schwan nicht zum Fliegen kommt...
Ist aber sicher einen separaten Thread wert und soll den Thread hier nicht kapern !

Zitat von @commodity:

Du hast nicht ganz unrecht, ich könnte OpenVPN nutzen und eventuell statt
ip-win32 dynamic
eine feste IP in der Client Config hinterlegen, müsste ich mal testen. Dann hätte der Linux Client eine feste IP und könnte vom Datensicherungsserver immer gefunden werden. Allerdings müsste die IP immernoch im IPv4 Pool liegen den ich an der Sophos nur genau einmal definieren kann. Das ist für Firewall Regeln auch nicht so schön weil sie sich dann auf eine IP und nicht ein Netz beziehen. Außerdem könnte ein anderer VPN User sich theoretisch die passige IP geben und würde dann vom Datensicherungsserver angefunkt werden, wohl kaum eine ernsthafte Gefahr aber irgendwie unglücklich.

Meine erste Frage war ja auch tatsächlich

Welchen VPN Typ sollte man anstreben für ein möglichst performantes WAN-Backup?

Ich kenne die Unterschiede gar nicht, schon gar nicht zwischen IKEv1 und IKEv2. Ich habe ein bischen dazu gelesen aber so richtig schlau bin ich noch nicht. Die Sicherheit muss natürlich irgendwie da sein aber Ich glaube Performance ist für mich sogar noch wichtiger. Für die Sicherheit kann ich das Backup auch noch auf Dateiebene verschlüsseln, das ist sowieso noch eine Überlegung wert.

Und schön das aqui das gleich auch noch testet, feel free to debug. Ich komme wie gesagt heute nicht dazu weiter zu basteln - leider

Zur Info: Habe noch die Zertifikats-Variante des Road-Warrior Szenarios der Vollständigkeit halber oben ergänzt.

ich könnte OpenVPN nutzen

Wenn du dir die VPN Durchsatzzahlen von OpenVPN zu IPsec ansiehst besser nicht !!
Schon gar nicht bei einem Sicherungsserver !

Zitat von @ukulele-7:
... ich könnte OpenVPN nutzen

nur, wenn es um vergleichsweise geringe Datenmengen angeht, wie Kollege @aqui gleich treffend angemerkt hat.

Meine Frage war allein auf das Verständnis Deines Problems gerichtet und da komme ich immer noch nicht ganz mit. M.E. baust Du einen Tunnel und dann sicherst Du da durch. Welche IP die mit dem Tunnel arbeitenden Rechner bekommen und auf welche Weise dies geschieht, ist da doch gleichgültig. Du musst da imo auch nichts in der Client-Config hinterlegen. Tunnel und die Rechner, die ihn nutzen, sind zwei völlig unterschiedliche Paar Schuhe.
Vielleicht liegt es an der Implementierung in der Sophos, glaub ich aber eher nicht. Das weiß ich nicht, so proprietäres Zeug nutze ich nicht, wenn es (wie es bei Firewalls definitiv der Fall ist) sehr gute Alternativen gibt.

Geh' ansonsten weiter den von den Kollegen @colinardo und @aqui bereiteten Weg. Wertiger als mit deren Rat kann man so etwas kaum angehen.

Viele Grüße, commodity

Ich habe da nix als "gering" angemerkt.

Nicht das das falsch rüberkommt. Nur das der Datendurchsatz in einem OpenVPN Tunnel vergleichsweise erheblich schlechter ist als in einem IPsec Tunnel. OVPN supportet kein Multithreading !
Bei einem Datensicherungsserver sicher ein relevanter Punkt. Mit der IP Adressierung oben hast du aber natürlich Recht.

Die Grafik ist auf jedenfall gut genau die Aussage die ich gesucht habe. Ich muss jetzt nicht auf Teufel komm raus Performance hoch schrauben aber das ist eindeutig.

Zitat von @aqui:
Ich habe da nix als "gering" angemerkt.

Nö, nur auf das Durchsatzverhältnis hingewiesen. Kann ja jeder sehen.
Meine Übersetzung dieser Anmerkung in Bezug auf den TO (der ja explizit nach OpenVPN gefragt hatte) war:

Schlechterer Durchsatz = "nur" bei geringeren Datenmengen noch ok
Besserer Durchsatz = bei höherer Datenmenge jedenfalls sinnvoll.

Was habe ich jetzt falsch verstanden?

Viele Grüße, commodity

Aaahhsooo...ja das hast du Recht. Wenn er nicht mehr als 200 Mbit über den Tunnel schickt bzw. die VPN Anbindung gar nicht mehr kann, dann geht auch OpenVPN.

Danke für die Klarstellung

Ergänzungsfrage: Braucht er denn für den ausschließlichen Zweck Datensicherung überhaupt ein VPN?
Würde es nicht genügen, wenn er sein Ubuntu beim Datensicherungsserver per SSHFS (natürlich mit Public Key) mountet und dann dort das Verzeichnis sichert (oder anders herum)?

Viele Grüße, commodity

Also mir fehlen da die Erfahrungswerte, ein Grund warum ich lieber VPN machen würde. Die Kommunikation erfolgt tatsächlich nur zwischen Veeam Diensten, es handelt sich um ein Veeam immutable Backup, siehe:
https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.htm ...

Mein Testfall läuft einwandfrei, ist aber eine VM im gleichen Netz erreichbar. Auch wenn ich keinen allumfassenden Zugriff aus der Ferne auf die Kiste brauche möchte ich das doch eher in der Firewall konfigurierbar halten.

PS: Bin leider noch nicht zum Testen gekommen, die Hardware der Box hat leider noch eine Macke.

Bin leider noch nicht zum Testen gekommen,

Wir bleiben aber gespannt... 😉

Zitat von @ukulele-7:
Also mir fehlen da die Erfahrungswerte, ein Grund warum ich lieber VPN machen würde.

Ja, verstehe ich. Die Frage war auch mehr allgemein in die Runde, ob was gegen SSHFS sprechen würde (ich fürchte, es ist die Performance). Wahrscheinlich kann man auch den Veeam-Zugriff über SSH tunneln, aber wie oben schon gesagt, bleib auf dem eingeschlagenen Weg und berichte

Viele Grüße, commodity

Also ich bin heute der Anleitung mit VICI von @colinardo gefolgt.

Zunächst habe ich die Config meines bisherigen Versuchs raus geschmissen. Dann hatte ich Probleme mit dem Preshared Key und hatte einen falschen remote_ts Eintag, beides jetzt gelöst. Allerdings hatte ich in dem Zug auf /30er Netz für die VPN Verbindung umgestellt, ich wollte ja erst ein /31er testen was ansich gehen müsste. Also derzeit ist in der Sophos 10.0.254.252/30 als VPN Pool IPsec eingerichtet. Wenn ich mich jetzt einwähle (local_adr 0.0.0.0) bekommt der Client die 10.0.254.253/30 für sein VPN Interface, also die erste Host-Adresse im Netz. Müsste nicht die Sophos auch eine Host-Adresse in dem Netz belegen? Bei OpenVPN hat die Sophos definitiv eine eigene IP im VPN Pool, wie sollte das auch anders gehen?

PS: Ping und sowas geht alles durch gem. Firewall-Regeln also VPN scheint zu laufen nur das ich keine IP der Sophos im VPN Netz zu haben scheine das verwirrt mich.

Zitat von @ukulele-7:
Wenn ich mich jetzt einwähle (local_adr 0.0.0.0) bekommt der Client die 10.0.254.253/30 für sein VPN Interface, also die erste Host-Adresse im Netz. Müsste nicht die Sophos auch eine Host-Adresse in dem Netz belegen?
Bei OpenVPN hat die Sophos definitiv eine eigene IP im VPN Pool, wie sollte das auch anders gehen?

Nein, OpenVPN arbeitet hier anders als IPSec. Bei IPSec wird werden dem Client in der Phase 2 per SA-Policy die Remote-Netze mitgeteilt und der Client routet nur anhand dieser Policies Traffic in das Remote-Netz, nicht über eine explizite Gateway-IP, diese ist hier also überflüssig. Die eingerichteten Policies am Client siehst du ja mit swanctl -l.
Die virtuelle IP benutzt die Sophos zur Zuordnung des Traffics zum Client um diesen wieder auch wieder korrekt zurück an den Client zu routen.

PS: Ping und sowas geht alles durch gem. Firewall-Regeln also VPN scheint zu laufen nur das ich keine IP der Sophos im VPN Netz zu haben scheine das verwirrt mich.

Keine Angst das ist bei IPSec völlig normal

Man lernt nie aus

Auf jedenfall schonmal vielen Dank das war sehr detailiert und hilfreich.

In Betrieb geht das leider noch nicht, ich muss erst noch den Datensicherungsserver etwas umbauen, vorher macht das keinen Sinn aber dann bin ich sehr gespannt auf mein zukünftiges immutable Backup over WAN auf eigenbau Hardware.