Eine Site-to-Site-Verbindung verbindet zwei Netzwerke miteinander.
Beispielsweise das lokale Netzwerk einer Hauptstelle mit dem lokalen Netzwerk einer Filiale / Zweigstelle.
Für das Verbinden der beiden Gegenstellen lassen sich öffentliche IP-Adressen, sowie dynamische DNS Einträge, verwenden.
Konfiguration einer IPSec Site-to-Site Verbindung
Nach dem Login auf das Administrations-Interface der Firewall (im Auslieferungszustand: https://192.168.175.1:11115) kann im Menü → VPN →IPSec Schaltfläche IPSec Verbindung hinzufügen eine IPSec Verbindung hinzugefügt werden.
Einrichtungsassistent
Schritt 1 - Verbindungstyp
Beschriftung
Wert
Beschreibung
Einrichtungsschritt 1
Site to Site
Es stehen folgende Verbindungen zur Verfügung.
Roadwarrior
Site to Site
Für die Konfiguration einer Site to Site Verbindung wird eben diese ausgewählt.
Schritt 2 - Allgemein
Name:
IPSec S2S
Name für die Verbindung
Einrichtungsschritt 2
Authentifizierungsmethode:
PSK
Außerdem möglich: X.509 Zertifikat RSA
Bei Authentifizierungsmethode PSK Pre-Shared Key:
12345
Ein beliebiger PSK. Mit der Schaltfläche wird ein sehr starker Schlüssel erzeugt.
Bei Authentifizierungsmethode X.509 Zertifikat X.509 Zertifikat:
Server-Zertifikat
Auswahl eines Zertifikates
IKE Version:
IKE v1IKE v2
Auswahl der IKE Version Neu ab v12.2
Bei Verwendung von IKE v2 ist es möglich, mehrere Subnetze unter einer SA zusammenzufassen (default für neu angelegte Verbindungen).
Ohne diese Option wird für jede Subnetzkombination eine eigene SA ausgehandelt. Dies hat besonders bei vielen SAs deutliche Nachteile und führt durch das Design des IPSec-Protokolls zu Limitierungen und zu Einbußen in der Stabilität der Verbindungen. Aktiviert wird diese Option bei der Bearbeitung der Konfiguration der Phase 2 mit dem Eintrag Subnetzkombinationen gruppieren.
Bei Authentifizierungsmethode RSA Hier steht nur IKE v1 zu Verfügung.
Schritt 3 - Lokal
Local Gateway ID:
LAN1
Beliebige Zeichenfolge Die Gateway ID fließt in die Authentifizierung mit ein. Dies kann eine IP-Adresse, ein Hostname oder eine Schnittstelle sein. Auf der Gegenstelle muss dieser Wert exakt genau so konfiguriert werden.
Sollte als Gayteway-ID eine E-Mail-Adresse verwendet werden, ist es erforderlich vor die ID ein doppeltes @@ einzfügen (Aus mail@… wird @@mail@…). Andernfalls wird die ID als FQDN behandelt
Einrichtungsschritt 3
Bei Authentifizierungsmethode RSA Privater RSA-Schlüssel:
RSA-Site2Site
Privater RSA-Schlüssel zur Identifizierung
Netzwerke freigeben:
»192.168.122.0/24
Das lokale Netzwerk der Gegenstelle, auf das zugegriffen werden soll
Schritt 4 - Gegenstelle
Remote Gateway:
192.0.2.192
Öffentliche IP-Adresse (oder Hostname, der per DNS aufgelöst werden kann) der Gegenstelle
Einrichtungsschritt 4
Remote Gateway ID:
192.0.2.192
ID, die auf der Gegenstelle als lokale ID konfiguriert wurde (beliebige Zeichenfolge)
Bei Authentifizierungsmethode RSA Öffentlicher RSA-Schlüssel:
RSA-Site2Site
RSA-Schlüssel, der öffentliche Teil mit dem sich die Gegenstelle authentifizieren muss.
Netzwerke freigeben:
»192.168.192.0/24
Das lokale Netzwerk der Gegenstelle, auf das zugegriffen werden soll
Beenden des Einrichtungsassistenten mit Fertig
Phase 2 bearbeiten
Neu ab v12.2 Mehrere Subnetze per MULTI_TRAFFIC_SELECTOR zusammen fassen.
Subnetzkombinationen gruppieren: Ein
Sind auf lokaler Seite oder auf der Gegenstelle mehr als ein Netz konfiguriert, wird bei Deaktivierung für jede Subnetzkombination eine eigene SA ausgehandelt. Dies hat besonders bei mehreren Subnetzen viele Subnetzkombinationen und damit viele SAs zur Folge und führt durch das Design des IPSec-Protokolls zu Limitierungen und zu Einbußen in der Stabilität der Verbindungen.
Alle Subnetze haben untereinander Zugriff
Durch den Assistenten wird automatisch jedes lokale Netz mit jedem remote Netz verbunden.
Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen.
Subnetzkombinationen gruppieren Aktiviert Ein
root@firewall:~# swanctl --list-conns
IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s
local: %any
remote: 192.0.2.192
local pre-shared key authentication:
id: 192.168.175.218
remote pre-shared key authentication:
id: 192.0.2.192
IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.218.0/24 192.168.219.0/24
remote: 192.168.192.0/24 192.168.193.0/24
Subnetzkombinationen gruppieren Deaktiviert Aus root@firewall:~# swanctl --list-conns
IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s
local: %any
remote: 192.0.2.192
local pre-shared key authentication:
id: 192.168.175.218
remote pre-shared key authentication:
id: 192.0.2.192
IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.218.0/24
remote: 192.168.192.0/24
IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.218.0/24
remote: 192.168.193.0/24
IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.219.0/24
remote: 192.168.192.0/24
IPSec$20S2S_7: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.219.0/24
remote: 192.168.193.0/24
Alle Subnetze haben untereinander Zugriff
Nicht alle Subnetze dürfen auf jedes Netz der Gegenstelle zugreifen
Wird in Phase zwei ein lokales Netzwerk nicht mit allen remote Netzwerken (oder ein remote Netzwerk nicht mit allen lokalen) verbunden, wird das bei aktiver Option Subnetkombiantionen gruppieren nicht berücksichtigt! Durch diese Option werden alle lokalen Netzwerke mit allen remote Netzwerken verbunden!
Portfilterregeln ermöglichen es, den Zugriff zu steuern.
Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen.
Subnetzkombinationen gruppieren Aktiviert Einroot@firewall:~# swanctl --list-conns
IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s
Subnetzkombinationen gruppieren Deaktiviert Aus root@firewall:~# swanctl --list-conns
IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s
local: %any
remote: 192.0.2.192
local pre-shared key authentication:
id: 192.168.175.218
remote pre-shared key authentication:
id: 192.0.2.192
IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.218.0/24
remote: 192.168.192.0/24
IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.218.0/24
remote: 192.168.193.0/24
IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart
local: 192.168.219.0/24
remote: 192.168.192.0/24
Das zweite lokale Subnetz wird nur mit einem remote Subnetz verbunden
Regelwerk
Um den Zugriff, auf das Interne Netz zu gewähren muss die Verbindung erlaubt werden.
Es ist möglich, aber nicht empfehlenswert dies mit impliziten Regeln unter → Firewall →Implizite Regeln Abschnitt VPN zu konfigurieren. Diese Impliziten Regeln geben die Ports, die für IPSec Verbindungen genutzt werden, jedoch auf allen Schnittstellen frei.
Implizite Regeln
Grundsätzlich gilt: Es wird nur das freigegeben, was benötigt wird und nur für denjenigen, der es benötigt!
Netzwerkobjekt anlegen
Es muss ein Netzwerkobjekt für das entfernte Netz erstellt werden. → Firewall →PortfilterReiter Netzwerkobjekte Schaltfläche Objekt hinzufügen
Existieren mehrere Subnetze auf der Gegenstelle, muss für jedes Subnetz ein Netzwerkobjekt angelegt werden. Wenn die entsprechenden Berechtigungen vergeben werden sollen, lassen sich diese zu Netzwerkgruppen zusammenfassen.
Name:
IPSec-S2S
Name für das IPSec-S2S-Netzwerkobjekt
Netzwerkobjekt
Typ:
VPN-Netzwerk
zu wählender Typ
Adresse:
192.168.192.0/24
Die IP-Adresse des lokalen Netzwerks der gegenüberliegenden Seite, wie im Installationsassistenten in Schritt 4 - Gegenstelle in der Zeile Netzwerke freigeben eingetragen wurde. In diesem Beispiel also das Netzwerk 192.168.192.0/24.
Zone:
vpn-ipsec
zu wählende Zone
Gruppe:
Optional: Eine oder mehrere Gruppen, zu denen das Netzwerkobjekt gehört.
Portfilter Regeln
Es müssen zwei Portfilter Regeln erstellt werden. Menü → Firewall →PortfilterReiter Portfilter Schaltfläche Regel hinzufügen
Existieren unterschiedliche Zugriffsrechte von/auf lokale und remote Netzwerke müssen mehrere Portfilterregeln angelegt werden.
Portfilter-Regel
Erste Regel
Quelle
internal-network
Host oder Netzwerk (-Pool), der Zugriff auf das interne Netz bekommen soll
Ziel
IPSc-Netzwerk
Ziel
Dienst
benötigter Dienst
Dienst oder Dienstgruppe, die benötigt wird
NAT
Typ
Hidenat Exclude
Netzwerkobjekt
external-interface
Zweite Regel
Quelle
IPSc-Netzwerk
Host oder Netzwerk (-Pool), der Zugriff auf das interne Netz bekommen soll
Ziel
internal-network
Ziel
Dienst
benötigter Dienst
Dienst oder Dienstgruppe, die benötigt wird
NAT
Kein NAT
Konfiguration des zweiten Gateways
Es ist zu beachten, dass die IKE-Version auf beiden Seiten identisch ist.
Verwendung einer Securepoint UTM
Auf der entfernten Appliance müssen die Einstellungen analog vorgenommen werden
Mit Hilfe des IPSec-Assistenten wird eine neue IPSec-VPN-Verbindung angelegt
Ein Netzwerkobjekt für das IPSec-Netzwerk wird erstellt
Portfilterregeln werden erstellt.
Gegenstelle Schritt 2
Es muss die gleiche Authentifizierungsmethode gewählt werden
Es muss der gleiche Authentifizierungs-Schlüssel (PSK, Zertifikat, RSA-Schlüssel) vorliegen
Es muss die gleiche IKE-Version verwendet werden
Gegenstelle Schritt 3
Als Local Gateway ID muss nun die Remote Gateway ID aus Schritt 4 der ersten UTM verwendet werden
Unter Netzwerke freigeben muss ebenfalls das (dort Remote-) Netzwerk aus Schritt 4 der ersten UTM verwendet werden
Gegenstelle Schritt 4
Als Remote Gateway muss die öffentliche IP-Adresse (oder ein Hostname, der per DNS aufgelöst werden kann) der ersten UTM eingetragen werden. (Diese Adresse wurde im Assistenten der ersten UTM nicht benötigt)
Als Remote Gateway ID muss die Local Gateway ID aus Schritt 3 der ersten UTM verwendet werden
Unter Netzwerke freigeben muss ebenfalls das (dort lokale) Netzwerk aus Schritt 3 der ersten UTM verwendet werden
Netzwerkobjekt der Gegenstelle anlegen
Das Netzwerkobjekt der Gegenstelle stellt das Netzwerk der ersten UTM dar. Entsprechend muss unter Adresse' die Netzwerkadresse des lokalen Netzes der ersten UTM eingetragen werden. Im Beispiel 192.168.218.0/24
Hinweise
Transparente Regel
Der transparente HTTP-Proxy
Wenn aus dem Internen Netzwerk via HTTP auf einen Server hinter der Site-to-Site Verbindung zugegriffen werden soll, kann es sein das der transparente HTTP-Proxy die Pakete filtert. Dies kann zu Fehlern bei den Zugriffen auf das Ziel führen. Damit das nicht passiert, muss im Menü → Anwendungen →HTTP-ProyReiter Transparenter Modus Schaltfläche Transparente Regel hinzufügen eine Regel Exclude mit der Quelle internal-network' zum Ziel name-vpn-netzwerk-objekt' und dem Protokoll HTTP erstellt werden.