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

Aus Securepoint Wiki
Wechseln zu:Navigation, Suche
 
Zeile 1: Zeile 1:
 +
{{DISPLAYTITLE:IPSec Site to Site Beispiele}}
 
== Informationen ==
 
== Informationen ==
 
Letze Anpassung zur Version: '''11.7'''  
 
Letze Anpassung zur Version: '''11.7'''  

Aktuelle Version vom 12. April 2017, 10:09 Uhr

Informationen

Letze Anpassung zur Version: 11.7
Bemerkung: Funktions- und Designanpassung
Vorherige Versionen: 11.6.12

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

IPSec single oNat.png

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 Modems 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.

Singlepath pppoe zentrale nk.png
Singlepath pppoe beide dr.png
IPSec Phase1
IPSec PHASE1.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die entsprechende externe Schnittstelle ausgewählt. Der 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 dem 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, wie zum Beispiel Butterbrot, verwendet werden. 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öglichst hohe Sicherheit zu gewährleisten. Da dieser dadurch natürlich sehr komplex und schwer zu merken ist, sollte er 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 Pakete, 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 diese 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.

Singlepath pppoe filiale nk.png
Singlepath pppoe beide dr.png
IPSec Phase1
IPSec PHASE 1 Remote.png

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier ebenfalls die externe Schnittstelle ausgewählt.
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 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.

Single-Path mit einer genatteten Seite

IPSec single eNat.png

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 Seite eine öffentliche IP-Adresse 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.

Singlepath pppoe zentrale nk.png
Singlepath pppoe beide dr.png
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 rsakeys-zentrale.png
IPSec Phase1
IPSec rsa.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die entsprechende externe Schnittstelle ausgewählt. Der 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 dem 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: 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 zusätzliche 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 Pakete, 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 diese 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.

Singlepath nat filiale nk.png
Singlepath nat filiale dr.png
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 rsakeys-filiale.png
IPSec Phase1
Ipsec12314.png

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier ebenfalls die externe Schnittstelle ausgewählt.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld 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

IPSec single bNat.png

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 wird 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.

Singlepath zentrale nat nk.png
Singlepath zentrale nat dr.png
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 rsakeys-zentrale.png
IPSec Phase1
Beidseitig genattet 1.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die entsprechende externe Schnittstelle ausgewählt. Der 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 dem Pre-Shared Key, RSA-Schlüsseln 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 Pakete, 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 diese 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.

Singlepath nat filiale nk.png
Singlepath nat filiale dr.png
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 rsakeys-filiale.png
IPSec Phase1
Beidseitig genattet 2.png

Local Gateway: Da die Firewall auch hier nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier ebenfalls die externe Schnittstelle ausgewählt.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld 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

IPSec multi oNat.png

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn auf einer Seite mehrere Internetleitungen vorhanden sind und auf beiden Seiten ö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 mehrere 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.

Multipath zentrale nk.png
Multipath zentrale dr.png
IPSec Phase1
Multipath kein nat 1.png

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 öffentliche IP-Adressen eingetragen sind.
Route Over: Hier wird die IP-Adresse des Gateway eingetragen, über den das Internet erreichbar ist und über den die VPN-Verbindung aufgebaut werden soll. 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 dem 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öglichst 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 Pakete, 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 diese 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.

Singlepath pppoe filiale nk.png
Singlepath pppoe beide dr.png
IPSec Phase1
Multipath kein nat 2.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die externe Schnittstelle ausgewählt.
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

IPSec multi eNat.png

Im folgenden wird erklärt, wie eine IPSec-VPN Konfiguration aussieht, wenn auf einer Seite mehrere Internetleitungen vorhanden sind und dort öffentliche IP-Adressen direkt an den UTM anliegen. Die andere Seite 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

In diesem Szenario nehmen wir den Fall an, dass die Zentrale mehrere 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.

Multipath zentrale nk.png
Multipath zentrale dr.png
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 rsakeys zentrale.png
IPSec Phase1
Multipath 1 Seite NAt.png

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 und über den die VPN-Verbindung aufgebaut werden soll. 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 dem 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: 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 Pakete, 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 diese nicht verwendet werden.

Filiale

Netzwerkvorgaben

In diesem Szenario ist die Filiale über einen ADSL Router mit dem Internet verbunden. Dadurch gibt es ein Transfernetz, in unserem Beispiel 192.168.2.0/24, über das 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.

Singlepath nat filiale nk.png
Singlepath nat filiale dr.png
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 rsakeys filiale.png
IPSec Phase1
Multipath 1 Seite Nat.png 2.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die externe Schnittstelle ausgewählt.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld 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 beidseitig genattet

IPSec multi bNat.png

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

In diesem Szenario nehmen wir den Fall an, dass die Zentrale mehrere Anschlüsse zum Internet hat.
Hier 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.

Multipath zentrale nat nk.png
Multipath zentrale nat dr.png
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 rsakeys zentrale.png
IPSec Phase1
Multipath beide NAT 1.png

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 der Internetanschluss erreichbar ist über das die VPN-Verbindung aufgebaut werden soll. In diesem Fall die des ADSL-Router 192.168.178.1.
Local Gateway ID: Bei der ID handelt es sich um ein zweites Authentifizierungsmerkmal neben dem 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: 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 Pakete, 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 diese nicht verwendet werden.

Filiale

Netzwerkvorgaben

In diesem Szenario ist die Filiale ebenfalls über einen ADSL Router mit dem Internet verbunden. Dadurch gibt es ein Transfernetz, in unserem Beispiel 192.168.2.0/24, über das 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.

Singlepath nat filiale nk.png
Singlepath nat filiale dr.png
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 rsakeys filiale.png
IPSec Phase1
Multipath beide NAT 2.png

Local Gateway: Da die Firewall nur eine Leitung (Single-Path) und damit nur eine Route zum Internet hat, wird hier die externe Schnittstelle ausgewählt.
Route Over: Wird aus dem Routing übernommen und automatisch im Hintergrund eingetragen. Daher kann dieses Feld 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.