UTM/VPN/IPSec-S2S Beispiele v11.7: Unterschied zwischen den Versionen

Version vom 23. Juni 2016, 08:22 Uhr

Beispiele zur Konfiguration von IPSec-VPN Site to Site Verbindungen

Bei einer IPSec Verbindung gibt es für jeden Netzaufbau empfohlene Konfigurationen, damit ein Tunnel aufgebaut werden kann. Dabei wird unterschieden, ob die öffentliche IP auf der UTM liegt oder ob die Verbindung genattet ist. Auch ob es mehrere Internetleitungen gibt spielt hierbei eine Rolle.

Single-Path mit öffentlichen IP-Adressen

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn an beiden Seiten der Verbindung jeweils nur eine Internetleitung vorhanden ist und öffentliche IP-Adressen direkt an den UTM anliegen. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle ein ADSL-Modem angeschlossen ist.

Zentrale

Netzwerkvorgaben

Für den Anschluss eines Modem an der UTM wird eine PPPoE Schnittstelle und eine Standard Route über diese Schnittstelle eingerichtet.
In unserem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält.

IPSec Phase1

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier defaultroute ausgewählt bleiben. Dieser Wert wird von der UTM aus dem Routing ausgelesen und automatisch für diese IPSec-Verbindung übernommen.
Route Over: Dieses wird ebenfalls aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld bei einer Single-Path Konfiguration frei bleiben.
Local Gateway ID: Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben den Pre-Shared Key oder den Zertifikaten. In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ppp0 ausgelesen und übernommen wird. Es können aber auch Text-Strings verwendet werden wie zum Beispiel Butterbrot. Dieser Text-String muss dann auf der Gegenstelle unter Remote Gateway ID ebenfalls eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der VPN Gegenstelle eingetragen. In unserem Beispiel also die IP-Adresse der Filiale 198.51.100.2.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Filiale eingetragen.

Authentifizierung: Für die Authentifizierung verwenden wir für diese Konfiguration einen Pre-Shared Key. Diesen lassen wir uns vom System generieren um eine möglicht hohe Sicherheit zu gewährleisten. Da dieser dadurch natürlich sehr komplex und schwer zu merken ist, sollte dieser einmal kopiert werden, um ihn im Anschluss auf der Gegenstelle ebenfalls einzutragen.

Startverhalten: Um eine VPN-Verbindung aufzubauen, muss diese von einer der beiden Seiten Initiiert werden. Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung automatisch vornimmt.
Bei einer IPSec-VPN-Verbindung ohne NAT auf beiden Seiten ist es in der Regel egal, wer die Initiierung übernimmt. Hierbei können bei zwei Securepoint Geräten sogar beide auf Outgoing eingestellt werden.
Alternativ kann hier auch das Startverhalten Incomming gewählt werden. Dann versucht die Zentrale nicht die Verbindung zu initiieren. Outgoing muss dann auf der UTM der Filiale eingestellt sein.

Dead Peer Detection: Diese überprüft die Verbindung durch versenden sogenannter Keep Alive Paket, auf die die Gegenstelle antworten muss. Tut sie das nicht, wird die Verbindung abgebaut und wieder neu aufgebaut.
Wichtig ist, dass auch die Gegenstelle die Dead Peer Detection implementiert haben muss, ansonsten kann dieses nicht verwendet werden.

Filiale

Netzwerkvorgaben

Auch hier wurde ein Modem an der UTM angeschlossen, eine PPPoE Schnittstelle und eine Standard Route über diese Schnittstelle eingerichtet.
Auch in diesem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält.

IPSec Phase1

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier ebenfalls defaultroute ausgewählt bleiben.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld wieder frei bleiben.
Local Gateway ID: In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ppp0 ausgelesen und übernommen wird.

Remote Gateway: Hier wird die öffentliche IP-Adresse der Zentrale 203.0.113.1 eingetragen.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Zentrale eingetragen.

Authentifizierung: Da der Pre-Shared Key auf beiden Seiten der VPN-Verbindung identisch sein muss, wird hier der auf der Seite der Zentrale kopierte Schlüssel eingefügt.

