Konfiguration einer IPSEC-VPN-Verbindung zwischen einer Sophos UTM und einer Sonicwall TZ100

Ich stand heute vor der Aufgabe, eine Sonicwall TZ100 an eine Sophos UTM (ehemals Astaro) anzubinden, um ein Site-to-Site-VPN aufzubauen. Da die Konfiguration ein paar Anpassungen benötigte beschreibe ich in diesem Beitrag den Aufbau und die Konfiguration.

Die UTM steht als zentraler Router an Standort A und ist über mehrere Anbindungen an das Internet angebunden. Die VPN-Strecke soll nicht über die primäre Internetanbindung erfolgen, sondern über eine parallel vorhandene Unitymedia-Leitung. Die Sonicwall TZ100 steht an Standort B und ist hier mit einer festen IP-Adresse angebunden. An Standort B gibt es nur eine Internetleitung, über diese läuft zusätzlich zu dem “normalen” Traffic noch der VPN-Traffic.

Zuerst habe ich an Standort B die TZ100 konfiguriert. Unter VPN im Hauptmenü kann eine neue Verbindung eingerichtet werden.

image

Unter Generel müssen die gezeigten Informationen eingestellt werden. IPsec Primary Gateway Name or Address muss auf die IP-Adresse konfiguriert werden, die das UTM-Gerät an Standort A hat. Shared Secret muss auf beiden Geräten gleich sein, was Sie hier eintragen ist völlig egal. Je kryptischer der Schlüssel desto besser.

Local IKE ID und Peer IKE ID habe ich in meinem Fall auf IPv4 Address gestellt. Als Wert wurden die jeweiligen IP-Adressen der Geräte eingetragen.

image

Unter Network muss konfiguriert werden, um welches lokale und um welches Remote-Netzwerk es sich bei dieser Verbindung handelt. In meinem Fall waren dies jeweils die LAN-Bereiche von Standort A und Standort B (z.B. 192.168.100.0/24 und 192.168.101.0/24).

image

Unter Proposals habe ich die Standartwerte gelassen.

image

Im Reiter Advanced habe ich nur die Einstellung Enable Keep Alive aktiviert.

An Standort A in der Konfiguration der Sophos UTM habe ich im Menü unter Site-to-site VPN => IPsec als erstes unter Policies eine neue Policy erstellt. Hierzu habe ich die vorhandene Policy TripleDES geclont und angepasst. Das Ergebnis sieht wie folgt aus:

image

Danach habe ich unter Remote Gateways ein neues VPN-Gateway definiert:

image

Unter Gateway muss die WAN-IP-Adresse der TZ100 konfiguriert werden. Der Preshared Key muss der gleiche wie in der TZ100 sein, damit eine Verbindung erfolgreich aufgebaut werden kann. VPN ID Type ist IP Address, die VPN ID ist die IP-Adresse der TZ100 an Standort B (WAN-IP-Adresse). Remote Networks definiert den LAN-Bereich an Standort B. Unter Advanced habe ich keine weiteren Einstellungen aktiviert oder geändert.

Nun kann unter Connections die eigentliche Verbindung eingerichtet werden:

image

Name ist hier angepasst an den Namen in der Sonicwall, wobei ich nicht weiß ob dies Bedingung ist. Remote Gateway ist die im Vorfeld konfigurierte TZ100, unter Local Interface kann das Interface konfiguriert werden, über das die VPN-Verbindung aufgebaut werden soll. Dies ist sehr nützlich, da ich hier die Unitymedia-Anbindung nutzen kann. Unter Policy kann nun die geclone Richtlinie genutzt werden. Local Networks definiert den internen LAN-Bereich, der über diese VPN-Verbindung genutzt werden kann. Mit einem Haken bei Automatic Firewall Rules werden automatisch die benötigten Firewall-Regeln angelegt.

Nun können die Einstellungen übernommen werden, und wenn alles wie gewünscht funktioniert dann wird die Verbindung direkt aufgebaut. Sowohl in der Sonicwall als auch in der Sophos wird dies angezeigt:

image

image

Teilen:

Jan Kappen

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Im April 2015 wurde Jan Kappen im Bereich "File System Storage" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

2 Kommentare:

  1. Hallo Herr Kappen,

    sofern möglich sollte man auf 3DES und DH2 verzichten.
    AES ist schneller und die 1024bit von DH2 werden nach den letzten Monaten nicht mehr als alzu sicher angesehen. DH5 oder DH14 ist also besser geeignet.
    Solange es keine Probleme gibt, sollte man also lieber eine höhere Sicherheit aktivieren.

    Klar kann man behaupten, das wäre paronoid aber wenn es um Unternehmssicherheit geht, sollte man doch auf die beste Verfügbare Variante zurückgreifen, da mehr Sicherheit meistens mit nur einem Häcken zu realisieren ist und außer ein paar CPU Zyklen nichts kostet.

  2. Sehr hilfreicher Beitrag! Danke
    LG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert