Dieses Menü steht nicht auf dem FL MGUARD BLADE-Controller zur Verfügung.

Lizenzstatus

Lizenzierte Gegenstel­len (IPsec)

Anzahl der Gegenstellen, die aktuell eine VPN-Verbindung über das IPsec-Protokoll aufgebaut haben.

Lizenzierte Gegenstel­len (OpenVPN)

Anzahl der Gegenstellen, zu denen aktuell eine VPN-Verbin­dung ü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 Status der VPN-Verbindung nach einem Neustart/Booten des mGuards (z. B. nach einer Unterbrechung der Stromver­sorgung).

VPN-Verbindungen, die nicht deaktiviert sind, können über Icons in der Web-Oberfläche, SMS, Schalter oder Taster ge­startet oder gestoppt werden.

Zustand

Zeigt den aktuellen Aktivierungszustand der OpenVPN-Ver­bindung.

VPN-Status

Zeigt an, ob die entsprechende OpenVPN-Verbindung aufge­baut wurde oder nicht.

Client-IP

IP-Adresse des OpenVPN-Interface.

Name

Name der VPN-Verbindung

OpenVPN-Client >> Verbindungen >> Editieren >> Allgemein

Optionen

Ein beschreibender Name für die Verbin­dung

Sie können die Verbindung frei benennen bzw. umbenennen.

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 mGuards (z. B. nach einer Unterbrechung der Stromver­sorgung).

VPN-Verbindungen, die nicht deaktiviert sind, können über Icons in der Web-Oberfläche, SMS, Schalter oder Taster ge­startet oder gestoppt werden.

Schaltender Service Eingang/CMD

(Nur verfügbar beim TC MGUARD RS4000/RS2000 3G, TC MGUARD RS4000/RS2000 4G, FL MGUARD RS4000/RS2000, FL MGUARD RS4004/RS2005, FL MGUARD RS, FL MGUARD GT/GT.)

Kein / Service-Eingang CMD 1-3

Die VPN-Verbindung kann über einen angeschlossenen Tas­ter/Schalter geschaltet werden.

Der Taster/Schalter muss an einen der Servicekontakte (CMD 1-3) angeschlossen sein.

Invertierte Logik ver­wenden

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, aus­schalten.

Timeout zur Deaktivie­rung

Zeit, nach der die VPN-Verbindung gestoppt wird, wenn sie über SMS, Schalter, Taster oder die Web-Oberfläche gestar­tet worden ist. Der Timeout startet beim Übergang in den Zu­stand „Gestartet“.

Die Verbindung verbleibt nach Ablauf des Timeouts in dem Zustand „Gestoppt“, bis sie erneut gestartet wird.

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.

Token für SMS-Steue­rung

(Nur verfügbar beim TC MGUARD RS4000/RS2000 3G, TC MGUARD RS4000/RS2000 4G.)

Eingehende SMS können dazu benutzt werden, VPN-Verbin­dungen zu initiieren (start) oder zu beenden (stop). Die SMS muss das Kommando „openvpn/start“ bzw. „openvpn/stop“ gefolgt von dem Token enthalten.

Verbindung

Adresse des VPN-Gateways der Gegen­stelle

IP-Adresse oder Hostname der des VPN-Gateways der Ge­genstelle

Protokoll

TCP / UDP

Das vom OpenVPN-Server verwendete Netzwerkprotokoll muss an dieser Stelle im mGuard ebenfalls ausgewählt wer­den.

Lokaler Port

Port des lokalen OpenVPN-Clients, von dem aus die Verbin­dung mit einem OpenVPN-Server initiiert wird.