Startverhalten: Das Startverhalten Outgoing definiert, das diese Seite ebenfalls die Initiierung der Verbindung vornimmt. Aber sie reagiert auch auf initiierte Datenpakete der Gegenstelle.
Alternativ kann hier auch das Startverhalten Incomming gewählt werden. Dann versucht die Filiale nicht die Verbindung zu initiieren sondern reagiert nur auf ankommende Datenpakete.

Dead Peer Detection: Muss hier ebenfalls aktiviert sein, damit diese funktioniert.

Single-Path mit einer genatteten Seite

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn an beiden Seiten der Verbindung jeweils nur eine Internetleitung vorhanden ist aber nur auf einer eine öffentliche IP-Adressen direkt an den UTM anliegt. Die andere steht hinter einem Router, welcher der UTM über ein Transfernetz den Internetzugang ermöglicht. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle der UTM der ADSL-Router eines Internet-Providers angeschlossen ist.

Zentrale

Netzwerkvorgaben

Für den Anschluss eines Modem an der UTM wird eine PPPoE Schnittstelle und eine Standard Route über diese Schnittstelle eingerichtet.
In unserem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält.

RSA-Schlüssel

Sobald eine IPSec-VPN-Verbindung auf mindestens einer Seite zum Beispiel durch einen Router genattet wird, empfehlen wir statt eines Pre-Shared Key die Verwendung von RSA-Schlüsseln. Dadurch ist es möglich, bei jeder weiteren VPN-Verbindung einen eigenen Schlüssel und auch wieder die Gateway ID als zweites Authentifizierungsmerkmal zu verwenden.

Das erstellen eines RSA-Schlüsselpaares erfolgt unter dem Menü Authentifizierung und dem Untermenü RSA Schlüssel (siehe auch RSA-Keys_erstellen_und_verteilen).
Es muss dann nur noch der Öffentliche Schlüssel der Zentrale im PEM, HEX oder Base64 Format exportiert und in die UTM der Filiale importiert werden. Der Öffentliche Schlüssel der Filiale wird ebenfalls exportiert und in die UTM der Zentrale importiert.

IPSec Phase1

Singlepath ipsec p1 zentrale nat-rsa.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier defaultroute ausgewählt bleiben. Dieser Wert wird von der UTM aus dem Routing ausgelesen und automatisch für diese IPSec-Verbindung übernommen.
Route Over: Dieses wird ebenfalls aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld bei einer Single-Path Konfiguration frei bleiben.
Local Gateway ID: Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben den Pre-Shared Key oder den Zertifikaten. In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ppp0 ausgelesen und übernommen wird. Es können aber auch Text-Strings verwendet werden wie zum Beispiel Butterbrot. Dieser Text-String muss dann auf der Gegenstelle unter Remote Gateway ID ebenfalls eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der VPN Gegenstelle eingetragen. In unserem Beispiel also die IP-Adresse der Filiale 198.51.100.2.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Filiale eingetragen.

Authentifizierung: Diese stellen wir auf RSA und verwenden die RSA-Schlüssel die gerade erstellt beziehungsweise importiert worden sind.

Local Key: zentrale-rsa
Remote Key: filiale-rsa_pem

Startverhalten: Um eine VPN-Verbindung automatisch aufzubauen, muss diese von einer der beiden Seiten Initiiert werden.
Bei einseitig genatteten IPSec-VPN-Verbindungen empfehlen wir, dass die Seite die Verbindung initiiert, die hinter dem Router steht, durch den das NAT notwendig ist. Die nicht genattete Seite sollte dann nur auf die Datenpakete der Gegenstelle reagieren aber nicht selbst versuchen diese Verbindung zu initiieren.
Das Startverhalten Incomming definiert, das die Seite der Zentrale nur auf IPSec Verbindungsanfragen der Filiale reagiert diese aber nicht aktiv initiiert.

Dead Peer Detection: Diese überprüft die Verbindung durch versenden sogenannter Keep Alive Paket, auf die die Gegenstelle antworten muss. Tut sie das nicht, wird die Verbindung abgebaut und wieder neu aufgebaut.
Wichtig ist, dass auch die Gegenstelle die Dead Peer Detection implementiert haben muss, ansonsten kann dieses nicht verwendet werden.

Filiale

Netzwerkvorgaben

