Sophos XG – SSL VPN – keine Einstellungen möglich
Kann man an den Default SSL VPN Einstellungen keine Änderungen, wie z.B. Protokoll oder IP Range vornehmen, erstelle man die Defalt CA und das Appliance Zertifikat neu.
Kann man an den Default SSL VPN Einstellungen keine Änderungen, wie z.B. Protokoll oder IP Range vornehmen, erstelle man die Defalt CA und das Appliance Zertifikat neu.
Einrichtung einer IPSec VPN Verbindung zwischen Sophos XG(S) mit SFOS 18 und einer Fritz! Box über den Fully-Qualified Domain Name (FQDN), auch für Hosts ohne statischer IP Adresse via einem DynDNS Dienst:
Sophos XG IPSec Richtlinie
Allgemeine Einstellungen
Name: FritzBox
Schlüsselaustausch: IKEv1
Authentifizierungsmethode: Hauptmodus
Schlüsselaushandlungsversuche: 0
Schlüsselerneuerungsverbindung: An
Daten in komprimierten Format übergeben: Aus
SHA-2 mit 96-Bit-Verkürzung: Aus
Phase 1
Schlüssel-Lebensdauer: 3600
Zeit bis zur Schlüsselerneuerung: 360
Zeit variieren um: 50
DH-Gruppe (Schlüsselgruppe): 14 [DH2048]
Verschlüsselung: AES2556
Authentifizierung: SHA2 512
Phase 2
PFS-Gruppe (DH-Gruppe): Gleich wie Phase 1
Schlüssel-Lebensdauer: 3600
Verschlüsselung: AES2556
Authentifizierung: SHA2 512
Dead Peer Detection (DPD)
Dead Peer Detection (DPD): An
Peer überprüfen alle: 30
Auf Antwort warten bis zu: 120
Wenn Peer unerreichbar: Neu initiieren
Sophos XG IPSec Verbindung
Allgemeine Einstellungen:
Name: BlaBla
IP-Version: IPv4
Verbindungstyp: Standort zu Standort
Gateway-Typ: Verbindung herstellen
Beim Speichern aktivieren: An
Firewallregel anlegen: An
Verschlüsselung
Richtlinie: FritzBox
Authentifizierung-Typ: Verteilter Schlüssel
Schlüssel: IPSEC-PASSWORT
Gateway-Einstellungen
Lausch-Schnittstelle: PortX-ExterneIP
Lokaler ID-Typ: DNS
Lokale ID: FQDN-SophosXG
Lokales Subnetz: IP-Range-SophosXG
Gateway-Adresse: FQDN-FritzBox
Entfernter ID-Typ: DNS
Entfernte ID: FQDN-FritzBox
Entferntes Subnetz: IP-Range-FritzBox
Network Address Translation (NAT): Aus
Erweitert
Benutzerauthentifizierungsmodus: Aus
FritzBox IPSec Richtlinie
vpncfg { connections { enabled = yes; conn_type = conntype_lan; name = "Fritz to Sophos"; always_renew = yes; reject_not_encrypted = no; dont_filter_netbios = yes; localip = 0.0.0.0; local_virtualip = 0.0.0.0; remoteip = 0.0.0.0; remote_virtualip = 0.0.0.0; remotehostname = "FQDN-SophosXG"; localid { fqdn = FQDN-FritzBox; } remoteid { fqdn = FQDN-SophosXG; } mode = phase1_mode_idp; phase1ss = "dh14/aes/sha"; keytype = connkeytype_pre_shared; key = "IPSEC-PASSWORT"; cert_do_server_auth = no; use_nat_t = no; use_xauth = no; use_cfgmode = no; phase2localid { ipnet { ipaddr = IP-RANGE-FRITZ-LAN; mask = NETZWERKMASKE-FRITZ-LAN; } } phase2remoteid { ipnet { ipaddr = IP-RANGE-SOPHOS-LAN; mask = NETZWERKMASKE-SOPHOS-LAN; } } phase2ss = "esp-all-all/ah-none/comp-all/pfs"; accesslist = "permit ip any IP-RANGE-SOPHOS-LAN NETZWERKMASKE-SOPHOS-LAN"; } ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", "udp 0.0.0.0:4500 0.0.0.0:4500"; }
Bekommt man beim Erneuern bzw. Aktivieren der let’s encrypt Zertifikate folgenden Fehler:
Die aktuelle Version der Let’s Encrypt Nutzungsbedingungen konnte nicht bezogen werden. Ein erneuter automatischer Versuch wird beim nächsten Erneuerungsversuch unternommen. Ein manueller Erneuerungsversuch kann jederzeit vorgenommen werden
Zuerst lösche man in der Zertifikatsverwaltung am Webinterface die alten let’s encrypt CAs und starte manuell die Erneuerung des betroffenen Zertifikats.
Achtung: let’s encrypt hat eine fair use policy und blockiert bei zu häufigen Abfragen in kurzer Zeit temporär die Ereuerungsversuche, daher kann man auch mal nen Tag vor dem nächsten Versuch warten, bzw. ereuert sich das Zertifikat eh selber sobald die CA gelöscht wurde.
Hilft das nichts melde man sich auf der SSH Shell an und:
chmod 0755 /etc/ssl/certs
Verbindet man sich von einer Sophos XGS zu einem älteren Gateway mit IPsec IKEv1 und der Tunnel erscheint als aktiv, nur geht kein Verkehr über die Verbindung in das entfernte Netz schalte man in dem jeweiligen VPN Profil auf der XGS die Option SHA2 with 96-bit truncation an.
Schmeisst die File Station einen Fehler wie „es steht kein gemeinsam genutzter Ordner zur Verfügung“ obwohl das Volume vorhanden und in Ordnung ist, überprüfe man in der Benutzerverwaltung einfach erst mal, ob der Benutzer auch Rechte auf diesen Ordner hat.
Landen aus unerfindlichen Gründen Mails z.B. an grössere Verteiler oder mit dicken Anhängen in der Error Queue, mit einem „Scanner Timeout“ als Fehler, überprüfe oder deaktivere man einfach einmal die E-Mail-Verschlüsselung. Besonderes Augenmerk auch auf einen möglicherweise vorhandenen PGP Keyserver (raus damit).