Werte: 1 – 65535; Default: %any (Auswahl wird der Gegen­stelle überlassen

Remote-Port

Port des Remote-OpenVPN-Servers, der auf Anfragen des OpenVPN-Clients antworten soll.

Werte: 1 – 65535; Default: 1194

OpenVPN-Client >> Verbindungen >> Editieren >> Tunneleinstellungen

Remote-Netze

Netzwerk

Adressen der Netze, die sich hinter dem OpenVPN-Server (VPN-Gateway der Gegenstelle) befinden (CIDR-Schreib­weise).

Kommentar

Optional: kommentierender Text.

Tunneleinstellungen

Lerne Remote-Netze vom Server

Bei aktivierter Funktion (Standard) werden Remote-Netze automatisch vom Server gelernt, wenn der Server entspre­chend konfiguriert ist.

Bei deaktivierter Funktion werden die statisch eingetrage­nen Routen verwendet.

Dynamisch gelernte Remote-Netze

Dynamisch gelernte Remote-Netze werden angezeigt.

Verwende Komprimie­rung

Ja / Nein / Adaptiv / Deaktiviert

Sie können auswählen, ob eine Komprimierung immer, nie oder adaptiv (je nach Art des Traffics angepasst) angewendet wird.

Die Option Deaktiviert deaktiviert die Komprimierung voll­ständig, indem die Benutzung von liblzo bzw. comp-lzo deak­tiviert wird.

Datenverschlüsselung

Verschlüsselungsal­gorithmus

Blowfish / AES-128 / AES-192 / AES-256 (Standard)

Vereinbaren Sie mit dem Administrator der Gegenstelle, wel­cher Verschlüsselungsalgorithmus verwendet werden soll.

Grundsätzlich gilt Folgendes: Je länger die Schlüssellänge (in Bits) ist, die ein Verschlüsselungsalgorithmus verwendet (an­gegeben durch die angefügte Zahl), desto sicherer ist er. Der Verschlüsselungsvorgang ist umso zeitaufwändiger, je länger der Schlüssel ist.

Key-Renegotiation

Bei aktivierter Funktion (Standard) wird der mGuard versu­chen, einen neuen Schlüssel zu vereinbaren, wenn die Gültig­keit des alten abläuft.

Key-Renegotiation-Intervall

Zeitspanne, nach der die Gültigkeit des aktuellen Schlüssels abläuft und eine neuer Schlüssel zwischen Server und Client vereinbart wird.

Zeit in hh:mm:ss (Standard: 8 h)

Dead Peer Detection

Wenn die Gegenstelle Dead Peer Detection unterstützt, können die jeweiligen Partner er­kennen, ob die OpenVPN-Verbindung noch aktiv ist oder neu aufgebaut werden muss.

Verzögerung bis zur nächsten Anfrage nach einem Lebens­zeichen

Zeitspanne, nach welcher DPD Keep Alive-Anfragen gesen­det werden sollen. Diese Anfragen testen, ob die Gegenstelle noch verfügbar ist.

Zeit in hh:mm:ss

Default: 0:00:00 (DPD ist ausgeschaltet)

Zeitüberschreitung bei Ausbleiben des Lebenszeichens, nach welcher die Gegen­stelle für tot befunden wird

Zeitspanne, nach der die Verbindung zur Gegenstelle für tot erklärt werden soll, wenn auf die Keep Alive-Anfragen keine Antwort erfolgte.

Zeit in hh:mm:ss

Default: 0:00:00 (DPD ist ausgeschaltet)

Authentifizierung

Authentisierungs­verfahren

Es gibt drei Möglichkeiten für den mGuard, sich als Open­VPN-Client bei einem OpenVPN-Server zu authentifizieren:

–X.509-Zertifikat (Standard)

–Login/Passwort

–X.509-Zertifikat + Login/Passwort

Je nachdem, welches Verfahren Sie auswählen, zeigt die Seite unterschiedliche Einstellmöglichkeiten.

Login

Bei Authentisierungsverfahren Login/Passwort

Benutzerkennung (Login), mit der sich der mGuard beim OpenVPN-Server authentifiziert.

Passwort

Verabredetes Passwort, das bei der Authentifizierung mit einer Benutzerkennung (Login) verwendet wird.

Bei Authentisierungsverfahren X.509-Zertifikat

Jeder VPN-Teilnehmer besitzt 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 Auto­rity, CA) enthält.)