In diesem Szenario ist die Seite der Filiale die Gegenstelle der IPSec-Verbindung, die durch einen ADSL Router über das Transfernetz 192.168.2.0/24 zusätzlich genattet werden muss. Die Öffentliche IP-Adresse liegt also nicht direkt auf der externen Schnittstelle der UTM. In der Standard-Route wird die IP-Adresse des ADSL Router 192.168.2.1 als Gateway eingetragen.

RSA-Schlüssel

Wie schon auf der UTM der Zentrale muss der Öffentliche Schlüssel der Filiale im PEM, HEX oder Base64 Format exportiert und in die UTM der Zentrale importiert werden. Der Öffentliche Schlüssel der Zentrale wird ebenfalls exportiert und in die UTM der Filiale importiert.

IPSec Phase1

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier ebenfalls defaultroute ausgewählt bleiben.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld wieder frei bleiben.
Local Gateway ID: Durch das Transfernetz zum ADSL Router liegt die öffentliche IP-Adresse nicht auf der Schnittstelle. Hier muss die 198.51.100.2 manuell eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der Zentrale 203.0.113.1 eingetragen.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Zentrale eingetragen.

Authentifizierung: Hier wird, wie auch schon auf der UTM der Zentrale, RSA ausgewählt und die RSA-Schlüssel die gerade erstellt beziehungsweise importiert worden sind verwendet.

Local Key: filiale-rsa
Remote Key: zentrale-rsa_pem

Startverhalten: Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung vornimmt.

Dead Peer Detection: Muss hier ebenfalls aktiviert sein, damit diese funktioniert.

Single-Path beidseitig genattet

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn an beiden Seiten der Verbindung jeweils nur eine Internetleitung vorhanden ist und beide Seiten der Verbindung stehen hinter einem Router, welcher der UTM über ein Transfernetz den Internetzugang ermöglicht. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle der UTM der ADSL-Router eines Internet-Providers angeschlossen ist.

Diese Konfiguration wird von Securepoint nicht empfohlen, da diese in der Regel instabil ist, wenn sie denn überhaupt aufgebaut wird. Empfohlen wir für dieses Szenario eine OpenVPN Site to Site Verbindung.

Zentrale

Netzwerkvorgaben

In diesem Szenario soll die Zentrale die IPSec-Verbindung über eine Internetleitung aufbauen, die durch einen ADSL Router über das Transfernetz 192.168.178.0/24 zusätzlich genattet werden muss. Die Öffentliche IP-Adresse liegt also nicht direkt auf der externen Schnittstelle der UTM. In der Standard-Route wird die IP-Adresse des ADSL Router 192.168.178.1 als Gateway eingetragen.

RSA-Schlüssel

Sobald eine IPSec-VPN-Verbindung auf mindestens einer Seite zum Beispiel durch einen Router genattet wird, empfehlen wir statt eines Pre-Shared Key die Verwendung von RSA-Schlüsseln. Dadurch ist es möglich, bei jeder weiteren VPN-Verbindung einen eigenen Schlüssel und auch wieder die Gateway ID als zweites Authentifizierungsmerkmal zu verwenden.

Das erstellen eines RSA-Schlüsselpaares erfolgt unter dem Menü Authentifizierung und dem Untermenü RSA Schlüssel (siehe auch RSA-Keys_erstellen_und_verteilen).
Es muss dann nur noch der Öffentliche Schlüssel der Zentrale im PEM, HEX oder Base64 Format exportiert und in die UTM der Filiale importiert werden. Der Öffentliche Schlüssel der Filiale wird ebenfalls exportiert und in die UTM der Zentrale importiert.

IPSec Phase1

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier defaultroute ausgewählt bleiben. Dieser Wert wird von der UTM aus dem Routing ausgelesen und automatisch für diese IPSec-Verbindung übernommen.
Route Over: Dieses wird ebenfalls aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld bei einer Single-Path Konfiguration frei bleiben.
Local Gateway ID: Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben den Pre-Shared Key oder den Zertifikaten. Durch das Transfernetz zum ADSL Router liegt die öffentliche IP-Adresse nicht auf der Schnittstelle. Hier muss die öffentliche IP-Adresse der Zentrale 203.0.113.1 manuell eingetragen werden. Es können aber auch Text-Strings verwendet werden wie zum Beispiel Butterbrot. Dieser Text-String muss dann auf der Gegenstelle unter Remote Gateway ID ebenfalls eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der VPN Gegenstelle eingetragen. In unserem Beispiel also die IP-Adresse der Filiale 198.51.100.2.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Filiale eingetragen.

