This menu is not available on the FL MGUARD BLADE controller.

Options

Allow packet forward­ing between VPN con­nections

When the function is deactivated (default): VPN connec­tions exist separately. There is no packet forwarding between the configured VPN connections.

When the function is activated: “hub and spoke” feature en­abled: acting as a control center, the mGuard diverts VPN connections to several branches that can then also communi­cate with each other.

With a star VPN connection topology, mGuard peers can also exchange data with one another. In this case, it is recom­mended that the local mGuard consults CA certificates for the authentication of peers (see "Authentication" on page 342).

In the case of “hub and spoke”, 1:1 NAT of the peer is not sup­ported.

Archive diagnostic messages for VPN connections

Function deactivated (default)

If errors occur when establishing VPN connections, the mGuard logging function can be used to find the source of the error based on corresponding entries (see Logging >> Browse Local Logs menu item). This option for error diagnostics is used as standard. If it is sufficient, you can deactivate the func­tion at this point.

Function activated

If the option of diagnosing VPN connection problems using the mGuard logging function is too impractical or insufficient, se­lect this option. This may be the case if the following condi­tions apply:

–In certain application environments, e.g., when the mGuard is “operated” by means of a machine controller via the CMD contact (only for FL MGUARD RS4000/RS2000, TC MGUARD RS4000/RS2000 3G, TC MGUARD RS4000/RS2000 4G, FL MGUARD RS4004/RS2005, and FL MGUARD RS, FL MGUARD GT/GT), the option for a user to view the mGuard log file via the web-based user interface of the mGuard may not be available at all.

–When used remotely, it is possible that a VPN connection error can only be diagnosed after the mGuard is tempo­rarily disconnected from its power source – which causes all the log entries to be deleted.

–The relevant log entries of the mGuard that could be use­ful may be deleted because the mGuard regularly deletes older log entries on account of its limited memory capaci­ty.

–If an mGuard is being used as the central VPN peer, e.g., in a remote maintenance center as the gateway for the VPN connections of numerous machines, the mes­sages regarding activity on the various VPN connections are logged in the same data stream. The resulting logging volume makes it time-consuming to find the information relevant to one error.

After archiving is enabled, relevant log entries about the oper­ations involved in establishing VPN connections are archived in the non-volatile memory of the mGuard if the connections are established as follows:

–Via the CMD contact

–Via text message

–Via the “Start” icon on the web interface

–Via the CGI interface nph-vpn.cgi using the “synup” com­mand (see application note: “How to use the CGI Inter­face”). (Application notes are available in the download area of phoenixcontact.net/products.)

–Archived log entries are not affected by a restart. They can be downloaded as part of the support snapshot (Hardware menu item). A snapshot provides your suppli­er's support team with additional options for more efficient troubleshooting than would be possible without archiving.

Archive diagnostic messages only upon failure

(Only when Archiving is acti­vated)

If only log entries generated for failed connection attempts are to be archived, activate the function.

When the function is deactivated, all log entries will be ar­chived.

TCP encapsulation can only be used if an mGuard (Version 6.1 or later) is used at both ends of the VPN tunnel. The "Path Finder" function can be used from version 8.3 and also functions with the mGuard Secure VPN Client.

TCP encapsulation should only be used if required, because connections are slowed down by the significant increase in the data packet overhead and by the correspondingly longer processing times.

If the mGuard is configured to use a proxy for HTTP and HTTPS in the Network >> Proxy Settings menu item, then this proxy is also used for VPN connections that use TCP en­capsulation.

TCP encapsulation supports the basic authentication and NTLM authentication methods for the proxy. The "Path Finder" function also supports the "Digest" authentication pro­cess.

For the TCP encapsulation to work through an HTTP proxy, the proxy must be named ex­plicitly in the proxy settings (Network >> Proxy Settings menu item) (i.e., it must not be a transparent proxy) and this proxy must also understand and permit the HTTP method CONNECT.

To use the “Path Finder” function to establish a VPN connection to an mGuard Secure VPN Client, the function must be enabled on both sides of the connection (server and cli­ent).

TCP encapsulation does not work in conjunction with authentication via pre-shared key (PSK).

TCP encapsulation only works if one of the two ends is waiting for connections (connec­tion initiation: wait) and is given as address of the "%any" peer VPN gateway.

TCP encapsulation

Listen for incoming VPN connections, which are encapsu­lated

Default setting: deactivated

Only activate this function if the TCP encapsulation function is used. Only then can the mGuard allow connection establish­ment with encapsulated packets.

The interfaces to be used for listening are determined by the mGuard according to the settings on the active VPN connec­tions that have “%any” configured as the peer. The decisive setting is specified under “Interface to use for gateway setting %any”.

TCP port to listen on

(For TCP encapsulation)

Default: 8080

Number of the TCP port where the encapsulated data packets to be received arrive. The port number specified here must be the same as the one specified for the mGuard of the peer as the TCP port of the server, which accepts the encapsu­lated connection (IPsec VPN >> Connections menu item, Edit, General tab page).

The following restriction applies:

The port to be used for listening must not be identical to:

–A port that is being used for remote access (SSH, HTTPS or SEC-Stick)

–The port which is used for listening with enabled Path Finder function

Server ID (0-63)

(For TCP encapsulation)

The default value 0 does not usually have to be changed. The numbers are used to differentiate between different control centers.

A different number is only to be used in the following scenario: an mGuard connected upstream of a machine must establish connections to two or more different maintenance centers and their mGuard devices with TCP encapsulation enabled.

Enable Path Finder for mGuard Secure VPN Client

