Wechseln zu:Navigation, Suche
Wiki





























De.png
En.png
Fr.png

Phase 1

→ VPN →IPSecReiter Verbindungen Schaltfläche Phase 1
Allgemein

Reiter Allgemein

Beschriftung Wert Beschreibung UTM v12.6.2 VPN Ipsec RW IKEv2 Phase 1 Allgemein.png
Phase 1 Allgemein
Beliebige Remote-Adressen erlauben Ein
Default
Diese Option deaktivieren für Site to Site-Verbindungen mit DynDNS-Hosts, wenn mehrere IPsec-Verbindungen mit a priori unbekannten Adressen (DynDNS S2S, Roadwarrior) konfiguriert sind.
Startverhalten Outgoing Der Tunnel wird von der UTM initiiert, auch wenn keine Pakete gesendet werden.
Eingehende Anfragen werden entgegen genommen.
Incoming Die UTM nimmt eingehende Tunnelanfragen entgegen.
Ausgehend wird keine Verbindung erstellt.
Route Der Tunnel wird von der UTM nur dann initiiert, wenn Pakete gesendet werden sollen.
Ignore Deaktiviert den Tunnel
Ein Überprüft in einem festgelegtem Intervall, ob der Tunnel noch besteht.
Wurde der Tunnel unerwartet beendet, werden die SAs abgebaut.
(Nur dann ist es auch möglich einen neuen Tunnel wieder herzustellen.)
  • Bei Deaktivierung wird automatisch auch die Option Neustart nach Abbruch in Phase 2 deaktiviert.

  • 1
    Neu ab 12.2.3
    30Link= Sekunden Zeitraum, bevor der Zustand unter Startverhalten wieder hergestellt wird
  • Unter IKEv2 steht dieser Parameter nicht zur Verfügung.
    Hier werden die gleichen Werte verwendet, wie für normale Pakete.
  • DPD Intervall
    Neu ab 12.2.3
    10Link= Sekunden Intervall der Überprüfung
    Aus Kompression wird nicht von allen Gegenstellen unterstützt
    Reiter Einstellungen, die in der UTM und im Client identisch sein müssen:
    Beschriftung Default-Werte UTM Default-Werte NCP-Client [[Datei: ]]
    Phase 1 IKEv
    Verschlüsselung: aes128 AES 128 Bit
    Authentifizierung: sha2_256 Hash: SHA2 256 Bit
    Diffie-Hellman Group: modp2048 IKE DH-Grupe: DH2 (modp1024)
    Reiter Weitere Einstellungen:
    Beschriftung Wert Beschreibung
    Strict: Aus Die konfigurierten Parameter (Authentisierungs- und Verschlüsselungsalgorithmen) werden bevorzugt für Verbindungen verwendet
    Ein Es werden keine weiteren Proposals akzeptiert. Eine Verbindung ist nur mit den konfigurierten Parametern möglich.
    IKE Lifetime: 1 Stunde Gültigkeitsdauer der Security Association: Vereinbarung zwischen zwei kommunizierenden Einheiten in Rechnernetzen. Sie beschreibt, wie die beiden Parteien Sicherheitsdienste anwenden, um sicher miteinander kommunizieren zu können. Beim Einsatz mehrerer Dienste müssen auch mehrere Sicherheitsverbindungen aufgebaut werden. (Quelle: Wikipedia 2022) in Phase 1
    unbegrenzt (empfohlen) Anzahl der Versuche, um die Verbindung herzustellen (initial oder nach Abbruch)
    Bei E2S-Verbindungen (Roadwarrior) kann die Einstellung 3 mal vermeiden, daß endlos versucht wird eine Verbindung zu nicht korrekt abgemeldeten Geräten herzustellen

    Phase 2

    → VPN →IPSecReiter Verbindungen Schaltfläche Phase 2
    Allgemein

    Reiter Allgemein : Einstellungen, die in der UTM und im Client identisch sein müssen:

    Beschriftung Default-Werte UTM Default-Werte NCP-Client [[Datei: ]]
    Phase 2 / Abschnitt Allgemein mit
    Verschlüsselung: aes128 AES 128 Bit
    Authentifizierung: sha2_256 SHA2 256 Bit
    DH-Gruppe (PFS): modp2048 keine
    Schlüssel-Lebensdauer 8 Stunden Schlüssel Lebensdauer in Phase 2
    Austausch-Modus Main Mode (nicht konfigurierbar) Aggressive Mode (IKEv1)
  • Muss im NCP-Client auf Main Mode geändert werden!
    Die UTM unterstützt aus Sicherheitsgründen keinen Aggressive Mode.
  • Reiter Allgemein: Weitere Einstellungen

    Beschriftung Wert Beschreibung
    Nein
  • Subnetzkombinationen gruppieren:
    2
    Ja

  • Wird das Gruppieren von der Gegenstelle nicht unterstützt, wird trotz gegenteiliger Statusanzeige in der Übersicht nur das erste Subnetz verbunden.
  • 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.
    Subnetze

    Reiter Subnetze 2
    Szenario: 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

    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
    

    UTM v12.6.2 VPN Ipsec RW IKEv1 Phase 2 Subnetze.png
    Alle Subnetze haben untereinander Zugriff
    Szenario: 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 die Option Subnetzkombinationen gruppieren 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 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
    

    UTM v12.6.2 VPN Ipsec RW IKEv1 Phase 2 reduzierte Subnetze.png
    Das zweite lokale Subnetz wird nur mit einem remote Subnetz verbunden

    Detaillierte Hinweise zum Troubleshooting finden sich im Troubleshooting-Guide.
    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.