Authentifizierung: Diese stellen wir auf RSA und verwenden die RSA-Schlüssel die gerade erstellt beziehungsweise importiert worden sind.

Local Key: zentrale-rsa
Remote Key: filiale-rsa_pem

Startverhalten: Um eine VPN-Verbindung automatisch aufzubauen, muss diese von einer der beiden Seiten Initiiert werden.
Wenn wie hier beide Seiten genattet sind, muss ausprobiert werden, welche Seite der VPN-Verbindung diese am besten aufbauen kann.
Das Startverhalten Outgoing definiert, das die UTM der Zentrale die Initiierung der Verbindung automatisch vornimmt.
Das Startverhalten Incomming definiert, das die UTM der Zentrale nur auf IPSec Verbindungsanfragen der Filiale reagiert diese aber nicht aktiv initiiert.

Dead Peer Detection: Diese überprüft die Verbindung durch versenden sogenannter Keep Alive Paket, auf die die Gegenstelle antworten muss. Tut sie das nicht, wird die Verbindung abgebaut und wieder neu aufgebaut.
Wichtig ist, dass auch die Gegenstelle die Dead Peer Detection implementiert haben muss, ansonsten kann dieses nicht verwendet werden.

Filiale

Netzwerkvorgaben

In diesem Szenario muss die Seite der Filiale, als IPSec-VPN Gegenstelle, durch einen ADSL Router über das Transfernetz 192.168.2.0/24 ebenfalls genattet werden. Die Öffentliche IP-Adresse liegt also nicht direkt auf der externen Schnittstelle der UTM. In der Standard-Route wird die IP-Adresse des ADSL Router 192.168.2.1 als Gateway eingetragen.

RSA-Schlüssel

Wie schon auf der UTM der Zentrale muss der Öffentliche Schlüssel der Filiale im PEM, HEX oder Base64 Format exportiert und in die UTM der Zentrale importiert werden. Der Öffentliche Schlüssel der Zentrale wird ebenfalls exportiert und in die UTM der Filiale importiert.

IPSec Phase1

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier ebenfalls defaultroute ausgewählt bleiben.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld wieder frei bleiben.
Local Gateway ID: Durch das Transfernetz zum ADSL Router liegt die öffentliche IP-Adresse nicht auf der Schnittstelle. Hier muss die 198.51.100.2 manuell eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der Zentrale 203.0.113.1 eingetragen.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Zentrale eingetragen.

Authentifizierung: Hier wird, wie auch schon auf der UTM der Zentrale, RSA ausgewählt und die RSA-Schlüssel die gerade erstellt beziehungsweise importiert worden sind verwendet.

Local Key: filiale-rsa
Remote Key: zentrale-rsa_pem

Startverhalten: Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung vornimmt.

Dead Peer Detection: Muss hier ebenfalls aktiviert sein, damit diese funktioniert.

Multipath mit öffentlichen IP-Adressen

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn auf einer Seite mehrere Internetleitungen vorhanden sind und öffentliche IP-Adressen direkt an den UTM anliegen. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle ein ADSL Modem angeschlossen ist.

Zentrale

Netzwerkvorgaben

In diesem Szenario nehmen wir den Fall an, dass die Zentrale mehrer Anschlüsse zum Internet hat.
Hier soll die IPSec-VPN Verbindung über einen Internetzugang mit direkt angeschlossenem DSL-Modem aufgebaut werden. In unserem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält. Da in diesem Beispiel mehrere Internetverbindungen gleichzeitig genutzt werden bestehen auch mehrere Standard Routen (Multipath-Routing).

Wichtig ist an dieser Stelle auch, dass die VPN Zonen vpn-ipsec und firewall-vpn-ipsec auf der Schnittstelle liegen, über die die VPN-Verbindung erstellt werden soll. Ansonsten wird es Probleme mit den Portfilterregeln geben.
Sollen unterschiedliche VPN-Verbindungen über unterschiedliche Internetverbindungen aufgebaut werden, müssen weitere VPN Zonen angelegt werden.

IPSec Phase1