Default setting: deactivated 

Only activate this function if the mGuard should accept a VPN connection from an mGuard Secure VPN Client that is posi­tioned behind a proxy server or a firewall.

The “Path Finder” function must also be enabled in the mGuard Secure VPN Client.

TCP port to listen on

(For Path Finder)

Default: 443

Number of the TCP port where the encapsulated data packets to be received arrive.

The port number specified here must be the same as the one specified for the VPN client of the peer as the TCP port of the server, which accepts the encapsulated connection.

The mGuard Secure VPN Client always uses port 443 as the destination port. It is when the port is overwritten by a firewall between the mGuard Secure VPN Client and the mGuard that the port in the mGuard has to be changed.

The following restriction applies:

The port to be used for listening must not be identical to:

–A port that is being used for remote access (SSH, HTTPS or SEC-Stick)

–The port which is used for listening with enabled TCP en­capsulation function

IP Fragmentation

IKE fragmentation

UDP packets can be oversized if an IPsec connection is es­tablished between the participating devices via IKE and certif­icates are exchanged. Some routers are not capable of for­warding large UDP packets if they are fragmented over the transmission path (e.g., via DSL in 1500-byte segments). Some faulty devices forward the first fragment only, resulting in connection failure.

If two mGuard devices communicate with each other, it is pos­sible to ensure at the outset that only small UDP packets are to be transmitted. This prevents packets from being frag­mented during transmission, which can result in incorrect rout­ing by some routers.

If you want to use this option, activate the function.

IPsec MTU (default is 16260)

The option for avoiding oversized IKE data packets, which cannot be routed correctly on the transmission path by faulty routers, can also be applied for IPsec data packets.

In order to remain below the upper limit of 1500 bytes often set by DSL, it is recommended that a value of 1414 (bytes) be set. This also allows enough space for additional headers.

If you want to use this option, specify a value lower than the default setting.

DynDNS Monitoring

Watch hostnames of remote VPN gateways

If the mGuard has the address of a VPN peer in the form of a host name (see "Defining a new VPN connection/VPN con­nection tunnel" on page 322) and this host name is registered with a DynDNS service, then the mGuard can check the rele­vant DynDNS at regular intervals to determine whether any changes have occurred. If so, the VPN connection will be es­tablished to the new IP address.

Refresh interval

Default: 300 seconds

NOTE: Use secure encryption and hash algorithms (see "Using secure encryption and hash algorithms" on page 21).

License Status

VPN license counter

Number of peers that currently have a VPN connection estab­lished using the IPsec protocol.

OpenVPN license counter

Number of peers to which a VPN connection is currently es­tablished using the OpenVPN protocol.

Connections

Initial mode

Disabled / Stopped / Started

The “Disabled” setting deactivates the VPN connection per­manently; it cannot be started or stopped.

The “Started” and “Stopped” settings determine the state of the VPN connection after restarting/booting the mGuard (e.g., after an interruption in the power supply).

VPN connections that are not deactivated can be started or stopped via icons on the web interface, via text message, a switch, a pushbutton, data traffic or the script nph-vpn.cgi.

State

Indicates the current activation state of the IPsec VPN con­nection.

ISAKMP SA

Indicates whether or not the corresponding ISAKMP SA has been established.

IPsec SA

Indicates how many of the configured tunnels are established. The number of established tunnels may be higher than the number of configured tunnels, if the “Tunnel Group” function is used.

Name

Name of the VPN connection

Using the command line tool wget only functions in combination with mGuard firmware versions < 8.4.0. From mGuard firmware Version 8.4.0, the command line tool curl can be used (parameters and options differ!).

Example: curl --insecure "https://admin:mGuard@192.168.1.1/nph-vpn.cgi?name=Athen&cmd=up"

The admin password and the name that an action relates to may only contain the following characters:

–Letters: A - Z, a - z

–Numbers: 0 - 9

–Characters: - . _ ~

Other characters, such as a space or question mark, must be encoded accordingly (see "Encoding of special characters (URL encoding)" on page 453).

unknown

A VPN connection with this name does not exist.

void

The connection is inactive due to an error, e.g., the external network is down or the host name of the peer could not be resolved in an IP address (DNS).

The response “void” is also issued by the CGI interface, even if no error oc­curred. If, for example, the VPN connection is deactivated according to the configuration (No set in column) and has not been enabled temporarily using the CGI interface or CMD contact.

ready

The connection is ready to establish tunnels or allow incoming queries re­garding tunnel setup.

active

At least one tunnel has already been established for the connection.

Options

A descriptive name for the connection

The connection can be freely named/renamed. If several con­nection tunnels are defined under , then this name applies to the entire set of VPN connection tunnels grouped under this name.

Similarities between VPN connection tunnels:

–Same authentication method, as specified on the Authen­tication tab page (see "Authentication" on page 342)

–Same firewall settings

–Same IKE options set

Initial mode

Disabled / Stopped / Started

The “Disabled” setting deactivates the VPN connection per­manently; it cannot be started or stopped.

The “Started” and “Stopped” settings determine the status of the VPN connection after restarting/booting the mGuard (e.g., after an interruption in the power supply).

VPN connections that are not deactivated can be started or stopped via icons on the web interface, via text message, a switch, a pushbutton, data traffic or the script nph-vpn.cgi.

Address of the remote site's VPN gateway

An IP address, host name or %any for several peers or peers downstream of a NAT router.

%any can only be used together with the authentication method using X.509 certificates.