Es muss Folgendes festgelegt werden:

–Wie sich der mGuard bei der Gegenstelle authentisiert.

–Wie der mGuard die entfernte Gegenstelle authentifiziert

Lokales X.509-Zertifi­kat

Legt fest, mit welchem Maschinenzertifikat sich der mGuard bei der VPN-Gegenstelle ausweist.

In der Auswahlliste eines der Maschinenzertifikate auswäh­len.

Die Auswahlliste stellt die Maschinenzertifikate zur Wahl, die in den mGuard unter Menüpunkt Authentifizierung >> Zertifi­kate geladen worden sind.

CA-Zertifikat (zur Veri­fizierung des Server-Zertifikats)

An dieser Stelle ist ausschließlich das CA-Zertifikat von der CA (Certification Authority) zu referenzieren (in der Auswahl­liste auszuwählen), welche das von der VPN-Gegenstelle (OpenVPN-Server) 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 dann in den mGuard importiert werden – unter Menüpunkt „Authentifizierung >> Zertifikate“ auf Seite 256.

Die Auswahlliste stellt alle CA-Zertifikate zur Wahl, die unter Menüpunkt Authentifizierung >> Zertifikate in den mGuard im­portiert wurden.

Mit dieser Einstellung werden alle VPN-Gegenstellen akzep­tiert, wenn sie sich mit einem von einer CA signierten Zertifikat anmelden, das von einer bekannten CA (Certification Autho­rity) ausgestellt ist. Bekannt dadurch, weil in den mGuard das jeweils entsprechende CA-Zertifikat und außerdem alle weite­ren CA-Zertifikate geladen worden sind, so dass sie zusam­men mit den vorgezeigten Zertifikaten jeweils die Kette bilden bis zum Root-Zertifikat.

Pre-Shared Key für die TLS-Authentifizierung

Zur Erhöhung der Sicherheit (z. B. Verhinderung von DoS-An­griffen) kann die Authentifizierung der OpenVPN-Verbindung zusätzlich über Pre-Shared-Keys (TLS-PSK) abgesichert werden.

Dazu muss eine statische PSK-Datei (z. B. ta.key) zunächst erzeugt und auf beiden OpenVPN-Gegenstellen (Server und Client) installiert und aktiviert werden.

Die PSK-Datei kann

–vom OpenVPN-Server erzeugt werden oder

–aus einer beliebigen Datei (8 – 2048 Bytes) bestehen.

Wird die Datei vom Server erzeugt, kann zusätzlich die Schlüsselrichtung ausgewählt werden (siehe unten).

Um TLS-Authentifizierung zu aktivieren, muss eine PSK-Datei über das Icon  ausgewählt und über die Schaltfläche Hochladen hochgeladen werden.

Um die TLS-Authentifizierung zu deaktivieren, muss die Datei über die Schaltfläche Löschen gelöscht werden. Die Schalt­fläche Löschen ist immer sichtbar, d. h. auch dann, wenn keine PSK-Datei hochgeladen oder eine hochgeladene PSK-Datei gelöscht wurde.

Schlüsselrichtung für die TLS-Authentifizie­rung

Kein / 0 / 1

Kein

Muss ausgewählt werden, wenn die PSK-Datei nicht vom OpenVPN-Server erzeugt wurden.

0 und 1

Kann ausgewählt werden, wenn die PSK-Datei vom Open­VPN-Server erzeugt wurde.

Die Auswahl auf Client- und Serverseite muss dabei komple­mentär (0 <–>1 oder 1 <–> 0) oder identisch (Kein <–> Kein) erfolgen.

Fehlerhafte Einstellungen führen dazu, dass die Verbindung nicht aufgebaut wird und ein Log-Eintrag erstellt wird.

Die VPN-Firewall ist werkseitig so voreingestellt, dass für diese VPN-Verbindung alles zu­gelassen 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 „Me­nü 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, wer­den diese ignoriert.

