Dirkg (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Dirkg (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 70: | Zeile 70: | ||
=====RSA-Schlüssel===== | =====RSA-Schlüssel===== | ||
Sobald eine IPSec-VPN-Verbindung auf mindestens einer Seite 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. | Sobald eine IPSec-VPN-Verbindung auf mindestens einer Seite 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'' (siehe auch [[Howtos-V11/RSA-Keys_erstellen_und_verteilen | RSA-Keys_erstellen_und_verteilen]]).<br> | |||
Es muss dann nur noch der Öffentliche Schlüssel der Zentrale | Das erstellen eines RSA-Schlüsselpaares erfolgt unter dem Menü ''Authentifizierung'' und dem Untermenü ''RSA Schlüssel'' (siehe auch [[Howtos-V11/RSA-Keys_erstellen_und_verteilen | RSA-Keys_erstellen_und_verteilen]]).<br> | ||
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. | |||
[[Datei:ipsec_rsakeys-zentrale.png|600px|center]] | [[Datei:ipsec_rsakeys-zentrale.png|600px|center]] | ||
=====IPSec Phase1===== | =====IPSec Phase1===== | ||
[[Datei:singlepath_ipsec_p1_zentrale_nat-rsa.png|300px|right]] | [[Datei:singlepath_ipsec_p1_zentrale_nat-rsa.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. Dieser Wert wird von der UTM aus dem Routing ausgelesen und automatisch für diese IPSec-Verbindung übernommen.<br> | |||
'''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.<br> | |||
'''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''.<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:''' 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. Das Startverhalten ''Outgoing'' definiert, das diese Seite die Initiierung der Verbindung 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. | |||
'''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==== | ====Filiale==== | ||
Version vom 22. Juni 2016, 11:39 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 automatisch aufzubauen, muss diese von einer der beiden Seiten Initiiert werden. Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung 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.
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.
Dead Peer Detection: Muss hier ebenfalls aktiviert sein, damit dieses 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 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. 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. Das Startverhalten Outgoing definiert, das diese Seite die Initiierung der Verbindung 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.
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
RSA-Schlüssel
IPSec Phase1
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
RSA-Schlüssel
IPSec Phase1
Filiale
Netzwerkvorgaben
RSA-Schlüssel
IPSec Phase1
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
IPSec Phase1
Filiale
Netzwerkvorgaben
IPSec Phase1
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
Filiale
Netzwerkvorgaben
RSA-Schlüssel
IPSec Phase1