If locally stored CA certificates are to be used to authenticate the peer, the address of the remote site's VPN gateway can be specified explicitly (by means of an IP address or host name) or by %any. If it is specified using an explicit address (and not by “%any”), then a VPN identifier (see "VPN Identifier" on page 345) must be specified.

%any must be selected if the peer is located downstream of a NAT gateway. Otherwise, the renegotiation of new connection keys will fail on initial contact.

If TCP encapsulation is used (see "TCP encapsulation" on page 315): a fixed IP address or a host name must be specified if this mGuard is to initiate the VPN connection and en­capsulate the VPN data traffic.

If this mGuard is installed upstream of a maintenance center to which multiple remote mGuard devices establish VPN connections and transmit encapsulated data packets, %any must be specified for the VPN gateway of the peer.

Options

Address of the remote site's VPN gateway

IP address, host name or “%any” for any IP addresses, several peers or peers downstream of a NAT router.

Interface to use for gateway setting %any

(If %any was specified for “Ad­dress of the remote site's VPN gateway”)

Internal, External, External 2, Dial-in, DMZ, Implicitly cho­sen by the IP address specified to the right

External 2 and Dial-in are only for devices with a serial inter­face, see "Network >> Interfaces" on page 131.

Selection of the Internal option is not permitted in Stealth mode.

This interface setting is only considered when “%any” is en­tered as the address of the remote site's VPN gateway. In this case, the interface of the mGuard through which it answers and permits requests for the establishment of this VPN con­nection is set here.

The VPN connection can be established through the LAN and WAN port in all Stealth modes when External is selected.

The interface setting allows encrypted communication to take place over a specific interface for VPN peers without a known IP address. If an IP address or host name is entered for the peer, then this is used for the implicit assignment to an inter­face.

The mGuard can be used as a “single-leg router” in Router mode when Internal is selected, as both encrypted and de­crypted VPN traffic for this VPN connection is transferred over the internal interface.

IKE and IPsec data traffic is only possible through the primary IP address of the individual assigned interface. This also ap­plies to VPN connections with a specific peer.

DMZ can only be selected in Router mode. Here, VPN con­nections can be established to hosts in the DMZ and IP pack­ets can be routed from the DMZ in a VPN connection.

Implicitly chosen by the IP address below: an IP address is used instead of a dedicated interface.

IP address to use for gateway setting %any

IP address that is used for gateway setting %any.

Connection startup

Initiate / Initiate on traffic / Wait

Initiate

The mGuard initiates the connection to the peer. The fixed IP address of the peer or its name must be entered in the Ad­dress of the remote site's VPN gateway field (see above).

Initiate on traffic

The connection is initiated automatically when the mGuard sees that the connection should be used.

(Can be selected for all operating modes of the mGuard (Stealth, Router, etc.))

Wait

The mGuard is ready to allow the connection to the mGuard that a remote peer actively initiates and establishes.

Controlling service input

(Only available with the TC MGUARD RS4000/RS2000 3G, TC MGUARD RS4000/RS2000 4G, FL MGUARD RS4000/RS2000, FL MGUARD GT/GT, FL MGUARD RS4004/RS2005 and FL MGUARD RS.)

None / Service input CMD 1-3

The VPN connection can be switched via a connected push­button/switch.

The pushbutton/switch must be connected to one of the ser­vice contacts (CMD 1-3).

Use inverted control logic

Inverts the behavior of the connected switch.

If the switching service input is configured as an on/off switch, it can activate one VPN connection while simultaneously de­activating another which uses inverted logic, for example.

Deactivation timeout

Time, after which the VPN connection is stopped, if it has been started via a text message, switch, pushbutton, nph-vpn.cgi or the web interface. The timeout starts on transition to the “Started” state.

After the timeout has elapsed, the connection remains in the “Stopped” state until it is restarted.

Exception: “Initiate on traffic”

A connection initiated (established) by data traffic is released after the timeout has elapsed, but remains in the “Started” state. The timeout only starts once there is no more data traf­fic.

The VPN connection is established again when data traffic re­sumes.

Time in hours, minutes and/or seconds (00:00:00 to 720:00:00, around 1 month). The entry can be in seconds [ss], minutes and seconds [mm:ss] or hours, minutes, and seconds [hh:mm:ss].

0 means the setting is disabled.

Token for text mes­sage trigger

(Only available with the TC MGUARD RS4000/RS2000 3G, TC MGUARD RS4000/RS2000 4G.)

Incoming text messages can be used to start or stop VPN con­nections. The text message must contain the “vpn/start” or “vpn/stop” command followed by the token.

Encapsulate the VPN traffic in TCP

No / TCP encapsulation / Path Finder (default: No)

If the TCP encapsulation function is used (see "TCP encap­sulation" on page 315), only set this option to TCP encapsula­tion if the mGuard is to encapsulate its own outgoing data traf­fic for the VPN connection it initiated. In this case, the number of the port where the peer receives the encapsulated data packets must also be specified.

TPC encapsulation can also be used with the “Path Finder” function (see "TCP encapsulation with enabled “Path Finder” function" on page 316). In this case, only set this option to Path Finder if the peer also supports the “Path Finder” func­tion. The number of the port where the peer receives the en­capsulated data packets must then also be specified.

For TCP encapsulation / Path Finder the mGuard does not at­tempt to create the VPN connection via the standard IKE en­cryption (UDP-Port 500 and 4500), but always sends it via TCP protocol.

Connection startup setting when using TCP encapsula­tion/Path Finder

–If the mGuard is to establish a VPN connection to a main­tenance center and encapsulate the data traffic there:

–“Initiate” or “Initiate on traffic” must be specified.

–If the mGuard is installed at a maintenance center to which mGuard devices establish a VPN connection:

–“Wait” must be specified.

TCP-Port of the server, which accepts the encapsulated connec­tion

(Only visible if “Encapsulate the VPN traffic in TCP” is set to TCP encapsulation or Path Finder.)

Default: 8080

Number of the port where the encapsulated data packets are received by the peer. The port number specified here must be the same as the one specified for the mGuard of the peer under TCP port to listen on (IPsec VPN >> Global >> Options menu item).

Mode Configuration

The mGuard supports the "Extended Authentication" authentication method (XAuth) and the frequently required "Mode Config" protocol extension including "Split Tunneling“ as the server and as the client (including iOS and Android-support). Network settings and DNS and WINS configurations are communicated to the IPsec client by the IPsec server.

Mode configuration

Off / Server / Client (default: Off)

In order to communicate via an IPsec VPN connection as the server or client with peers that require “XAuth” and “Mode Config”, select “Server” or “Client”.

Off: do not use “Mode Config”.

Server: communicate the IPsec network configuration to the peer.

Client: accept and apply the IPsec network configuration communicated by the peer.

Settings as server

Allows clients that require “XAuth” and “Mode Config” (e.g., Apple iPad) to establish an IPsec VPN connection to the mGuard. The remote clients receive the necessary values for configuring the connection (local and remote network) from the mGuard.

Local

Fixed / From table below

Fixed: the local network on the server side is manually set and fixed and must also be set manually on the client side (on the remote client).

From table below: the local network(s) on the server side is/are communicated to the remote client using the split tun­neling extension.

Entry in CIDR format (see "CIDR (Classless Inter-Domain Routing)" on page 29).

Local IP network

(If “Fixed” was selected)

Local network at the server end in CIDR format.

Networks

(If “From table below” was se­lected)

Local network at the server end in CIDR format.

Remote

From pool below / From table below

From pool below

The server dynamically selects IP networks for the peer from the specified pool according to the selected tranche size.

From table below

(This function can only be used if an mGuard is used at the peer.)

The IP networks of the peer are communicated to the remote client using the split tunneling extension.

Remote IP network pool

(If “From pool” was selected)

Network pool from which IP networks for the peer are se­lected, in CIDR format.

Tranches of size (net­work size between 0 and 32)

(If “From pool” was selected)

Section sizes which determine the size of the IP networks which can be taken from the network pool for the peer.

Networks

(If “From table below” was se­lected)

IP networks for the peer in CIDR format.

1st and 2nd DNS server for the peer

Address of a DNS server which is communicated to the peer. The setting 0.0.0.0 means “no address”.

1st and 2nd WINS server for the peer

Address of a WINS server which is communicated to the peer. The setting 0.0.0.0 means “no address”.

Settings as client

Allows the mGuard to establish an IPsec VPN connection to servers that require “XAuth” and “Mode Config”. As an option, the mGuard receives the necessary values (IP ad­dress/IP network) for configuring the connection (local and remote network) from the re­mote server of the peer.

Local NAT

(Not active in Stealth modes “Autodetect” and “Static”)

No NAT / Masquerade

No NAT

Local IP addresses selected by the server can use the tunnel.

Masquerade

The mGuard can masquerade its local network. To do this, the local network must be specified in CIDR format (see "CIDR (Classless Inter-Domain Routing)" on page 29).

Local IP network

IP network at the local interface of the client that is masquer­aded.

Remote

Fixed / From Server

Fixed: the local network on the client side is manually set and fixed and must also be set manually on the server side (on the remote server).

From Server: the remote network(s) on the server side is/are communicated to the local client using the split tunneling ex­tension.

If the remote server does not use split tunneling, 0.0.0.0/0 is used.

Remote IP network

(If “Fixed” was selected)

The network of the remote server in CIDR format.

XAuth login

Some remote servers require an XAuth user name (login) and an XAuth password in order to authenticate the client.

XAuth password

Corresponding XAuth password

Transport and Tunnel Set­tings

Enabled

Specify whether the connection tunnel should be active or not.

Comment

Freely selectable comment text. Can be left empty.

Type

The following can be selected:

–Tunnel (network ↔ network)

–Transport (host ↔ host)

Tunnel (network ↔ network)

This connection type is suitable in all cases and is also the most secure. In this mode, the IP datagrams to be transmitted are completely encrypted and are, with a new header, trans­mitted to the VPN gateway of the peer – the “tunnel end”. The transmitted datagrams are then decrypted and the original da­tagrams are restored. These are then forwarded to the desti­nation computer.

Transport (host ↔ host)

For this type of connection, only the data of the IP packets is encrypted. The IP header information remains unencrypted.

When you switch to Transport, the following fields (apart from Protocol) are hidden as these parameters are omitted.

Local

(For “Tunnel” connection type)

Define the network areas for both tunnel ends under Local and Remote.

Local: here, specify the address of the network or computer which is connected locally to the mGuard.

Remote

(For “Tunnel” (network ↔ net­work) connection type)

Remote: here, specify the address of the network or computer which is located downstream of the remote VPN gateway.

Local NAT

(For “Tunnel” connection type)

No NAT / 1:1 NAT / Masquerade

It is possible to translate the IP addresses of devices located at the respective end of the VPN tunnel.

No NAT: NAT is not performed.

With 1:1 NAT, the IP addresses of devices at the local end of the tunnel are exchanged so that each individual address is translated into another specific address.

With Masquerade, the IP addresses of devices at the local end of the tunnel are exchanged with an IP address that is identical for all devices.

Remote NAT

(For “Tunnel” connection type)

No NAT / 1:1 NAT / Masquerade

No NAT: NAT is not performed.

With 1:1 NAT, the IP addresses of devices of the tunnel peer are exchanged so that each individual address is translated into another specific address.

With Masquerade, the IP addresses of devices of the peer are exchanged with an IP address that is identical for all de­vices.

Click on the  Edit Row icon to make further settings. The “IPsec VPN >> Connections >> Transport and Tunnel Settings >> General” window opens.

Transport and Tunnel Settings (Edit)

Options

Enabled

Specify whether the connection tunnel should be active or not.

Comment

Freely selectable comment text. Can be left empty.

Type

The following can be selected:

–Tunnel (network ↔ network)

–Transport (host ↔ host)

Tunnel (network ↔ network)

This connection type is suitable in all cases and is also the most secure. In this mode, the IP datagrams to be transmitted are completely encrypted and are, with a new header, trans­mitted to the VPN gateway of the peer – the “tunnel end”. The transmitted datagrams are then decrypted and the original da­tagrams are restored. These are then forwarded to the desti­nation computer.

Transport (host ↔ host)

For this type of connection, only the data of the IP packets is encrypted. The IP header information remains unencrypted.

When you switch to Transport, the following fields (apart from Protocol) are hidden as these parameters are omitted.

Local

(For “Tunnel” connection type)

Define the network areas for both tunnel ends under Local and Remote.

Local: here, specify the address of the network or computer which is connected locally to the mGuard.

Remote

(For “Tunnel” connection type)

Remote: here, specify the address of the network or computer which is located downstream of the remote VPN gateway.

Local NAT

Local NAT for IPsec tunnel connections

(For “Tunnel” connection type)

No NAT / 1:1 NAT / Masquerade

It is possible to translate the IP addresses of devices located at the respective end of the VPN tunnel.

No NAT: NAT is not performed.

With 1:1 NAT, the IP addresses of devices at the local end of the tunnel are exchanged so that each individual address is translated into another specific address.

With Masquerade, the IP addresses of devices at the local end of the tunnel are exchanged with an IP address that is identical for all devices.

If local devices transmit data packets, only those data packets are considered which:

–Are actually encrypted by the mGuard (the mGuard only forwards packets via the VPN tunnel if they originate from a trustworthy source).

–Originate from a source address within the network which is defined here.

–Have their destination address in the Remote network if 1:1 NAT is not set there for the peer.

The data packets of local devices are assigned a source ad­dress according to the address set under Local and are trans­mitted via the VPN tunnel.

You can specify 1:1 NAT rules for each VPN tunnel for local devices. In this way, an IP area that is distributed over a wide network can be gathered and sent through a narrow tunnel.

Real network

Configures the “From IP” address for 1:1 NAT.

Virtual network

Configures the translated IP address for 1:1 NAT.

Netmask

The netmask as a value between 1 and 32 for the real and vir­tual network address (see also "CIDR (Classless Inter-Do­main Routing)" on page 29).

Comment

Can be filled with appropriate comments.

Internal network address for local mas­querading

(When “Masquerade” is se­lected)

If local devices transmit data packets, only those data packets are considered which:

–Are actually encrypted by the mGuard (the mGuard only forwards packets via the VPN tunnel if they originate from a trustworthy source).

–Originate from a source address within the network which is defined here.

–Have their destination address in the Remote network if 1:1 NAT is not set for the Remote NAT.

Only one IP address (subnet mask /32) is permitted as the VPN network for this setting. The network to be masqueraded is translated to this IP address.

The data packets are then transmitted via the VPN tunnel. Masquerading changes the source address (and source port). The original addresses are recorded in an entry in the Conn­track table.

Where response packets are received via the VPN tunnel and there is a matching entry in the Conntrack table, these packets have their destination address (and destination port) written back to them.

Remote NAT

Remote NAT for IPsec tunnel connections

(For “Tunnel” connection type)

No NAT / 1:1 NAT / Masquerade

It is possible to translate the IP addresses of devices located at the respective end of the VPN tunnel.

With Remote 1:1 NAT, the IP addresses of devices of the tun­nel peer are exchanged so that each individual address is translated into another specific address.

With Masquerade set for the peer network, the IP addresses of devices of the peer are exchanged with an IP address that is identical for all devices.

Network address for 1:1 NAT

(For selection "1:1-NAT")

If local devices transmit data packets, only those data packets are considered which:

–Are actually encrypted by the mGuard (the mGuard only forwards packets via the VPN tunnel if they originate from a trustworthy source).

–Have a source address within the network which is de­fined here under Local.

The data packets are assigned a destination address from the network that is set under Remote. If necessary, the source ad­dress is also replaced (see Local). The data packets are then transmitted via the VPN tunnel.

Internal IP address used for remote mas­querading

(When “Masquerade” is se­lected)

Only one IP address (subnet mask /32) is permitted as the VPN network for this setting. The network to be masqueraded is translated to this IP address.

The data packets are then transmitted via the VPN tunnel. Masquerading changes the source address (and source port). The original addresses are recorded in an entry in the Conn­track table.

Where response packets are received via the VPN tunnel and there is a matching entry in the Conntrack table, these packets have their destination address (and destination port) written back to them.

Protocol

Protocol

All means TCP, UDP, ICMP, and other IP protocols

Local port (only for TCP/UDP): number of the port to be used.

Select “%all” for all ports, a number between 1 and 65535 or “%any” to leave the decision to the client.

Remote port (only for TCP/UDP): number of the port to be used.

Select “%all” for all ports, a number between 1 and 65535 or “%any” to leave the decision to the client.

Dynamic Routing

Add kernel route to remote network to allow OSPF route redistribution

(Only if OSPF is activated)

When the function is activated, a kernel route to the remote network (peer) is added in order to enable distribution by means of OSPF.

In Stealth mode, a default route over the VPN cannot be used.

Local mGuard

Remote mGuard A

Local

Remote

Local

Remote

10.0.0.0/8

10.0.0.0/8

>

10.1.7.0/24

10.0.0.0/8

Remote mGuard B

Local

Remote

>

10.3.9.0/24

10.0.0.0/8

etc.

Can only be used for Tunnel VPN type.

Masquerade can be used in the following network modes: Router, PPPoE, PPTP, Mo­dem, Built-in modem, Built-in mobile network modem, and Stealth (only “Multiple clients” in Stealth mode).

Modem / Built-in modem / Built-in mobile network modem: not available for all mGuard models (see "Network >> Interfaces" on page 131).

For IP connections via a VPN connection with active masquerading, the firewall rules for outgoing data in the VPN connection are used for the original source address of the con­nection.

Can only be used for Tunnel VPN type.

Authentication

Authentication method

There are two options:

–X.509 Certificate (default setting)

–Pre-shared key (PSK)

The page contains different setting options depending on the method chosen.

Authentication method: X.509 Certificate

This method is supported by most modern IPsec implementa­tions. With this option, each VPN device has a secret private key and a public key in the form of an X.509 certificate, which contains further information about the certificate's owner and the certification authority (CA).

The following must be specified:

–How the mGuard authenticates itself to the peer

–How the mGuard authenticates the remote peer

How the mGuard authenticates itself to the peer 

Local X.509 certificate

(Authentication method: “X.509 Certificate”)

Specifies which machine certificate the mGuard uses as au­thentication to the VPN peer.

Select one of the machine certificates from the selection list.

The selection list contains the machine certificates that have been loaded on the mGuard under the Authentication >> Cer­tificates menu item.

How the mGuard authenticates the remote peer

The following definition relates to how the mGuard verifies the authenticity of the VPN re­mote peer.

The table below shows which certificates must be provided for the mGuard to authenti­cate the VPN peer if the VPN peer shows one of the following certificate types when a con­nection is established:

–A machine certificate signed by a CA

–A self-signed machine certificate

Remote CA certificate

The following selection options are available:

–Signed by any trusted CA

–No CA certificate, but the Remote Certificate below

–Name of a CA certificate if available

Remote certificate

(For authentication using re­mote certificate)

You can upload the remote certificate. The certificate is se­lected and stored in the list of remote certificates (see "Re­mote Certificates" on page 254).

The peer shows the fol­lowing:

Machine certificate, signed by CA

Machine certificate, self-signed

The mGuard authenti­cates the peer using:

Remote certificate

Or all CA certificates that form the chain to the root CA certificate together with the certificate shown by the peer

Remote certificate

If the use of revocation lists (CRL checking) is activated under the Authentication >> Cer­tificates, Certificate Settings menu item, each certificate signed by a CA that is “shown” by the VPN peer is checked for revocations.

However, an existing VPN connection is not immediately terminated by a withdrawn cer­tificate if the CRL update is being performed during the existing VPN connection. Never­theless, it is no longer possible to exchange keys again (rekeying) or restart the VPN connection.

It is not possible to reference a remote certificate loaded under the Authentication >> Cer­tificates menu item.

It is not possible to reference a remote certificate loaded under the Authentication >> Cer­tificates menu item.

VPN Identifier

Authentication method: CA certificate

The following explanation applies if the VPN peer is authenticated using CA certificates.

VPN gateways use the VPN identifier to detect which configurations belong to the same VPN connection.

If the mGuard consults CA certificates to authenticate a VPN peer, then it is pos­sible to use the VPN identifier as a filter.

•Make a corresponding entry in the Remote field.

Local

Default: empty field

The local VPN identifier can be used to specify the name the mGuard uses to identify itself to the peer. It must match the data in the machine certificate of the mGuard.

Valid values:

–Empty, i.e., no entry (default). The “Subject” entry (previ­ously Distinguished Name) in the machine certificate is then used.

–The “Subject” entry in the machine certificate.

–One of the Subject Alternative Names, if they are listed in the certificate. If the certificate contains Subject Alterna­tive Names, these are specified under “Valid values:”. These can include IP addresses, host names with “@” prefix or e-mail addresses.

Remote

Specifies what must be entered as a subject in the machine certificate of the VPN peer for the mGuard to accept this VPN peer as a communication partner.

It is then possible to restrict or enable access by VPN peers, which the mGuard would accept in principle based on certifi­cate checks, as follows:

–   Restricted access to certain subjects (i.e., machines) and/or to subjects that have certain attributes or

–   Access enabled for all subjects

(See "Subject, certificate" on page 449.)

Access enabled for all subjects:

If the Remote field is left empty, then any subject entries are permitted in the machine cer­tificate shown by the VPN peer. It is then no longer necessary to identify or define the sub­ject in the certificate.

Restricted access to certain subjects:

In the certificate, the certificate owner is specified in the Subject field. The entry is com­prised of several attributes. These attributes are either expressed as an object identifier (e.g., 132.3.7.32.1) or, more commonly, as an abbreviation with a corresponding value.

Example: CN=VPN endpoint 01, O=Smith and Co., C=US

If certain subject attributes have very specific values for the acceptance of the VPN peer by the mGuard, then these must be specified accordingly. The values of the other freely selectable attributes are entered using the * (asterisk) wildcard.

Example: CN=*, O=Smith and Co., C=US (with or without spaces between attributes)

In this example, the attributes “O=Smith and Co.” and “C=US” should be entered in the certificate that is shown under “Subject”. It is only then that the mGuard would accept the certificate owner (subject) as a communication partner. The other attributes in the certifi­cates to be filtered can have any value.

Authentication

Authentication method: Pre-shared key (PSK)

This method is mainly supported by older IPsec implementations. In this case, both sides of the VPN authenticate themselves using the same PSK.

To make the agreed key available to the mGuard, proceed as follows:

•Enter the agreed string in the Pre-shared key (PSK) input field.

ISAKMP mode

Main Mode (secure)

In Main Mode, the party wishing to establish the connection (initiator) and the responder negotiate an ISAKMP SA.

We recommend using certificates in Main Mode.

Aggressive Mode (insecure)

Encryption for Aggressive Mode is not as secure as for Main Mode. The use of this mode can be justified if the responder does not know the initiator's address in advance, and both parties wish to use pre-shared keys for authentication. An­other reason may be to achieve faster connection establish­ment when the responder's credentials are already known, e.g., an employee wishing to access the company network.

Requirement:

–Cannot be used together with the redundancy function.

–The same mode must be used between peers.

–Aggressive mode is not supported in conjunction with XAuth/Mode Config.

–If two VPN clients downstream of the same NAT gateway establish the same connection to a VPN gateway, they must use the same PSK.
VPN connections in Aggressive Mode and with PSK au­thentication, which are to be implemented by means of a NAT gateway, must use unique VPN identifiers on both the client and the gateway.

VPN Identifier

VPN gateways use the VPN Identifier to detect which configurations belong to the same VPN connection.

The following entries are valid for PSK:

–Empty (IP address used by default)

–An IP address

–A host name with “@” prefix (e.g., “@vpn1138.example.com”)

–An e-mail address (e.g., “piepiorra@example.com”)

By default, the VPN firewall is set to allow all connections for this VPN connection.

However, the extended firewall settings defined and explained above apply independent­ly for each individual VPN connection (see "Network Security menu" on page 259, "Net­work Security >> Packet Filter" on page 259, "Advanced" on page 278).

If multiple firewall rules are defined, these are queried starting from the top of the list of entries until an appropriate rule is found. This rule is then applied. If the list of rules con­tains further subsequent rules that could also apply, these rules are ignored.

In Stealth mode, the actual IP address used by the client should be used in the firewall rules, or it should be left at 0.0.0.0/0, as only one client can be addressed through the tun­nel.

If the Allow packet forwarding between VPN connections function is activated on the Global tab page, the rules under Incoming are used for the incoming data packets to the mGuard, and the rules under Outgoing are applied to the outgoing data packets.

If the outgoing data packets are included in the same connection definition (for a defined VPN connection group), then the firewall rules for Incoming and Outgoing for the same connection definition are used.

If a different VPN connection definition applies to the outgoing data packets, the firewall rules for Outgoing for this other connection definition are used.

If the mGuard has been configured to forward SSH connection packets (e.g., by permit­ting a SEC-Stick hub & spoke connection), existing VPN firewall rules are not applied. This means, for example, that packets of an SSH connection are sent through a VPN tun­nel despite the fact that this is prohibited by its firewall rules.

Incoming

General firewall set­ting

Accept all incoming connections: the data packets of all in­coming connections are allowed.

Drop all incoming connections: the data packets of all in­coming connections are discarded.

Accept Ping only: the data packets of all incoming connec­tions are discarded, except for ping packets (ICMP).

Use the firewall ruleset below: displays further setting op­tions.

The following settings are only visible if “Use the firewall ruleset below” is set.

Protocol

All means TCP, UDP, ICMP, GRE, and other IP protocols.

From IP/To IP

0.0.0.0/0 means all IP addresses. To specify an address area, use CIDR format (see "CIDR (Classless Inter-Domain Rout­ing)" on page 29).

Name of IP groups, if defined. When a name is specified for an IP group, the host names, IP addresses, IP areas or net­works saved under this name are taken into consideration (see "IP/Port Groups" on page 276).

Incoming:

–From IP:   IP address in the VPN tunnel

–To IP:   1:1 NAT address or the actual address

Outgoing:

–From IP:   1:1 NAT address or the actual address

–To IP:   IP address in the VPN tunnel

From port / To port

(Only for TCP and UDP proto­cols)

any refers to any port.

startport:endport (e.g., 110:120) refers to a port range.

Individual ports can be specified using the port number or the corresponding service name (e.g., 110 for pop3 or pop3 for 110).

Name of port groups, if defined. When a name is specified for a port group, the ports or port ranges saved under this name are taken into consideration (see "IP/Port Groups" on page 276).

Action

Accept means that the data packets may pass through.

Reject means that the data packets are sent back and the sender is informed of their rejection. (In Stealth mode, Reject has the same effect as Drop.)

Drop means that the data packets are not permitted to pass through. They are discarded, which means that the sender is not informed of their whereabouts.

Name of rule sets, if defined. When a name is specified for rule sets, the firewall rules configured under this name take ef­fect (see "Rule Records" on page 270 tab page).

Name of Modbus TCP rule sets, if defined. When a Modbus TCP rule set is selected, the firewall rules configured under this rule set take effect (see "Modbus TCP" on page 283).

Comment

Freely selectable comment for this rule.

Log

For each individual firewall rule, you can specify whether the use of the rule:

–Should be logged – activate Log function

–Should not be logged – deactivate Log function (default)

Log entries for unknown connection attempts

When the function is activated, all connection attempts that are not covered by the rules defined above are logged.

Outgoing

The explanation provided under “Incoming” also applies to “Outgoing”.

ISAKMP SA (Key Exchange)

Algorithms

(This preference list starts with the most preferred pair of algorithms.)

Encryption

DES, 3DES, AES-128, AES-192, AES-256 (default)

The following applies in principle: the longer the encryption length (in Bits) which uses an encryption algorithm (stated by the appended number), the more secure it is.

The longer the key, the more time-consuming the encryption procedure. However, this does not affect the mGuard as it uses a hardware-based encryption technique. Nevertheless, this aspect may be of significance for the peer.

The algorithm designated as “Null” does not contain encryp­tion.

Checksum

MD5, SHA1, SHA-256 (default), SHA-512

Leave this set to All algorithms. It is then of no consequence whether the peer works with MD5, SHA-1, SHA-256, SHA-384 or SHA-512.

Diffie-Hellman

The Diffie-Hellman key exchange method is not available for all the algorithms. The bit depth for the encryption can be set here.

IPsec SA (Data Exchange)

In contrast to ISAKMP SA (Key Exchange) (see above), the procedure for data exchange is defined here. It does not necessarily have to differ from the procedure defined for key exchange.

Algorithms

See above: ISAKMP SA (Key Exchange).

Perfect Forward Secrecy (PFS)

Method for providing increased security during data transmis­sion. With IPsec, the keys for data exchange are renewed at defined intervals.

With PFS, new random numbers are negotiated with the peer instead of being derived from previously agreed random num­bers.

The peer must have the same entry. We recommend enabling this setting for security reasons.

Lifetimes and Limits

The keys of an IPsec connection are renewed at defined intervals in order to increase the difficulty of an attack on an IPsec connection.

ISAKMP SA lifetime

Lifetime in seconds (hh:mm:ss) of the keys agreed for ISAKMP SA. Default setting: 3600 seconds (1 hour). The max­imum permitted lifetime is 86400 seconds (24 hours).

IPsec SA lifetime

Lifetime in seconds (hh:mm:ss) of the keys agreed for IPsec SA.

Default setting: 28800 seconds (8 hours). The maximum per­mitted lifetime is 86400 seconds (24 hours).

IPsec SA traffic limit

0 to 2147483647 bytes

The value 0 indicates that there is no traffic limit for the IPsec SAs on this VPN connection.

All other values indicate the maximum number of bytes which are encrypted by the IPsec SA for this VPN connection (Hard Limit).

Re-key margin for life­times

Applies to ISAKMP SAs and IPsec SAs.

Minimum duration before the old key expires and during which a new key should be created. Default setting: 540 seconds (9 minutes).

Re-key margin for the traffic limit

Only applies to IPsec SAs.

The value 0 indicates that the traffic limit is not used.

0 must be set here when 0 is also set under IPsec SA traffic limit.

If a value above 0 is entered, then a new limit is calculated from two values. The number of bytes entered here is sub­tracted from the value specified under IPsec SA traffic limit (i.e., the Hard Limit).

The calculated value is then known as the Soft Limit. This specifies the number of bytes which must be encrypted for a new key to be negotiated for the IPsec SA.

A further amount is subtracted when a re-key fuzz (see below) above 0 is entered. This is a percentage of the re-key margin. The percentage is entered under Re-key fuzz.

The re-key margin value must be lower than the Hard Limit. It must be significantly lower when a Re-key fuzz is also added.

If the IPsec SA lifetime is reached earlier, the Soft Limit is ig­nored.

Re-key fuzz

Maximum percentage by which the Re-key margin should be randomly increased. This is used to delay key exchange on machines with multiple VPN connections. Default setting: 100 percent.

Keying tries

Number of attempts to negotiate new keys with the peer.

The value 0 results in unlimited attempts for connections initi­ated by the mGuard, otherwise it results in 5 attempts.

Dead Peer Detection

If the peer supports the Dead Peer Detection (DPD) protocol, the relevant peers can de­tect whether or not the IPsec connection is still active and whether it needs to be estab­lished again.

Delay between requests for a sign of life

Duration in seconds after which DPD Keep Alive requests should be transmitted. These requests test whether the peer is still available.

Default setting: 30 seconds (00:00:30).

Timeout for absent sign of life after which peer is assumed dead

Duration in seconds after which the connection to the peer should be declared dead if there has been no response to the Keep Alive requests.

Default setting: 120 seconds (00:02:00).

These settings do not apply in Stealth mode.

It is not possible to use the MD5 algorithm under Windows 7. The MD5 algorithm must be replaced by SHA-1.

Settings

Start L2TP server for IPsec/L2TP

If you want to enable IPsec/L2TP connections, activate the function.

It is then possible to establish L2TP connections to the mGuard via IPsec, which dynamically assign IP addresses to the clients within the VPN.

Local IP for L2TP con­nections

If set as shown in the screenshot above, the mGuard will in­form the peer that its address is 10.106.106.1.

Remote IP range start/end

If set as shown in the screenshot above, the mGuard will as­sign the peer an IP address between 10.106.106.2 and 10.106.106.254.

Status

Displays information about the L2TP status if this connection type has been selected.

ISAKMP SA

Local

–Local IP address

–Local port

–ID = subject of an X.509 certificate

State, lifetime, and encryption algorithm for the connection (bold = active)

Remote

–Remote IP address

–Local port

–ID = subject of an X.509 certificate

IPsec SA

–Name of the connec­tion

–Local networks ... Re­mote networks

State, lifetime, and encryption algorithm for the connection (bold = active)