Im Single-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 unter dem Menüpunkt IPsec VPN >> Global auf der Registerkarte Optionen die Funk­tion Erlaube Paketweiterleitung zwischen VPN-Verbindungen aktiviert, werden für die in den mGuard eingehende Datenpakete die Regeln unter Firewall eingehend ange­wendet und für die ausgehende Datenpakete die Regeln unter Firewall ausgehend. Das gilt ebenso für OpenVPN-Verbindungen wie für IPsec-Verbindungen.

Fallen die ausgehenden Datenpakete unter die selbe Verbindungsdefinition, werden die Firewall-Regeln für Eingehend und Ausgehend der selben Verbindungsdefinition ange­wendet.

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 weiter­leitet (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 Datenpa­kete aller eingehenden Verbindungen werden angenommen.

Alle eingehenden Verbindungen verwerfen, die Datenpa­kete aller eingehenden Verbindungen werden verworfen.

Nur Ping zulassen, die Datenpakete aller eingehenden Ver­bindungen 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-Proto­kolle.

Von IP/Nach IP

0.0.0.0/0 bedeutet alle IP-Adressen. Um einen Bereich anzu­geben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30).

Namen von IP-Gruppen, sofern definiert. Bei Angabe eines Namens einer IP-Gruppe werden die Hostnamen, IP-Adres­sen, IP-Bereiche oder Netzwerke berücksichtigt, die unter die­sem 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 Ad­resse

Ausgehend:

–Von IP:   die 1:1-NAT-Adresse bzw. die reale Ad­resse

–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 Portbe­reich.

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 eines 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ückgewie­sen, so dass der Absender eine Information über die Zurück­weisung 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 Informa­tion ü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 konfigu­riert sind (siehe „Modbus TCP“ auf Seite 298).

Kommentar

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 akti­vieren

–oder nicht – Funktion Log deaktivieren (werkseitige Vor­einstellung).

Log-Einträge für unbe­kannte Verbindungs­versuche

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

Lokales NAT

Das Gerät kann bei ausgehenden Datenpaketen die in ihnen angegebenen Absender-IP-Adressen aus seinem internen Netzwerk auf seine OpenVPN-Client-IP-Adresse um­schreiben, eine Technik, die als NAT (Network Address Translation) bezeichnet wird.

Diese Methode wird z. B. benutzt, wenn die internen Adressen extern nicht geroutet wer­den können oder sollen, z. B. weil ein privater Adressbereich wie 192.168.x.x oder die interne Netzstruktur verborgen werden sollen.

Lokales NAT für Open­VPN-Verbindungen

Kein NAT / 1:1-NAT / Maskieren

Es können die IP-Adressen von Geräten umgeschrieben wer­den, die sich am lokalen Ende des OpenVPN-Tunnels befin­den (d. h. hinter dem mGuard).

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 lo­kalen Ende des Tunnels gegen eine für alle Geräte identische IP-Adresse ausgetauscht.

Virtuelles lokales Netzwerk für 1:1-NAT

(Wenn „1:1-NAT“ ausgewählt wurde)

Konfiguriert den virtuellen IP-Adressbereich, auf den die rea­len lokalen IP-Adressen bei Verwendung von 1:1-NAT umge­schrieben werden.

Die angegebene Netzmaske in CIDR-Schreibweise gilt eben­falls für die Lokale Adresse für 1:1-NAT (siehe unten).

Lokale Adresse für 1:1-NAT

(Wenn „1:1-NAT“ ausgewählt wurde)

Konfiguriert den lokalen IP-Adressbereich, aus dem IP-Adres­sen durch die Verwendung von 1:1-NAT auf die virtuelle IP-Adressen im oben definierten Virtuellen Lokalen Netzwerk für 1:1-NAT (siehe oben) umgeschrieben werden.

Es gilt die für das Virtuelle lokale Netzwerk für 1:1-NAT ange­gebene Netzmaske (siehe oben).