Local Gateway: Da die Firewall mehrere Leitung (Multipath) und damit mehrere Routen zum Internet hat, wird hier die Schnittstelle ausgewählt, die für die IPSec-VPN Verbindung genutzt werden soll. Alternativ kann hier auch eine IP-Adresse eingetragen werden, wenn auf dieser Schnittstelle mehrere IP-Adressen eingetragen sind.
Route Over: Hier wird die IP-Adresse des Gateway eingetragen, über den das Internet erreichbar ist. Für PPPoE Verbindungen wird diese aus dem Routing übernommen daher wird hier die Schnittstelle ppp0 eingetragen.
Local Gateway ID: Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben den Pre-Shared Key, RSA Schlüsseln oder den Zertifikaten. In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ppp0 ausgelesen und übernommen wird. Es können aber auch Text-Strings verwendet werden wie zum Beispiel Butterbrot. Dieser Text-String muss dann auf der Gegenstelle unter Remote Gateway ID ebenfalls eingetragen werden.

Remote Gateway: Hier wird die öffentliche IP-Adresse der VPN Gegenstelle eingetragen. In unserem Beispiel also die IP-Adresse der Filiale 198.51.100.2.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Filiale eingetragen.

Authentifizierung: Für die Authentifizierung verwenden wir für diese Konfiguration einen Pre-Shared Key. Diesen lassen wir uns vom System generieren um eine möglicht hohe Sicherheit zu gewährleisten. Da dieser dadurch natürlich sehr komplex und schwer zu merken ist, sollte der einmal kopiert werden, um ihn im Anschluss auf der Gegenstelle ebenfalls einzutragen.

Startverhalten: Um eine VPN-Verbindung aufzubauen, muss diese von einer der beiden Seiten Initiiert werden. Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung automatisch vornimmt.
Bei einer IPSec-VPN-Verbindung ohne NAT auf beiden Seiten ist es in der Regel egal, wer die Initiierung übernimmt. Hierbei können bei zwei Securepoint Geräten sogar beide auf Outgoing eingestellt werden.
Alternativ kann hier auch das Startverhalten Incomming gewählt werden. Dann versucht die Zentrale nicht die Verbindung zu initiieren. Outgoing muss dann auf der UTM der Filiale eingestellt sein.

Dead Peer Detection: Diese überprüft die Verbindung durch versenden sogenannter Keep Alive Paket, auf die die Gegenstelle antworten muss. Tut sie das nicht, wird die Verbindung abgebaut und wieder neu aufgebaut.
Wichtig ist, dass auch die Gegenstelle die Dead Peer Detection implementiert haben muss, ansonsten kann dieses nicht verwendet werden.

Filiale

Netzwerkvorgaben

Auch hier wurde ein Modem an der UTM angeschlossen, eine PPPoE Schnittstelle und eine Standard Route über diese Schnittstelle eingerichtet.
Auch in diesem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält.

IPSec Phase1

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier defaultroute ausgewählt bleiben.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld frei bleiben.
Local Gateway ID: In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ppp0 ausgelesen und übernommen wird.

Remote Gateway: Hier wird die öffentliche IP-Adresse der Zentrale 203.0.113.1 eingetragen.
Remote Gateway ID: In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Zentrale eingetragen.

Authentifizierung: Da der Pre-Shared Key auf beiden Seiten der VPN-Verbindung identisch sein muss, wird hier der auf der UTM der Zentrale erstellte und kopierte Schlüssel eingefügt.

Startverhalten: Das Startverhalten Outgoing definiert, das diese Seite ebenfalls die Initiierung der Verbindung vornimmt. Aber sie reagiert auch auf initiierte Datenpakete der Gegenstelle.
Alternativ kann hier auch das Startverhalten Incomming gewählt werden. Dann versucht die Filiale nicht die Verbindung zu initiieren sondern reagiert nur auf ankommende Datenpakete.

Dead Peer Detection: Muss hier ebenfalls aktiviert sein, damit diese funktioniert.

Multipath mit einer genatteten Seite

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn auf einer Seite mehrere Internetleitungen vorhanden sind aber nur auf einer eine öffentliche IP-Adressen direkt an den UTM anliegt. Die andere steht hinter einem Router, welcher der UTM über ein Transfernetz den Internetzugang ermöglicht. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle der UTM der ADSL-Router eines Internet-Providers angeschlossen ist.

