Dieses Menü steht nicht auf dem FL MGUARD BLADE -Controller zur Verfügung.
Dieses Menü steht nicht auf dem FL MGUARD BLADE -Controller zur Verfügung. |
IPsec VPN >> Global >> Optionen |
||
|---|---|---|
Erlaube Paketweiterleitung zwischen VPN-Verbindungen |
|
|
|
|
Bei deaktivierter Funktion (werkseitige Voreinstellung): VPN-Verbindungen existieren für sich separat. Es finden keine Paketweiterleitungen zwischen den konfigurierten VPN-Verbindungen statt. Bei aktivierter Funktion: „Hub and Spoke“-Feature eingeschaltet: Der mGuard als Zentrale unterhält VPN-Verbindungen zu mehreren Zweigstellen, die dann auch untereinander kommunizieren können. 
|
|
|
Bei Aufbau solch einer sternförmigen Topologie von VPN-Verbindungen können Gegenstellen des mGuard s auch untereinander Daten austauschen. In diesem Fall ist zu empfehlen, dass der lokale mGuard für die Authentifizierung möglicher Gegenstellen CA-Zertifikate heranzieht (siehe „Authentifizierung“ auf Seite 358). |
|
|
Bei „Hub and Spoke“ wird 1:1-NAT der Gegenstelle nicht unterstützt. |
|
Bei deaktivierter Funktion (Standard) Falls beim Aufbau von VPN-Verbindungen Fehler auftreten, kann das Logging des mGuard s herangezogen und anhand entsprechender Einträge die Fehlerquelle ausfindig gemacht werden (Siehe Menüpunk Logging >> Logs ansehen ). Diese Möglichkeit zur Fehlerdiagnose ist standardmäßig gegeben. Wenn sie ausreichend ist, können Sie die Funktion an dieser Stelle deaktivieren. Bei aktivierter Funktion Wird die Möglichkeit zur Diagnose von VPN-Verbindungsproblemen anhand des Loggings des mGuard s als zu unpraktisch oder unzureichend empfunden, wählen Sie diese Option. Das ist möglicherweise der Fall, wenn folgende Bedingungen vorliegen: –In bestimmten Anwendungsumgebungen, z. B. wenn der mGuard per Maschinensteuerung über den CMD-Kontakt „bedient“ wird (nur bei FL MGUARD RS4000/RS2000 , TC MGUARD RS4000/RS2000 3G , TC MGUARD RS4000/RS2000 4G , FL MGUARD RS4004/RS2005 und beim FL MGUARD RS , FL MGUARD GT/GT ), steht die Möglichkeit, dass ein Anwender über die Web-basierte Bedienoberfläche des mGuard s die Logdatei des mGuard s einsieht, vielleicht gar nicht zur Verfügung. –Bei dezentralem Einsatz kann es vorkommen, dass eine Diagnose eines VPN-Verbindungsfehlers erst möglich ist, nachdem der mGuard vorübergehend von seiner Stromquelle getrennt worden ist - was zum Löschen aller Logeinträge führt. |
|
|
|
–Die relevanten Logeinträge des mGuard s, die Aufschluss geben könnten, sind eventuell gelöscht, weil der mGuard aufgrund seines endlichen Speicherplatzes ältere Logeinträge regelmäßig löscht. –Wird ein mGuard als zentrale VPN-Gegenstelle eingesetzt, z. B. in einer Fernwartungszentrale als Gateway für die VPN-Verbindungen vieler Maschinen, werden die Meldungen zu Aktivitäten der verschiedenen VPN-Verbindungen im selben Datenstrom protokolliert. Das dadurch entstehende Volumen des Logging macht es zeitaufwendig, die für einen Fehler relevanten Informationen zu finden. |
|
|
Nach Einschalten der Archivierung werden relevante Logeinträge über die Vorgänge beim Aufbau von VPN-Verbindungen im nicht flüchtigen Speicher des mGuard s archiviert, wenn die Verbindungsaufbauten wie folgt veranlasst werden: –über den CMD-Kontakt oder –über SMS oder –über die Icon „Starten“ auf der Web-Oberfläche oder –über das CGI-Interface nph-vpn.cgi per Kommando „synup“ (siehe Application Note: „How to use the CGI Interface“). (Application Notes stehen im Download-Bereich von phoenixcontact.net/products bereit.) –Archivierte Logeinträge überleben einen Neustart. Sie können als Bestandteil des Support-Snapshots (Menüpunkt Hardware heruntergeladen werden. Der Support Ihrer Bezugsquelle erhält durch solch einen Snapshot erweiterte Möglichkeiten, effizienter nach Problemursachen zu suchen und diese zu finden, als ohne die Archivierung möglich wäre. |
|
Archiviere Diagnosemeldungen nur bei Fehlverhalten (Nur wenn Archivierung aktiviert ist) |
Sollen nach Einschalten der Archivierung nur solche Logeinträge archiviert werden, die bei fehlgeschlagenen Verbindungsaufbauversuchen erzeugt werden, aktivieren Sie die Funktion. Bei deaktivierter Funktion werden alle Logeinträge archiviert. |
Die Funktion dient dazu, die über eine VPN-Verbindung zu übertragenden Datenpakete in TCP-Pakete einzukapseln. Ohne diese Einkapselung kann es bei VPN-Verbindungen unter Umständen passieren, dass z. B. durch zwischengeschaltete NAT-Router, Firewalls oder Proxy-Server wichtige Datenpakete, die zu einer VPN-Verbindung gehören, nicht ordnungsgemäß übertragen werden.
Zum Beispiel können Firewalls so eingestellt sein, dass keine Datenpakete des UDP-Protokolls durchgelassen werden oder (mangelhaft implementierte) NAT-Router könnten bei UDP-Paketen die Port-Nummern nicht korrekt verwalten.
Durch die TCP-Kapselung werden diese Probleme vermieden, weil die zur betreffenden VPN-Verbindung gehörenden Pakete in TCP-Pakete eingekapselt, d. h. verborgen sind, so dass für die Netz-Infrastruktur nur TCP-Pakete in Erscheinung treten
Der mGuard kann in TCP gekapselte VPN-Verbindungen annehmen, selbst wenn er im Netzwerk hinter einem NAT-Gateway angeordnet ist und deshalb von der VPN-Gegenstelle nicht unter seiner primären externen IP-Adresse erreicht werden kann. Das NAT-Gateway muss dafür den entsprechenden TCP-Port zum mGuard weiterreichen (siehe „Horche auf eingehende VPN-Verbindungen, die eingekapselt sind“ auf Seite 333).
TCP-Kapselung kann nur eingesetzt werden, wenn auf beiden Seiten des VPN-Tunnels ein mGuard (ab Version 6.1) eingesetzt wird. Die Funktion „Path Finder“ kann ab Version 8.3 eingesetzt werden und funktioniert ebenfalls mit dem mGuard Secure VPN Client . |
TCP-Kapselung sollte nur eingesetzt werden, wenn es erforderlich ist. Denn durch die beträchtliche Vergrößerung des Datenpaket-Overheads und durch entsprechend verlängerte Verarbeitungszeiten werden Verbindungen erheblich langsamer. |
Wenn beim mGuard unter Menüpunkt Netzwerk >> Proxy-Einstellungen festgelegt ist, dass ein Proxy für HTTP und HTTPS benutzt wird, dann wird dieser auch für VPN-Verbindungen verwendet, bei denen TCP-Kapselung eingesetzt wird. |
TCP-Kapselung unterstützt die Authentifizierungsverfahren Basic Authentification und NTLM gegenüber dem Proxy. Die Funktion „Path Finder“ unterstützt zusätzlich das Authentifizierungsverfahren „Digest“. |
Damit die TCP-Kapselung durch einen HTTP-Proxy hindurch funktioniert, muss einerseits der Proxy explizit in den Proxy-Einstellungen (Menüpunkt Netzwerk >> Proxy-Einstellungen ) benannt werden (darf also kein transparenter Proxy sein) und andererseits muss dieser Proxy die HTTP-Methode CONNECT verstehen und erlauben. |
Um die Funktion „Path Finder“ zum Aufbau einer VPN-Verbindung mit einem mGuard Secure VPN Client zu benutzen, muss die Funktion auf beiden Seiten der Verbindung (Server und Client) aktiviert werden. |
TCP-Kapselung funktioniert nicht in Verbindung mit einer Authentifizierung über Pre-Shared Key (PSK). |
TCP-Kapselung funktioniert nur, wenn eine der beiden Seiten auf Verbindungen wartet (Verbindungsinitiierung: Warte) und als Adresse des VPN-Gateways der Gegenstelle „%any“ angegeben ist. |
TCP-Kapselung mit aktivierter Funktion „Path Finder“
Die TCP-Kapselung mit aktivierter Funktion „Path Finder“ verbessert das Verhalten der oben beschriebenen Standard-TCP-Kapselung.
Wenn die Verbindung neu eingerichtet wird und keine Rückwärtskompatibilität notwendig ist, sollte die Path Finder Funktion verwendet werden.
Wird eine VPN-Verbindung durch den mGuard Secure VPN Client gestartet, der sich hinter einem Proxy-Server oder einer Firewall befindet, muss die Funktion „Path Finder“ sowohl im mGuard Secure VPN Client als auch im mGuard (Server) aktiviert sein. Die über die VPN-Verbindung zu übertragenden Datenpakete werden dabei in TCP-Pakete eingekapselt (siehe „TCP-Kapselung“ auf Seite 331).
Bild 10-1: TCP-Kapselung bei einem Anwendungsszenario mit Wartungszentrale und ferngewarteten Maschinen über VPN-Verbindungen
TCP-Kapselung |
Horche auf eingehende VPN-Verbindungen, die eingekapselt sind |
Standardeinstellung: Deaktiviert Nur bei Einsatz der Funktion TCP-Kapselung diese Funktion aktivieren. Nur dann kann der mGuard Verbindungsaufbauten mit eingekapselten Paketen annehmen. 
Auf welchen Schnittstellen gehorcht werden muss, ermittelt der mGuard aus den Einstellungen der aktiven VPN-Verbindungen, die „%any“ als Gegenstelle konfiguriert haben. Die Einstellung unter „Interface, welches bei der Einstellung %any für das Gateway benutzt wird“ ist ausschlaggebend. |
|
TCP-Port, auf dem zu horchen ist (Bei TCP-Kapselung) |
Standard: 8080 Nummer des TCP-Ports, über den die zu empfangenen eingekapselten Datenpakete eingehen. Die hier angegebene Port-Nummer muss mit der Port-Nummer übereinstimmen, die beim mGuard der Gegenstelle als TCP-Port des Servers, welcher die gekapselte Verbindung annimmt, festgelegt ist (Menüpunkt IPsec VPN >> Verbindungen , Editieren, Registerkarte Allgemein). Es gelten folgende Einschränkung: Der Port, auf dem zu horchen ist, darf nicht identisch sein –mit einem Port, der für Fernzugriff benutzt wird (SSH, HTTPS oder SEC-Stick), –mit dem Port, auf dem bei aktivierter Funktion Path Finder gehorcht wird. |
|
Server-ID (0-63) (Bei TCP-Kapselung) |
Der Standardwert 0 muss normalerweise nicht geändert werden. Die Nummern dienen zur Unterscheidung unterschiedlicher Zentralen. Eine andere Nummer muss nur in folgendem Fall verwendet werden: Ein mGuard , vorgeschaltet einer Maschine, muss zu zwei oder mehreren verschiedenen Wartungszentralen und deren mGuard s Verbindungen mit eingeschalteter TCP-Kapselung aufnehmen. |
|
Aktiviere Path Finder für mGuard Secure VPN Client |
Standardeinstellung: Deaktiviert Nur wenn der mGuard eine VPN-Verbindung von einem mGuard Secure VPN Client annehmen soll, der sich hinter einem Proxy-Server oder einer Firewall befindet, diese Funktion aktivieren. Die Funktion „Path Finder“ muss ebenfalls im mGuard Secure VPN Client aktiviert sein. |
|
TCP-Port, auf dem zu horchen ist (Bei Path Finder) |
Standard: 443 Nummer des TCP-Ports, über den die zu empfangenen eingekapselten Datenpakete eingehen. Die hier angegebene Port-Nummer muss mit der Port-Nummer übereinstimmen, die bei dem VPN-Client der Gegenstelle als TCP-Port des Servers, welcher die gekapselte Verbindung annimmt, festgelegt ist. Der mGuard Secure VPN Client verwendet als Ziel-Port immer Port 443. Nur für die Fälle, in denen der Port von einer Firewall zwischen dem mGuard Secure VPN Client und dem mGuard umgeschrieben wird, müsste der Port im mGuard geändert werden. Es gilt folgende Einschränkung: Der Port, auf dem zu horchen ist, darf nicht identisch sein –mit einem Port, der für Fernzugriffe benutzt wird (SSH, HTTPS oder SEC-Stick), –mit dem Port, auf dem bei aktivierter Funktion TCP-Kapselung gehorcht wird. |
IP-Fragmentierung |
IKE-Fragmentierung |
UDP-Pakete können insbesondere dann übergroß werden, wenn bei Aufbau einer IPsec-Verbindung die Verbindung zwischen den beteiligten Geräten per IKE ausgehandelt wird und dabei Zertifikate ausgetauscht werden. Es gibt Router, die nicht in der Lage sind, große UDP-Pakete weiterzuleiten, wenn diese auf dem Übertragungsweg (z. B. per DSL in 1500 Bytes große Stücke) fragmentiert worden sind. Manches defekte Gerät leitet dann nur das erste Fragment weiter, so dass dann die Verbindung fehlschlägt. Wenn zwei mGuard s miteinander kommunizieren, kann von vornherein dafür gesorgt werden, dass nur kleine UDP-Pakete ausgesandt werden. Damit wird verhindert, dass die Pakete unterwegs fragmentiert und damit möglicherweise von einigen Routern nicht korrekt weitergeleitet werden. Wenn Sie diese Option nutzen wollen, aktivieren Sie die Funktion. 
|
|
MTU für IPsec (Voreinstellung ist 16260) |
Die Option zur Vermeidung übergroßer IKE-Datenpakete, die von defekten Routern auf dem Übertragungsweg nicht korrekt weitergeleitet werden könnten, gibt es auch für IPsec-Datenpakete. Um unter der oft durch DSL gesetzten Obergrenze von 1500 Bytes zu bleiben, wird ein Wert von 1414 (Bytes) empfohlen, so dass auch für zusätzliche Header genügend Platz bleibt. Wenn Sie diese Option nutzen wollen, legen Sie einen niedrigeren Wert als die Voreinstellung fest. |
Erläuterung zu DynDNS siehe „DynDNS“ auf Seite 222.
Hostnamen von VPN-Gegenstellen überwachen |
Wenn der mGuard die Adresse einer VPN-Gegenstelle als Hostname hat (siehe „VPN-Verbindung / VPN-Verbindungstunnel neu definieren“ auf Seite 338) und dieser Hostname bei einem DynDNS-Service registriert ist, dann kann der mGuard regelmäßig überprüfen, ob beim betreffenden DynDNS eine Änderung erfolgt ist. Falls ja, wird die VPN-Verbindung zu der neuen IP-Adresse aufgebaut. |
|
|
Standard: 300 Sekunden |
|
Voraussetzungen für eine VPN-Verbindung
Generelle Voraussetzung für eine VPN-Verbindung ist, dass die IP-Adressen der VPN-Partner bekannt und zugänglich sind.
–Die mGuard s, die im Netzwerk-Modus Stealth ausgeliefert werden, sind auf die Stealth-Konfiguration „Mehrere Clients“ voreingestellt. In diesem Modus müssen Sie, wenn Sie VPN-Verbindungen nutzen wollen, eine Management IP-Adresse und ein Standard-Gateway konfigurieren (siehe „Standard-Gateway“ auf Seite 156). Alternativ können Sie eine andere Stealth-Konfiguration als „Mehrere Clients“ wählen oder einen anderen Netzwerk-Modus verwenden.
–Damit eine IPsec-Verbindung erfolgreich aufgebaut werden kann, muss die VPN-Gegenstelle IPsec mit folgender Konfiguration unterstützen:
–Authentifizierung über Pre-Shared Key (PSK) oder X.509-Zertifikate
–ESP
–Diffie-Hellman Gruppe (2, 5 und 14 – 18)
–DES-, 3DES- oder AES-Verschlüsselung
–MD5- und SHA-Hash-Algorithmen
–Tunnel- oder Transport-Modus
–XAuth und Mode Config
–Quick Mode
–Main Mode
–SA-Lebensdauer (1 Sekunde bis 24 Stunden)
Ist die Gegenstelle ein Rechner unter Windows 2000, muss dazu das Microsoft Windows 2000 High Encryption Pack oder mindestens das Service Pack 2 installiert sein.
–Befindet sich die Gegenstelle hinter einem NAT-Router, so muss die Gegenstelle NAT-Traversal (NAT-T) unterstützen. Oder aber der NAT-Router muss das IPsec-Protokoll kennen (IPsec/VPN-Passthrough). In beiden Fällen sind aus technischen Gründen nur IPsec Tunnelverbindungen möglich.
–Die Authentifizierung mittels „Pre Shared Key“ im Agressive Mode wird bei der Verwendung von „XAuth“/„Mode Config“ nicht unterstützt. Soll z. B. eine Verbindung vom iOS-oder Android-Client zum mGuard -Server hergestellt werden, muss die Authentifizierung via Zertifikat erfolgen.
Verschlüsselungs- und Hash-Algorithmen
Einige der zur Verfügung stehenden Algorithmen sind veraltet und werden nicht mehr als sicher angesehen. Sie sind deshalb nicht zu empfehlen. Aus Gründen der Abwärtskompatibilität können sie jedoch weiterhin im mGuard ausgewählt und verwendet werden.
ACHTUNG: Verwenden Sie sichere Verschlüsselungs- und Hash-Algorithmen (siehe „Verwendung sicherer Verschlüsselungs- und Hash-Algorithmen“ auf Seite 21). |
Liste aller VPN-Verbindungen, die definiert worden sind.
Jeder hier aufgeführte Verbindungsname kann eine einzige VPN-Verbindung oder eine Gruppe von VPN-Verbindungstunneln bezeichnen. Denn es gibt die Möglichkeit, unter den Transport- und/oder Tunneleinstellungen des betreffenden Eintrags mehrere Tunnel zu definieren.
Sie haben die Möglichkeit, neue VPN-Verbindungen zu definieren, VPN-Verbindungen zu aktivieren / deaktivieren, die Eigenschaften einer VPN-Verbindung oder -Verbindungsgruppe zu ändern (editieren) und Verbindungen zu löschen.
Lizenzstatus |
Lizenzierte Gegenstellen (IPsec) |
Anzahl der Gegenstellen, die aktuell eine VPN-Verbindung über das IPsec-Protokoll aufgebaut haben. |
|
Lizenzierte Gegenstellen (OpenVPN) |
Anzahl der Gegenstellen, zu denen aktuell eine VPN-Verbindung über das OpenVPN-Protokoll aufgebaut ist. |
Verbindungen |
Initialer Modus |
Deaktiviert / Gestoppt / Gestartet Die Einstellung „Deaktiviert“ deaktiviert die VPN-Verbindung permanent; sie kann weder gestartet noch gestoppt werden. Die Einstellungen „Gestartet“ und „Gestoppt“ bestimmen den Zustand der VPN-Verbindung nach einem Neustart/Booten des mGuard s (z. B. nach einer Unterbrechung der Stromversorgung). VPN-Verbindungen, die nicht deaktiviert sind, können über Icons in der Web-Oberfläche, SMS, Schalter, Taster, Datenverkehr oder das Skript nph-vpn.cgi gestartet oder gestoppt werden. |
|
Zustand |
Zeigt den aktuellen Aktivierungszustand der IPsec-VPN-Verbindung. |
|
ISAKMP-SA |
Zeigt an, ob die entsprechende ISAKMP-SA aufgebaut wurde oder nicht. |
|
IPsec-SA |
Zeigt an, wie viele der konfigurierten Tunnel aufgebaut sind. Die Anzahl der aufgebauten Tunnel kann höher als die Anzahl der konfigurierten Tunnel sein, wenn die Funktion „Tunnel-Gruppe“ genutzt wird. |
|
Name |
Name der VPN-Verbindung |
Verbindungen
VPN-Verbindung / VPN-Verbindungstunnel neu definieren
•In der Tabelle der
Verbindungen auf das Icon 
Neue
Zeile einfügen klicken, um eine neue Tabellenzeile hinzuzufügen.
•Auf auf das Icon 
Zeile bearbeiten klicken.
VPN-Verbindung / VPN-Verbindungstunnel bearbeiten
•In der gewünschten
Zeile auf das Icon 
Zeile
bearbeiten klicken.
URL für Starten, Stoppen, Statusabfrage einer VPN-Verbindung
Die folgende URL kann verwendet werden, um VPN-Verbindungen, die sich im initialen Modus „Gestartet“ oder „Gestoppt“ befinden, zu starten, zu stoppen oder deren Verbindungsstatus abzufragen:
Beispiel (nur mGuard -Firmwareversionen < 8.4.0)
https://server/nph-vpn.cgi?name=verbindung&cmd=(up|down|status)
wget --no-check-certificate "https://admin:mGuard@192.168.1.1/nph-vpn.cgi?name=Athen&cmd=up"
Die Verwendung des Kommandozeilen-Tools
wget funktioniert nur
im Zusammenspiel mit mGuard -Firmwareversionen < 8.4.0.
Ab mGuard -Firmwareversion 8.4.0 kann das
Kommandozeilen-Tool curl
verwendet werden (Parameter und Optionen abweichend!). |
Das Admin-Passwort und der Name, auf den sich eine Aktion bezieht, dürfen ausschließlich folgende Zeichen enthalten: –Buchstaben: A – Z, a – z –Ziffern: 0 – 9 –Zeichen: - . _ ~
Andere Sonderzeichen, z. B. das Leerzeichen oder das Fragezeichen, müssen entsprechend codiert werden (siehe „Codierung von Sonderzeichen (URL encoding)“ auf Seite 475). |
Die Option --no-check-certificate (wget) bzw. --insecure (curl) sorgt dafür, dass das HTTPS-Zertifikat des mGuard s nicht weiter geprüft wird.
Ein solches Kommando bezieht sich auf alle Verbindungstunnel, die unter dem betreffenden Namen, in diesem Beispiel Athen, zusammengefasst sind. Das ist der Name, der unter IPsec VPN >> Verbindungen >> Editieren >> Allgemein als „Ein beschreibender Name für die Verbindung“ aufgeführt ist. Sofern Mehrdeutigkeit besteht, wirkt der Aufruf des URL nur auf den ersten Eintrag in der Liste der Verbindungen.
Ein Ansprechen einzelner Tunnel einer VPN-Verbindung ist nicht möglich. Wenn einzelne Tunnel deaktiviert sind, werden diese nicht gestartet. Damit hat das Starten und Stoppen auf diesem Wege keine Auswirkung auf die Einstellungen zu den einzelnen Tunneln (siehe „Transport- und Tunneleinstellungen“ auf Seite 349).
Wenn durch Verwendung der oben angegeben URL der Status einer VPN-Verbindung abgefragt wird, können folgende Antworten erwartet werden:
Bedeutung |
|
|---|---|
unknown |
Eine VPN-Verbindung mit dem Namen existiert nicht. |
void |
Die Verbindung ist aufgrund eines Fehlers inaktiv, zum Beispiel weil das externe Netzwerk gestört ist oder weil der Hostname der Gegenstelle nicht in eine IP-Adresse aufgelöst werden konnte (DNS). Die Antwort "void" wird von der CGI-Schnittstelle auch herausgegeben, ohne dass ein Fehler vorliegt. Zum Beispiel, wenn die VPN-Verbindung entsprechend der Konfiguration deaktiviert ist (Spalte auf Nein) und nicht vorübergehend mit Hilfe der CGI-Schnittstelle oder des CMD-Kontaktes freigeschaltet worden ist. |
ready |
Die Verbindung ist bereit, selbst Tunnel aufzubauen oder hereinkommende Anfragen zum Tunnelaufbau zu erlauben. |
active |
Zu der Verbindung ist mindestens ein Tunnel auch wirklich aufgebaut. |
VPN-Verbindung / VPN-Verbindungstunnel definieren
Nach Klicken auf das Icon 
Zeile bearbeiten erscheint je nach
Netzwerk-Modus des mGuard s folgende Seite.
Optionen |
Sie können die Verbindung frei benennen bzw. umbenennen. Werden weiter unten unter mehrere Verbindungstunnel definiert, benennt dieser Name das gesamte Set der VPN-Verbindungstunnel, die unter diesem Namen zusammengefasst sind. Gemeinsamkeiten bei VPN-Verbindungstunneln: –gleiches Authentifizierungsverfahren, festgelegt auf der Registerkarte Authentifizierung (siehe „Authentifizierung“ auf Seite 358) –gleiche Firewall-Einstellungen –gleiche Einstellung der IKE-Optionen. |
|
|
Initialer Modus |
Deaktiviert / Gestoppt / Gestartet Die Einstellung „Deaktiviert“ deaktiviert die VPN-Verbindung permanent; sie kann weder gestartet noch gestoppt werden. Die Einstellungen „Gestartet“ und „Gestoppt“ bestimmen den Status der VPN-Verbindung nach einem Neustart/Booten des mGuard s (z. B. nach einer Unterbrechung der Stromversorgung). VPN-Verbindungen, die nicht deaktiviert sind, können über Icons in der Web-Oberfläche, SMS, Schalter, Taster, Datenverkehr oder das Skript nph-vpn.cgi gestartet oder gestoppt werden. |
|
Eine IP-Adresse, ein Hostname oder %any für beliebige, mehrere Gegenstellen oder Gegenstellen hinter einem NAT-Router |
|
Adresse des VPN-Gateways der Gegenstelle
Bild 10-2: Die Adresse des Übergangs zum privaten Netz, in dem sich der entfernte Kommunikationspartner befindet.
–Falls der mGuard aktiv die Verbindung zur entfernten Gegenstelle initiieren und aufbauen soll, dann geben Sie hier die IP-Adresse oder den Hostnamen der Gegenstellen an.
–Falls das VPN-Gateway der Gegenstelle keine feste und bekannte IP-Adresse hat, kann über die Inanspruchname des DynDNS-Service (siehe Glossar) dennoch eine feste und bekannte Adresse simuliert werden.
–Falls der mGuard bereit sein soll, die Verbindung anzunehmen, die eine entfernte Gegenstelle mit beliebiger IP-Adresse aktiv zum lokalen mGuard initiiert und aufbaut, dann geben Sie an: %any
Diese Einstellung ist auch bei einer VPN-Sternkonfiguration zu wählen, wenn der mGuard an der Zentrale angeschlossen ist.
So kann eine entfernte Gegenstelle den mGuard „anrufen“, wenn diese Gegenstelle ihre eigene IP-Adresse (vom Internet Service Provider) dynamisch zugewiesen erhält, d. h. eine wechselnde IP-Adresse hat. Nur wenn in diesem Szenario die entfernte „anrufende“ Gegenstelle auch eine feste und bekannte IP-Adresse hat, können Sie diese IP-Adresse angeben.
%any kann nur zusammen mit dem Authentisierungsverfahren über X.509-Zertifikate verwendet werden. |
Wenn die Gegenstelle mit Hilfe von lokal hinterlegten CA-Zertifikaten authentifiziert werden soll, kann die Adresse des VPN-Gateway der Gegenstelle konkret (durch IP-Adresse oder Hostname) oder durch %any angegeben werden. Wird sie durch eine konkrete Adresse angegeben (und nicht durch „%any“), dann muss ein VPN-Identifier (siehe „VPN-Identifier“ auf Seite 361) spezifiziert werden. |
Wenn sich die Gegenstelle hinter einem NAT-Gateway befindet, muss %any gewählt werden. Ansonsten wird das Aushandeln weiterer Verbindungsschlüssel nach der ersten Kontaktaufnahme fehlschlagen. |
Bei Einsatz von TCP-Kapselung (siehe „TCP-Kapselung“ auf Seite 331): Es muss eine feste IP-Adresse oder ein Hostname angegeben werden, wenn dieser mGuard die VPN-Verbindung initiieren und den VPN-Datenverkehr einkapseln soll. Ist dieser mGuard einer Wartungszentrale vorgeschaltet, zu der mehrere entfernte mGuard s VPN-Verbindungen herstellen und eingekapselte Datenpakete senden, muss das VPN-Gateway der Gegenstelle mit %any angegeben werden. |
.
Optionen |
Adresse des VPN-Gateways der Gegenstelle |
IP-Adresse, Hostname oder '%any' für beliebige IP-Adressen, mehrere Gegenstellen oder Gegenstellen hinter einem NAT-Router. |
|
Interface, das bei der Einstellung %any für das Gateway benutzt wird (Wenn bei „Adresse des VPN-Gateways der Gegenstelle“ %any angegeben wurde) |
Intern, Extern, Extern 2, Einwahl, DMZ, Implizit ausgewählt durch die rechts angegebene IP-Adresse Extern 2 und Einwahl nur bei Geräten mit serieller Schnittstelle, siehe „Netzwerk >> Interfaces“ auf Seite 137. Die Auswahl von Intern ist im Stealth-Modus nicht erlaubt. Die Einstellung des Interfaces wird nur beachtet, wenn als Adresse des VPN-Gateways der Gegenstelle „%any“ eingetragen ist. In diesem Fall wird hier das Interface des mGuard s eingestellt, über das er Anfragen zum Aufbau dieser VPN-Verbindung beantwortet und erlaubt. Bei allen Stealth-Modi gilt, wenn Extern ausgewählt ist, kann die VPN-Verbindung sowohl über den LAN- als auch den WAN-Port aufgebaut werden. Die Einstellung des Interfaces ermöglicht es für VPN-Gegenstellen ohne bekannte IP-Adresse die verschlüsselte Kommunikation über ein konkretes Interface zu führen. Falls eine IP-Adresse oder ein Hostname für die Gegenstelle angegeben sind, wird die Zuordnung zu einem Interface implizit daraus ermittelt. Über Auswahl von Intern kann der mGuard im Router-Modus als „Einbein-Router“ eingesetzt werden, weil dann der entschlüsselte wie auch der verschlüsselte VPN-Verkehr dieser VPN-Verbindung über das interne Interface geführt wird. IKE- und IPsec-Datenverkehr ist immer nur über die primäre IP-Adresse der jeweils zugeordneten Schnittstelle möglich. Dies gilt auch für VPN-Verbindungen mit konkreter Gegenstelle. |
|
|
Die Auswahl von DMZ ist nur im Router-Modus möglich. Hierbei können VPN-Verbindungen zu Hosts in der DMZ aufgebaut werden sowie IP-Pakete aus der DMZ in eine VPN-Verbindung geroutet werden. Implizit ausgewählt durch die unten angegebene IP-Adresse: Hierbei wird statt eines dedizierten Interface eine IP-Adresse verwendet. |
|
IP-Adresse, die bei der Einstellung %any für das Gateway benutzt wird |
IP-Adresse, die bei der Einstellung %any für das Gateway benutzt wird. |
|
Initiiere / Initiiere bei Datenverkehr / Warte Initiiere In diesem Fall initiiert der mGuard die Verbindung zur Gegenstelle. Im Feld Adresse des VPN-Gateways der Gegenstelle (s. o.) muss die feste IP-Adresse der Gegenstelle oder deren Name eingetragen sein. Initiiere bei Datenverkehr Die Verbindung wird automatisch initiiert, wenn der mGuard bemerkt, dass die Verbindung genutzt werden soll. (Ist bei jeder Betriebsart des mGuard s (Stealth, Router usw.) wählbar.) 
Warte In diesem Fall ist der mGuard bereit, die Verbindung anzunehmen, die eine entfernte Gegenstelle aktiv zum mGuard initiiert und aufbaut. 
|
|
|
Schaltender Service Eingang/CMD (Nur verfügbar beim TC MGUARD RS4000/RS2000 3G , TC MGUARD RS4000/RS2000 4G , FL MGUARD RS4000/RS2000 , FL MGUARD GT/GT , FL MGUARD RS4004/RS2005 , FL MGUARD RS .) |
Kein / Service-Eingang CMD 1-3 Die VPN-Verbindung kann über einen angeschlossenen Taster/Schalter geschaltet werden. Der Taster/Schalter muss an einen der Servicekontakte (CMD 1-3) angeschlossen sein. 
|
|
Invertierte Logik verwenden |
Kehrt das Verhalten des angeschlossenen Schalters um. Wenn der schaltende Service-Eingang als Ein-/Aus-Schalter konfiguriert ist, kann er z. B. eine VPN-Verbindung ein- und gleichzeitig eine andere, die invertierte Logik verwendet, ausschalten. |
|
Timeout zur Deaktivierung |
Zeit, nach der die VPN-Verbindung gestoppt wird, wenn sie über SMS, Schalter, Taster, nph-vpn.cgi oder die Web-Oberfläche gestartet worden ist. Der Timeout startet beim Übergang in den Zustand „Gestartet“. Die Verbindung verbleibt nach Ablauf des Timeouts in dem Zustand „Gestoppt“, bis sie erneut gestartet wird. Ausnahme „Initiierung durch Datenverkehr“ Eine durch Datenverkehr initiierte (aufgebaute) Verbindung wird nach Ablauf des Timeouts abgebaut, verbleibt aber in dem Zustand „Gestartet“. Der Timeout startet erst, wenn kein Datenverkehr mehr stattfindet. Die Verbindung wird bei erneut auftretendem Datenverkehr wieder aufgebaut. Zeit in Stunden, Minuten und/oder Sekunden (0:00:00 bis 720:00:00, etwa 1 Monate). Die Eingabe kann aus Sekunden [ss], Minuten und Sekunden [mm:ss] oder Stunden, Minuten und Sekunden [hh:mm:ss] bestehen. Bei 0 ist diese Einstellung abgeschaltet. |
|
(Nur verfügbar beim TC MGUARD RS4000/RS2000 3G , TC MGUARD RS4000/RS2000 4G .) |
Eingehende SMS können dazu benutzt werden, VPN-Verbindungen zu initiieren (start) oder zu beenden (stop). Die SMS muss das Kommando „vpn/start“ bzw. „vpn/stop“ gefolgt von dem Token enthalten. |
|
Kapsele den VPN-Datenverkehr in TCP ein |
Nein / TCP-Kapselung / Path Finder (Standard: Nein) Bei Anwendung der Funktion TCP-Kapselung (siehe „TCP-Kapselung“ auf Seite 331) diesen Schalter nur dann auf TCP-Kapselung setzen, wenn der mGuard bei der von ihm initiierten VPN-Verbindung den von ihm ausgehenden Datenverkehr einkapseln soll. In diesem Fall muss auch die Nummer des Ports angegeben werden, über den die Gegenstelle die eingekapselten Datenpakete empfängt. TPC-Kapselung kann ebenfalls mit der Funktion „Path Finder“ (siehe „TCP-Kapselung mit aktivierter Funktion „Path Finder““ auf Seite 332) verwendet werden. In diesem Fall den Schalter nur dann auf Path Finder setzen, wenn die Gegenstelle die Funktion „Path Finder“ ebenfalls unterstützt. Anschließend muss auch die Nummer des Ports angegeben werden, über den die Gegenstelle die eingekapselten Datenpakete empfängt. Bei TCP-Kapselung / Path Finder wird der mGuard nicht versuchen, die VPN-Verbindung über die Standard IKE-Verschlüsselung (UDP-Port 500 und 4500) herzustellen, sondern sie immer über das TCP-Protokoll verschicken. Einstellung der Verbindungsinitiierung bei Verwendung von TCP-Kapselung / Path Finder. –Wenn der mGuard eine VPN-Verbindung zu einer Wartungszentrale aufbauen und den Datenverkehr dorthin einkapseln soll: –Es muss „Initiiere“ oder „Initiiere bei Datenverkehr“ festgelegt werden. –Wenn der mGuard bei einer Wartungszentrale installiert ist, zu der mGuard s eine VPN-Verbindung aufbauen: –Es muss „Warte“ festgelegt werden. |
|
TCP-Port des Servers, welcher die gekapselte Verbindung annimmt (Nur sichtbar, wenn „Kapsele den VPN-Datenverkehr in TCP ein“ auf TCP-Kapselung oder Path Finder steht.) |
Standard: 8080 Nummer des Ports, über den die Gegenstelle die eingekapselten Datenpakete empfängt. Die hier angegebene Port-Nummer muss mit der Port-Nummer übereinstimmen, die beim mGuard der Gegenstelle als TCP-Port, auf dem zu horchen ist festgelegt ist (Menüpunkt IPsec VPN >> Global >> Optionen). |
Der mGuard unterstützt die Authentifizierungsmethode „Extended Authentication“ (XAuth) und die häufig erforderliche Protokollerweiterung „Mode Config“ inklusive „Split Tunneling“ als Server und als Client (u. a. iOS- und Android-Unterstützung). Netzwerkeinstellungen, DNS- und WINS-Konfigurationen werden dem IPsec-Client vom IPsec-Server mitgeteilt. |
||
|
Mode Configuration |
Aus / Server / Client (Standard: Aus) Um als Server oder Client über eine IPsec-VPN-Verbindungen mit Gegenstellen zu kommunizieren, die „XAuth“ und „Mode Config“ benötigen, wählen Sie „Server“ oder „Client“ aus. Aus: Kein „Mode Config“ verwenden. Server: Der Gegenstelle die IPsec-Netzwerkkonfiguration mitteilen. Client: Die von der Gegenstelle mitgeteilte IPsec-Netzwerkkonfiguration übernehmen und anwenden. 
|
|
Einstellungen als Server Ermöglicht Clients, die „XAuth“ und „Mode Config“ benötigen (z. B. Apple iPad), eine IPsec-VPN-Verbindung zum mGuard aufzubauen. Die benötigten Werte zur Konfiguration der Verbindung (lokales und entferntes Netz) erhalten die Remote-Clients vom mGuard . 
|
|
|
||
|
Lokal |
Fest / Aus der unten stehenden Tabelle Fest: Das lokale Netz auf der Server-Seite wird manuell fest eingestellt und muss auf der Client-Seite (beim Remote-Client) ebenfalls manuell eingestellt werden. Aus der unten stehenden Tabelle: Das oder die lokalen Netze der Server-Seite werden dem Remote-Client über die Split-Tunneling-Erweiterung mitgeteilt. Eingabe in CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30). |
|
Lokales IP-Netzwerk (Wenn „Fest “ ausgewählt wurde) |
Lokales Netzwerk auf der Server-Seite in CIDR-Schreibweise. |
|
Netzwerke (Wenn „Aus der unten stehenden Tabelle“ ausgewählt wurde) |
Lokale Netzwerke auf der Server-Seite in CIDR-Schreibweise. |
|
Gegenstelle |
Aus dem unten stehenden Pool / Aus der unten stehenden Tabelle Aus dem unten stehenden Pool Der Server wählt dynamisch IP-Netzwerke für die Gegenstelle aus dem angegebenen Pool, entsprechend der ausgewählten Abschnittsgröße. Aus der unten stehenden Tabelle (Diese Funktion kann nur verwendet werden, wenn auf der Gegenstelle ein mGuard eingesetzt wird.) Die IP-Netzwerke der Gegenstelle werden dem Remote-Client über die Split-Tunneling-Erweiterung mitgeteilt. |
|
IP-Netzwerk-Pool der Gegenstelle (Wenn „Aus diesem Pool“ ausgewählt wurde) |
Netzwerk-Pool, aus dem IP-Netzwerke für die Gegenstelle ausgewählt werden, in CIDR-Schreibweise. |
|
Abschnittsgröße (Netzwerkgröße zwischen 0 und 32) (Wenn „Aus diesem Pool“ ausgewählt wurde) |
Abschnittsgröße, die die Größe der IP-Netzwerke bestimmt, die aus dem Netzwerk-Pool für die Gegenstelle entnommen werden können. |
|
Netzwerke (Wenn „Aus der unten stehenden Tabelle“ ausgewählt wurde) |
IP-Netzwerke für die Gegenstelle in CIDR-Schreibweise. |
|
1. und 2. DNS-Server für die Gegenstelle |
Adresse eines DNS-Servers, die der Gegenstelle mitgeteilt wird. Die Einstellung 0.0.0.0 bedeutet „keine Adresse“. |
|
1. und 2. WINS-Server für die Gegenstelle |
Adresse eines WINS-Servers, die der Gegenstelle mitgeteilt wird. Die Einstellung 0.0.0.0 bedeutet „keine Adresse“. |
|
Einstellungen als Client Ermöglicht dem mGuard , eine IPsec-VPN-Verbindung zu Servern aufzubauen, die „XAuth“ und „Mode Config“ benötigen. Die benötigten Werte (IP-Adresse/IP-Netzwerk) zur Konfiguration der Verbindung (lokales und entferntes Netz) erhält der mGuard optional vom Remote-Server der Gegenstelle. |
|
|
||
|
Lokales NAT (Nicht aktiv im Stealth-Modus „Automatisch“ und „Statisch“)
|
Kein NAT / Maskieren Kein NAT Vom Server ausgewählte lokale IP-Adressen können den Tunnel nutzen. Maskieren Der mGuard kann sein lokales Netz maskieren. Dazu muss das lokale Netz in CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30) angegeben werden. |
|
Lokales IP-Netzwerk |
IP-Netzwerk am lokalen Interface des Clients, das maskiert wird. |
|
Gegenstelle |
Fest / Vom Server Fest: Das lokale Netz auf der Client-Seite wird manuell fest eingestellt und muss auf der Server-Seite (beim Remote-Server) ebenfalls manuell eingestellt werden. Vom Server: Das oder die Remote-Netzwerke der Server-Seite werden dem lokalen Client über die Split-Tunneling-Erweiterung mitgeteilt. Verwendet der Remote-Server kein „Split Tunneling“, wird 0.0.0.0/0 verwendet. |
|
IP-Netzwerk der Gegenstelle (Wenn „Fest“ ausgewählt wurde) |
Das Netzwerk des Remote-Servers in CIDR-Schreibweise. |
|
XAuth-Login |
Manche Remote-Server benötigen zur Authentifizierung des Clients einen XAuth-Benutzernamen (Login) und ein XAuth-Passwort. |
|
XAuth-Passwort |
Zugehöriges XAuth-Passwort |
|
||
|
||
|
Aktiv |
Legen Sie fest, ob der Verbindungstunnel aktiv sein soll oder nicht. |
|
Kommentar |
Frei einzugebender kommentierender Text. Kann leer bleiben. |
|
Typ |
Es stehen zur Auswahl: –Tunnel (Netz ↔ Netz) –Transport (Host ↔ Host) Tunnel (Netz ↔ Netz) Dieser Verbindungstyp eignet sich in jedem Fall und ist der sicherste. In diesem Modus werden die zu übertragenen IP-Datagramme vollkommen verschlüsselt und mit einem neuen Header versehen zum VPN-Gateway der Gegenstelle, dem „Tunnelende“, gesendet. Dort werden die übertragenen Datagramme entschlüsselt und aus ihnen die ursprünglichen Datagramme wiederhergestellt. Diese werden dann zum Zielrechner weitergeleitet. 
Transport (Host ↔ Host) Bei diesem Verbindungstyp werden nur die Daten der IP-Pakete verschlüsselt. Die IP-Header-Informationen bleiben unverschlüsselt. Bei Wechsel auf Transport werden die nachfolgenden Felder (bis auf Protokoll) ausgeblendet, weil diese Parameter entfallen. |
|
Lokal (Bei Verbindungstyp „Tunnel“) |
Unter Lokal und Gegenstelle definieren Sie die Netzwerkbereiche für beide Tunnelenden. Lokal: Hier geben Sie die Adresse des Netzes oder Computers an, das/der lokal am mGuard angeschlossen ist. |
|
(Bei Verbindungstyp „Tunnel“ (Netz ↔ Netz)) |
Gegenstelle: Hier geben Sie die Adresse des Netzes oder Computers an, das/der sich hinter dem Remote-VPN-Gateway befindet. |
|
Lokales NAT (Bei Verbindungstyp „Tunnel“) |
Kein NAT / 1:1-NAT / Maskieren Es können die IP-Adressen von Geräten umgeschrieben werden, die sich am jeweiligen Ende des VPN-Tunnels befinden. Kein NAT: Es wird kein NAT vorgenommen. Bei 1:1-NAT werden die IP-Adressen von Geräten am lokalen Ende des Tunnels so ausgetauscht, dass jede einzelne gegen eine bestimmte andere umgeschrieben wird. 
Beim Maskieren werden die IP-Adressen von Geräten am lokalen Ende des Tunnels gegen eine für alle Geräte identische IP-Adresse ausgetauscht. |
|
Remote-NAT (Bei Verbindungstyp „Tunnel“) |
Kein NAT / 1:1-NAT / Maskieren Kein NAT: Es wird kein NAT vorgenommen. Bei 1:1-NAT werden die IP-Adressen von Geräten der Gegenstelle des Tunnels so ausgetauscht, dass jede einzelne gegen eine bestimmte andere umgeschrieben wird. Beim Maskieren werden die IP-Adressen von Geräten der Gegenstelle gegen eine für alle Geräte identische IP-Adresse ausgetauscht. |
|
|
|
|
Um
weitere Einstellungen vorzunehmen, klicken Sie auf das Icon |
|
|
||
Transport- und Tunneleinstellungen (Editieren) |
||
Optionen |
Aktiv |
Legen Sie fest, ob der Verbindungstunnel aktiv sein soll oder nicht. |
|
Kommentar |
Frei einzugebender kommentierender Text. Kann leer bleiben. |
|
Typ |
Es stehen zur Auswahl: –Tunnel (Netz ↔ Netz) –Transport (Host ↔ Host) Tunnel (Netz ↔ Netz) Dieser Verbindungstyp eignet sich in jedem Fall und ist der sicherste. In diesem Modus werden die zu übertragenen IP-Datagramme vollkommen verschlüsselt und mit einem neuen Header versehen zum VPN-Gateway der Gegenstelle, dem „Tunnelende“, gesendet. Dort werden die übertragenen Datagramme entschlüsselt und aus ihnen die ursprünglichen Datagramme wiederhergestellt. Diese werden dann zum Zielrechner weitergeleitet. 
Transport (Host ↔ Host) Bei diesem Verbindungstyp werden nur die Daten der IP-Pakete verschlüsselt. Die IP-Header-Informationen bleiben unverschlüsselt. Bei Wechsel auf Transport werden die nachfolgenden Felder (bis auf Protokoll) ausgeblendet, weil diese Parameter entfallen. |
|
Lokal (Bei Verbindungstyp „Tunnel“) |
Unter Lokal und Gegenstelle definieren Sie die Netzwerkbereiche für beide Tunnelenden. Lokal: Hier geben Sie die Adresse des Netzes oder Computers an, das/der lokal am mGuard angeschlossen ist. |
|
(Bei Verbindungstyp „Tunnel“) |
Gegenstelle: Hier geben Sie die Adresse des Netzes oder Computers an, das/der sich hinter dem Remote-VPN-Gateway befindet. |
Lokales NAT |
Lokales NAT für IPsec-Tunnelverbindungen (Bei Verbindungstyp „Tunnel“) |
Kein NAT / 1:1-NAT / Maskieren Es können die IP-Adressen von Geräten umgeschrieben werden, die sich am jeweiligen Ende des VPN-Tunnels befinden. Kein NAT: Es wird kein NAT vorgenommen. Bei 1:1-NAT werden die IP-Adressen von Geräten am lokalen Ende des Tunnels so ausgetauscht, dass jede einzelne gegen eine bestimmte andere umgeschrieben wird. Beim Maskieren werden die IP-Adressen von Geräten am lokalen Ende des Tunnels gegen eine für alle Geräte identische IP-Adresse ausgetauscht. |
|
|
Wenn lokale Geräte Datenpakete senden, kommen nur solche in Betracht, –die der mGuard tatsächlich verschlüsselt (vom mGuard werden nur Pakete durch den VPN-Tunnel weitergeleitet, wenn sie aus einer vertrauenswürdigen Quelle stammen). –die ihren Ursprung in einer Quelladresse innerhalb des Netzwerkes haben, das hier definiert wird. –deren Zieladresse im Netzwerk der Gegenstelle liegt, wenn dort kein 1:1-NAT für die Gegenstelle eingestellt ist. Die Datenpakete von lokalen Geräten bekommen eine Quelladresse entsprechend der eingestellten Adresse unter Lokal zugewiesen und werden durch den VPN-Tunnel gesendet. |
|
|
Sie können für lokale Geräte 1:1-NAT-Regeln für jeden VPN-Tunnel festlegen. So kann ein IP-Bereich, der über eine weites Netzwerk verstreut ist, gesammelt und durch einen schmalen Tunnel geschickt werden. |
|
|
|
|
||
|
Reales Netzwerk |
Konfiguriert die „von IP“-Adresse für 1:1-NAT. |
|
Virtuelles Netzwerk |
Konfiguriert die umgeschriebene IP-Adresse für 1:1-NAT. |
|
Netzmaske |
Die Netzmaske als Wert zwischen 1 und 32 für die reale und virtuelle Netzwerkadresse (siehe auch „CIDR (Classless Inter-Domain Routing)“ auf Seite 30). |
|
Kommentar |
Kann mit kommentierendem Text gefüllt werden. |
|
Interne Netzwerkadresse für lokales Maskieren (Bei Auswahl „Maskieren“) |
Wenn lokale Geräte Datenpakete senden, kommen nur solche in Betracht, –die der mGuard tatsächlich verschlüsselt (vom mGuard werden nur Pakete durch den VPN-Tunnel weitergeleitet, wenn sie aus einer vertrauenswürdigen Quelle stammen). –die ihren Ursprung in einer Quelladresse innerhalb des Netzwerkes haben, das hier definiert wird. –deren Zieladresse im Netzwerk Gegenstelle liegt, wenn kein 1:1-NAT für das Gegenstelle-NAT eingestellt ist. |
|
|
In dieser Einstellung ist als VPN-Netzwerk nur eine IP-Adresse (Subnetzmaske /32) zugelassen. Das zu maskierende Netzwerk wird auf diese IP-Adresse umgeschrieben. Danach werden die Datenpakete durch den VPN-Tunnel gesendet. Das Maskieren ändert die Quelladresse (und den Quell-Port). Die ursprünglichen Adressen werden in einem Eintrag der Conntrack-Tabelle aufgezeichnet. Antwort-Pakete, die durch den VPN-Tunnel empfangen werden und zu einem Eintrag der Conntrack-Tabelle passen, bekommen ihre Zieladresse (und ihren Ziel-Port) zurückgeschrieben. |
Remote-NAT |
Remote-NAT für IPsec-Tunnelverbindungen (Bei Verbindungstyp „Tunnel“) |
Kein NAT / 1:1-NAT / Maskieren Es können die IP-Adressen von Geräten umgeschrieben werden, die sich am jeweiligen Ende des VPN-Tunnels befinden. Bei Remote-1:1-NAT werden die IP-Adressen von Geräten der Gegenstelle des Tunnels so ausgetauscht, dass jede einzelne gegen eine bestimmte andere umgeschrieben wird. Beim Maskieren des Netzwerks der Gegenstelle werden die IP-Adressen von Geräten der Gegenstelle gegen eine für alle Geräte identische IP-Adresse ausgetauscht. |
|
Netzwerkadresse für 1:1-NAT im Remote-Netz (Bei Auswahl „1:1-NAT“) |
Wenn lokale Geräte Datenpakete senden, kommen nur solche in Betracht, –die der mGuard tatsächlich verschlüsselt (vom mGuard werden nur Pakete durch den VPN-Tunnel weitergeleitet, wenn sie aus einer vertrauenswürdigen Quelle stammen). –deren Quelladresse innerhalb des Netzwerkes liegt, das hier unter Lokal definiert wird. Die Datenpakete bekommen eine Zieladresse aus dem Netzwerk, das unter Gegenstelle eingestellt ist. Wenn nötig, wird auch die Quelladresse ersetzt (siehe Lokal). Danach werden die Datenpakete durch den VPN-Tunnel gesendet. |
|
Interne IP-Adresse zur Maskierung des Remote-Netzwerks (Bei Auswahl „Maskieren“) |
In dieser Einstellung ist als VPN-Netzwerk nur eine IP-Adresse (Subnetzmaske /32) zugelassen. Das zu maskierende Netzwerk wird auf diese IP-Adresse umgeschrieben. |
|
|
Danach werden die Datenpakete durch den VPN-Tunnel gesendet. Das Maskieren ändert die Quelladresse (und den Quell-Port). Die ursprünglichen Adressen werden in einem Eintrag der Conntrack-Tabelle aufgezeichnet. Antwort-Pakete, die durch den VPN-Tunnel empfangen werden und zu einem Eintrag der Conntrack-Tabelle passen, bekommen ihre Zieladresse (und ihren Ziel-Port) zurückgeschrieben. |
Protokoll |
Protokoll |
Alle bedeutet: TCP, UDP, ICMP und andere IP-Protokolle Lokaler Port (nur bei TCP / UDP): Nummer des zu verwendenden Ports. Wählen Sie „%all“ für alle Ports, eine Nummer zwischen 1 und 65535 oder „%any“, um den Vorschlag dem Client zu überlassen. Remote-Port (nur bei TCP / UDP): Nummer des zu verwendenden Ports. Wählen Sie „%all“ für alle Ports, eine Nummer zwischen 1 und 65535 oder „%any“, um den Vorschlag dem Client zu überlassen. |
Dynamisches Routing |
Füge Kernel-Route zum Remote-Netz hinzu, um die Weiterverbreitung durch OSPF zu ermöglichen (Nur wenn OSPF aktiviert ist) |
Bei aktivierter Funktion wird eine Kernel-Route zum Remote-Netz (Gegenstelle) hinzugefügt, um die Weiterverbreitung durch OSPF zu ermöglichen. |
Einstellung für Tunneleinstellung IPsec/L2TP
Wenn sich Clients per IPsec/L2TP über den mGuard verbinden sollen, dann aktivieren Sie den L2TP-Server und machen in den nachfolgend aufgelisteten Feldern die jeweils dahinter stehenden Angaben:
–Typ: Transport
–Protokoll: UDP
–Lokal: %all
–Gegenstelle: %all
–PFS: Nein („Perfect Forward Secrecy (PFS)“ auf Seite 372)
Festlegung einer Standard-Route über das VPN
Die Adresse 0.0.0.0/0 gibt eine Standard-Route über das VPN an.
Bei dieser Adresse wird sämtlicher Datenverkehr, für den keine anderen Tunnel oder Routen existieren, durch diesen VPN-Tunnel geleitet.
Eine Standard-Route über das VPN sollte nur für einen einzigen Tunnel angegeben werden.
Im Stealth-Modus kann eine Standard-Route über das VPN nicht verwendet werden. |
Option Tunnelgruppen
Das VPN-Lizenz-Modell (seit mGuard Firmwareversion 8.3) erlaubt es, mit allen VPN-Lizenzen Tunnelgruppen zu erstellen.
Die Lizenz begrenzt nun nicht mehr die Anzahl der aufgebauten Tunnel, sondern die Anzahl der verbundenen Gegenstellen (VPN-Peers). Werden zu einer Gegenstelle mehrere Tunnel aufgebaut, wird nur eine Gegenstelle gezählt, was eine Verbesserung zum alten Modell darstellt.
Wird als Adresse des VPN-Gateway der Gegenstelle %any angegeben, können sich auf der entfernten Seite viele mGuard s bzw. viele Netzwerke befinden.
Dann wird beim lokalen mGuard im Feld Gegenstelle ein sehr großer Adressenbereich festgelegt, und bei den entfernten mGuard s wird jeweils für das bei ihnen unter Lokal angegebene Netz ein Teil dieses Adressenbereichs verwendet.
Um das zu illustrieren: Die Angaben in den Feldern Lokal und Gegenstelle beim lokalen und bei entfernten mGuard s könnten zum Beispiel wie folgt lauten:
Lokaler mGuard |
|
|
Entfernter mGuard A |
|
Lokal |
Gegenstelle |
|
Lokal |
Gegenstelle |
10.0.0.0/8 |
10.0.0.0/8 |
> |
10.1.7.0/24 |
10.0.0.0/8 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Entfernter mGuard B |
|
|
|
|
Lokal |
Gegenstelle |
|
|
> |
10.3.9.0/24 |
10.0.0.0/8 |
|
|
|
|
|
|
|
|
usw. |
|
Auf diese Weise kann durch die Konfiguration eines einzigen Tunnels der Verbindungsaufbau durch viele Stellen gewährt werden.
Maskieren
Kann nur für VPN-Typ Tunnel verwendet werden. |
Beispiel
Eine Zentrale unterhält zu sehr vielen Zweigstellen jeweils einen VPN-Tunnel. In den Zweigstellen ist jeweils ein lokales Netzwerk mit zahlreichen Rechnern installiert, die über den jeweiligen VPN-Tunnel mit der Zentrale verbunden sind. In diesem Fall könnte der Adressraum zu klein sein, um die Rechner an den verschiedenen VPN-Tunnelenden insgesamt darin unterzubringen.
Maskieren schafft hier Abhilfe:
Die im Netzwerk einer Zweigstelle angeschlossenen Rechner treten durch das Maskieren für das VPN-Gateway der Zentrale unter einer einzigen IP-Adresse in Erscheinung. Außerdem wird ermöglicht, dass die lokalen Netzwerke in den unterschiedlichen Zweigstellen lokal jeweils die selben Netzwerkadresse benutzen. Nur die Zweigstelle kann VPN-Verbindungen zur Zentrale aufbauen.
Netzwerkadresse für das Maskieren
Sie geben den IP-Adressenbereich an, für den das Maskieren angewendet wird.
Nur wenn ein Rechner eine IP-Adresse aus diesem Bereich hat, wird in den Datenpaketen, die dieser Rechner über die VPN-Verbindung aussendet, die Absenderadresse gegen die ausgetauscht, die im Feld Lokal angegeben ist (siehe oben).
Die im Feld Lokal angegebene Adresse muss die Netzmaske /32 haben, damit es sich um genau eine IP-Adresse handelt.
Maskieren kann in folgenden Netzwerk-Modi verwendet werden: Router, PPPoE, PPTP, Modem, Eingebautes Modem, Eingebautes Mobilfunkmodem und Stealth (nur Stealth-Modus „Mehrere Clients“). Modem / Eingebautes Modem / Eingebautes Mobilfunkmodem: Steht nicht bei allen mGuard -Modellen zur Verfügung (siehe „Netzwerk >> Interfaces“ auf Seite 137). |
Für IP-Verbindungen, die durch eine VPN-Verbindung mit aktiviertem Maskieren vermittelt werden, werden die Firewall-Regeln für ausgehende Daten in der VPN-Verbindung auf die originale Quelladresse der Verbindung angewendet. |
1:1-NAT
Kann nur für VPN-Typ Tunnel verwendet werden. |
Mit Hilfe von 1:1-NAT im VPN können weiterhin die tatsächlich genutzten Netzwerkadressen zur Angabe des Tunnelanfangs oder -endes angegeben werden, unabhängig von den mit der Gegenseite vereinbarten Tunnelparametern:
Bild 10-3: 1:1-NAT
Authentifizierung |
Authentisierungsverfahren |
Es gibt 2 Möglichkeiten: –X.509-Zertifikat (werkseitige Voreinstellung) –Pre-Shared Key (PSK) Je nachdem, welches Verfahren Sie auswählen, zeigt die Seite unterschiedliche Einstellmöglichkeiten. |
|
|
Bei Authentisierungsverfahren X.509-Zertifikat Dieses Verfahren wird von den meisten neueren IPsec-Implementierungen unterstützt. (Dabei besitzt jeder VPN-Teilnehmer einen privaten geheimen Schlüssel sowie einen öffentlichen Schlüssel in Form eines X.509-Zertifikats, welches weitere Informationen über seinen Eigentümer und einer Beglaubigungsstelle (Certification Autority, CA) enthält.) Es muss Folgendes festgelegt werden: –Wie sich der mGuard bei der Gegenstelle authentisiert. –Wie der mGuard die entfernte Gegenstelle authentifiziert |
|
....wie sich der mGuard bei der Gegenstelle authentisiert. 
|
|
|
Lokales X.509-Zertifikat (Bei Authentisierungsverfahren „X.509-Zertifikat) |
Legt fest, mit welchem Maschinenzertifikat sich der mGuard bei der VPN-Gegenstelle ausweist. In der Auswahlliste eines der Maschinenzertifikate auswählen. Die Auswahlliste stellt die Maschinenzertifikate zur Wahl, die in den mGuard unter Menüpunkt Authentifizierung >> Zertifikate geladen worden sind. 
|
|
....wie der mGuard die entfernte Gegenstelle authentifiziert |
|
|
Nachfolgend wird festgelegt, wie der mGuard die Authentizität der entfernten VPN-Gegenstelle prüft. Die Tabelle unten zeigt, welche Zertifikate dem mGuard zur Authentifizierung der VPN-Gegenstelle zur Verfügung stehen müssen, wenn die VPN-Gegenstelle bei Verbindungsaufnahme eines der folgenden Zertifikatstypen vorzeigt: –ein von einer CA signiertes Maschinenzertifikat –ein selbst signiertes Maschinenzertifikat |
|
|
Remote CA-Zertifikat |
Folgende Auswahlmöglichkeiten stehen zur Verfügung: –Ausgestellt von einer vertrauenswürdigen CA –Kein CA-Zertifikat, sonder das Gegenstellen-Zertifikat unten –Name eines CA-Zertifikats, wenn verfügbar |
|
Gegenstellen-Zertifikat (Bei Authentifizierung mittels Gegenstellen-Zertifikat) |
Sie können das Gegenstellen-Zertifikat hochladen. Das Zertifikat wird ausgewählt und in der Liste der Gegenstellen-Zertifikate gespeichert (siehe „Gegenstellen-Zertifikate“ auf Seite 267). |
Zum Verständnis der nachfolgenden Tabelle siehe Kapitel „Authentifizierung >> Zertifikate“ auf Seite 256.
Authentifizierung bei VPN
Die Gegenstelle zeigt vor: |
Maschinenzertifikat von CA signiert |
Maschinenzertifikat selbst signiert |
Der mGuard authentifiziert die Gegenstelle anhand von... |
|
|
|
Gegenstellen-Zertifikat oder, allen CA-Zertifikaten, die mit dem von der Gegenstelle vorgezeigten Zertifikat die Kette bis zum Root-CA-Zertifikat bilden |
Gegenstellen-Zertifikat |
Nach dieser Tabelle sind dem mGuard die Zertifikate zur Verfügung zu stellen, die er zur Authentifizierung der jeweiligen VPN-Gegenstelle heranziehen muss.
Voraussetzung
Die nachfolgenden Anleitungen gehen davon aus, dass die Zertifikate bereits ordnungsgemäß im mGuard installiert sind (siehe „Authentifizierung >> Zertifikate“ auf Seite 256 ; abgesehen vom Gegenstellen-Zertifikat).
Ist unter Menüpunkt Authentifizierung >> Zertifikate , Zertifikatseinstellungen die Verwendung von Sperrlisten (= CRL-Prüfung) aktiviert, wird jedes von einer CA signierte Zertifikat, das VPN-Gegenstellen „vorzeigen“, auf Sperrung geprüft. Eine bestehende VPN-Verbindung wird jedoch durch ein zurückgezogenes Zertifikat nicht umgehend beendet, wenn das CRL-Update während der bestehenden VPN-Verbindung erfolgt. Ein erneuter Schlüsselaustausch (rekeying) oder das erneute Starten der VPN-Verbindung ist dann jedoch nicht mehr möglich. |
Selbst signiertes Maschinenzertifikat
Wenn sich die VPN-Gegenstelle mit einem selbst signierten Maschinenzertifikat authentisiert:
•Wählen Sie aus der Auswahlliste folgenden Eintrag:
„Kein CA-Zertifikat, sondern das Gegenstellen-Zertifikat unten“
•Installieren Sie unter Gegenstellen-Zertifikat das Gegenstellen-Zertifikat (siehe „Gegenstellen-Zertifikat installieren“ auf Seite 361).
Es ist nicht möglich, ein Gegenstellen-Zertifikat zu referenzieren, das unter Menüpunkt Authentifizierung >> Zertifikate geladen ist. |
CA-signiertes Maschinenzertifikat
Wenn sich die VPN-Gegenstelle mit einem von einer CA signierten Maschinenzertifikat authentisiert:
Es gibt die Möglichkeit, das von der Gegenstelle vorgezeigte Maschinenzertifikat wie folgt zu authentifizieren;
–durch CA-Zertifikate
–durch das entsprechende Gegenstellen-Zertifikat
Authentifizierung durch CA-Zertifikate:
An dieser Stelle ist ausschließlich das CA-Zertifikat von der CA zu referenzieren (in der Auswahlliste auszuwählen), welche das von der VPN-Gegenstelle vorgezeigte Zertifikat signiert hat. Die weiteren CA-Zertifikate, die mit dem von der Gegenstelle vorgezeigten Zertifikat die Kette bis zum Root-CA-Zertifikat bilden, müssen aber im mGuard installiert sein - unter Menüpunkt Authentifizierung >> Zertifikate .
Die Auswahlliste stellt alle CA-Zertifikate zur Wahl, die in den mGuard unter Menüpunkt Authentifizierung >> Zertifikate geladen worden sind.
Weitere Auswahlmöglichkeit ist „Alle bekannten CAs“.
Mit dieser Einstellung werden alle VPN-Gegenstellen akzeptiert, wenn sie sich mit einem von einer CA signierten Zertifikat anmelden, das von einer bekannten CA (Certification Authority) ausgestellt ist. Bekannt dadurch, weil in den mGuard das jeweils entsprechende CA-Zertifikat und außerdem alle weiteren CA-Zertifikate geladen worden sind, so dass sie zusammen mit den vorgezeigten Zertifikaten jeweils die Kette bilden bis zum Root-Zertifikat.
Authentifizierung durch das entsprechende Gegenstellen-Zertifikat:
•Wählen Sie aus der Auswahlliste folgenden Eintrag:
„Kein CA-Zertifikat, sondern das Gegenstellen-Zertifikat unten“
•Installieren Sie unter Gegenstellen-Zertifikat das Gegenstellen-Zertifikat siehe „Gegenstellen-Zertifikat installieren“ auf Seite 361).
Es ist nicht möglich, ein Gegenstellen-Zertifikat zu referenzieren, das unter Menüpunkt Authentifizierung >> Zertifikate geladen ist. |
Gegenstellen-Zertifikat installieren
Das Gegenstellen-Zertifikat muss konfiguriert werden, wenn die VPN-Gegenstelle per Gegenstellen-Zertifikat authentifiziert werden soll.
Um ein Zertifikat zu importieren, gehen Sie wie folgt vor:
Voraussetzung
Die Zertifikatsdatei (Dateiname = *.pem, *.cer oder *.crt) ist auf dem angeschlossenen Rechner gespeichert.
•Keine Datei ausgewählt... klicken, um die Datei zu selektieren
•Hochladen klicken.
Danach wird der Inhalt der Zertifikatsdatei angezeigt.
IPsec VPN >> Verbindungen >> Editieren >> Authentifizierung |
||
|---|---|---|
Bei Authentisierungsverfahren CA-Zertifikat Die nachfolgende Erklärung gilt, wenn die Authentifizierung der VPN-Gegenstelle anhand von CA-Zertifikaten erfolgt. Über VPN-Identifier erkennen die VPN-Gateways, welche Konfigurationen zu der gleichen VPN-Verbindung gehören. Wenn der mGuard CA-Zertifikate heranzieht, um eine VPN-Gegenstellen zu authentifizieren, ist es möglich den VPN-Identifier als Filter zu benutzen. •Machen Sie dazu im Feld Gegenstelle den entsprechenden Eintrag. |
||
|
Lokal |
Standard: leeres Feld Mit dem lokalen VPN-Identifier können Sie den Namen festlegen, mit dem sich der mGuard bei der Gegenstelle meldet (identifiziert). Er muss mit den Angaben aus dem Maschinenzertifikat des mGuard s übereinstimmen. Gültige Werte sind: –Leer, also kein Eintrag (Voreinstellung). Dann wird der Subject-Eintrag (früher Distinguished Name) des Maschinenzertifikats verwendet. –Der Subject-Eintrag im Maschinenzertifikat –Einen der Subject Alternative Names, wenn die im Zertifikat aufgelistet sind. Wenn das Zertifikat Subject Alternative Names enthält, werden diese unter „Gültige Werte sind:“ mit angegeben. Es können IP-Adressen, Hostnamen mit vorangestelltem @-Zeichen oder E-Mail-Adressen sein. |
|
Legt fest, was im Maschinenzertifikat der VPN-Gegenstelle als Subject eingetragen sein muss, damit der mGuard diese VPN-Gegenstelle als Kommunikationspartner akzeptiert. Durch eine entsprechende Festlegung ist es möglich, VPN-Gegenstellen, die der mGuard auf Grundlage von Zertifikatsprüfungen im Prinzip akzeptieren würde, wie folgt zu beschränken bzw. freizugeben: – Beschränkung auf bestimmte Subjects (d. h. Maschinen) und/oder auf Subjects, die bestimmte Merkmale (Attribute) haben, oder – Freigabe für alle Subjects (Siehe „Subject, Zertifikat“ auf Seite 469.) 
|
|
|
Freigabe für alle Subjects: Wenn Sie das Feld Gegenstelle leer lassen, legen Sie fest, dass im Maschinenzertifikat, das die VPN-Gegenstelle vorzeigt, beliebige Subject-Einträge erlaubt sind. Dann ist es überflüssig, das im Zertifikat jeweils angegebene Subject zu kennen oder festzulegen. Beschränkung auf bestimmte Subjects: Im Zertifikat wird der Zertifikatsinhaber im Feld Subject angegeben, das sich aus mehreren Attributen zusammensetzt. Diese Attribute werden entweder als Object Identifier ausgedrückt (z. B.: 132.3.7.32.1) oder, geläufiger, als Buchstabenkürzel mit einem entsprechenden Wert. Beispiel: CN=VPN-Endpunkt-01, O=Beispiel GmbH, C=DE Sollen bestimmte Attribute des Subjects ganz bestimmte Werte haben, damit der mGuard die VPN-Gegenstelle akzeptiert, muss dies entsprechend spezifiziert werden. Die Werte der anderen Attribute, die beliebig sein können, werden dann durch das Wildcard * (Sternchen) angegeben. Beispiel: CN=*, O=Beispiel GmbH, C=DE (mit oder ohne Leerzeichen zwischen Attributen) Bei diesem Beispiel müsste im vorgezeigten Zertifikat im Subject das Attribut „O=Beispiel GmbH“ und das Attribut „C=DE“ stehen. Nur dann würde der mGuard den Zertifikatsinhaber (= Subject) als Kommunikationspartner akzeptieren. Die anderen Attribute könnten in den zu filternden Zertifikaten beliebige Werte haben. 
|
|
Authentifizierung |
Bei Authentisierungsverfahren Pre-Shared Key (PSK) 
Dieses Verfahren wird vor allem durch ältere IPsec Implementierungen unterstützt. Dabei authentifizieren sich beide Seiten des VPNs über den gleichen PSK. Um den verabredeten Schlüssel dem mGuard zur Verfügung zu stellen, gehen Sie wie folgt vor: •Tragen Sie ins Eingabefeld Pre-Shared Key (PSK) die verabredete Zeichenfolge ein. 
|
|
|
ISAKMP-Modus |
Main Mode (sicher) Beim Main Mode handelt derjenige, der die Verbindung aufnehmen will (Initiator) mit dem Antwortenden (Responder) eine ISAKMP-SA aus. Wir empfehlen im Main Mode den Einsatz von Zertifikaten. Der Aggressive Mode ist nicht so streng verschlüsselt wie der Main Mode. Ein Grund für den Einsatz dieses Modus kann sein, dass die Adresse des Initiators dem Responder nicht von vornherein bekannt ist und beide Seiten Pre-shared Keys zur Authentifizierung einsetzen wollen. Ein anderer Grund kann sein, dass ein schnellerer Verbindungsaufbau gewünscht wird und die Richtlinien des Responders ausreichend bekannt sind, z. B. bei einem Mitarbeiter, der auf das Firmennetz zugreifen will. Bedingung: –Nicht zusammen mit der Redundanz-Funktion einsetzbar. –Zwischen Peers muss der gleiche Mode eingesetzt werden. –Der Agressive Mode wird in Verbindung mit XAuth/Mode Config nicht unterstützt. –Wenn
zwei VPN-Clients hinter demselben NAT-Gateway die gleiche Verbindung
zu einem VPN-Gateway aufbauen, müssen sie den gleichen PSK verwenden.
|
Über VPN Identifier erkennen die VPN-Gateways, welche Konfigurationen zu der gleichen VPN-Verbindung gehören. Bei PSK sind folgende Einträge gültig: –leer (die IP-Adresse wird verwendet, dies ist die Voreinstellung) –eine IP-Adresse –ein Hostname mit voran gestelltem ’@’ Zeichen (z. B. „@vpn1138.example.com“) –eine E-Mail Adresse (z. B. „piepiorra@example.com“) |
||
Firewall eingehend, Firewall ausgehend
Während die unter dem Menüpunkt Netzwerksicherheit vorgenommenen Einstellungen sich nur auf Nicht-VPN-Verbindungen beziehen (siehe oben unter „Menü Netzwerksicherheit“ auf Seite 273), beziehen sich die Einstellungen hier ausschließlich auf die VPN-Verbindung, die auf diesem Registerkarten-Set definiert ist.
Wenn Sie mehrere VPN-Verbindungen definiert haben, können Sie für jede einzelne den Zugriff von außen oder von innen beschränken. Versuche, die Beschränkungen zu übergehen, können Sie ins Log protokollieren lassen.
Die VPN-Firewall ist werkseitig so voreingestellt, dass für diese VPN-Verbindung alles zugelassen ist. Für jede einzelne VPN-Verbindung gelten aber unabhängig voneinander gleichwohl die erweiterten Firewall-Einstellungen, die weiter oben definiert und erläutert sind (siehe „Menü Netzwerksicherheit“ auf Seite 273, „Netzwerksicherheit >> Paketfilter“ auf Seite 273, „Erweitert“ auf Seite 293). |
Wenn mehrere Firewall-Regeln gesetzt sind, werden diese in der Reihenfolge der Einträge von oben nach unten abgefragt, bis eine passende Regel gefunden wird. Diese wird dann angewandt. Falls in der Regelliste weitere passende Regeln vorhanden sind, werden diese ignoriert. |
Im Stealth-Modus ist in den Firewall-Regeln die vom Client wirklich verwendete IP-Adresse zu verwenden oder aber auf 0.0.0.0/0 zu belassen, da nur ein Client durch den Tunnel angesprochen werden kann. |
Ist auf der Registerkarte Global die Funktion Erlaube Paketweiterleitung zwischen VPN-Verbindungen aktiviert gesetzt, werden für die in den mGuard eingehende Datenpakete die Regeln unter Firewall eingehend angewendet und für die ausgehende Datenpakete die Regeln unter Firewall ausgehend. Fallen die ausgehenden Datenpakete unter die selbe Verbindungsdefinition (bei einer definierten VPN-Verbindungsgruppe), werden die Firewall-Regeln für Eingehend und Ausgehend der selben Verbindungsdefinition angewendet. Gilt für die ausgehenden Datenpakete eine andere VPN-Verbindungsdefinition, werden die Firewall-Regeln für Ausgehend dieser anderen Verbindungsdefinition angewendet. |
Wenn der mGuard so konfiguriert wurde, dass er Pakete einer SSH-Verbindung weiterleitet (z. B. durch das Erlauben einer SEC-Stick Hub & Spoke-Verbindung), dann werden vorhandene VPN-Firewall-Regeln nicht angewendet. Das bedeutet, dass zum Beispiel die Pakete einer SSH-Verbindung durch einen VPN-Tunnel geschickt werden, obwohl dessen Firewall-Regel dies verbietet. |
Eingehend |
Allgemeine Firewall- Einstellung |
Alle eingehenden Verbindungen annehmen, die Datenpakete aller eingehenden Verbindungen werden angenommen. Alle eingehenden Verbindungen verwerfen, die Datenpakete aller eingehenden Verbindungen werden verworfen. Nur Ping zulassen, die Datenpakete aller eingehenden Verbindungen werden verworfen, mit Ausnahme der Ping-Pakete (ICMP). Wende das unten angegebene Regelwerk an, blendet weitere Einstellmöglichkeiten ein. |
|
Die folgenden Einstellungen sind nur sichtbar, wenn „Wende das unten angegebene Regelwerk an“ eingestellt ist. |
|
|
Protokoll |
Alle bedeutet: TCP, UDP, ICMP, GRE und andere IP-Protokolle. |
|
Von IP/Nach IP |
0.0.0.0/0 bedeutet alle IP-Adressen. Um einen Bereich anzugeben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30). Namen von IP-Gruppen, sofern definiert. Bei Angabe des Namens einer IP-Gruppe werden die Hostnamen, IP-Adressen, IP-Bereiche oder Netzwerke berücksichtigt, die unter diesem Namen gespeichert sind (siehe „IP- und Portgruppen“ auf Seite 290). 
Eingehend: –Von IP: die IP-Adresse im VPN-Tunnel –Nach IP die 1:1-NAT-Adresse bzw. die reale Adresse Ausgehend: –Von IP: die 1:1-NAT-Adresse bzw. die reale Adresse –Nach IP: die IP-Adresse im VPN-Tunnel |
|
Von Port / Nach Port (Nur bei den Protokollen TCP und UDP) |
any bezeichnet jeden beliebigen Port. startport:endport (z. B. 110:120) bezeichnet einen Portbereich. Einzelne Ports können Sie entweder mit der Port-Nummer oder mit dem entsprechenden Servicenamen angegeben (z. B. 110 für pop3 oder pop3 für 110). Namen von Portgruppen, sofern definiert. Bei Angabe des Namens einer Portgruppe werden die Ports oder Portbereiche berücksichtigt, die unter diesem Namen gespeichert sind (siehe „IP- und Portgruppen“ auf Seite 290). |
|
Aktion |
Annehmen bedeutet, die Datenpakete dürfen passieren. Abweisen bedeutet, die Datenpakete werden zurückgewiesen, so dass der Absender eine Information über die Zurückweisung erhält. (Im Stealth-Modus hat Abweisen dieselbe Wirkung wie Verwerfen.) Verwerfen bedeutet, die Datenpakete dürfen nicht passieren. Sie werden verschluckt, so dass der Absender keine Information über deren Verbleib erhält. Namen von Regelsätzen, sofern definiert. Bei Angabe eines Namens für Regelsätze treten die Firewall-Regeln in Kraft, die unter diesem Namen konfiguriert sind (siehe Registerkarte Regelsätze). 
Namen von Modbus-TCP-Regelsätzen, sofern definiert. Bei der Auswahl eines Modbus-TCP-Regelsatzes treten die Firewall-Regeln in Kraft, die unter diesem Regelsatz konfiguriert sind (siehe „Modbus TCP“ auf Seite 298). |
|
Ein frei wählbarer Kommentar für diese Regel. |
|
|
Log |
Für jede einzelne Firewall-Regel können Sie festlegen, ob bei Greifen der Regel –das Ereignis protokolliert werden soll – Funktion Log aktivieren –oder nicht – Funktion Log deaktivieren (werkseitige Voreinstellung). |
|
Log-Einträge für unbekannte Verbindungsversuche |
Bei aktivierter Funktion werden alle Verbindungsversuche protokolliert, die nicht von den voranstehenden Regeln erfasst werden. |
Ausgehend |
Die Erklärung unter „Eingehend“ gilt auch für „Ausgehend“. |
|
10.3IPsec VPN >> L2TP über IPsec
Diese Einstellungen gelten nicht im Stealth-Modus. Unter Windows 7 ist die Verwendung des MD5-Algorithmus nicht möglich. Der MD5-Algorithmus muss durch SHA-1 ersetzt werden. |
Ermöglicht den Aufbau von VPN-Verbindungen durch das IPsec/L2TP-Protokoll zum mGuard .
Dabei wird über eine IPsec-Transportverbindung das L2TP-Protokoll gefahren um darin wiederum eine Tunnelverbindung mit dem Point-to-Point-Protokoll (PPP) aufzubauen. Durch das PPP werden den Clients automatisch IP-Adressen zugewiesen.
Um IPsec/L2TP zu nutzen muss der L2TP-Server aktiviert werden sowie eine oder mehrere IPsec-Verbindungen mit den folgenden Eigenschaften eingerichtet werden:
–Typ: Transport
–Protokoll: UDP
–Lokal: %all
–Gegenstelle: %all
–PFS: Nein
Siehe
–IPsec VPN >> Verbindungen >> Editieren >> Allgemein auf Seite 340
–IPsec VPN >> Verbindungen >> Editieren >> IKE-Optionen, Perfect Forward Secrecy (PFS) auf Seite 372
Wollen Sie IPsec/L2TP-Verbindungen ermöglichen, aktivieren Sie die Funktion. Über IPsec können dann zum mGuard L2TP-Verbindungen aufgebaut werden, über welche den Clients dynamisch IP-Adressen innerhalb des VPNs zugeteilt werden. |
||
|
Lokale IP-Adresse für L2TP-Verbindungen |
Nach dem obigen Screenshot teilt der mGuard der Gegenstelle mit, er habe die Adresse 10.106.106.1. |
|
Beginn / Ende des Remote-IP-Adressbereichs |
Nach dem obigen Screenshot teilt der mGuard der Gegenstelle eine IP-Adresse zwischen 10.106.106.2 und 10.106.106.254 mit. |
|
Informiert über den L2TP-Status, wenn dieser als Verbindungstyp gewählt ist. |
|
Informiert über den aktuellen Status der konfigurierten IPsec-Verbindungen.
Wartend: Zeigt alle nicht aufgebauten VPN-Verbindungen an, die mittels einer Initiierung durch Datenverkehr gestartet werden oder auf einen Verbindungsaufbau warten.
Im Aufbau: Zeigt alle VPN-Verbindungen an, die aktuell versuchen, eine Verbindung aufzubauen.
Die ISAKMP SA wurde aufgebaut und die Authentifizierung der Verbindungen war erfolgreich. Verbleibt die Verbindung im Status „Verbindungsaufbau“, stimmten gegebenenfalls andere Parameter nicht: Stimmt der Verbindungstyp (Tunnel, Transport) überein? Wenn Tunnel gewählt ist, stimmen die Netzbereiche auf beiden Seiten überein?
Aufgebaut: Zeigt alle VPN-Verbindungen an, die eine Verbindung erfolgreich aufgebaut haben.
Die VPN-Verbindung ist erfolgreich aufgebaut und kann genutzt werden. Sollte dies dennoch nicht möglich sein, dann macht das VPN-Gateway der Gegenstelle Probleme. In diesem Fall die Verbindung deaktivieren und wieder aktivieren, um die Verbindung erneut aufzubauen
Icons
Aktualisieren
Um die angezeigten Daten auf den aktuellen
Stand zu bringen, klicken Sie auf das Icon 
Aktualisieren.
Neustart
Wollen Sie eine Verbindung trennen und dann
neu starten, auf die entsprechende Neustart-Schaltfläche
klicken.
Editieren
Wollen Sie eine Verbindung neu konfigurieren,
klicken Sie auf das entsprechende Icon 
Zeile bearbeiten.
Verbindung, ISAKMP-SA-Status, IPsec-SA-Status
ISAKMP SA |
Lokal |
–lokale IP-Adresse –lokaler Port –ID = Subject eines X.509-Zertifikats |
Zustand, Lebensdauer und Verschlüsselungsalgorithmus der Verbindung (Fett = aktiv) |
|
Gegenstelle |
–Remote-IP-Adresse –lokaler Port –ID = Subject eines X.509-Zertifikats |
|
IPsec SA |
|
–Name der Verbindung –lokale Netze...Remote-Netze |
Zustand, Lebensdauer und Verschlüsselungsalgorithmus der Verbindung (Fett = aktiv) |
Bei Problemen empfiehlt es sich, in die VPN-Logs der Gegenstelle zu schauen, zu der die Verbindung aufgebaut wurde. Denn der initiierende Rechner bekommt aus Sicherheitsgründen keine ausführlichen Fehlermeldungen zugesandt.