Netzwerk

(Wenn „Maskieren“ ausgewählt wurde)

Interne Netzwerke, deren Geräte-IP-Adressen auf die Open­VPN-Client-IP-Adresse umgeschrieben werden.

0.0.0.0/0 bedeutet, alle internen IP-Adressen werden dem NAT-Verfahren unterzogen. Um einen Bereich anzugeben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30).

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

IP- und Port-Weiterleitung

Listet die festgelegten Regeln zur IP- und Port-Weiterleitung (DNAT = Destination-NAT) auf.

Bei IP- und Port-Weiterleitung (DNAT) geschieht Folgendes: Der Header eingehender Datenpakete aus dem OpenVPN-Tunnel, die an die OpenVPN-Client-IP-Adresse des mGuards sowie an einen bestimmten Port des mGuards gerichtet sind, werden so umge­schrieben, dass sie ins interne Netz an einen bestimmten Rechner und zu einem be­stimmten Port dieses Rechners weitergeleitet werden. D. h., die IP-Adresse und die Port-Nummer im Header eingehender Datenpakete werden geändert.

Protokoll: TCP / UDP / GRE

Geben Sie hier das Protokoll an, auf das sich die Regel bezie­hen soll (TCP / UDP / GRE).

IP-Pakete des GRE-Protokolls können weitergeleitet wer­den. Allerdings wird nur eine GRE-Verbindung zur gleichen Zeit unterstützt. Wenn mehr als ein Gerät GRE-Pakete an die selbe externe IP-Adresse sendet, kann der mGuard mögli­cherweise Antwortpakete nicht korrekt zurückleiten.

Von IP

Absenderadresse, für die Weiterleitungen durchgeführt wer­den sollen.

0.0.0.0/0 bedeutet alle Adressen. Um einen Bereich anzuge­ben, benutzen Sie die CIDR-Schreibweise (siehe „CIDR (Classless Inter-Domain Routing)“ auf Seite 30).

Namen von IP-Gruppen, sofern definiert. Bei Angabe eines Namens einer IP-Gruppe werden die Hostnamen, IP-Adres­sen, IP-Bereiche oder Netzwerke berücksichtigt, die unter die­sem Namen gespeichert sind (siehe „IP- und Portgruppen“ auf Seite 290).

Von Port

Absenderport, für den Weiterleitungen durchgeführt werden sollen.

any bezeichnet jeden beliebigen Port.

Er kann entweder über die Port-Nummer oder über den ent­sprechenden Servicenamen angegeben werden, z. B. pop3 für Port 110 oder http für Port 80.

Namen von Portgruppen, sofern definiert. Bei Angabe eines Namens einer Portgruppe werden die Ports oder Portbereiche berücksichtigt, die unter diesem Namen gespeichert sind (siehe „IP- und Portgruppen“ auf Seite 290).

Eintreffend auf Port

Original-Ziel-Port, der in eingehenden Datenpaketen angege­ben ist.

Er kann entweder über die Port-Nummer oder über den ent­sprechenden Servicenamen angegeben werden, z. B. pop3 für Port 110 oder http für Port 80.

Beim Protokoll „GRE“ ist diese Angabe irrelevant. Sie wird vom mGuard ignoriert.

Weiterleiten an IP

Interne IP-Adresse, an die die Datenpakete weitergeleitet werden sollen und auf die die Original-Zieladressen umge­schrieben werden.

Weiterleiten an Port

Interner Port, an den die Datenpakete weitergeleitet werden sollen und auf den der Original-Port umgeschrieben wird.

Kommentar

Ein frei wählbarer Kommentar für diese Regel.

Log

Für jede einzelne Port-Weiterleitungs-Regel können Sie fest­legen, ob bei Greifen der Regel

–das Ereignis protokolliert werden soll - Funktion Log akti­vieren.

–oder nicht - Funktion Log deaktivieren setzen (werkseitige Voreinstellung).