Zentrale

Netzwerkvorgaben

RSA-Schlüssel

IPSec Phase1

Filiale

Netzwerkvorgaben

RSA-Schlüssel

IPSec Phase1

Multipath beidseitig genattet

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn auf einer Seite mehrere Internetleitungen vorhanden sind und beide Seiten der Verbindung stehen hinter einem Router, welcher der UTM über ein Transfernetz den Internetzugang ermöglicht. Dieses ist zum Beispiel der Fall, wenn an der externen Schnittstelle der UTM der ADSL-Router eines Internet-Providers angeschlossen ist.

Diese Konfiguration wird von Securepoint nicht empfohlen, da diese in der Regel instabil ist, wenn sie denn überhaupt aufgebaut wird. Empfohlen wir für dieses Szenario eine OpenVPN Site to Site Verbindung.

Zentrale

Netzwerkvorgaben

RSA-Schlüssel

IPSec Phase1

Multipath ipsec p1 zentrale nat rsa beide.png

@@ Zeile 56: / Zeile 56: @@
 Alternativ kann hier auch das Startverhalten ''Incomming'' gewählt werden. Dann versucht die Filiale nicht die Verbindung zu initiieren sondern reagiert nur auf ankommende Datenpakete.
-'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit dieses funktioniert.
+'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit diese funktioniert.
 ===Single-Path mit einer genatteten Seite===
@@ Zeile 123: / Zeile 123: @@
 '''Startverhalten:''' Das Startverhalten ''Outgoing'' definiert, das diese Seite die Initiierung der Verbindung vornimmt.
-'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit dieses funktioniert.
+'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit diese funktioniert.
@@ Zeile 194: / Zeile 194: @@
 '''Startverhalten:''' Das Startverhalten ''Outgoing'' definiert, das diese Seite die Initiierung der Verbindung vornimmt.
-'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit dieses funktioniert.
+'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit diese funktioniert.
 ===Multipath mit öffentlichen IP-Adressen===
@@ Zeile 207: / Zeile 207: @@
 Da in diesem Beispiel mehrere Internetverbindungen gleichzeitig genutzt werden bestehen auch mehrere Standard Routen (Multipath-Routing).<br>
-Wichtig ist an dieser Stelle auch, dass die VPN Zonen auf der Schnittstelle liegen, über die die VPN-Verbindung erstellt werden soll. Ansonsten wird es Probleme mit den Portfilterregeln geben.<br>
+Wichtig ist an dieser Stelle auch, dass die VPN Zonen ''vpn-ipsec'' und ''firewall-vpn-ipsec'' auf der Schnittstelle liegen, über die die VPN-Verbindung erstellt werden soll. Ansonsten wird es Probleme mit den Portfilterregeln geben.<br>
 Sollen unterschiedliche VPN-Verbindungen über unterschiedliche Internetverbindungen aufgebaut werden, müssen weitere VPN Zonen angelegt werden.
 [[Datei:multipath_zentrale_nk.png|600px|center]]
@@ Zeile 214: / Zeile 214: @@
 =====IPSec Phase1=====
 [[Datei:multipath_ipsec_p1_zentrale.png|300px|right]]
