Wechseln zu:Navigation, Suche
Wiki






























De.png
En.png
Fr.png






IPSec Verbindungen Site-to-Site
Letzte Anpassung: 12.2
Neu:
notempty
Dieser Artikel bezieht sich auf eine Resellerpreview

11.7 11.6.12


Einleitung

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 UTM v12.6 IPSec S2S Schritt1.png
Site to Site Für die Konfiguration einer
Site to Site
Verbindung wird eben diese ausgewählt.

Schritt 2 - Allgemein
|| IPSec S2S || Name für die Verbindung || class="bild width-m" rowspan="5" | UTM v12.6.1 IPSec S2S Schritt2 .png
Authentifizierungsmethode: PSK Ein Pre-Shared Key wird verwendet
PSK
|| 12345 || Ein beliebiger PSK
X.509 Zertifikat
X.509 Zertifikat:
Auswahl eines Zertifikates
IKE v1IKE v2 Auswahl der IKE Version.
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.
  

RSA
Hier steht nur IKE v1 zu Verfügung.



Schritt 3 - Lokal
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 Gateway-ID eine E-Mail-Adresse verwendet werden, ist es erforderlich vor die ID ein doppeltes @@ einzufügen (Aus mail@… wird @@mail@…). Andernfalls wird die ID als FQDN behandelt
  • Wird bei Authentifizierungsmethode Zertifikat nach Zertifikatsauswahl automatisch ausgefüllt.
  • UTM v12.6 IPSec S2S Schritt3.png
    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
    || 192.0.2.192 || Öffentliche IP-Adresse (oder Hostname, der per DNS aufgelöst werden kann) der Gegenstelle || class="bild width-m" rowspan="4" | UTM v12.6 IPSec S2S Schritt4.png
    || 192.0.2.192 || ID, die auf der Gegenstelle als lokale ID konfiguriert wurde (beliebige Zeichenfolge)
    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

    Bei S2S-Verbindungen sollte geprüft werden, ob sich mehrere Subnetze per MULTI_TRAFFIC_SELECTOR zusammen fassen lassen. Damit wird die Anzahl der SAs signifikant reduziert und die Stabilität der Verbindung erhöht.
    Dazu wird in Phase 2 die Option Subnetzkombinationen gruppieren aktiviert.


    Ein
    [[Datei: ]]
    '


  • 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
    



    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
    

    [[Datei: ]]
    '


    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
    



    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
    

    [[Datei: ]]

    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.

    UTM v12.6 Implizite-Regeln IPSec.png
    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 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.
  • || IPSec-S2S || || class="bild width-m" rowspan="5" | UTM v12.6 Netzwerkobjekt IPSec.png
    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.
    || vpn-ipsec || zu wählende Zone
    Gruppe:     Optional: Eine oder mehrere Gruppen, zu denen das Netzwerkobjekt gehört.


  • [[Datei: ]]
    Erste Regel
    Quelle
    internal-network Host oder Netzwerk (-Pool), der Zugriff auf das interne Netz bekommen soll
    Ziel
        Ziel
    Dienst
        Dienst oder Dienstgruppe, die benötigt wird
    NAT

    Typ
    Hidenat Exclude
    external-interface

    Zweite Regel
    Quelle
        Host oder Netzwerk (-Pool), der Zugriff auf das interne Netz bekommen soll
    Ziel
    internal-network Ziel
    Dienst
        Dienst oder Dienstgruppe, die benötigt wird
    NAT
    Kein NAT



    Konfiguration des zweiten Gateways


    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
    • Paketfilterregeln 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-Proxy  Bereich 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.