+'''Local Gateway:''' Da die Firewall mehrere Leitung (Multipath) und damit mehrere Routen zum Internet hat, wird hier die Schnittstelle ausgewählt, die für die IPSec-VPN Verbindung genutzt werden soll. Alternativ kann hier auch eine IP-Adresse eingetragen werden, wenn auf dieser Schnittstelle mehrere IP-Adressen eingetragen sind.<br>
+'''Route Over:''' Hier wird die IP-Adresse des Gateway eingetragen, über den das Internet erreichbar ist. Für PPPoE Verbindungen wird diese aus dem Routing übernommen daher wird hier die Schnittstelle ppp0 eingetragen.<br>
+'''Local Gateway ID:''' Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben den Pre-Shared Key, RSA Schlüsseln oder den Zertifikaten. In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ''ppp0'' ausgelesen und übernommen wird. Es können aber auch Text-Strings verwendet werden wie zum Beispiel ''Butterbrot''. Dieser Text-String muss dann auf der Gegenstelle unter ''Remote Gateway ID'' ebenfalls eingetragen werden.
+'''Remote Gateway:''' Hier wird die öffentliche IP-Adresse der VPN Gegenstelle eingetragen. In unserem Beispiel also die IP-Adresse der Filiale ''198.51.100.2''.<br>
+'''Remote Gateway ID:''' In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Filiale eingetragen.
+'''Authentifizierung:''' Für die Authentifizierung verwenden wir für diese Konfiguration einen Pre-Shared Key. Diesen lassen wir uns vom System generieren um eine möglicht hohe Sicherheit zu gewährleisten. Da dieser dadurch natürlich sehr komplex und schwer zu merken ist, sollte der einmal kopiert werden, um ihn im Anschluss auf der Gegenstelle ebenfalls einzutragen.
+'''Startverhalten:''' Um eine VPN-Verbindung aufzubauen, muss diese von einer der beiden Seiten Initiiert werden. Das Startverhalten ''Outgoing'' definiert, das diese Seite die Initiierung der Verbindung automatisch vornimmt.<br>
+Bei einer IPSec-VPN-Verbindung ohne NAT auf beiden Seiten ist es in der Regel egal, wer die Initiierung übernimmt. Hierbei können bei zwei Securepoint Geräten sogar beide auf ''Outgoing'' eingestellt werden.<br>
+Alternativ kann hier auch das Startverhalten ''Incomming'' gewählt werden. Dann versucht die Zentrale nicht die Verbindung zu initiieren. Outgoing muss dann auf der UTM der Filiale eingestellt sein.
+'''Dead Peer Detection:''' Diese überprüft die Verbindung durch versenden sogenannter ''Keep Alive'' Paket, auf die die Gegenstelle antworten muss. Tut sie das nicht, wird die Verbindung abgebaut und wieder neu aufgebaut.<br>
+Wichtig ist, dass auch die Gegenstelle die ''Dead Peer Detection'' implementiert haben muss, ansonsten kann dieses nicht verwendet werden.
 ====Filiale====
 =====Netzwerkvorgaben=====
+Auch hier wurde ein Modem an der UTM angeschlossen, eine [[Konfiguration_PPPoE_UTMV11 | PPPoE]] Schnittstelle und eine Standard Route über diese Schnittstelle eingerichtet.<br>
+Auch in diesem Fall ist es die erste PPPoE Schnittstelle, die dann die Bezeichnung ppp0 erhält.
 [[Datei:singlepath_pppoe_filiale_nk.png|600px|center]]
 [[Datei:singlepath_pppoe_beide_dr.png|600px|center]]
@@ Zeile 222: / Zeile 239: @@
 =====IPSec Phase1=====
 [[Datei:singlepath_ipsec_p1_filiale.png|300px|right]]
+'''Local Gateway:''' Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, kann hier  ''defaultroute'' ausgewählt bleiben.<br>
+'''Route Over:''' Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld frei bleiben.<br>
+'''Local Gateway ID:''' In unserem Beispiel verwenden wir die öffentliche IP-Adresse, welche von der Schnittstelle ''ppp0'' ausgelesen und übernommen wird.
+'''Remote Gateway:''' Hier wird die öffentliche IP-Adresse der Zentrale ''203.0.113.1'' eingetragen.<br>
+'''Remote Gateway ID:''' In unserem Beispiel verwenden wir die die IP-Adressen als ID, daher wird hier ebenfalls die öffentliche IP-Adresse der Zentrale eingetragen.
+'''Authentifizierung:''' Da der Pre-Shared Key auf beiden Seiten der VPN-Verbindung identisch sein muss, wird hier der auf der UTM der Zentrale erstellte und kopierte Schlüssel eingefügt.
+'''Startverhalten:''' Das Startverhalten ''Outgoing'' definiert, das diese Seite ebenfalls die Initiierung der Verbindung vornimmt. Aber sie reagiert auch auf initiierte Datenpakete der Gegenstelle.<br>
+Alternativ kann hier auch das Startverhalten ''Incomming'' gewählt werden. Dann versucht die Filiale nicht die Verbindung zu initiieren sondern reagiert nur auf ankommende Datenpakete.
+'''Dead Peer Detection:''' Muss hier ebenfalls aktiviert sein, damit diese funktioniert.