Innominate rs4000 3G, Switch,, rs2000 3G, Switch,, centerport ²,, industrial rs, smart ²,, pci ² SD, pcie ² SD, blade, delta ², mGuard, EAGLE mGuard Reference Manual
Below you will find brief product information for mGuard rs4000 3G, mGuard rs4000 Switch, mGuard rs4000, mGuard rs2000 3G, mGuard rs2000 Switch, mGuard rs2000, mGuard centerport², mGuard centerport, mGuard industrial rs, mGuard smart², mGuard smart, mGuard pci² SD, mGuard pcie² SD, mGuard blade, mGuard delta², mGuard delta, EAGLE mGuard. The mGuard is a versatile security appliance that can be used in various network configurations to protect data and secure connections. The mGuard offers a range of security features including a hardware-based VPN router, a configurable firewall, and an anti-virus scanner. It can be used in stealth mode, network router mode, DMZ mode, and VPN gateway mode. The mGuard also supports various networking protocols such as DHCP, DNS, and SNMP.
advertisement
Firmware 8.3
Configuration of the mGuard Security Appliances
Software Reference Manual
Innominate
S e c u r i t y Te ch n o l o g i e s
Software Reference Manual mGuard Firmware 8.3
Configuration of the mGuard Security Appliances
2015-11-04
Designation:
Revision:
Order No.:
UM EN MGUARD 8.3
03
—
This user manual is valid for the mGuard software release 8.3 when using devices of the mGuard product range:
– mGuard 3G
– mGuard Switch
– mGuard
– mGuard
– mGuard
– mGuard rs
– mGuard
– mGuard
– mGuard SD
– mGuard SD
– mGuard
– mGuard
– mGuard
– EAGLE
Innominate Security Technologies I15020_en_03
Device mGuard rs4000 mGuard rs2000 mGuard rs4000 Switch mGuard rs2000 Switch mGuard rs4000 3G mGuard rs2000 3G mGuard delta² mGuard pci² SD mGuard smart² mGuard centerport² mGuard delta mGuard pci mGuard smart mGuard blade mGuard centerport
Supported devices
Model mGuard rs4000 TX/TX mGuard rs4000 TX/TX VPN mGuard rs2000 TX/TX VPN mGuard rs4000 4TX/TX mGuard rs4000 4TX/TX VPN mGuard rs2000 5TX/TX VPN mGuard rs4000 4TX/3G/TX VPN mGuard rs2000 4TX/3G VPN mGuard delta² TX/TX mGuard delta² TX/TX VPN mGuard pci² SD mGuard pcie² SD mGuard pci² SD VPN mGuard pcie² SDVPN mGuard smart² mGuard smart² VPN mGuard centerport² mGuard centerport² VPN 250 mGuard centerport² VPN 1000 mGuard delta mGuard pci / 533 mGuard pci / 266 mGuard pci / 533 VPN mGuard pci / 266 VPN mGuard smart / 266 mGuard smart / 533 mGuard smart / 266 VPN mGuard smart / 533 VPN mGuard blade / 533 mGuard blade / 266 mGuard bladebase mGuard bladepack / 533 mGuard bladepack / 266 mGuard centerport mGuard centerport VPN-250 mGuard centerport VPN-1000
BD-101030
HW-106010
BD-621000
BD-622000
HW-103050
HW-102050
HW-102020
BD-111020
BD-111010
HW-101020
HW-101050
BD-101010
BD-101020
HW-104050
HW-104020
HW-104500
Order number
HW-107010
BD-701000
HW-108010
HW-107020
BD-702000
HW-108020
BD-703000
HW-108030
HW-103060
BD-211010
HW-102061
HW-102071
BD-111040
BD-111060
HW-101130
HW-104850
HW-104820
HW-106000
BD-601000
BD-602000
Innominate Security Technologies
mGuard industrial rs
EAGLE mGuard mGuard industrial rs mGuard industrial rs Analog mGuard industrial rs ISDN mGuard industrial rs VPN mGuard industrial rs VPN Analog mGuard industrial rs VPN ISDN
EAGLE mGuard
EAGLE mGuard VPN
HW-105000
HW-105010
HW-105020
BD-501000
BD-501010
BD-501020
HW-201000
BD-301010
Innominate Security Technologies
Please observe the following notes
Target group of this user manual
The use of products described in this user manual is aimed solely at:
– Qualified electricians or persons instructed by them, who are familiar with applicable standards and other regulations regarding electrical engineering and, in particular, the relevant safety concepts.
– Qualified application programmers and software engineers, who are familiar with the safety concepts of automation technology as well as applicable standards and other regulations.
Explanation of symbols used and signal words
This symbol indicates hazards that could lead to personal injury. Obey all safety measures that follow this symbol to avoid possible injury or death.
There are three different categories of personal injury that are indicated by a signal word.
DANGER This indicates a hazardous situation which, if not avoided, will result in death or serious injury.
WARNING This indicates a hazardous situation which, if not avoided, could result in death or serious injury.
CAUTION This indicates a hazardous situation which, if not avoided, could result in minor or moderate injury.
This symbol together with the signal word NOTE and the accompanying text alert the reader to a situation which may cause damage or malfunction to the device, hardware/software, or surrounding property.
This symbol and the accompanying text provide the reader with additional information or refer to detailed sources of information.
Using Secure Passwords
Only use strong passwords, which contain uppercase and lowercase letters, numbers and non-alphanumerics (symbols). The passwords should be changed regularly.
Innominate Security Technologies
General terms and conditions of use for technical documentation
Innominate reserves the right to alter, correct, and/or improve the technical documentation and the products described in the technical documentation at its own discretion and without giving prior notice, insofar as this is reasonable for the user. The same applies to any changes that serve the purpose of technical progress.
The receipt of technical documentation (in particular user documentation) does not constitute any further duty on the part of Innominate to furnish information on modifications to products and/or technical documentation. You are responsible for verifying the suitability and intended use of the products in your specific application, in particular with regard to observing the applicable standards and regulations. All information made available in the technical data is supplied without any accompanying guarantee, whether expressly mentioned, implied or tacitly assumed.
In general, the provisions of the current standard Terms and Conditions of Innominate apply exclusively, in particular as concerns any warranty liability.
This user manual, including all illustrations contained herein, is copyright protected. Any changes to the contents or the publication of extracts of this document are prohibited.
Innominate reserves the right to register its own intellectual property rights for the product identifications of Innominate products that are used here. Registration of such intellectual property rights by third parties is prohibited.
Other product identifications may be afforded legal protection, even where they may not be indicated as such.
“Innominate” and “mGuard” are registered trade names of Innominate Security Technologies AG. mGuard technology is protected by patents 10138865 and 10305413, granted by the German Patent and Trademark Office, and by US patents 7,430,759 and 8,146,144.
Further patents are pending.
Published by
Innominate Security Technologies AG
Rudower Chaussee 13
12489 Berlin
Germany
Phone: +49 (0)30 92 10 28-0 [email protected]
www.innominate.com
© 4. November 2015 Innominate Security Technologies AG
Innominate Security Technologies
Table of contents
Stealth mode (Plug-n-Protect) .............................................................. 15
Resolving network conflicts .................................................................. 19
Input help during configuration (system messages)............................................. 22
Establishing OpenVPN connections .................................................... 27
Dynamic routing (OSPF) ...................................................................... 27
Support for GRE tunnels ...................................................................... 27
Client .................................................................................................... 27
New access check and modified test report creation (logging) for
Improved display of the VPN status (IPsec) ......................................... 28
New VPN license model ....................................................................... 28
Improved use of configuration profiles ................................................. 28
Improved timeout behavior for VPN connections ................................. 28
Support for XAuth and Mode Config (iOS support) .............................. 29
Optional use of the proxy server by the secondary external interface .. 29
User firewall in VPN connections ......................................................... 30
Function extension of the service contacts .......................................... 31
OPC Inspector for Deep Packet Inspection for OPC Classic ................ 32
New in CIFS Integrity Monitoring .......................................................... 34
Innominate Security Technologies
7
I15020_en_03
Management >> Update ...................................................................... 73
Management >> Central Management ................................................................ 96
Modem / Console ............................................................................... 148
8
Innominate Security Technologies I15020_en_03
I15020_en_03
Table of contents
IP and Port Forwarding ...................................................................... 164
Internal/External DHCP ...................................................................... 171
HTTP(S) Proxy Settings ..................................................................... 175
Mobile Network Notifications .............................................................. 185
Positioning system ............................................................................. 188
Machine Certificates .......................................................................... 215
Remote Certificates ........................................................................... 219
Innominate Security Technologies
9
mGuard rs2000 Switch ...................................................................... 242
User Firewall Templates .................................................................... 245
CIFS Integrity Monitoring >> Importable Shares ................................................ 250
Importable Shares .............................................................................. 250
CIFS Integrity Monitoring >> CIFS Integrity Checking........................................ 252
Filename Patterns .............................................................................. 261
CIFS Integrity Monitoring >> CIFS AV Scan Connector ..................................... 263
CIFS Antivirus Scan Connector .......................................................... 263
DynDNS Monitoring ........................................................................... 274
10
Innominate Security Technologies I15020_en_03
Table of contents
Internal/External/External 2/Dial-in ..................................................... 338
VPN via Internal/VPN via External/VPN via External 2/VPN via
Internal/External/External 2/Dial-in ..................................................... 343
Egress Rules (VPN) ........................................................................... 344
Connectivity Checks .......................................................................... 355
Redundancy >> FW Redundancy Status........................................................... 357
Redundancy Status ............................................................................ 357
Connectivity Status ............................................................................ 360
Ring/Network Coupling ...................................................................... 362
Log entry categories .......................................................................... 366
I15020_en_03 Innominate Security Technologies
11
Components in firewall redundancy ................................................... 374
Interaction of the firewall redundancy components ............................ 376
Firewall redundancy settings from previous versions ......................... 376
Requirements for firewall redundancy ................................................ 376
Fail-over switching time ...................................................................... 377
Error compensation through firewall redundancy ............................... 379
Handling firewall redundancy in extreme situations ........................... 380
Interaction with other devices ............................................................. 382
Transmission capacity with firewall redundancy ................................ 385
Limits of firewall redundancy .............................................................. 386
Components in VPN redundancy ....................................................... 387
Interaction of the VPN redundancy components ................................ 388
Error compensation through VPN redundancy ................................... 388
Setting the variables for VPN redundancy .......................................... 389
Requirements for VPN redundancy .................................................... 390
Handling VPN redundancy in extreme situations ............................... 390
Interaction with other devices ............................................................. 392
Transmission capacity with VPN redundancy .................................... 394
Limits of VPN redundancy .................................................................. 395
12
Innominate Security Technologies I15020_en_03
mGuard basics
1 mGuard basics
Network features
Firewall features
Anti-virus features
VPN features (IPsec)
The mGuard protects IP data links by combining the following functions:
– VPN router (VPN - Virtual Private Network) for secure data transmission via public net-
– Configurable firewall for protection against unauthorized access. The dynamic packet filter inspects data packets using the source and destination address and blocks undesired data traffic.
1.1
Basic properties of the mGuards
– Stealth (auto, static, multi), router (static, DHCP client), PPPoE (for DSL), PPTP (for
DSL), and modem
– VLAN
– DHCP server/relay on the internal and external network interfaces
– DNS cache on the internal network interface
– Dynamic routing
– GRE Tunneling
– Administration via HTTPS and SSH
– Optional conversion of DSCP/TOS values (Quality of Service)
– Quality of Service (QoS)
– LLDP
– MAU management
– SNMP
– Stateful packet inspection
– Anti-spoofing
– IP filter
– L2 filter (only in stealth mode)
– NAT with FTP, IRC, and PPTP support (only in router modes)
– 1:1 NAT (only in router network mode)
– Port forwarding (not in stealth network mode)
– Individual firewall rules for different users (user firewall)
– Individual rule sets as action (target) of firewall rules (apart from user firewall or VPN firewall)
– CIFS integrity check of network drives for changes to specific file types (e.g., executable files)
– Anti-virus scan connector which supports central monitoring of network drives with virus scanners
– Protocol: IPsec (tunnel and transport mode)
– IPsec encryption in hardware with DES (56 bits), 3DES (168 bits), and AES (128, 192,
256 bits)
– Packet authentication: MD5, SHA-1
– Internet Key Exchange (IKE) with main and quick mode
– Authentication via:
Innominate Security Technologies
13
I15020_en_03
– Pre-shared key (PSK)
– X.509v3 certificates with public key infrastructure (PKI) with certification authority
(CA), optional certificate revocation list (CRL), and the option of filtering by subject or
– Partner certificate, e.g., self-signed certificates
– Detection of changing partner IP addresses via DynDNS
– NAT traversal (NAT-T)
– Dead Peer Detection (DPD): detection of IPsec connection aborts
– IPsec/L2TP server: connection of IPsec/L2TP clients
– IPsec firewall and 1:1 NAT
– Default route over VPN tunnel
– Data forwarding between VPNs (hub and spoke)
– Depending on the license: up to 250 VPN tunnels, in the case of centerport² up to 3000 active VPN tunnels
– Hardware acceleration for encryption in the VPN tunnel (except
VPN features (OpenVPN)
Additional features
Support
– OpenVPN client
– OpenVPN encryption with Blowfish, AES (128, 192, 256 Bit)
– Dead Peer Detection (DPD)
– Authentication via Login, Password or X.509v3 certificate
– Detection of changing partner IP addresses via DynDNS
– Open VPN firewall and 1:1 NAT
– Routes over VPN tunnel statically configurable and dynamically learnable
– Data forwarding between VPNs (hub and spoke)
– Depending on the license: up to 50 VPN tunnels
– Remote Logging
– VPN/firewall redundancy (depending on the license)
– Administration using SNMP v1 - v3 and Innominate Device Manager
– PKI support for HTTPS/SSH remote access
– Can act as an NTP and DNS server via the LAN interface
– Compatible with MGUARD Secure Cloud
– Plug-n-Protect technology
– Tracking and time synchronization via GPS/GLONASS positioning system
– COM server
In the event of problems with your mGuard, please contact your dealer.
Additional information on the device as well as on release notes and software updates can be found on the Internet at: www.innominate.com
.
14
Innominate Security Technologies I15020_en_03
I15020_en_03 mGuard basics
1.2
Typical application scenarios
This section describes various application scenarios for the mGuard.
–
–
–
–
–
–
– Mobile phone router via integrated mobile phone modem
1.2.1
Stealth mode (Plug-n-Protect)
In stealth mode, the mGuard can be positioned between an individual computer and the rest of the network.
The settings (e.g., for firewall and VPN) can be made using a web browser under the URL https://1.1.1.1/.
No configuration modifications are required on the computer itself.
Figure 1-1 Stealth mode (Plug-n-Protect)
Innominate Security Technologies
15
1.2.2
Network router
When used as a network router, the mGuard can provide the Internet link for several computers and protect the company network with its firewall.
One of the following network modes can be used on the mGuard:
– Router, if the Internet connection is, for example, via a DSL router or a permanent line.
– PPPoE, if the Internet connection is, for example, via a DSL modem and the PPPoE protocol is used (e.g., in Germany).
– PPTP, if the Internet connection is, for example, via a DSL modem and the PPTP protocol is used (e.g., in Austria).
– Modem, if the Internet connection is via a serial connected modem (compatible with
Hayes or AT command set).
– Built-in mobile phone modem, mobile phone router via integrated mobile phone modem
For computers in the Intranet, the mGuard must be specified as the default gateway.
DSL-Modem/
Router
Intranet Internet
16
Innominate Security Technologies I15020_en_03
I15020_en_03 mGuard basics
1.2.3
DMZ
A DMZ (demilitarized zone) is a protected network that is located between two other networks. For example, a company's website may be in the DMZ so that new pages can only be copied to the server from the Intranet using FTP. However, the pages can be read from the Internet via HTTP.
IP addresses within the DMZ can be public or private, and the mGuard, which is connected to the Internet, forwards the connections to private addresses within the DMZ by means of port forwarding.
a
DMZ
Intranet
Internet
DMZ
1.2.4
VPN gateway
The VPN gateway provides company employees with encrypted access to the company network from home or when traveling. mGuard performs the role of the VPN gateway.
IPsec-capable VPN client software must be installed on the external computers or failing that, the computer is equipped with a mGuard.
Internet Intranet
Innominate Security Technologies
17
1.2.5
WLAN via VPN
WLAN via VPN is used to connect two company buildings via a WLAN path protected using
IPsec. The annex should also be able to use the Internet connection of the main building.
Internet
192.168.1.0/24
Figure 1-5 WLAN via VPN
In this example, the mGuard devices were set to router mode and a separate network with
172.16.1.x addresses was set up for the WLAN.
To provide the annex with an Internet connection via the VPN, a default route is set up via the VPN:
Tunnel configuration in the annex
Connection type
Address of the local network
Address of the remote network
Tunnel (network <-> network)
192.168.2.0/24
0.0.0.0/0
In the main building, the corresponding counterpart is configured:
Tunnel configuration in the main building
Connection type
Local network
Address of the remote network
Tunnel (network <-> network)
0.0.0.0
192.168.2.0/24
The default route of an mGuard usually uses the WAN port. However, in this case the Internet can be accessed via the LAN port:
Default gateway in the main building:
IP address of default gateway 192.168.1.253
18
Innominate Security Technologies I15020_en_03
mGuard basics
1.2.6
Resolving network conflicts
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
10.0.0.0/16
10.0.0.0/16
10.0.0.0/16
Resolving network conflicts
In the example, the networks on the right-hand side should be accessible to the network or computer on the left-hand side. However, for historical or technical reasons the networks on the right-hand side overlap.
The 1:1 NAT feature of the mGuard can be used to translate these networks to other networks, thereby resolving the conflict.
(1:1 NAT can be used in normal routing and in IPsec tunnels.)
I15020_en_03 Innominate Security Technologies
19
20
Innominate Security Technologies I15020_en_03
Configuration help
2 Configuration help
2.1
Suitable browsers
The device can be configured easily using a web browser.
To configure the mGuard, use a web browser with SSL encryption (HTTPS).
Browsers with SSL encryption (HTTPS) approved by Innominate:
– Mozilla Firefox, Version 4 or later
– Google Chrome, Version 12 or later
– Microsoft Internet Explorer, Version 8 or later
– Apple Safari, Version 5.1.7 or later
Further information can be found on the Innominate website at: www.innominate.com .
Limitation of login attempts
In the event of a Denail of Service attack, services are intentionally made unable to function.
To prevent this type of attack, the mGuard is provided with a choke for different network requests.
This feature is used to count all connections going out from one IP address and using a specific protocol. When counting a specific number of connections without a valid login, the choke becomes effective. If no invalid connection attempt is made for the duration of 30 seconds, the choke is reset. Each new request without valid login from this IP address resets the timer by 30 seconds.
The number of connection attempts that need to fail until the choke becomes effective depends on the protocol.
– 20 when using HTTPS
– 6 when using SSH, SNMP, COM server
2.2
User roles
root admin netadmin audit
User role without restrictions
Administrator
Administrator for the network only
Auditor/tester
The predefined users (root, admin, netadmin, and audit) have different permissions.
– The root user has unrestricted access to the mGuard.
– The admin user also has unrestricted functional access to the mGuard, however the number of simultaneous SSH sessions is limited.
– Permissions are explicitly assigned to the netadmin user via the manager. This user only has read access to the other functions. Passwords and private keys cannot be read by this user.
– This audit user only has read access to all functions. By default, the audit user role can manager, in the same way as netadmin.
Innominate Security Technologies
21
I15020_en_03
2.3
Input help during configuration (system messages)
With firmware 8.0 or later, modified or invalid entries are highlighted in color on the web interface.
With firmware 8.1 or later, dynamic values are displayed in red. In this way, status messaged indicating a current value can be recognized more easily.
System messages which explain why an entry is invalid, for example, are also displayed.
The browser used must allow JavaScript for this support to function.
Figure 2-1 Example system message
– Modified entries are highlighted in blue on the relevant page and in the associated menu item until the changes are saved or reset. (Exception: modified tables)
– Invalid entries are highlighted in red on the relevant page and tab and in the associated menu item.
The modified or invalid entries remain highlighted even when you close a menu.
When necessary, information relating to the system is displayed at the top of the screen.
You can also open this area by clicking the letter icon.
22
Innominate Security Technologies I15020_en_03
I15020_en_03
Configuration help
2.4
Using the web interface
You can click on the desired configuration via the menu on the left-hand side,
The page is then displayed in the main window – usually in the form of one or more tab pages – where settings can be made. If the page is organized into several tab pages, you can switch between them using the tabs at the top.
Working with tab pages
–
You can make the desired entries on the corresponding tab page (see also “Working
– You can return to the previously accessed page by clicking on the Back button located at the bottom right of the page, if available.
Entry of impermissible values
If you enter an impermissible value (e.g., an impermissible number in an IP address) and click on the Apply button, the relevant tab page title is displayed in red. This makes it easier to trace the error.
Entry of timeouts
Entering a timeout can occur in three ways:
– in seconds [ss]
– in minutes and seconds [mm:ss]
– in hours, minutes and seconds [h:mm:ss]
The three possible values are each separated by a colon. If only one value is entered, it will be interpreted as seconds, two values as minutes and seconds, three values as hours, minutes and seconds. The values for minutes and seconds may be greater than 59. After the values have been applied, they will always be shown as [h:mm:ss] (if you enter 90:120 for example, it will be shown as 1:32:00).
Buttons
The following buttons are located at the top of every page:
Logout
Reset
Apply
For logging out after configuration access to the mGuard.
If the user does not log out, he/she is logged out automatically if there has been no further activity and the time period specified by the configuration has elapsed. Access can only be restored by logging in again.
Resets to the original values. If you have entered values on a configuration page and these have not yet taken effect (by clicking on the Apply button), you can restore the original values on the page by clicking the Reset button.
To apply the settings on the device, you must click on the Apply button.
This applies across all pages.
Innominate Security Technologies
23
Working with sortable tables
Many settings are saved as data records. Accordingly, the adjustable parameters and their values are presented in the form of table rows. If multiple firewall rules are defined, these are queried starting from the top of the list of entries until an appropriate rule is found. Therefore, note the order of the entries, if necessary. The order can be changed by moving table rows up or down.
With tables you can:
– Insert rows to create a new data record with settings (e.g., the firewall settings for a specific connection)
– Move rows (i.e., them)
– Delete rows to delete the entire data record
Inserting rows
1.
Click on the arrow below which you want to insert a new row.
2.
The new row is inserted.
You can now enter or specify values in the row.
Moving rows
1.
Select the row(s) you want to move.
2.
Click on the arrow below which you want to move the selected rows.
3.
The rows are moved.
Deleting rows
1.
Select the rows you want to delete.
2.
Click on to delete the rows.
3.
The rows are deleted.
24
Innominate Security Technologies I15020_en_03
Configuration help
2.5
CIDR (Classless Inter-Domain Routing)
IP subnet masks and CIDR are methods of notation that combine several IP addresses to create a single address area. An area comprising consecutive addresses is handled like a network.
To specify an area of IP addresses for the mGuard, e.g., when configuring the firewall, it may be necessary to specify the address area in CIDR format. In the table below, the left-hand column shows the IP subnet mask, while the far right-hand column shows the corresponding CIDR notation.
IP subnet mask Binary CIDR
I15020_en_03
Example: 192.168.1.0/255.255.255.0 corresponds to CIDR: 192.168.1.0/24
Innominate Security Technologies
25
Router
External IP address:
192.168.11.2
Internal IP address:
192.168.15.254
Subnet mask:
255.255.255.0
Router
External IP address:
192.168.15.1
Internal IP address:
192.168.27.254
Subnet mask:
255.255.255.0
= additional internal routes
2.6
Network example diagram
The following diagram shows how IP addresses can be distributed in a local network with subnetworks, which network addresses result from this, and how the details regarding additional internal routes may look for the mGuard.
Internet
(assigned by the Internet service provider) mGuard in Router network mode
Internal address of the mGuard: 192.168.11.1
Switch
A1 A2
Router
Switch
A3 A4 A5
Network A
Network address: 192.168.11.0/24
Subnet mask: 255.255.255.0
Network B
Network address:
192.168.15.0/24
Subnet mask: 255.255.255.0
B1 B2
Router
Switch
B3 B4
C1 C2 C3 C4
Network C
Network address:
192.168.27.0/24
Subnet mask: 255.255.255.0
Network A Computer A1
IP address 192.168.11.3
A2
192.168.11.4
A3
192.168.11.5
A4
192.168.11.6
A5
192.168.11.7
Subnet mask 255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Network B
Network C
Computer B1
IP address 192.168.15.2
Subnet mask 255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Computer C1
IP address 192.168.27.1
B2
192.168.15.3
C2
192.168.27.2
B3
192.168.15.4
C3
192.168.27.3
B4
192.168.15.5
C4
192.168.27.4
Subnet mask 255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Additional internal routes:
Network:
192.168.15.0/24
Gateway:
192.168.11.2
Network:
192.168.27.0/24
Gateway:
192.168.11.2
26
Innominate Security Technologies I15020_en_03
Changes compared to the previous version
3 Changes compared to the previous version
3.1
Overview of the changes in Version 8.3
The following functions have been added to firmware Version 8.3:
– Establishing OpenVPN connections
– Dynamic routing (OSPF)
– Support for GRE tunnels
– Support for the Path Finder function of the mGuard Secure VPN Client
– Use of IP and port groups
– New access check and modified test report creation (logging) for CIFS
– Improved display of the VPN status (IPsec)
– Improved timeout behavior for VPN connections
– New VPN license model
– Improved use of configuration profiles
– Optional use of the proxy server by the secondary external interface
– Support for XAuth and Mode Config (iOS support)
3.1.1
Establishing OpenVPN connections
As an OpenVPN client, the mGuard can establish VPN connections to partners which support OpenVPN as the server.
3.1.2
Dynamic routing (OSPF)
Support for the OSPF (Open Shortest Path First) dynamic routing protocol. As an OSPF router, the mGuard can dynamically learn the routes of neighboring OSPF routers and distribute its own as well as learned routes. This simplifies the configuration of complex network structures, since fewer routes have to be entered statically.
The OSPF routes can be learned and distributed via every selected interface (internal, external, DMZ) as well as via OpenVPN and IPsec connections (with the aid of GRE tunnels).
3.1.3
Support for GRE tunnels
The mGuard supports the use of GRE tunnels. It is therefore possible to encapsulate network layer protocols and transport them over the Internet Protocol (IP) inside a tunnel. This will enable the dynamic distribution of OSPF routes via IPsec connections.
3.1.4
Support for the Path Finder function of the mGuard Secure
VPN Client
The “Path Finder” function enables the mGuard Secure VPN Client to establish a connection when it is located behind a proxy server or a firewall.
3.1.5
Use of IP and port groups
IP and port groups enable the easy creation and management of firewall and NAT rules in complex network structures.
IP addresses, IP areas, and networks can be grouped in IP groups and identified by a name.
Likewise, ports or port ranges can be grouped in port groups.
Innominate Security Technologies
27
I15020_en_03
Access check
Test report (log file)
If a firewall or NAT rule is created, instead of IP addresses/IP areas or ports/port ranges, the
IP or port groups can be selected directly in the corresponding fields and assigned to the rule.
3.1.6
New access check and modified test report creation (logging) for CIFS
In order to prevent a comprehensive integrity check being aborted due to the absence of access permissions to the destination drive, access permission can be checked before the actual scan. This access check is much faster and generates a test report which can be downloaded and analyzed. If all access permissions are present, the integrity check can then be performed.
The old results of a test are not deleted from the test report when a new test is performed.
The new results are simply added to the report. When the report reaches a specified file size, it is stored as a backup file and a new test report is created. When this test report also reaches a specified file size, the backup file is overwritten with the new report and another report is created.
3.1.7
Improved display of the VPN status (IPsec)
The status page for displaying information about VPN connections has been revised. The status of all VPN connections is clearly displayed.
3.1.8
New VPN license model
The new VPN license model allows tunnel groups to be created with all VPN licenses.
The license no longer limits the number of tunnels established, but instead the number of connected partners (VPN peers). If several tunnels are established to a partner, only one partner is counted, which is an improvement over the old model.
The license status, i.e., the total number of licensed partners and the number of licensed partners currently used, is clearly shown in the “IPsec VPN” and “OpenVPN Client” menus.
3.1.9
Improved use of configuration profiles
Before the settings of saved configuration profiles are applied, the changes to the current configuration can be shown and therefore checked. The changes can be applied unmodified. However, individual settings can also be freely modified before being applied.
3.1.10
Improved timeout behavior for VPN connections
A timeout can stop a VPN connection that was started via a button on the web interface, a text message, a switch, a pushbutton or the script nph-vpn.cgi. This VPN connection is terminated after the timeout has elapsed and is set to the “Stopped” state.
A VPN connection that is initiated (established) by data traffic is also terminated by a timeout. However, this VPN connection is not set to the “Stopped” state after the timeout has elapsed, instead it remains in the “Started” state. When data traffic resumes, the VPN connection is established again. This function is particularly useful when using the mobile interface (3G).
28
Innominate Security Technologies I15020_en_03
Changes compared to the previous version
3.1.11
Support for XAuth and Mode Config (iOS support)
The mGuard now supports the “Extended Authentication” (XAuth) authentication method and the frequently required “Mode Config” protocol extension, including split tunneling as server and as client (e.g., support for Apple iOS). Network settings and DNS and WINS configurations are communicated to the IPsec client by the IPsec server.
3.1.12
Optional use of the proxy server by the secondary external interface
If a proxy server is used, the secondary external interface may be exempted from its use.
This can be useful if the secondary external interface is a mobile network modem (3G).
I15020_en_03 Innominate Security Technologies
29
3.2
Overview of the changes in Version 8.1
The following functions have been added to firmware Version 8.1.
– User firewall in VPN connections
– Dynamic activation of the firewall rules
– Function extension of the service contacts
– OPC Inspector for Deep Packet Inspection for OPC Classic
– Extended DynDNS providers
– New mode for Pre-Shared Secret authentication method
– On the web interface, dynamic modifications are displayed in red-.
– Detailed logging of modems
3.2.1
User firewall in VPN connections
The user firewall can be used within VPN connections.
A VPN connection in which the user firewall rules apply can now be selected for the user
firewall (under “Network Security >> User Firewall >> User Firewall Templates” on
3.2.2
Dynamic activation of the firewall rules
(conditional firewall)
The firewall rules can now be activated via an external event:
–
A button on the web interface (under “Network Security >> Packet Filter >> Rule Records” )
– An API command line that is activated using the name or the row ID.
/Packages/mguard-api_0/mbin/action fwrules/[in]active <ROWID>
– /Packages/mguard-api_0/mbin/action_name fwrules/[in]active <NAME>
– An externally connected pushbutton/switch (for mGuards that allow connection,
see “Dynamic activation of the firewall rules (conditional
– Establishing or releasing a VPN connection. It can be set whether an established
VPN connection activates or deactivates the firewall rule record.
– Incoming text message (for mGuard
– CGI interface. The CGI script “nph-action.cgi may” can be used to control firewall rule records.
If the status of the firewall rule record changes, an e-mail can be sent automatically. In the
3G, a text message can also be sent in such an event.
30
Innominate Security Technologies I15020_en_03
I15020_en_03
Changes compared to the previous version
3.2.3
Function extension of the service contacts
Service contacts (service I/Os) can be connected to some mGuards.
– mGuard 3G
– mGuard
– mGuard rs
A pushbutton or an on/off switch can be connected to inputs CMD 1-3. The pushbutton or on/off switch is used to establish and release predefined VPN connections or the defined firewall rule records.
For the VPN connections it can be set whether the VPN connection is to be switched via one
of the service contacts ("IPsec VPN >> Connections >> Edit >> General"). If a switch is con-
nected, the switch behavior can also be inverted.
For the firewall rule records it can be set whether a rule is to be switched via one of the ser-
vice contacts or if a VPN connection is to be switched ("Network Security >> Packet Filter
In this way, one or more freely selectable VPN connections or firewall rule records can be switched. A mixture of VPN connections and firewall rule records is also possible.
The web interface displays which VPN connections and which firewall rule records are con-
nected to an input ("Management >> Service I/O >> Service I/O").
Outputs ACK 1-2 can be used to monitor specific VPN connections or firewall rule records and to display them using LEDs.
Alarm output ACK 03 monitors the function of the mGuard and therefore enables remote diagnostics.
The alarm output reports the following, if it has been activated.
– Failure of the redundant supply voltage
– Monitoring of the link status of the Ethernet connections
– Monitoring of the temperature state
– Monitoring of the connection status of the internal modem
Innominate Security Technologies
31
3.2.4
OPC Inspector for Deep Packet Inspection for OPC Classic
When using the OPC Classic network protocol, interconnected firewalls virtually have no effect. In addition, conventional NAT routing cannot be used.
When the OPC
The TCP ports that are negotiated during the connection opened first are detected and opened for OPC packets. If no OPC packets are transmitted via these ports within a configurable timeout, they are closed again. If the OPC validity check is activated, only OPC packets must be transmitted via OPC Classic port 135.
3.2.5
Additional functions
Extended DynDNS providers
– When establishing VPN connections, it is useful if the devices obtain their IP address via a DynDNS service.
More DynDNS providers are supported in Version 8.1.
New mode for Pre-Shared Key authentication method
When selecting the Pre-Shared Key (PSK) authentication method, “Aggressive Mode” can
be selected (under "IPsec VPN >> Connections >> Edit >> Authentication").
On the web interface, dynamic modifications are highlighted red-.
Status messages are displayed on the web interface and updated continuously. To identify these dynamic entries more easily, they are displayed in red-.
Detailed logging of modems
Only for mGuards that have an internal or external modem or that are capable of mobile
communication (under "Logging >> Settings").
32
Innominate Security Technologies I15020_en_03
I15020_en_03
Changes compared to the previous version
3.3
Overview of the changes in Version 8.0
The following functions have been added to firmware Version 8.0.
Configuration extensions
–
Improved CIFS Integrity Monitoring (see “New in CIFS Integrity Monitoring” on page
–
Integrated COM server for mGuard platforms with serial interface (see “COM server for
– Configurable multicast support for devices with internal switch in order to send data
to a group of receivers without the transmitter having to send it multiple times (see “Mul-
–
VPN extensions (see “VPN extensions” on page
– Dynamic web interface for configuration. Incorrect entries are highlighted in color and help is also offered in the form of system messages.
–
Support for mobile network and positioning functions (see “Network >> Mobile
–
Support for integrated Managed and Unmanaged Switches (see “Network >>
– Support for a dedicated DMZ port (only mGuard 3G)
The DMZ port can be set so that it forwards packets to the internal, external or secondary external interface.
The DMZ port is only supported in router mode and requires at least one IP address and a corresponding subnet mask. The DMZ does not support any VLANs.
Removed functions
– HiDiscovery support
– The “Apply” button which only applied changes for the current page has been removed.
Changes are made across all pages.
Innominate Security Technologies
33
Time schedule
3.3.1
New in CIFS Integrity Monitoring
The time schedule has been improved in Version 8.0. Now more than one scan per day is possible. Continuous scanning can also be set.
If the scan takes longer than planned, it is aborted. However you can adjust the settings so that a scan is started regularly.
Extended display of the current status
Each row of the CIFS Integrity Monitoring also displays the following information.
– The status of the scanned network drives
– The result of the last scan or the progress of the current scan
The menu in the web interface has been extended so that you can now see the status of each scan. The progress indicator shows the number of checked files.
3.3.2
VPN extensions
Status of the VPN connections
The setting for the VPN connection is now divided into “Disabled”, “Started”, and “Stopped”.
The “Disabled” setting ignores the VPN connection, as if it were not configured. This also means it cannot be dynamically enabled/disabled. The other two settings determine the status of the VPN connection when restarting the connection or booting.
In Version 8.0, the VPN connections can be started or stopped via a button on the web interface, via text message, an external switch or the script nph-vpn.cgi. This takes into account all VPN connections. Packets that correspond to a VPN connection that is not disabled are forwarded when the connection is established or discarded if the connection is not established. VPN connections which were set to “Active: No” in the previous versions are now interpreted as “Disabled”.
Unique names
Timeout for the VPN connection
In Version 8.0, the names of VPN connections are made unique. During the update, a hash or unique number is added to names that are duplicated.
You can set a timeout which aborts the VPN connection if it has been started via a text message, nph-vpn.cgi script or the web interface. VPN connections which have been started by an explicit request via an application are not affected.
Source-based routing VPN tunnels which only differ in their source network can now be configured.
From Version 8.0, the VPN configuration permits a remote network with different local networks in one configuration. The VPN tunnel groups are extended so that they permit an established VPN connection to select only one subnetwork from the local network. In previous versions, this was only possible for remote networks.
34
Innominate Security Technologies I15020_en_03
Management menu
4 Management menu
For security reasons, we recommend you change the default root and administrator pass-
page until the passwords are changed.
4.1
Management >> System Settings
4.1.1
Host
Management >> System Settings >> Host
System
Uptime
Power supply 1/2
Device operating time since the last restart.
rs4000 rs4000,
State of both power supply units
I15020_en_03
System Temperature
(°C)
An SNMP trap is triggered if the temperature exceeds or falls below the specified temperature range.
centerport² not with firmware 7.6.0)
CPU temperature (°C) An SNMP trap is triggered if the temperature exceeds or falls below the specified temperature range.
Innominate Security Technologies
35
System DNS Hostname
SNMP Information
Hostname mode
Host name
Domain search path
System name
Location
You can assign a name to the mGuard using the Hostname
mode and Hostname fields. This name is then displayed, for
example, when logging in via SSH (see “Management >> System Settings” on page
signing names simplifies the administration of multiple mGuard devices.
User defined (from field below)
(Default) The name entered in the “Hostname” field is the name used for the mGuard.
If the mGuard is running in Stealth mode, the “User defined” option must be selected under “Hostname mode”.
Provider defined (e.g., via DHCP)
If the selected network mode permits external setting of the host name, e.g., via DHCP, the name supplied by the provider is assigned to the mGuard.
If the “User defined” option is selected under “Hostname mode”, enter the name that should be assigned to the mGuard here.
Otherwise, this entry will be ignored (i.e., if the “Provider defined” option (e.g., via DHCP) is selected under “Hostname mode”).
This option makes it easier for the user to enter a domain name. If the user enters the domain name in an abbreviated form, the mGuard completes the entry by appending the domain suffix that is defined here under “Domain search path”.
A name that can be freely assigned to the mGuard for administration purposes, e.g., “Hermes”, “Pluto”. (Under SNMP: sysName)
A description of the installation location that can be freely assigned, e.g., “Hall IV, Corridor 3”, “Control cabinet”.
Contact The name of the contact person responsible for the mGuard, ideally including the phone number. (Under SNMP: sysContact)
Keyboard
36
Innominate Security Technologies
Keyboard Layout
Repetition Rate
Repetition Delay
Selection list for selecting the appropriate keyboard layout.
Determines how many characters the keyboard generates per second when a key is held down. (Default: 30)
Determines how long a key must be held down on the keyboard until the repeat function takes effect and the number of characters defined above under Repetition Rate are generated per second. (Default: 250)
I15020_en_03
Management menu
4.1.2
Time and Date
Set the time and date correctly. Otherwise, certain time-dependent activities cannot be
Management >> System Settings >> Time and Date
Time and Date Current system time
(UTC)
Current system time
(local)
The current system time is displayed as Universal Time Coor-
dinates (UTCs). If Enable NTP time synchronization is not
yet activated (see below) and Time-stamp in filesystem is
deactivated, the clock will start at January 1, 2000.
Display: If the (sometimes different) current local time should be displayed, the corresponding entry must be made under
Timezone in POSIX.1 notation (see below).
I15020_en_03 Innominate Security Technologies
37
Management >> System Settings >> Time and Date[...]
System time state Indicates whether the mGuard system time has ever been synchronized with a currently valid time during mGuard runtime. If the display indicates that the mGuard system time has not been synchronized, the mGuard does not per-
form any time-controlled activities.
Devices without built-in clock always start in “Not synchronized” mode. Devices with integrated clock usually start in
“Synchronized by hardware clock” mode.
The state of the clock only returns to “Not synchronized” if the firmware is reinstalled on the device or if the built-in clock has been disconnected from the power for too long.
Power supply of the integrated clock is ensured by the following components:
– Capacitor (mGuard 3G,
– Battery (mGuard
– Accumulator (mGuard
rs4000/rs2000 mGuard
In the case of the mGuard rs4000/rs2000, the accumulator lasts at least five days.
38
Innominate Security Technologies I15020_en_03
Management menu
Management >> System Settings >> Time and Date[...]
Time-controlled activities
– Time-controlled pick-up of configuration from a configuration server:
This is the case when the Time Schedule setting is selected under the Management
>> Central Management, Configuration Pull menu item for the Pull Schedule setting
(see “Management >> Configuration Profiles” on page 77, “Configuration Pull” on
– Interruption of the connection at a certain time using PPPoE network mode:
This is the case when Network Mode is set to PPPoE under the Network >> Inter-
faces, General menu item, and Automatic Re-connect is set to Yes (see 6.1 “Net-
– Acceptance of certificates when the system time has not yet been synchronized:
This is the case when the Wait for synchronization of the system time setting is se-
lected under the Authentication >> Certificates, Certificate settings menu item for the
Check the validity period of certificates and CRLs option (see “Authentication >>
– CIFS integrity checking:
The regular, automatic check of the network drives is only started when the mGuard has a valid time and date (see the following section).
The system time can be set or synchronized by various events:
– Synchronized by hardware clock: The mGuard has a built-in clock, which has been synchronized with the current time at least once. A synchronized built-in clock ensures that the mGuard has a synchronized system time even after a restart.
– Synchronized manually: The administrator has defined the current time for the
mGuard runtime by making a corresponding entry in the Local system time field.
–
Synchronized by file system time-stamp: The administrator has set the Time-
stamp in filesystem setting to Yes, and has either transmitted the current system
time to the mGuard via NTP (see below under NTP Server) or has entered it under
Local system time. The system time of the mGuard is then synchronized using the
time stamp after a restart (even if it has no built-in clock and is set exactly again afterwards via NTP).
– Synchronized by Network Time Protocol NTP: The administrator has activated
NTP time synchronization under NTP Server, has entered the address of at least one
NTP server, and the mGuard has established a connection with at least one of the specified NTP servers. If the network is working correctly, this occurs a few seconds
– Synchronized by GPS data: The mGuard 3G can set and synchro-
nize the system time via the positioning system (GPS/GLONASS) (under “Network
>> Mobile Network >> Positioning system” ).
I15020_en_03 Innominate Security Technologies
39
Management >> System Settings >> Time and Date[...]
Local system time Here you can set the time for the mGuard, if no NTP server has been set up or the NTP server cannot be reached. You should
The date and time are specified in the format YYYY.MM.DD-
HH:MM:SS:
YYYY
MM
DD
HH
MM
SS
Year
Month
Day
Hour
Minute
Second
NTP Server
Timezone in POSIX.1 notation
If a current local time (that differs from Greenwich Mean Time) is to be displayed under Current system time, you must enter the number of hours that your local time is ahead of or behind
Greenwich Mean Time.
Example: in Berlin, the time is one hour ahead of GMT. Therefore, enter: CET-1.
In New York, the time is five hours behind Greenwich Mean
Time. Therefore, enter: CET+5.
Time-stamp in filesystem
The only important thing is the -1, -2 or +1, etc. value as only these values are evaluated – not the preceding letters. They can be “CET” or any other designation, such as “UTC”.
If you wish to display Central European Time (e.g., for Germany) and have it automatically switch to/from daylight saving time, enter:
CET-1CEST,M3.5.0,M10.5.0/3
If this option is set to Yes, the mGuard writes the current system time to its memory every two hours.
If the mGuard is switched off and then on again, a time from this two-hour time slot is displayed, not a time on January 1,
2000.
(NTP - Network Time Protocol) The mGuard can act as the NTP server for computers that are connected to its LAN port. In this case, the computers should be configured so that the local address of the mGuard is specified as the NTP server address.
this is configured) must be used for the computers, or the IP address 1.1.1.1 must be entered as the local address of the mGuard.
For the mGuard to act as the NTP server, it must obtain the current date and the current time from an NTP server (= time server). To do this, the address of at least one NTP server must be specified. This feature must also be activated.
40
Innominate Security Technologies I15020_en_03
Management menu
Management >> System Settings >> Time and Date[...]
Enable NTP time synchronization
Once the NTP is activated, the mGuard obtains the date and time from one or more time server(s) and synchronizes itself with it or them.
Initial time synchronization can take up to 15 minutes. During this time, the mGuard continuously compares the time data of the external time server and that of its own time so that this can be adjusted as accurately as possible. Only then the mGuard can act as the NTP server for the computers connected to its
LAN interface and provide them with the system time.
An initial time synchronization with the external time server is performed after every booting process, unless the mGuard
rs4000/rs2000 rs4000/rs2000,
NTP State
NTP Server
After initial time synchronization, the mGuard regularly compares the system time with the time servers. Fine adjustment of the time is usually only made in the second range.
Displays the current NTP status.
Shows whether the NTP server running on the mGuard has been synchronized with the configured NTP servers to a sufficient degree of accuracy.
If the system clock of the mGuard has never been synchronized prior to activation of NTP time synchronization, then synchronization can take up to 15 minutes. The NTP server still changes the mGuard system clock to the current time after a few seconds, as soon as it has successfully contacted one of the configured NTP servers. The system time of the mGuard is then regarded as synchronized. Fine adjustment of the time is usually only made in the second range.
Enter one or more time servers from which the mGuard should obtain the current time. If several time servers are specified, the mGuard will automatically connect to all of them to determine the current time.
I15020_en_03 Innominate Security Technologies
41
4.1.3
Shell Access
Displayed when En- able X.509 certificates for SSH ac-
cess is set to Yes
42
Innominate Security Technologies
The mGuard must not be simultaneously configured via the web access, shell access, or
SNMP. Simultaneous configuration via the different access methods might lead to unexpected results.
I15020_en_03
Management menu
Management >> System Settings >> Shell Access
Shell Access When SSH remote access is enabled, the mGuard can be configured from remote com-
puters using the command line.
This option is disabled by default.
NOTE: If remote access is enabled, ensure that secure passwords are defined for root and admin.
Make the following settings for SSH remote access:
Session Timeout (seconds)
Specifies after what period of inactivity (in h:mm:ss) the sesset to 0 (default settings), the session is not terminated automatically.
The specified value is also valid for shell access via the serial interface instead of via the SSH protocol.
The effects of the “Session Timeout” field settings are temporarily ineffective if processing of a shell command exceeds the number of seconds set.
In contrast, the connection can also be aborted if it is no longer
able to function correctly, see “Delay between requests for a
Enable SSH remote access
If you want to enable SSH remote access, set this option to
Yes. Internal SSH access (i.e., from the directly connected
LAN or from the directly connected computer) can be enabled independently of this setting.
The firewall rules for the available interfaces must be defined on this page under Allowed Networks in order to specify differentiated access options on the mGuard.
I15020_en_03 Innominate Security Technologies
43
44
Innominate Security Technologies
Port for incoming SSH connections (remote administration only)
Default: 22
If this port number is changed, the new port number only applies for access via the External, External 2, DMZ, VPN, GRE and Dial-in interface. Port number 22 still applies for internal access.
The remote partner that implements remote access may have to specify the port number defined here during login.
Example:
If this mGuard can be accessed over the Internet via address
123.124.125.21 and default port number 22 has been specified for remote access, you may not need to enter this port number in the SSH client (e.g., PuTTY or OpenSSH) of the remote partner.
Delay between requests for a sign of life
If a different port number has been set (e.g., 2222), this must be specified, e.g.: ssh -p 2222 123.124.125.21
Default: 120 seconds
Values from 0 seconds to 1 hour can be set. Positive values indicate that the mGuard is sending a query to the partner within the encrypted SSH connection to find out whether it can still be accessed. The request is sent if no activity was detected from the partner for the specified number of seconds (e.g., due to network traffic within the encrypted connection).
The value entered relates to the functionality of the encrypted
SSH connection. As long as the functions are working properly, the SSH connection is not terminated by the mGuard as a result of this setting, even when the user does not perform any actions during this time.
Because the number of simultaneously open sessions is lim-
ited (see Concurrent Session Limits), it is important to termi-
nate sessions that have expired.
Therefore, the request for a sign of life is preset to 120 seconds in the case of Version 7.4.0 or later. If a maximum of three requests for a sign of life are issued, this causes an expired session to be detected and removed after six minutes.
In previous versions, the preset was “0”. This means that no requests for a sign of life are sent.
If it is important not to generate additional traffic, you can adjust the value. When the setting “0” is made in conjunction with
“Concurrent Session Limits”, subsequent access may be
blocked if too many sessions are interrupted but not closed as a result of network errors.
I15020_en_03
Management menu
Maximum number of missing signs of life
Update SSH and
HTTPS keys
Specifies the maximum number of times a sign of life request to the partner may remain unanswered.
For example, if a sign of life request should be made every 15 seconds and this value is set to 3, the SSH connection is deleted if a sign of life is still not detected after approximately 45 seconds.
Generate new 2048-bit keys
Keys that have been generated using an older firmware might be weak and should be renewed.
• Click on this button to generate a new key.
• Observe the fingerprints of the new keys generated.
• Login via HTTPS and compare the certificate information provided by the browser.
Concurrent Session Limits In the case of administrative access to the mGuard via SSH, the number of simultaneous sessions is limited, depending on the predefined user. Approximately 0.5 Mbytes of memory space are required for each session.
The “root” user has unrestricted access. In the case of administrative access via another user (admin, netadmin, and audit), the number of simultaneous sessions is restricted. You can specify the number here.
The netadmin and audit authorization levels relate to access rights with the
The restriction does not affect existing sessions; it only affects newly established access instances.
Maximum number of concurrent sessions for role “admin”
2 to 2147483647
At least two simultaneously permitted sessions are required for “admin” to prevent it from having its access blocked.
0 to 2147483647 Maximum number of concurrent sessions for role “netadmin”
When “0” is set, no session is permitted. The “netadmin” user is not necessarily used.
Maximum number of concurrent sessions for role “audit”
0 to 2147483647
When “0” is set, no session is permitted. The “audit” user is not necessarily used.
Allowed Networks
I15020_en_03 Innominate Security Technologies
45
46
Innominate Security Technologies
Lists the firewall rules that have been set up. These apply for incoming data packets of an
SSH remote access attempt.
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 contains further subsequent rules that could also apply, these rules are ignored.
The rules specified here only take effect if Enable SSH remote access is set to Yes. Internal access is also possible when this option is set to No. A firewall rule that would refuse Internal access does therefore not apply in this case.
The following options are available:
From IP Enter the address of the computer or network from which remote access is permitted or forbidden in this field.
The following options are available:
IP address: 0.0.0.0/0 means all addresses. To specify an ad-
dress area, use CIDR format, see “CIDR (Classless Inter-Do-
Interface Internal / External / External 2 / DMZ / VPN /GRE / Dial-in
External 2 and Dial-in are only for devices with a serial inter-
Specifies to which interface the rule should apply.
If no rules are set or if no rule applies, the following default settings apply:
SSH access is permitted via Internal, VPN, DMZ and Dial-in.
Access via External, External 2 and GRE is refused.
Specify the access options according to your requirements.
NOTE: If you want to refuse access via Internal,
VPN, DMZ or Dial-in, you must implement this explicitly by means of corresponding firewall
example, Drop as an action.
To prevent your own access being blocked, you may have to permit access simultaneously via another interface explicitly with Accept before clicking on the Apply button to activate the new setting. Otherwise, if your access is blocked, you must carry out the recovery procedure.
I15020_en_03
Action
Comment
Log
Management menu
Options:
– 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, Re-
ject 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.
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
I15020_en_03 Innominate Security Technologies
47
RADIUS Authentication
This menu item is not included in the scope of functions for
Use RADIUS authentication for Shell access
If set to No, the passwords of users who log in via shell access are checked via the local database on the mGuard.
Select Yes to enable users to be authenticated via a RADIUS server. This also applies for users who want to access the mGuard via shell access using SSH or a serial console. The password is only checked locally in the case of predefined users (root, admin, netadmin, and audit).
The netadmin and audit authorization levels relate to access
Under X.509 Authentication, if you set Enable X.509
tion procedure can be used as an alternative. Which procedure is actually used by the user depends on how the user uses the SSH client.
When setting up a RADIUS authentication for the first time, select Yes.
You should only select As only method for
password authentication if you are an experienced user, as doing so could result in all access to the mGuard being blocked.
If you do intend to use the As only method for password au-
thentication option when setting up RADIUS authentication, we recommend that you create a “Customized Default Profile” which resets the authentication method.
The predefined users (root, admin, netadmin, and audit) are then no longer able to log in to the mGuard via SSH or serial console.
There is one exception: it is still possible to perform authentication via an externally accessible serial console by correctly entering the local password for the root user name.
48
Innominate Security Technologies I15020_en_03
Management menu
X.509 Authentication
X.509 certificates for SSH clients
The mGuard supports the authentication of SSH clients using X.509 certificates. It is sufficient to configure CA certificates that are required for the establishment and validity check of a certificate chain. This certificate chain must exist between the CA certificate on the
This must take place before the SSH clients use their new client certificates.
If the CRL check is activated (under Authentication >> Certificates >> Certificate settings),
one URL (where the corresponding CRL is available) must be maintained for each CA certificate. The URL and CRL must be published before the mGuard uses the CA certificates in order to confirm the validity of the certificates shown by the VPN partners.
Management >> System Settings >> Shell Access
X.509 Authentication
This menu item is not included in the scope of functions for
Enable X.509 certificates for
– If No is selected, then only conventional authentication methods (user name and password or private and public keys) are permitted, not the X.509 authentication method.
– If Yes is selected, then the X.509 authentication method can be used in addition to conventional authentication methods (as also used for No).
– If Yes is selected, the following must be specified:
– How the mGuard authenticates itself to the SSH client according to X.509, see SSH server certificate
(1)
– How the mGuard authenticates the remote SSH client according to X.509, see SSH server certificate
(2)
I15020_en_03 Innominate Security Technologies
49
Management >> System Settings >> Shell Access[...]
SSH server certificate
(1)
Specifies how the mGuard identifies itself to the SSH client.
Select one of the machine certificates from the list or the None entry.
None:
When None is selected, the SSH server of the mGuard does not authenticate itself to the SSH client via the X.509 certificate. Instead, it uses a server key and thus behaves in the same way as older versions of the mGuard.
If one of the machine certificates is selected, this is also offered to the SSH client. The client can then decide whether to use the conventional authentication method or the method according to X.509.
The selection list contains the machine certificates that
have been loaded on the mGuard under the Authentica-
SSH server certificate
(2)
Specifies how the mGuard authenticates the SSH client
The following definition relates to how the mGuard verifies the authenticity of the SSH client.
The table below shows which certificates must be provided for the mGuard to authenticate the SSH client if the SSH client shows one of the following certificate types when a connection is established:
– A certificate signed by a CA
– A self-signed certificate
For additional information about the table, see “Authentication >> Certificates” .
Authentication for SSH
The partner shows the following:
Certificate (specific to individual), signed by CA
Certificate (specific to individual), self-signed
The mGuard authenticates the partner using:
All CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
PLUS (if required)
Remote certificates, if used as a filter
According to this table, the certificates that must be provided are the ones the mGuard uses to authenticate the relevant SSH client.
50
Innominate Security Technologies I15020_en_03
Management menu
The following instructions assume that the certificates have already been correctly installed
on the mGuard (see “Authentication >> Certificates” ).
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 SSH clients is checked for revocations.
Management >> System Settings >> Shell Access
CA certificate
X.509 subject
This configuration is only necessary if the SSH client shows a certificate signed by a CA.
All CA certificates required by the mGuard to form the chain to the relevant root CA certificate with the certificates shown by the SSH client must be configured.
The selection list contains the CA certificates that have been
loaded on the mGuard under the Authentication >> Certifi-
Enables a filter to be set in relation to the contents of the Sub-
ject field in the certificate shown by the SSH client. It is then possible to limit or enable access for SSH clients, which the mGuard would accept based on certificate checks:
– Limited access to certain subjects (i.e., and/or to subjects that have certain attributes or
–
Access enabled for all subjects (see glossary under “Sub-
The X.509 subject field must not be left empty.
I15020_en_03 Innominate Security Technologies
51
Management >> System Settings >> Shell Access[...]
An * (asterisk) in the X.509 subject field can be used to specify that all subject entries in the certificate shown by the SSH client are permitted. It is then no longer necessary to identify or define the subject in the certificate.
Limited access to certain subjects (i.e., individuals) or to subjects that have certain attributes:
In the certificate, the certificate owner is specified in the Subject field. The entry is comprised 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=John Smith, O=Smith and Co., C=US
If certain subject attributes have very specific values for the acceptance of the SSH client 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=*, C=US (with or without spaces between attributes)
In this example, the attribute “C=US” must be entered in the certificate under “Subject”. It is only then that the mGuard would accept the certificate owner (subject) as a communication partner. The other attributes in the certificates to be filtered can have any value.
If a subject filter is set, the number (but not the order) of the specified attributes must correspond to that of the certificates for which the filter is to be used.
Please note that the filter is case-sensitive.
Several filters can be set and their sequence is irrelevant.
Authorized for access as
All users/root/admin/netadmin/audit
Additional filter which specifies that the SSH client has to be authorized for a specific administration level in order to gain access.
When establishing a connection, the SSH client shows its certificate and also specifies the system user for which the SSH session is to be opened (root, admin, netadmin, audit). Access is only granted if the entries match those defined here.
Access for all listed system users is possible when All users is set.
The netadmin and audit setting options relate to
52
Innominate Security Technologies I15020_en_03
Management menu
Management >> System Settings >> Shell Access[...]
Client certificate Configuration is required in the following cases:
– SSH clients each show a self-signed certificate.
– SSH clients each show a certificate signed by a CA. Filtering should take place: access is only granted to a user whose certificate copy is installed on the mGuard as the remote certificate and is provided to the mGuard in this table as the Client certificate.
This filter is not subordinate to the Subject filter. It resides on the same level and is allocated a logical OR function with the Subject filter.
The entry in this field defines which remote certificate the mGuard should adopt in order to authenticate the partner
(SSH client).
The remote certificate can be selected from the selection list.
The selection list contains the remote certificates that have
been loaded on the mGuard under the “Authentication >> Cer-
Authorized for access as
All users/root/admin/netadmin/audit
Filter which specifies that the SSH client has to be authorized for a specific administration level in order to gain access.
When establishing a connection, the SSH client shows its certificate and also specifies the system user for which the SSH session is to be opened (root, admin, netadmin, audit). Access is only granted if the entries match those defined here.
Access for all listed system users is possible when All users is set.
The netadmin and audit setting options relate to
I15020_en_03 Innominate Security Technologies
53
4.1.4
Management >> System Settings >> E-Mail
(Make sure that the e-mail settings for the mGuard are correctly configured)
Sender address of email notifications
Address of the e-mail server
E-Mail notifications
E-mail address, which is displayed as the sender from mGuard.
Address of the e-mail server
Port number of the email server
Encryption mode for the e-mail server
Port number of the e-mail server
No Encryption / TLS Encryption / TLS Encryption with
StartTLS
Encryption mode for the e-mail server
User name SMTP Login name
SMTP Password Password for the e-mail server
Any e-mail recipients can be linked with predefined events and a freely definable message. The list is processed from top to bottom.
Specifies the e-mail address.
E-Mail recipient
Event When the selected event occurs or the event is configured for the first time, the linked recipient address is selected and the event is sent to them via e-mail.
An e-mail message can also be stored and sent. Some of the events listed depend on the hardware used.
A complete list of all events can be found at “Event table” on
Selector A configured VPN connection can be selected here, which is monitored via e-mail.
54
Innominate Security Technologies I15020_en_03
Management menu
Management >> System Settings >> E-Mail [...]
E-Mail Subject
E-Mail Message
Text appears in the subject line of the e-mail
The text is freely definable. You can use blocks from the events table which can be inserted as wildcards in plain text
(\A and \V) or in machine-readable form (\a and \v). Time stamps in the form of wildcards (\T or \t (machine-readable)) may also be inserted.
Here you can enter the text that is sent as the e-mail body.
The text is freely definable. You can use blocks from the events table which can be inserted as wildcards in plain text
(\A and \V) or in machine-readable form (\a and \v). Time stamps in the form of wildcards (\T or \t (machine-readable)) may also be inserted.
Table 4-1 Examples for timestamps
Plain text \T
Monday, April 10 2000 11:22:36
Machine-readable \t (according to RFC-3339)
2015-06-16T07:04:30+0200
Plain text
\A = event
State of the External Configuration Storage ECS
Validity of the positional data
\V = value
Not present
Removed
Present and in sync
Machine-readable
\a = event
/ecs/status
2
3
\v = value
1
Not in sync
Generic Error
4
8
Positioning data not valid
Positioning data valid yes
/gsm/incoming_call Telephone number of an incoming call
Telephone number and message of an incoming text message
Roaming state of the mobile network engine
/gsm/incoming_sms
Registration state to the mobile network
Currently selected SIM slot
Registered to home network
Registered to foreign network
Not registered
Not registered to mobile network
Registered to mobile network
Using SIM 1
Using SIM 2
SIM interface disabled
/gsm/selected_sim yes unknown yes
1
2
0
I15020_en_03 Innominate Security Technologies
55
Plain text
\A = event
Mobile network fallback
SIM activity
Mobile network probes
\V = value
Normal operation (Primary SIM)
Fallback mode (Secondary SIM)
The network probes are disabled
The network probes are enabled
The network probes failed
The network probes succeeded
State of the Alarm output Alarm output closed / high [OK]
Alarm output is open / low [FAILURE]
Reason for activating the
Alarm output
No alarm
No network link on external interface
No network link on internal interface
Power supply 1 out of order
Power supply 2 out of order
Board temperature exceeding configured bounds
Redundancy connectivity check failed
The internal modem is offline
No network link on LAN2
No network link on LAN3
No network link on LAN1
No network link on LAN4
No network link on LAN5
No network link on DMZ
Power supply 1 working State of Power Supply 1
State of Power Supply 2
Power supply 1 out of order
Power supply 2 working
Power supply 2 out of order
State of the Input/CMD 1 Service input 1 activated
Service input 1 deactivated
State of the Input/CMD 3 Service input 2 activated
Service input 2 deactivated
State of the Input/CMD 3 Service input 3 activated
Service input 3 deactivated
Board temperature state Temperature OK
Temperature too hot
Temperature too cold
Machine-readable
\a = event
/gsm/sim_fallback
\v = value no yes
/gsm/network_probe disabled enabled failed succeeded
/ihal/contactreason
/ihal/power/psu1
/ihal/power/psu2
/ihal/service/cmd1
/ihal/service/cmd2
/ihal/service/cmd3
/ihal/temperature/board_alarm open link_ext link_int psu1 psu2 temp off on off ok hot cold check modem link_swp0 link_swp1 link_swp2 link_swp3 link_swp4 fail on off on link_dmz ok fail ok
56
Innominate Security Technologies I15020_en_03
Management menu
Plain text
\A = event
Temporary state of the secondary external interface
State of the modem
\V = value
On standby
Temporarily up
Machine-readable
\a = event
/network/ext2up
Status of redundancy
Offline
Dialing
Online
Initialized waiting
The redundancy controller starts up
The device does not (yet) have proper connectivity or cannot determine it for sure
The device does not (yet) have proper connectivity or cannot determine it for sure and waits for a restarting component
The device has an empty or outdated firewall or VPN state information which it wants to resynchronize
The device has an empty or outdated firewall or VPN state information which it wants to resynchronize and waits for a restarting component
The device is on standby
The device is on standby and waits for a restarting component
The device becomes active
The device is actively forwarding and filtering network traffic
/network/modem/state
/redundancy/status
Activation state of a Firewall rule record
The device is actively forwarding and filtering network traffic and waits for a restarting component
The device transitions to the hot standby state
IPsec VPN Connection
Preparation state
Stopped
Started
IPsec SA State of the VPN
Connection
No IPsec SAs established
Not all IPSec SAs established
All IPSec SAs established
The state of the firewall rule record has changed.
/vpn/con/*/armed
/vpn/con/*/ipsec
/fwrules/*/state
\v = value no yes offline dialing online init booting faulty faulty_waiting outdated outdated_waiting on_standby on_standby_waiting becomes_active active active_waiting becomes_standby no yes down some up inactive active
I15020_en_03 Innominate Security Technologies
57
Plain text
\A = event
OpenVPN Connection
Activation State
OpenVPN Connection
State
\V = value
Stopped
Started
Down
Established
4.1.5
Secure Cloud
Machine-readable
\a = event
/openvpn/con/*/armed
\v = value no yes
/openvpn/con/*/state down up
Management >> System Settings >> Secure Cloud mGuard Secure Cloud private SSH Remote Access Yes / No (Default: No)
Secure
Choosing Yes enables the mGuard to be configured/updated
Cloud private via by mGuard Secure Cloud private via SSH/IPsec.
IPsec
58
Innominate Security Technologies I15020_en_03
4.2
Management >> Web Settings
4.2.1
General
Management menu
Management >> Web Settings >> General
General Language
Session Timeout
If (automatic) is selected in the list of languages, the device uses the language setting of the computer's browser.
Specifies the period of inactivity after which the user will be automatically logged out of the mGuard web interface. Possible
The entry can be made in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes and seconds [h:mm:ss].
I15020_en_03 Innominate Security Technologies
59
4.2.2
Access
Only displayed when Login with
X.509 user certifi-
cate is selected
The mGuard must not be simultaneously configured via the web access, shell access, or
SNMP. Simultaneous configuration via the different access methods might lead to unexpected results.
When web access via HTTPS protocol is enabled, the mGuard can be configured from a
remote computer using its web-based administrator interface. This means that a browser on the remote computer is used to configure the mGuard.
This option is disabled by default.
NOTE: If remote access is enabled, ensure that secure passwords are defined for root and admin.
To enable HTTPS remote access, make the following settings:
60
Innominate Security Technologies I15020_en_03
Management menu
Management >> Web Settings >> Access
HTTPS Web Access Enable HTTPS remote access: Yes/No
If you want to enable HTTPS remote access, set this option to
Yes. Internal HTTPS remote access (i.e., from the directly connected LAN or from the directly connected computer) can be enabled independently of this setting.
The firewall rules for the available interfaces must be defined on this page under Allowed Networks in order to specify differentiated access options on the mGuard.
Remote HTTPS TCP
Port (remote administration only)
In addition, the authentication rules under User authentica-
tion must be set, if necessary.
Default: 443
If this port number is changed, the new port number only applies for access via the External, External 2, VPN, and Dial-in interface. Port number 443 still applies for internal access.
The remote partner that implements remote access may have to specify the port number defined here after the IP address during entry of the address.
Example: if this mGuard can be accessed over the Internet via address 123.124.125.21 and port number 443 has been specified for remote access, you do not need to enter this port number after the address in the web browser of the remote partner.
If a different port number is used, it should be entered after the
IP address, e.g.,: https://123.124.125.21:442/
The mGuard authenticates itself to the partner, in this case the browser of the user, using a selfsigned machine certificate. This is a unique certificate issued by Innominate for each mGuard.
This means that every mGuard device is delivered with a unique, self-signed machine certificate.
Update SSH and
HTTPS keys
Generate new 2048-bit keys
Keys that have been generated using a older firmware might be weak and should be renewed.
• Click on this button to generate a new key.
• Observe the fingerprints of the new keys generated.
• Login via HTTPS and compare the certificate information provided by the browser.
I15020_en_03 Innominate Security Technologies
61
Management >> Web Settings >> Access[...]
Allowed Networks
Lists the firewall rules that have been set up. These apply for incoming data packets of an
HTTPS remote access attempt.
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 contains further subsequent rules that could also apply, these rules are ignored.
The rules specified here only take effect if Enable HTTPS remote access is set to Yes.
Internal access is also possible when this option is set to No. A firewall rule that would refuse Internal access does therefore not apply in this case.
The following options are available:
From IP Enter the address of the computer or network from which remote access is permitted or forbidden in this field.
IP address: 0.0.0.0/0 means all addresses. To specify an ad-
dress area, use CIDR format – see “CIDR (Classless Inter-Do-
Interface Internal / External / External 2 / DMZ / VPN / GRE / Dialin
1
Specifies to which interface the rule should apply.
If no rules are set or if no rule applies, the following default settings apply:
HTTPS access is permitted via Internal, DMZ, VPN, and Dial-
in. Access via External, External 2 and GRE is refused.
Specify the access options according to your requirements.
If you want to refuse access via Internal, DMZ,
VPN or Dial-in, you must implement this explicitly by means of corresponding firewall rules, for example, by specifying Drop as an action.
To prevent your own access being blocked, you may have to permit access simultaneously via another interface explicitly with Accept before clicking on the Apply button to activate the new setting. Otherwise, if your access is blocked, you must carry out the recovery procedure.
62
Innominate Security Technologies I15020_en_03
Management menu
Management >> Web Settings >> Access[...]
Action
Comment
Log
RADIUS Authentication
This menu item is not included in the scope of functions for
Enable RADIUS authentication
– 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, Re-
ject 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.
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
If set to No, the passwords of users who log in via HTTPS are checked via the local database.
The User authentication method can only be set to Login
restricted to X.509 client certificate if No is selected.
Select Yes to enable users to be authenticated via the RA-
DIUS server. The password is only checked locally in the case of predefined users (root, admin, netadmin, audit, and user).
The netadmin and audit authorization levels relate to access
You should only select As only method for
password authentication if you are an experienced user, as doing so could result in all access to the mGuard being blocked.
When setting up a RADIUS authentication for the first time, select Yes.
If you do intend to use the As only method for password au-
thentication option when setting up RADIUS authentication, we recommend that you create a “Customized Default Profile” which resets the authentication method.
If you have selected RADIUS authentication as the only method for checking the password, it may no longer be possible to access the mGuard. For example, this may be the case if you set up the wrong RADIUS server or convert the mGuard.
The predefined users (root, admin, netadmin, audit, and user) are then no longer accepted.
1
I15020_en_03 Innominate Security Technologies
63
Management >> Web Settings >> Access
User authentication
This menu item is not included in the scope of functions for
Defines how the local mGuard authenticates the remote partner
User authentication method
Login with password
Specifies that the remote mGuard user must use a password to log into the mGuard. The password is specified under the
The option of RADIUS authentication is also available (see
Depending on which user ID is used to log in (user or administrator password), the user has the right to operate and/or configure the mGuard accordingly.
Login with X.509 client certificate or password
– User authentication is by means of login with a password
(see above) or
– The user’s browser authenticates itself using an X.509 certificate and a corresponding private key. Additional details must be specified below.
The use of either method depends on the web browser of the remote user. The second option is used when the web browser provides the mGuard with a certificate.
Login restricted to X.509 client certificate
The user’s browser must use an X.509 certificate and the corresponding private key to authenticate itself. Additional details must be specified here.
Before enabling the Login restricted to X.509 client
certificate option, you must first select and test the
Login with X.509 client certificate or password option.
Only switch to Login restricted to X.509 client cer-
tificate when you are sure that this setting works.
Otherwise your access could be blocked.
Always take this precautionary measure when modifying settings under User authentication.
64
Innominate Security Technologies I15020_en_03
Management menu
If the following User authentication methods are defined:
– Login restricted to X.509 client certificate
– Login with X.509 client certificate or password
You must then specify how the mGuard authenticates the remote user according to X.509.
The table below shows which certificates must be provided for the mGuard to authenticate the user (access via HTTPS) if the user or their browser shows one of the following certificate types when a connection is established:
– A certificate signed by a CA
– A self-signed certificate
X.509 authentication for
HTTPS
The partner shows the following:
The mGuard authenticates the partner using:
Certificate (specific to individual), signed by CA
1
Certificate (specific to individual), self-signed
All CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
PLUS (if required)
Remote certificates, if used as a filter
1
The partner can additionally provide sub-CA certificates. In this case, the mGuard can form the set union for creating the chain from the CA certificates provided and the self-configured CA certificates. The corresponding root certificate must always be available on the mGuard.
According to this table, the certificates that must be provided are the ones the mGuard uses to authenticate a remote user (access via HTTPS) or their browser.
The following instructions assume that the certificates have already been correctly installed
the HTTPS clients must be checked for revocations.
I15020_en_03 Innominate Security Technologies
65
Management >> Web Settings >> Access
CA certificate This configuration is only necessary if the user (access via
HTTPS) shows a certificate signed by a CA.
All CA certificates required by the mGuard to form the chain to the relevant root CA certificate with the certificates shown by the user must be configured.
If the browser of the remote user also provides CA certificates that contribute to forming the chain, then it is not necessary for these CA certificates to be installed on the mGuard and referenced at this point.
However, the corresponding root CA certificate must be installed on the mGuard and made available (referenced) in any case.
When selecting the CA certificates to be used or when changing the selection or the filter settings, you must first select and test the Login with X.509
client certificate or password option as the User
authentication method before enabling the (new) setting.
Only switch to Login restricted to X.509 client cer-
tificate when you are sure that this setting works.
Otherwise your access could be blocked.
Always take this precautionary measure when modifying settings under User authentication.
66
Innominate Security Technologies I15020_en_03
Management >> Web Settings >> Access [...]
X.509 Subject
Management menu
Enables a filter to be set in relation to the contents of the Sub-
ject field in the certificate shown by the browser/HTTPS client.
It is then possible to limit or enable access for the browser/HTTPS client, which the mGuard would accept based on certificate checks:
– Limited access to certain subjects (i.e., and/or to subjects that have certain attributes or
–
Access enabled for all subjects (see glossary under “Sub-
The X.509 Subject field must not be left empty.
An * (asterisk) in the X.509 Subject field can be used to specify that all subject entries in the certificate shown by the browser/HTTPS client are permitted. It is then no longer necessary to identify or define the subject in the certificate.
I15020_en_03 Innominate Security Technologies
67
Management >> Web Settings >> Access [...] and/or to subjects that have certain attributes:
In the certificate, the certificate owner is specified in the Sub-
ject field. The entry is comprised 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=John Smith, O=Smith and Co., C=US
If certain subject attributes have very specific values for the acceptance of the browser 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=*, C=US (with or without spaces between attributes)
In this example, the attribute “C=US” must be entered in the certificate under “Subject”. It is only then that the mGuard would accept the certificate owner (subject) as a communication partner. The other attributes in the certificates to be filtered can have any value.
If a subject filter is set, the number (but not the order) of the specified attributes must correspond to that of the certificates for which the filter is to be used.
Please note that the filter is case-sensitive.
Several filters can be set and their sequence is irrelevant.
With HTTPS, the browser of the accessing user does not specify which user or administration rights it is using to log in.
These access rights are assigned by setting filters here (under
“Authorized for access as”).
This has the following result: if there are several filters that “let through” a certain user, then the first filter applies. The user is assigned the access rights as defined by this filter. This could differ from the access rights assigned to the user in the subsequent filters.
If remote certificates are configured as filters in the
X.509 Certificate table column, then these filters have priority over the filter settings here.
68
Innominate Security Technologies I15020_en_03
Management menu
Management >> Web Settings >> Access [...]
Authorized for access as
All users/root/admin/netadmin/audit
Specifies which user or administrator rights are granted to the remote user.
For a description of the root, admin, and user authorization
levels, see “Authentication >> Administrative Users” on
The netadmin and audit authorization levels relate to access
X.509 Certificate Configuration is required in the following cases:
– Remote users each show a self-signed certificate.
– Remote users each show a certificate signed by a CA. Filtering should take place: access is only granted to a user whose certificate copy is installed on the mGuard as the remote certificate and is provided to the mGuard in this table as the X.509 certificate.
If used, this filter has priority over the Subject filter in the table above.
The entry in this field defines which remote certificate the mGuard should adopt in order to authenticate the partner
(browser of the remote user).
The remote certificate can be selected from the selection list.
The selection list contains the remote certificates that have
been loaded on the mGuard under the Authentication >> Cer-
Authorized for access as root/admin/netadmin/audit/user
Specifies which user or administrator rights are granted to the remote user.
For a description of the root, admin, and user authorization
levels, see “Authentication >> Administrative Users” on
The netadmin and audit authorization levels relate to access
I15020_en_03 Innominate Security Technologies
69
4.3
Management >> Licensing
You can obtain additional optional licenses from you authorized mGuard dealer.
4.3.1
Overview
With mGuard Version 5.0 or later, licenses remain installed even after the firmware is flashed.
However, licenses are still deleted when devices with older firmware versions are flashed to
Version 5.0.0 or later. Before flashing, the license for using the new update must then first be obtained so that the required license file is available for the flashing process.
This applies to major release upgrades, e.g., from Version 4.x.y to Version 5.x.y to Version
6.x.y, etc.
Management >> Licensing >> Overview
Basic settings Feature License Shows which functions are included with the installed mGuard licenses, e.g., the number of possible VPN tunnels, whether remote logging is supported, etc.
4.3.2
Install
More functions can be added later to the mGuard license you have obtained. You will find a voucher serial number and a voucher key in the voucher included with the mGuard. The voucher can also be purchased separately.
It can be used to:
– Request the required feature license file
– Install the license file that you receive following this request
70
Innominate Security Technologies I15020_en_03
Management menu
Management >> Licensing >> Install
Automatic License Installation
Voucher Serial Number/Voucher Key
Manual License Installation
Reload Licenses
Order License
Filename
Enter the serial number printed on the voucher and the corresponding voucher key, then click on Online License Re-
quest.
The mGuard now establishes a connection via the Internet and installs the corresponding license on the mGuard if the voucher is valid.
This option can be used if the license installed on the mGuard has been deleted. Click on Online License Reload.
The licenses that were previously issued for this mGuard are then retrieved from the server via the Internet and installed.
After clicking on Edit License Request Form, an online form is displayed, which can be used to order the desired license.
Enter the following information in the form:
– Voucher Serial Number: the serial number printed on your voucher
– Voucher Key: the voucher key on your voucher
– Flash ID: this is entered automatically
After sending the form, the license file is made available for download and can be installed on the mGuard in a further step.
Install license file
To install a license, first save the license file as a separate file on your computer, then proceed as follows:
• Click on Browse... next to the Filename field. Select the file and open it so that the file name or path is displayed in the Filename field.
• Then click on Install license file.
I15020_en_03 Innominate Security Technologies
71
4.3.3
Terms of License
72
Lists the licenses of the external software used on the mGuard. The software is usually open-source software.
Innominate Security Technologies I15020_en_03
Management menu
4.3.4
Management >> Update
With mGuard firmware Version 5.0.0 or later, a license must be obtained for the relevant device before a major release upgrade (e.g., from Version 4.x.y to Version 5.x.y or from
Version 5.x.y to Version 6.x.y) can be installed.
Minor release upgrades (i.e., the same major version, e.g., within Version 5.x.y) can be installed without a license until further notice.
4.3.5
Overview
Management >> Update >> Overview
System Information Version
Package Versions
Base
The current software version of the mGuard.
The software version that was originally used to flash this mGuard.
Updates List of updates that have been installed on the base.
Lists the individual software modules of the mGuard. Can be used for support purposes.
I15020_en_03 Innominate Security Technologies
73
4.3.6
Update
Firmware updates with firewall redundancy enabled
Updates of Version 7.3.1 or later can be performed while an mGuard redundant pair is connected and operating.
This does not apply to the following devices:
– mGuard rs
– mGuard
– mGuard
– mGuard
– mGuard
These devices must be updated successively while the relevant redundant device is disconnected.
If firewall redundancy is activated, the two mGuard devices of a redundant pair can be updated at the same time. mGuard devices that form a pair automatically decide which mGuard is to perform the update first while the other mGuard remains active. If the active mGuard is unable to boot within 25 minutes of receiving the update command (because the other mGuard has not yet taken over), it aborts the update and continues to run using the existing firmware version.
Updating the firmware
There are two options for performing a firmware update:
1.
You have the current package set file on your computer (the file name ends with
“.tar.gz”) and you perform a local update.
2.
The mGuard downloads a firmware update of your choice from the update server via the Internet and installs it.
74
Innominate Security Technologies
NOTE: Do not interrupt the power supply to the mGuard during the update process. Otherwise, the device could be damaged and may have to be reactivated by the manufacturer.
I15020_en_03
Management menu
Depending on the size of the update, the process may take several minutes.
A message is displayed if a restart is required after completion of the update.
With mGuard firmware Version 5.0.0 or later, a license must be obtained for the relevant device before a major release upgrade (e.g., from Version 5.x.y to Version 6.x.y or from
Version 6.x.y to Version 7.x.y) can be installed.
Minor release upgrades (i.e., the same major version, e.g., within Version 7.x.y) can be installed without a license until further notice.
Management >> Update
Local Update
Online Update
Automatic Update
Filename
Package set name
To install the packages, proceed as follows:
• Click on Browse..., select the file, and open it so that the file name or path is displayed in the Filename field.
The file name must have the following format: update-a.b.c-d.e.f.default.<platform>.tar.gz
Example: update-7.0.0-7.0.1.default.ixp4xx_be.tar.gz
• Then click on Install Packages.
To perform an online update, proceed as follows:
• Make sure that there is at least one valid entry under Up-
date Servers. You should have received the necessary details from your licenser.
• Enter the name of the package set, e.g.,
7.2.0”.
• Then click on Install Package Set.
This is a version of the online update where the mGuard independently determines the required package set.
Install the latest patch release (x.y.Z)
Patch releases resolve errors in previous versions and have a version number which only changes in the third digit position.
For example, 4.0.1 is a patch release for Version 4.0.0.
Install the latest minor release (x.Y.z) for the currently installed major version
Minor and major releases supplement the mGuard with new properties or contain changes that affect the behavior of the mGuard. Their version number changes in the first or second digit position.
Install the next major release (X.y.z)
For example, 4.1.0 is a major or minor release for versions
3.1.0 or 4.0.1 respectively.
I15020_en_03 Innominate Security Technologies
75
Management >> Update [...]
Update Servers Specify from which servers an update may be performed.
The list of servers is processed from top to bottom until an available server is found. The order of the entries therefore also specifies their priority.
All configured update servers must provide the same updates.
The following options are available:
Protocol The update can be performed via HTTPS or HTTP.
Server
Via VPN
Host name of the server that provides the update files.
The update is performed via the VPN tunnel.
Default: No.
Updates via VPN are not supported if the relevant
VPN tunnel has been disabled in the configuration
(see IPsec VPN >> Connections) and has only
been temporarily opened via the service contact or
CGI interface.
Login
Password
Login for the server.
Password for login.
76
Innominate Security Technologies I15020_en_03
Management menu
4.4
Management >> Configuration Profiles
4.4.1
Configuration Profiles
I15020_en_03
You can save the settings of the mGuard as a configuration profile under any name on the mGuard. It is possible to create multiple configuration profiles. You can then switch between different profiles as required, for example, if the mGuard is used in different environments.
Furthermore, you can also save the configuration profiles as files on your configuration computer. Alternatively, these configuration files can be loaded onto the mGuard and activated.
In addition, you can restore the Factory Default settings at any time.
Certain models also allow the configuration profiles to be stored on external configuration storage (ECS).
– SD card: mGuard
– V.24/USB memory stick: EAGLE mGuard
When a configuration profile is saved, the passwords used for authenticating administrative access to the mGuard are not saved.
It is possible to load and activate a configuration profile that was created under an older firmware version. However, the reverse is not true – a configuration profile created under a newer firmware version should not be loaded and will be rejected.
Innominate Security Technologies
77
Encrypted configuration memory
In the case of platform 2 mGuard and firmware 7.6.1 or later, the configuration storage
(ECS) and configuration profile (ATV) can be encrypted. This makes the rollout easier. You can save several mGuard configurations on an SD card and then use it to startup all mGuards. During the startup process, the mGuard finds the valid configurations on the SD
card. This is loaded, decrypted, and used as a valid configuration (see “Encrypt the data on
Management >> Configuration Profiles
Configuration Profiles At the top of the page there is a list of the configuration profiles that are stored on the been saved by the user (see below), they will be listed here.
Active configuration profile: the configuration profile that is currently enabled has an Active symbol at the start of the entry. If a configuration is changed in a way that it corresponds to a stored configuration profile, the stored profile will be marked with the Active symbol, after the settings were applied.
Configuration profiles that are stored on the mGuard can be:
– Enabled
– Saved as a file on the connected configuration computer
– Viewed (and checked)
– Deleted
– Displayed
Displaying the configuration profile:
• Click on the name of the configuration profile in the list.
View (and check) the configuration profile before enabling:
• Click on View to the right of the name of the relevant configuration profile.
The corresponding configuration profile will be loaded but not enabled. All entries that differ from the actually used configuration are highlighted in blue on the relevant pages and in the associated menu items (Exception: modified tables). The displayed changes may be saved (Apply) with or without further manually changes or discarded
(Reset).
• Change entries arbitrarily and click on Apply to safe the entries of the loaded profile with all made changes.
• Click on Reset to discard all made changes.
Enabling the factory default or a configuration profile saved on the mGuard by the user:
• Click on Restore to the right of the name of the relevant configuration profile.
The corresponding configuration profile is activated.
Saving the configuration profile as a file on the configuration computer:
• Click on Download to the right of the name of the relevant configuration profile.
• In the dialog box that is displayed, specify the file name and folder under which the configuration profile is to be saved as a file.
(The file name can be freely selected.)
78
Innominate Security Technologies I15020_en_03
Management menu
Management >> Configuration Profiles [...]
Deleting a configuration profile:
• Click on Delete to the right of the name of the relevant configuration profile.
The Factory Default profile cannot be deleted.
Save Current Configuration to
Profile
Saving the active configuration as a configuration profile on the mGuard:
• Enter the desired profile name in the Name for the new profile field next to “Save Current Configuration to Profile”.
• Click on Save.
The configuration profile is saved on the mGuard, and the name of the profile appears in the list of profiles already stored on the mGuard.
Upload Configuration to Profile Uploading a configuration profile that has been saved to a file on the configuration computer:
Requirement: a configuration profile has been saved on the configuration computer as a file according to the procedure described above.
• Enter the desired profile name in the Name for the new profile field next to “Upload
Configuration to Profile”.
• Click on Browse..., select and open the relevant file in the dialog box that is displayed.
• Click on Upload.
The configuration profile is loaded on the mGuard, and the name assigned in step 1 appears in the list of profiles already stored on the mGuard.
External Config Storage
(ECS)
Saved configuration profiles on the mGuard may be exported to External Configuration
Storages (ECS). Exported profiles can again be imported from the ECS into the mGuard.
Dependent on the used device and technical preconditions, different ECS (e.g. SD cards or USB flash drives) may be used as a storage medium.
Files will be exported with file extension “ecs.tgz“. To import the file into the mGuard the device must be started with an inserted SD card or connected USB flash drive. The Configuration will be automatically loaded and decrypted and subsequently used as the active configuration.
Current state of the
ECS
The current state is updated dynamically. (See “State of the
External Configuration Storage ECS” in “Event table” on
Save the current configuration to an ECS
I15020_en_03
When replacing the original device with a replacement device, the configuration profile of the original device can be applied using the ECS. To do so, the replacement device must still use
“root” as the password for the “root” user.
If the root password on the replacement device is not “root”, this password must be entered in the The root password to
save to the ECS field.
(See “Saving a profile to an external storage medium” )
Innominate Security Technologies
79
Management >> Configuration Profiles [...]
Automatically save configuration changes to an ECS
When set to Yes, the configuration changes are automatically saved to the ECS, i.e., the ECS always stores the profile currently used.
The mGuard only uses the automatically stored configuration profiles upon startup if the original password (“root”) is still set
on the mGuard for the “root” user (see “Loading a profile from
Configuration changes are also made, if the ECS is disconnected, full, or defective. The corresponding error messages
are displayed in the Logging menu (see “Logging >> Browse local logs” ).
Activation of the new setting extends the response time of the user interface when changing any settings.
80
Innominate Security Technologies I15020_en_03
Management menu
Management >> Configuration Profiles [...]
Encrypt the data on the ECS
Load configuration from ECS during boot
In the case of firmware 7.6.1 or later, the configuration storage
(ECS) and configuration profile (ATV) can be encrypted. This makes the mGuard rollout easier. You can save several mGuard configurations on an SD card (on a USB stick in the centerport) and then use it to startup all mGuards. During the startup process, the mGuard finds the valid configurations on the configuration storage. This is loaded, decrypted, and used as a valid configuration.
If Yes is selected, the configuration changes are encrypted and stored on an ECS.
When set to Yes, the ECS is accessed during the boot process.
I15020_en_03 Innominate Security Technologies
81
Profiles on an external storage medium
rs4000/rs2000 rs4000/rs2000, storage (ECS).
configuration profiles can also be stored on a USB stick. This must have the following properties:
– FAT file system on the first primary partition, at least 64 Mbytes free memory capacity.
rs4000/rs2000 rs4000/rs2000, stored on an SD card (up to 2 GB capacity). It must have the following properties:
– FAT file system on the first primary partition, at least 64 Mbytes free memory capacity.
– Certified and released by Innominate Security Technologies AG (current release list can be found at www.innominate.com
).
Saving a profile to an external storage medium
• EAGLE
(ACA21). Type ACA21 ECS devices are not suitable for manual modifications by a computer or similar.
• mGuard
terface: insert the USB stick into the USB socket.
• mGuard
• If the root password on the mGuard onto which the profile is going to be subsequently loaded is not “root”, this password must be entered in the The root password to save
to the ECS field.
• Click on Save.
For EAGLE mGuard: the LED STATUS and LED V.24 flash until the saving process is complete.
Loading a profile from an external storage medium
• EAGLE
(ACA21). Type ACA21 ECS are not suitable for manual modifications by a computer or similar.
• mGuard mGuard with USB interface: insert the USB stick into the USB socket.
• mGuard
• Once the storage medium has been inserted, start the mGuard.
• The mGuard root password must either be “root” or correspond to the password that was specified while the profile was being saved.
For EAGLE mGuard: the LED STATUS and LED V.24 flash until the saving process is complete.
The configuration profile loaded from the storage medium is loaded onto the mGuard and applied.
82
Innominate Security Technologies I15020_en_03
Management menu
The loaded configuration profile does not appear in the list of configuration profiles stored on the mGuard.
The configuration on the external storage medium also contains the passwords for the
root, admin, netadmin, audit, and user users. These passwords are also loaded when loading from an external storage medium. The netadmin and audit authorization levels re-
4.5
Management >> SNMP
The mGuard must not be simultaneously configured via the web access, shell access, or
SNMP. Simultaneous configuration via the different access methods might lead to unexpected results.
4.5.1
Query
I15020_en_03
The SNMP (Simple Network Management Protocol) is mainly used in more complex networks to monitor the state and operation of devices.
SNMP is available in several releases: SNMPv1/SNMPv2 and SNMPv3.
The older versions (SNMPv1/SNMPv2) do not use encryption and are not considered to be secure. The use of SNMPv1/SNMPv2 is therefore not recommended.
SNMPv3 is significantly better in terms of security, but not all management consoles support this version yet.
Innominate Security Technologies
83
If SNMPv3 or SNMPv1/v2 is activated, this is indicated by a green signal field on the tab at the top of the page. Otherwise, i.e., if SNMPv3 or SNMPv1/v2 is not active, the signal field is red.
Processing an SNMP request may take more than one second. However, this value corresponds to the default timeout value of some SNMP management applications.
• If you experience timeout problems, set the timeout value of your management application to values between 3 and 5 seconds.
Management >> SNMP >> Query
Settings Enable SNMPv3 access: Yes/No
If you wish to allow monitoring of the mGuard via SNMPv3, set this option to Yes.
The firewall rules for the available interfaces must be defined on this page under Allowed Networks in order to specify differentiated access and monitoring options on the mGuard.
Enable SNMPv1/v2 access: Yes/No
Access via SNMPv3 requires authentication with a login and password. The default settings for the login parameters are:
Login: admin
Password: SnmpAdmin (please note that the password is case-sensitive)
MD5 is supported for the authentication process; DES is supported for encryption.
The login parameters for SNMPv3 can only be changed using
SNMPv3.
If you wish to allow monitoring of the mGuard via SNMPv1/v2, set this option to Yes.
You must also enter the login data under SNMPv1/v2 Com-
munity.
The firewall rules for the available interfaces must be defined on this page under Allowed Networks in order to specify differentiated access and monitoring options on the mGuard.
Port for incoming
SNMP connections
Default: 161
If this port number is changed, the new port number only applies for access via the External, External 2, DMZ, VPN, GRE, and Dial-in interface. Port number 161 still applies for internal access.
The remote partner that implements remote access may have to specify the port number defined here during entry of the address.
84
Innominate Security Technologies I15020_en_03
Management menu
Management >> SNMP >> Query [...]
Run SNMP Agent under the permissions of the following user
SNMPv1/v2 Community
Allowed Networks admin / netadmin
Defines under which permissions the SNMP agent runs.
Read-Write Community
Enter the required login data in this field.
Read-Only Community Enter the required login data in this field.
Lists the firewall rules that have been set up. These apply for incoming data packets of an
SNMP access attempt.
The rules specified here only take effect if Enable SNMPv3 access or Enable
SNMPv1/v2 access is set to Yes.
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 contains further subsequent rules that could also apply, these rules are ignored.
From IP Enter the address of the computer or network from which remote access is permitted or forbidden in this field.
The following options are available:
– An IP address.
–
To specify an address area, use CIDR format (see “CIDR
Interface
– 0.0.0.0/0 means all addresses.
Internal / External / External 2 / DMZ / VPN / GRE /Dialin
1
Specifies to which interface the rule should apply.
If no rules are set or if no rule applies, the following default settings apply:
SNMP monitoring is permitted via Internal, DMZ, VPN, and
Dial-in.
Access via External, External 2 and GRE is refused.
Specify the monitoring options according to your requirements.
NOTE: If you want to refuse access via Internal,
DMZ, VPN or Dial-in, you must implement this explicitly by means of corresponding firewall rules, for example, by specifying Drop as an action. To
prevent your own access being blocked, you may have to permit access simultaneously via another interface explicitly with Accept before clicking on the Apply button to activate the new setting. Otherwise, if your access is blocked, you must carry out the recovery procedure.
I15020_en_03 Innominate Security Technologies
85
Management >> SNMP >> Query [...]
Action
Comment
Log
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.
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
1
86
Innominate Security Technologies I15020_en_03
4.5.2
Trap
Management menu
I15020_en_03
In certain cases, the mGuard can send SNMP traps. SNMP traps are only sent if the SNMP request is activated.
The traps correspond to SNMPv1. The trap information for each setting is listed below. A more detailed description can be found in the MIB that belongs to the mGuard.
If SNMP traps are sent to the partner via a VPN tunnels, the IP address of the partner must be located in the network that is specified as the Remote network in the definition of the
VPN connection.
The internal IP address must be located in the network that is specified as Local in the
definition of the VPN connection (see IPsec VPN >> Connections >> Edit >> General).
–
If the IPsec VPN >> Connections >> Edit >> General, Local option is set to 1:1 NAT
(see Page 288), the following applies:
The internal IP address must be located in the specified local network.
Innominate Security Technologies
87
–
If the IPsec VPN >> Connections >> Edit >> General, Remote option is set to 1:1 NAT
(see Page 289), the following applies:
The IP address of the SysLog server must be located in the network that is specified as
Remote in the definition of the VPN connection.
Management >> SNMP >> Trap
Basic traps SNMP authentication Activate traps Yes/No
– enterprise-oid : mGuardInfo
– generic-trap : authenticationFailure
– specific-trap : 0
Link Up/Down
Sent if an unauthorized station attempts to access the mGuard
SNMP agent.
Activate traps Yes/No
– enterprise-oid : mGuardInfo
– generic-trap : linkUp, linkDown
– specific-trap : 0
Sent when the connection to a port is interrupted (linkDown) or restored (linkUp).
Coldstart Activate traps Yes/No
– enterprise-oid : mGuardInfo
– generic-trap : coldStart
– specific-trap : 0
Sent after a cold restart or warm start.
Admin connection attempt (SSH, HTTPS)
Activate traps Yes/No
– enterprise-oid : mGuard
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardHTTPSLoginTrap (1)
: mGuardHTTPSLastAccessIP
This trap is sent if someone has tried successfully or unsuccessfully (e.g., using an incorrect password) to open an
HTTPS session. The trap contains the IP address from which the attempt was issued.
– enterprise-oid : mGuard
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardShellLoginTrap (2)
: mGuardShellLastAccessIP
This trap is sent when someone opens the shell via SSH or the serial interface. The trap contains the IP address of the login request. If this request was sent via the serial interface, the value is 0.0.0.0.
88
Innominate Security Technologies I15020_en_03
Management menu
Management >> SNMP >> Trap [...]
Admin access (SSH,
HTTPS)
Hardware related traps
(only
Switch,
New DHCP client
Chassis (power, signal relay)
Activate traps Yes/No
– enterprise-oid : mGuard
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapSSHLogin
: mGuardTResSSHUsername
mGuardTResSSHRemoteIP
This trap is sent when someone accesses the mGuard via
SSH.
– enterprise-oid : mGuard
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapSSHLogout
: mGuardTResSSHUsername
mGuardTResSSHRemoteIP
This trap is sent when access to the mGuard via SSH is terminated.
– enterprise-oid : mGuard
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: 3
: mGuardDHCPLastAccessMAC
This trap is sent when a DHCP request is received from an unknown client.
Activate traps Yes/No
– enterprise-oid : mGuardTrapSenderIndustrial
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapIndustrialPowerStatus (2)
: mGuardTrapIndustrialPowerStatus
Sent when the system registers a power failure.
– enterprise-oid : mGuardTrapSenderIndustrial
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapSignalRelais (3)
: mGuardTResSignalRelaisState
(mGuardTEsSignlalRelaisReason, mGuardTResSignal RelaisReasonIdx)
Sent after the signal contact is changed and indicates the current status (0 = Off, 1 = On).
I15020_en_03 Innominate Security Technologies
89
Management >> SNMP >> Trap [...]
Agent (external config storage, temperature)
Activate traps Yes/No
– enterprise-oid : mGuardTrapIndustrial
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapIndustrialTemperature (1)
: mGuardSystemTemperature,
mGuardTrapIndustrialTempHiLimit,
mGuardTrapIndustrialLowLimit
The trap indicates the temperature in the event of the temperature exceeding the specified limit values.
– enterprise-oid : mGuardTrapIndustrial
– genericTrap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapAutoConfigAdapterState
(4)
: mGuardTrapAutoConfigAdapter
Change
This trap is sent after access to the ECS.
traps (BLADE only)
(Blade switch, failure): activate traps Yes/No
– enterprise-oid : mGuardTrapBladeCTRL
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapBladeCtrlPowerStatus (2)
: mGuardTrapBladeRackID,
mGuardTrapBladeSlotNr,
mGuardTrapBladeCtrlPowerStatus
This trap is sent when the power supply status of the blade pack changes.
– enterprise-oid : mGuardTrapBladeCTRL
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapBladeCtrlRunStatus (3)
: mGuardTrapBladeRackID,
mGuardTrapBladeSlotNr,
mGuardTrapBladeCtrlRunStatus
This trap is sent when the blade run status changes.
Blade reconfiguration (Backup/restore): activate traps Yes/No
– enterprise-oid : mGuardTrapBladeCtrlCfg
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapBladeCtrlCfgBackup (1)
: mGuardTrapBladeRackID,
mGuardTrapBladeSlotNr,
mGuardTrapBladeCtrlCfgBackup
This trap is sent when configuration backup is triggered for the
90
Innominate Security Technologies I15020_en_03
Management menu
Management >> SNMP >> Trap [...]
– enterprise-oid : mGuardTrapBladeCtrlCfg
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapBladeCtrlCfgRestored 2
: mGuardTrapBladeRackID,
mGuardTrapBladeSlotNr,
mGuardTrapBladeCtrlCfgRestored
This trap is sent when configuration restoration is triggered
CIFS integrity traps
This menu item is not included in the scope of functions for
Successful integrity check of a CIFS share
Failed integrity check of a CIFS share
Found a (suspicious) difference on a CIFS share
Activate traps Yes/No
– enterprise-oid : mGuardTrapCIFSScan
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapCIFSScanInfo (1)
: mGuardTResCIFSShare, mGuardTResCIFSScanError, mGuardTResCIFSNumDiffs
This trap is sent if the CIFS integrity check has been successfully completed.
Activate traps Yes/No
– enterprise-oid : mGuardTrapCIFSScan
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapCIFSScanFailure (2)
: mGuardTResCIFSShare, mGuardTResCIFSScanError, mGuardTResCIFSNumDiffs
This trap is sent if the CIFS integrity check has failed.
Activate traps Yes/No
– enterprise-oid : mGuardTrapCIFSScan
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapCIFSScanDetection (3)
: mGuardTResCIFSShare, mGuardTResCIFSScanError, mGuardTResCIFSNumDiffs
This trap is sent if the CIFS integrity check has detected a deviation.
I15020_en_03 Innominate Security Technologies
91
Management >> SNMP >> Trap [...]
Redundancy traps Status change
This menu item is not included in the scope of functions for
Userfirewall traps
This menu item is not included in the scope of functions for
Userfirewall traps
Activate traps Yes/No
– enterprise-oid : mGuardTrapRouterRedundancy
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapRouterRedBackupDown
: mGuardTResRedundacyBackup-
Down
This trap is sent when the Backup device (secondary mGuard) is not reachable by the Master device (primary mGuard). (The trap will only be sent if the ICMP check is not active.)
– enterprise-oid : mGuardTrapRouterRedundancy
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapRRedundancyStatus-
Change
: mGuardRRedStateSSV, mGuardRRedStateACSummary, mGuardRRedStateCCSummary, mGuardRRedStateStateRepSummary
This trap is sent when the status of the HA cluster has changed.
Activate traps Yes/No
– enterprise-oid : mGuardTrapUserFirewall
– generic-trap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapUserFirewallLogin (1)
: mGuardTResUserFirewallUsername, mGuardTResUserFirewallSrcIP, mGuardTResUserFirewallAuthenticationMethod
This trap is sent when a user logs into the user firewall.
– enterprise-oid : mGuardTrapUserFirewall
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapUserFirewallLogout (2)
: mGuardTResUserFirewallUsername, mGuardTResUserFirewallSrcIP, mGuardTResUserFirewallLogoutReason
This trap is sent when a user logs out of the user firewall.
– enterprise-oid : mGuardTrapUserFirewall
– generic-trap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapUserFirewallAuthError
TRAP-TYPE (3)
: mGuardTResUserFirewallUsername, mGuardTResUserFirewallSrcIP, mGuardTResUserFirewallAuthentication-
Method
This trap is sent in the event of an authentication error.
92
Innominate Security Technologies I15020_en_03
Management menu
Management >> SNMP >> Trap [...]
VPN traps
Mobile network traps
This menu item is only included in the scope of functions for the
IPsec connection status changes
Activate traps Yes/No
– enterprise-oid :
– genericTrap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapVPNIKEServerStatus (1)
: mGuardTResVPNStatus
This trap is sent when the IPsec IKE server is started or stopped.
– enterprise-oid : mGuardTrapVPN
– genericTrap : enterpriseSpecific
– specific-trap
– additional
: mGuardTrapVPNIPsecConnStatus (2)
: mGuardTResVPNName, mGuardTResVPNIndex, mGuardTResVPNPeer, mGuardTResVPNStatus, mGuardTResVPNType, mGuardTResVPNLocal, mGuardTResVPNRemote
This trap is sent when the status of an IPsec connection changes.
– enterprise-oid : mGuard
– generic-trap : enterpriseSpecific
– specific-trap : mGuardTrapVPNIPsecConnStatus
This trap is sent when a connection is established or aborted.
It is not sent when the mGuard is about to accept a connection request for this connection.
L2TP connection status changes
Activate traps Yes/No
– enterprise-oid : mGuardTrapVPN
– genericTrap
– specific-trap
– additional
: enterpriseSpecific
: mGuardTrapVPNL2TPConnStatus (3)
: mGuardTResVPNName, mGuardTResVPNIndex, mGuardTResVPNPeer, mGuardTResVPNStatus, mGuardTResVPNLocal, mGuardTResVPNRemote
This trap is sent when the status of an L2TP connection changes.
Incoming text message or voice call and network supervision
Enables traps for mobile phone connection. Traps are sent when an text message is received, a call is received or the mobile phone connection drops.
I15020_en_03 Innominate Security Technologies
93
Management >> SNMP >> Trap [...]
Trap destinations Traps can be sent to multiple destinations.
Destination IP IP address to which the trap should be sent.
Destination Port Default: 162
Destination port to which the trap should be sent.
Destination Name
Destination
Community
Optional name for the destination. Does not affect the generated traps.
Name of the SNMP community to which the trap is assigned.
94
Innominate Security Technologies I15020_en_03
Management menu
4.5.3
LLDP
LLDP (Link Layer Discovery Protocol, IEEE 802.1AB/D13) uses suitable request methods to automatically determine informations about the network infrastructure. A System that uses LLDP can be configurated in a way, that it listens to or sends LLDP informations. There are no requests, replies, or acknowledgements of any kind.
As a sender the mGuard sends Ethernet multicasts (layer 2) unsolicited periodically in configured time intervals (typically ~30s).
Management >> SNMP >> LLDP
LLDP Mode
Internal/LAN interface
External/WAN interface
Chassis ID
IP address
Port description
System name
Button: Update
Enabled/Disabled
The LLDP service or agent can be globally enabled or disabled here. If the function is enabled, this is indicated by a green signal field on the tab at the top of the page. If the signal field is red, the function is disabled.
A unique ID of the computer found; typically one of its MAC addresses.
IP address of the computer found. This can be used to perform administrative activities on the computer via SNMP.
A textual description of the network interface where the computer was found.
Host name of the computer found.
To update the displayed data, if necessary, click on Update.
I15020_en_03 Innominate Security Technologies
95
4.6
Management >> Central Management
4.6.1
Configuration Pull
The mGuard can retrieve new configuration profiles from an HTTPS server in adjustable time intervals, provided that the server makes them available to the mGuard as files (file extension: .atv). If the configuration provided differs from the active configuration of the mGuard, the available configuration is automatically downloaded and activated.
Management >> Central Management >> Configuration Pull
Configuration Pull Pull Schedule Here, specify whether (and if so, when and at what intervals) the mGuard should attempt to download and apply a new configuration from the server. To do this, open the selection list and select the desired value.
A new field is shown when Time Schedule is selected. In this field, specify whether the new configuration should be downloaded from the server daily or regularly on a certain weekday, and at what time.
Time-controlled download of a new configuration is only pos-
Server
Time control sets the selected time based on the configured time zone.
IP address or host name of the server that provides the configurations.
96
Innominate Security Technologies I15020_en_03
Management menu
Management >> Central Management >> Configuration Pull [...]
Directory The directory (folder) on the server where the configuration is located.
Filename The name of the file in the directory defined above. If no file name is defined here, the serial number of the mGuard is used with file extension “.atv”.
Number of times a configuration profile is ignored after it was rolled back
Default: 10
After retrieving a new configuration, it is possible that the mGuard may no longer be accessible after applying the new configuration. It is then no longer possible to implement a new remote configuration to make corrections. In order to prevent this, the mGuard performs the following check:
As soon as the retrieved configuration is applied, the mGuard tries to connect to the configuration server again based on the new configuration. It then attempts to download the newly applied configuration profile again.
If successful, the new configuration remains in effect.
If this check is unsuccessful for whatever reason, the mGuard assumes that the newly applied configuration profile is faulty. The mGuard remembers the MD5 total for identification purposes. The mGuard then performs a rollback.
Rollback means that the last (working) configuration is restored. This assumes that the new (non-functioning) configuration contains an instruction to perform a rollback if a newly loaded configuration profile is found to be faulty according to the checking procedure described above.
When the mGuard makes subsequent attempts to retrieve a new configuration profile periodically after the time defined in the Pull Schedule field (and Time Schedule) has elapsed, it will only accept the profile subject to the following selection criterion: the configuration profile provided must differ from the configuration profile previously identified as faulty for the mGuard and which resulted in the rollback.
(The mGuard checks the MD5 total stored for the old, faulty, and rejected configuration against the MD5 total of the new configuration profile offered.)
If this selection criterion is met, i.e., a newer configuration profile is offered, the mGuard retrieves this configuration profile, applies it, and checks it according to the procedure described above. It also disables the configuration profile by means of rollback if the check is unsuccessful.
If the selection criterion is not met (i.e., the same configuration profile is being offered), the selection criterion remains in force for all further cyclic requests for the period specified in the Number of times... field.
If the specified number of times elapses without a change of the configuration profile on the configuration server, the mGuard applies the unchanged new (“faulty”) configuration profile again, despite it being “faulty”. This is to rule out the possibility that external factors
(e.g., network failure) may have resulted in the check being unsuccessful.
The mGuard then attempts to connect to the configuration server again based on the new configuration that has been reapplied. It then attempts to download the newly applied configuration profile again. If this is unsuccessful, another rollback is performed. The selection criterion is enforced again for the further cycles for loading a new configuration as often as is defined in the Number of times... field.
I15020_en_03 Innominate Security Technologies
97
Management >> Central Management >> Configuration Pull [...]
If the value in the Number of times... field is specified as 0, the selection criterion (the offered configuration profile is ignored if it remains unchanged) will never be enforced. As a result, the second of the following objectives could then no longer be met.
This mechanism has the following objectives:
1.
After applying a new configuration, it must be ensured that the mGuard can still be configured from a remote location.
2.
When cycles are close together (e.g., Pull Schedule = 15 minutes), the mGuardMGUARD must be prevented from repeatedly testing a configuration profile that might be faulty at intervals that are too short. This can hinder or prevent external administrative access, as the mGuard might be too busy dealing with its own processes.
3.
External factors (e.g., network failure) must be largely ruled out as a reason why the mGuard considers the new configuration to be faulty.
Download timeout Default: 2 minutes
Specifies the maximum timeout length (period of inactivity) when downloading the configuration file. The download is aborted if this time is exceeded. If and when a new download is attempted depends on the setting of Pull Schedule (see above).
The entry can be made in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes and seconds [h:mm:ss].
Login
Password
Server Certificate
Login (user name) that the HTTPS server requests.
Password that the HTTPS server requests.
The certificate that the mGuard uses to check the authenticity of the certificate “shown” by the configuration server. It prevents an incorrect configuration from an unauthorized server from being installed on the mGuard.
The following may be specified here:
– A self-signed certificate of the configuration server or
– The root certificate of the CA (certification authority) that issued the server certificate. This is valid when the configuration server certificate is signed by a CA (instead of selfsigned).
98
Innominate Security Technologies I15020_en_03
Management menu
Management >> Central Management >> Configuration Pull [...]
.
If the stored configuration profiles also contain the private VPN key for the VPN connection(s) with
PSK, the following conditions must be met:
Download Test
– The password should consist of at least 30 random upper and lower case letters and numbers (to prevent unauthorized access).
– The HTTPS server should only grant access to the configuration of this individual mGuard using the login and password specified. Otherwise, users of other mGuard devices could access this individual device.
The IP address or the host name specified under
Server must be the same as the server certificate's common name (CN).
Self-signed certificates should not use the “keyusage” extension.
To install a certificate, proceed as follows:
Requirement: the certificate file must be saved on the connected computer.
• Click on Browse... to select the file.
• Click on Import.
• By clicking on Test Download, you can test whether the specified parameters are correct without actually saving the modified parameters or activating the configuration profile. The result of the test is displayed in the right-hand column.
Ensure that the profile on the server does not contain unwanted variables starting with
“GAI_PULL_”, as these overwrite the applied configuration.
I15020_en_03 Innominate Security Technologies
99
4.7
Management >> Service I/O
Service contacts (service I/Os) can be connected to some mGuards.
– mGuard 3G
– mGuard Switch
– mGuard
– mGuard rs
Connection of the service contacts is described in the user manual for the devices (UM EN
MGUARD DEVICES).
Input/CMD 1, CMD 2, CMD
3
A push button or an on/off switch can be connected to the inputs. One or more freely selectable VPN connections or firewall rule records can be switched via the corresponding switch.
A mixture of VPN connections and firewall rule records is also possible. The web interface displays which VPN connections and which firewall rule records are connected to this input.
The push button or on/off switch is used to establish and release predefined VPN connections or to activate defined firewall rule records.
Signal contact (signal output) ACK 1, 2
You can set whether to monitor specific VPN connections or firewall rule records and to display them using LEDs.
If VPN connections are being monitored, an illuminated LED indicates that VPN connections are established.
Alarm output ACK 3 The alarm output monitors the function of the mGuard and therefore enables remote diagnostics.
The associated LED lights up red if the alarm output is open due to an error.
The alarm output reports the following, if it has been activated.
– Failure of the redundant supply voltage
– Monitoring of the link status of the Ethernet connections
– Monitoring of the temperature condition
– Monitoring of the connection state of the redundancy
– Monitoring of the connection state of the internal modem
100
Innominate Security Technologies I15020_en_03
4.7.1
Service I/O
Management menu
Management >> Service I/O >> Service I/O
Input/CMD 1-3 Switch type connected to the input
Push button or on/off switch
Select the type of switch connected.
Current state Displays the state of the connected switch.
When editing the VPN connection, the switch must be se-
lected under “Controlling service input” (under IPsec VPN >>
Connections >> Edit >> General and OpenVPN Client >>
Connections >> Edit >> General.
I15020_en_03 Innominate Security Technologies
101
Management >> Service I/O >> Service I/O [...]
Output/ACK 1-2
IPsec connections controlled by this input
Switch, mGuard devices have connections to which external buttons or an on/off switch and actuators (e.g., a signal lamp) can be connected. One of the configured VPN connections can be established and disconnected via the button or on/off switch. The
VPN connection is specified here.
The display shows the VPN connections that have been set up
under IPsec VPN >> Connections >> Edit >> General.
For the input to be active, the service input must be selected
under Controlling service input in the IPsec VPN >> Connec-
tions >> Edit >> General menu.
OpenVPN connections controlled by this input
Switch, mGuard devices have connections to which external buttons or an on/off switch and actuators (e.g., a signal lamp) can be connected. One of the configured VPN connections can be established and disconnected via the button or on/off switch. The
VPN connection is specified here.
The display shows the VPN connections that have been set up
under OpenVPN Client >> Connections >> Edit >> General.
For the input to be active, the service input must be selected
under Controlling service input in the OpenVPN Client >>
Connections >> Edit >> General menu.
The display shows the firewall rule records that have been set
up under Network Security >> Packet Filter >> Rule Records.
Firewall rule records controlled by this input
Monitor VPN connections or Firewall rule record
Off/VPN connections/Rule Records
The state of the selected VPN connection or the selected firewall rule record is indicated via the associated signal contact
(ACK output).
102
Innominate Security Technologies I15020_en_03
4.7.2
Alarm output
Management menu
Management >> Service I/O >> Alarm output
General Operation mode
Operation supervision
Manual setting
When the state is switched manually to Open (Alarm) the
LED FAULT will not turn red (no alarm).
Displays the state of the alarm output.
Current state
Redundant power supply
If set to Ignore, the state of the power supply does not influence the alarm output.
If set to Supervise, the alarm output is opened if one of the two supply voltages fails.
Link supervision Ignore/Supervise
Monitoring of the link status of the Ethernet connections.
If set to Ignore, the link status of the Ethernet connections does not influence the alarm output.
If set to Supervise, the alarm output is opened if one link does not indicate connectivity. Set the links to be monitored under
“Link supervision” in the Network >> Ethernet >> MAU set-
Temperature condition
Operation supervision/Manual setting
The alarm output can be controlled automatically using Oper-
ation supervision (default) or Manual setting.
Closed/Open (Alarm)
The desired state of the alarm output (for function control) can be selected here:
The alarm output indicates overtemperature and undertem-
perature. The permissible range is set under “System Temper-
ature (°C)” in the Management >> System Settings >> Host
menu.
If set to Ignore, the temperature does not influence the signal contact.
If set to Supervise, the alarm output is opened if the temperature is not within the permissible range.
I15020_en_03 Innominate Security Technologies
103
Management >> Service I/O >> Alarm output [...]
Connection state of the internal modem
Only if an internal modem is available and switched on rs with internal analog modem or ISDN modem).
If set to Ignore, the connection status of the internal modem does not influence the alarm output.
If set to Supervise, the alarm output is opened if the internal modem does not have a connection.
Connectivity state of redundancy
If set to Ignore, the connectivity check does not influence the alarm output.
If set to Supervise, the alarm output is opened if the connectivity check fails. This is regardless of whether the mGuard is active or in standby mode.
104
Innominate Security Technologies I15020_en_03
Management menu
4.8
Management >> Restart
4.8.1
Restart
Restarts the mGuard. Has the same effect as a temporary interruption in the power supply, whereby the mGuard is switched off and on again.
A restart (reboot) is necessary in the event of an error. It may also be necessary after a software update.
I15020_en_03 Innominate Security Technologies
105
106
Innominate Security Technologies I15020_en_03
5 Blade Control menu
ity, always use the latest blade slide-in module as controller.
5.1
Blade Control >> Overview
Blade Control menu
Blade Control >> Overview
Overview Rack ID
Power supply P1/P2
Blade
Device
Status
WAN
LAN
Serial
Version
B
R
The ID of the rack where the mGuard is located. This value can be configured for all blade devices on the controller.
Status of power supply units P1 and P2.
– OK
– Absent
– Defect
– Fatal error
Number of the slot where the mGuard blade is installed.
Device name, e.g., “blade” or “blade XL”.
– Online - The device in the slot is operating correctly.
– Present - The device is present, but not yet ready, e.g., because it is just starting up.
– Absent - No device found in the slot.
Status of the WAN port.
Status of the LAN port.
Serial number of the mGuard.
Software version of the mGuard.
Backup: automatic configuration backup on the controller is activated/deactivated for this slot.
Restore: automatic configuration restoration after replacing the mGuard is activated/deactivated for this slot.
I15020_en_03 Innominate Security Technologies
107
5.2
Blade Control >> Blade 01 to 12
These pages display the status information for each installed mGuard device and enable the configuration of the relevant mGuard device to be backed up and restored.
5.2.1
Blade in slot #...
Blade Control >> Blade xx >> Blade in slot xx
Overview Device type
ID bus controller ID
Serial number
Flash ID
Software version
MAC addresses
Status
LAN status
WAN link status
Temperature
Device name, e.g., “blade” or “blade XL”.
ID of this slot on the control bus of the bladebase.
Serial number of the mGuard.
Flash ID of the flash memory of the mGuard.
Version of the software installed on the mGuard.
All MAC addresses used by the mGuard.
mGuard status.
Status of the LAN port.
Status of the WAN port.
N/A = Not available
108
Innominate Security Technologies I15020_en_03
Blade Control menu
5.2.2
Configuration
Blade Control >> Blade xx >> Configuration
Configuration
The status of the stored configuration is displayed for each blade:
Configuration backup
[Blade #__ -> Controller]
[No configuration file]
[Out of date]
– Automatic: the new configuration is stored automatically on the controller shortly after a configuration change on the mGuard.
– Manual: the configuration can be stored on the controller by clicking on Backup.
– Click on Restore to transfer the configuration stored on the controller to the mGuard.
[Up to date]
[File copy in progress]
[Blade change detected]
[---] No blade available
If the blade was reconfigured after a manual configuration backup, but the new configuration was not saved, the configuration stored on the controller is out of date. This is indicated on the Configu-
ration tab page by “Configuration [Obsolete]”.
This indicates that something has been overlooked: in this case, you must backup the configuration on the controller.
[Configuration upload to
Blade[%d] initiated/Configuration upload to Blade[%d] failed.]
[Configuration download from Blade[%d] initiated/Configuration download from Blade[%d] failed.]
Reconfiguration, if After replacing an mGuard in this slot, the configuration stored is on the controller is automatically transferred to the new device replaced in this slot.
[Configuration file from
Blade[%d] not found]
Delete configuration backup of Blade #__
Deletes the configuration stored on the controller for the device in this slot.
[New configuration file for
Blade[%d] saved.]
Upload configuration from client
Uploads and saves the configuration profile for this slot on the controller.
[Configuration file deletion of Blade[%d] failed.]
Download configuration to client
Downloads the configuration profile stored on the controller for this slot onto the configuration PC.
[Configuration file of
Blade[%d] deleted.]
I15020_en_03 Innominate Security Technologies
109
110
Innominate Security Technologies I15020_en_03
Network menu
6 Network menu
6.1
Network >> Interfaces
The mGuard has the following interfaces with external access:
Ethernet: internal: LAN external:
WAN
Serial interface
Yes No
Yes
LAN: 4
WAN: 1
DMZ: 1
LAN: 5
WAN: 1
No
Yes
Yes
Yes LAN: 4
WAN: 1
DMZ: 1
LAN: 4
WAN: no
DMZ: no
LAN: 1
WAN: 1
DMZ: 1
LAN: 1
WAN: 1
LAN: 4
Yes
Yes
Yes
Yes
WAN: 1
Yes Yes
Built-in modem
No
No
No
No
Yes
Yes
No
No
No
No
Serial console via
USB
1
No
Yes
No
No
No
No
No
No
No
No
Yes No No No
Yes Yes Yes No
(ISDN/analog)
1
The LAN port is connected to a stand-alone computer or the local network (internal). The
WAN port is used to connect to the external network. For devices with a serial interface, the connection to the external network can also or additionally be established via the serial interface using a modem. Alternatively, the serial interface can also be used as follows: for
PPP dial-in into the local network or for configuration purposes. For devices with a built-in modem (analog modem or ISDN terminal adapter), the modem can also be used to combine access options.
Innominate Security Technologies
111
I15020_en_03
The details for this must be configured on the General, Ethernet, Dial-out, Dial-in, and
Modem / Console tabs. For a more detailed explanation of the options for using the serial
Connecting the network interface
Connect the EAGLE mGuard to the PC via a standard Ethernet patch cable. This ensures correct connection even when auto MDIX and auto negotiation are switched off.
The mGuard platforms have DTE interfaces (only exception: the EAGLE mGuard has a
DCE network interface). Connect the mGuards to the DTE interface using an Ethernet crossover cable. Here auto MDIX is permanently switched on, so it does not matter if the auto negotiation parameter is disabled.
112
Innominate Security Technologies I15020_en_03
Network menu
6.1.1
General
Network >> Interfaces >> General
Network Status External IP address Display only: the addresses via which the mGuard can be accessed by devices from the external network. They form the interface to other parts of the LAN or to the Internet. If the transition to the Internet takes place here, the IP addresses are usually assigned by the Internet service provider (ISP). If an IP address is assigned dynamically to the mGuard, the currently valid IP address can be found here.
Active Defaultroute via Display only: the IP address that the mGuard uses to try to reach unknown networks is displayed here. This field can contain “(none)” if the mGuard is in Stealth mode.
Used DNS servers
In Stealth mode, the mGuard adopts the address of the locally connected computer as its external IP.
Display only: the names of the DNS servers used by the mGuard for name resolution are displayed here. This information can be useful, for example, if the mGuard is using the DNS servers assigned to it by the Internet service provider.
Internal modem Displays the status of the internal modem (mobile network
3G and the internal an-
I15020_en_03 Innominate Security Technologies
113
Network >> Interfaces >> General [...]
Network Mode Network Mode Stealth / Router
The mGuard must be set to the network mode that corresponds to its connection to the network.
Depending on which network mode the mGuard is set to, the page will change together with its configuration parameters.
“Stealth” network mode is not available for the wired WAN interface.
See:
EAGLE mGuard)” on page 115 and “Network Mode: Stealth”
Router Mode
Only used when “Router” is selected as the network mode.
static / DHCP / PPPoE / PPTP / Modem
1
/ Built-in Modem
/ Built-in mobile network modem
See:
“Router Mode: static” on page 117 and ““Router” network
“Router Mode: DHCP” on page 117 and ““Router” network
“Router Mode: PPPoE” on page 117 and ““Router” network
“Router Mode: PPTP” on page 117 and ““Router” network
“Router Mode: Modem” on page 118 and ““Router” network
1
114
Innominate Security Technologies I15020_en_03
I15020_en_03
Network menu
Stealth mode (Plug-n-Protect) is used to protect a stand-alone computer or a local network with the mGuard. Important: if the mGuard is in Stealth network mode, it is inserted into the existing network (see figure) without changing the existing network configuration of the connected devices.
Before:
After: mGuard
(A LAN can also be on the left.)
The mGuard analyzes the active network traffic and independently configures its network connection accordingly. It then operates transparently, i.e., without the computers having to be reconfigured.
As in the other modes, firewall and VPN security functions are available.
Externally supplied DHCP data is allowed through to the connected computer.
If the mGuard is to provide services such as VPN, DNS, NTP, etc., a firewall installed on the computer must be configured to allow ICMP echo requests (ping).
In Stealth mode, the mGuard uses internal IP address 1.1.1.1. This can be accessed from the computer if the default gateway configured on the computer is accessible.
In Stealth network mode, a secondary external interface can also be configured (see “Sec-
For the further configuration of Stealth network mode, see “Network Mode: Stealth” on
Innominate Security Technologies
115
WAN port
LAN port
Router (default setting mGuard rs4000/rs2000 3G, mGuard rs4000/rs2000 Switch, mGuard centerport, mGuard centerport², mGuard blade controller, mGuard delta)
If the mGuard is in Router mode, it acts as the gateway between various subnetworks and has both an external interface (WAN port) and an internal interface (LAN port) with at least one IP address.
The mGuard is connected to the Internet or other “external” parts of the LAN via its WAN port.
– mGuard smart²: the WAN port is the Ethernet socket.
The mGuard is connected to a local network or a stand-alone computer via its LAN port:
– mGuard smart²: the LAN port is the Ethernet connector.
– mGuard operating system that has the network card operating system (in this example,
– In Power-over-PCI mode, the LAN port is the LAN socket of the mGuard SD,
As in the other modes, firewall and VPN security functions are available.
If the mGuard is operated in Router mode, it must be set as the default gateway on the locally connected computers.
This means that the IP address of the mGuard LAN port must be specified as the default gateway address on these computers.
NAT should be activated if the mGuard is operated in Router mode and establishes the
Only then can the computers in the connected local network access the Internet via the mGuard. If NAT is not activated, it is possible that only VPN connections can be used.
In Router network mode, a secondary external interface can also be configured (see “Sec-
There are several Router modes, depending on the Internet connection:
– static
– DHCP
– PPPoE
– PPPT
– Modem
– Built-in Modem/Built-in mobile network modem
116
Innominate Security Technologies I15020_en_03
I15020_en_03
Network menu
Router Mode: static
The IP address is fixed.
Router Mode: DHCP
The IP address is requested by the mGuard and allocated by an external DHCP server.
Router Mode: PPPoE
PPPoE mode corresponds to Router mode with DHCP but with one difference: the PPPoE protocol, which is used by many DSL modems (for DSL Internet access), is used to connect to the external network (Internet, WAN). The external IP address, which the mGuard uses for access from remote partners, is specified by the provider.
If the mGuard is operated in PPPoE mode, the mGuard must be set as the default gateway on the locally connected computers.
This means that the IP address of the mGuard LAN port must be specified as the default gateway address on these computers.
If the mGuard is operated in PPPoE mode, NAT must be activated in order to access the
Internet.
If NAT is not activated, it is possible that only VPN connections can be used.
For the further configuration of PPPoE network mode, see ““Router” network mode, “PP-
Router Mode: PPTP
Similar to PPPoE mode. For example, in Austria the PPTP protocol is used instead of the
PPPoE protocol for DSL connections.
(PPTP is the protocol that was originally used by Microsoft for VPN connections.)
If the mGuard is operated in PPTP mode, the mGuard must be set as the default gateway on the locally connected computers.
This means that the IP address of the mGuard LAN port must be specified as the default gateway on these computers.
If the mGuard is operated in PPTP mode, NAT should be activated in order to access the
If NAT is not activated, it is possible that only VPN connections can be used.
For the further configuration of PPTP network mode, see ““Router” network mode, “PPTP”
Innominate Security Technologies
117
Router Mode: Modem
If Modem network mode is selected, the external Ethernet interface of the mGuard is deactivated and data traffic is transferred to and from the WAN via the externally accessible serial interface (serial port) of the mGuard.
An external modem, which establishes the connection to the telephone network, is connected to the serial port. The connection to the WAN or Internet is then established via the telephone network (by means of the external modem).
If the address of the mGuard is changed (e.g., by changing the network mode from
Stealth to Router), the device can only be accessed via the new address. If the configuration is changed via the LAN port, confirmation of the new address is displayed before the change is applied. If configuration changes are made via the WAN port, no confirmation is displayed.
If the mode is set to Router, PPPoE or PPTP and you then change the IP address of the
LAN port and/or the local subnet mask, make sure you specify the correct values. Otherwise, the mGuard may no longer be accessible under certain circumstances.
For the further configuration of Built-in mobile network modem / Built-in Modem / Modem
Router Mode: Built-in Modem er
If Built-in Modem network mode is selected, the external Ethernet interface of the mGuard is deactivated and data is transferred to and from the WAN via the built-in modem or builtin ISDN terminal adapter of the mGuard. This must be connected to the telephone network.
The connection to the Internet is then established via the telephone network.
After selecting Built-in Modem, the fields for specifying the modem connection parameters are displayed.
For the further configuration of Built-in Modem / Modem network mode (see ““Router” net-
Router Mode: Built-in mobile network modem
If Built-in mobile network modem is selected as the network mode, data traffic is routed via the built-in mobile network modem instead of the WAN port of the mGuard.
For the further configuration of Built-in Modem / Modem network mode (see ““Router” net-
118
Innominate Security Technologies I15020_en_03
When “Stealth” is selected as the network mode...
...and “static” is selected for Stealth configuration
I15020_en_03
Network Mode: Stealth
Network menu
Innominate Security Technologies
119
Network >> Interfaces >> General (“Stealth” network mode)
Network Mode
Only applies if “Stealth” is selected as the network mode.
Stealth configuration autodetect / static / multiple clients autodetect
The mGuard analyzes the network traffic and independently configures its network connection accordingly. It operates transparently.
static
If the mGuard cannot analyze the network traffic, e.g., because the locally connected computer only receives data and does not send it, then Stealth configuration must be set to static. In this case, further input fields are available for
Static Stealth Configuration at the bottom of the page.
multiple clients
(Default) As with autodetect, but it is possible to connect more than one computer to the LAN port (secure port) of the mGuard, meaning that multiple IP addresses can be used at the LAN port (secure port) of the mGuard.
Autodetect: ignore
NetBIOS over TCP traffic on TCP port 139
No / Yes
Only with autodetect stealth configuration: if a Windows computer has more than one network card installed, it may alternate between the different IP addresses for the sender address in the data packets it sends. This applies to network packets that the computer sends to TCP port 139 (NetBIOS).
As the mGuard determines the address of the computer from the sender address (and therefore the address via which the mGuard can be accessed), the mGuard would have to switch back and forth, and this would hinder operation considerably.
To avoid this, set this option to Yes if the mGuard has been connected to a computer that has these properties.
120
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> General (“Stealth” network mode) [...]
Stealth Management IP
Address
An additional IP address can be specified here for the administration of the mGuard.
If:
– The multiple clients option is selected under Stealth configuration
– The client does not answer ARP requests
– No client is available
Remote access via HTTPS, SNMP, and SSH is only possible using this address.
With static Stealth configuration, the Stealth Management IP Address can always be accessed, even if the network card of the client PC has not been activated.
If the routing settings are such that data traffic to the Stealth Management
IP Address would be routed via the secondary external interface, this longer administered locally.
To prevent this, the mGuard has a built-in mechanism that ensures that in such an event the Stealth Management IP Address can still be accessed by the locally connected computer (or network).
I15020_en_03 Innominate Security Technologies
121
Network >> Interfaces >> General (“Stealth” network mode) [...]
Management IP addresses
IP
IP address via which the mGuard can be accessed and administered. dress.
Change the management IP address first before specifying any additional addresses.
Netmask
The subnet mask of the IP address above.
Use VLAN: Yes / No
IP address and subnet mask of the VLAN port.
If the IP address should be within a VLAN, set this option to
Yes.
In Stealth mode, VLAN cannot be used when the redundancy function is activated at the same time.
VLAN ID
This option only applies if you set the “Stealth configuration” option to “multiple clients” .
– A VLAN ID between 1 and 4095.
–
An explanation can be found under “VLAN” on page
– If you want to delete entries from the list, please note that the first entry cannot be deleted.
In multi stealth mode, the external DHCP server of the mGuard cannot be used if a VLAN ID is assigned as the management IP.
Default gateway The default gateway of the network where the mGuard is located.
122
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> General (“Stealth” network mode) [...]
Static routes In Stealth modes “autodetect” and “static”, the mGuard adopts the default gateway of the computer connected to its LAN port. This does not apply if a management IP address is configured with the default gateway.
Alternative routes can be specified for data packets destined for the WAN that have been created by the mGuard. These include the packets from the following types of data traffic:
– Download of certificate revocation lists (CRLs)
– Download of a new configuration
– Communication with an NTP server (for time synchronization)
– Sending and receiving encrypted data packets from VPN connections
– Requests to DNS servers
– Syslog messages
– Download of firmware updates
– Download of configuration profiles from a central server (if configured)
– SNMP traps
If this option is used, make the relevant entries afterwards. If it is not used, the affected data packets are routed via the default gateway specified for the client.
Network
Gateway
Specify the network in CIDR format (see “CIDR (Classless
The gateway via which this network can be accessed.
The routes specified here are mandatory routes for data packets created by the mGuard. This setting has priority over other
Static Stealth Configuration Client's IP address The IP address of the computer connected to the LAN port.
Client's MAC address The physical address of the network card of the local computer to which the mGuard is connected.
• The MAC address can be determined as follows:
In DOS (Start, All Programs, Accessories, Command
Prompt), enter the following command: ipconfig /all
The MAC address does not necessarily have to be specified. The mGuard can automatically obtain the MAC address from the client. The MAC address 0:0:0:0:0:0 must be set in order to do this. Please note that the mGuard can only forward network packets to the client once the MAC address of the client has been determined.
If no Stealth Management IP Address or Client's MAC address is configured in static
Stealth mode, then DAD ARP requests are sent via the internal interface (see RFC 2131,
“Dynamic Host Configuration Protocol”, Section 4.4.1)
I15020_en_03 Innominate Security Technologies
123
Network >> Interfaces >> General (“Stealth” network mode) [...]
Secondary External Interface
This menu item is not included in the scope of functions for
Only in Router network mode with static/DHCP router mode or Stealth network mode.
rs4000 centerport, mGuard rs2000 Switch or
In these network modes, the serial interface of the mGuard can be configured as an additional Secondary External Interface.
router mode, the built-in mobile network modem of the mGuard can be configured as an additional secondary external interface.
The secondary external interface can be used to transfer data traffic permanently or tem-
porarily to the external network (WAN).
If the secondary external interface is activated, the following applies:
In Stealth network mode
Only the data traffic generated by the mGuard is subject to the routing specified for the secondary external interface, not the data traffic from a locally connected computer. Locally connected computers cannot be accessed remotely either; only the mGuard itself can be accessed remotely – if the configuration permits this.
As in Router network mode, VPN data traffic can flow to and from the locally connected computers. Because this traffic is encrypted by the mGuard, it is seen as being generated by the mGuard.
In Router network mode
All data traffic, i.e., from and to locally connected computers, generated by the mGuard, can be routed to the external network (WAN) via the secondary external interface.
124
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> General (“Stealth” network mode) [...]
Network Mode Off / Modem / Built-in mobile network modem
Off
(Default). Select this setting if the operating environment of the mGuard does not require a secondary external interface. You can then use the serial interface (or the built-in modem, if pres-
Operation Mode
Modem/Built-in Modem
If you select one of these options, the secondary external interface will be used to route data traffic permanently or tempo-
rarily to the external network (WAN).
The secondary external interface is created via the serial interface of the mGuard and an external modem connected to it.
Built-in mobile network modem
Firmware 5.2 or later supports an external or internal modem as a fallback for the external interface. From Version 8.0, this also includes the internal mobile network modem of the
The modem can be used permanently as the secondary external interface.
In the event of a network error, it can also be used temporarily as a secondary external interface.
It supports dedicated routes and DNS configuration.
permanent / temporary
After selecting Modem or Built-in Modem network mode for the secondary external interface, the operating mode of the secondary external interface must be specified.
permanent
Data packets whose destination corresponds to the routing settings specified for the secondary external interface are always routed via this external interface. The secondary external interface is always activated.
I15020_en_03 Innominate Security Technologies
125
Network >> Interfaces >> General (“Stealth” network mode) [...] temporary
Data packets whose destination corresponds to the routing settings specified for the secondary external interface are only routed via this external interface when additional, separately defined conditions are met. Only then is the secondary external interface activated and the routing settings for the second-
ary external interface take effect (see “Probes for activation”
Secondary External
Routes
Network
Specify the routing to the external network here. Multiple routes can be specified. Data packets intended for these networks are then routed to the corresponding network via the secondary external interface – in permanent or temporary mode.
Gateway
Specify the IP address (if known) of the gateway that is used for routing to the external network described above.
When you dial into the Internet using the phone number of the
Internet service provider, the address of the gateway is usually not known until you have dialed in. In this case, enter %gate-
way in the field as a placeholder.
126
Innominate Security Technologies I15020_en_03
I15020_en_03
Network menu
Operation Mode: permanent/temporary
In both permanent and temporary operating mode, the modem must be available to the mGuard for the secondary external interface so that the mGuard can establish a connection to the WAN (Internet) via the telephone network connected to the modem.
Which data packets are routed via the primary external interface (Ethernet interface) and which data packets are routed via the secondary external interface is determined by the routing settings that are applied for these two external interfaces. Therefore an interface can only take a data packet if the routing setting for that interface matches the destination of the data packet.
The following rules apply for routing entries:
If multiple routing entries for the destination of a data packet match, then the smallest network defined in the routing entries that matches the data packet destination determines which route this packet takes.
Example:
– The external route of the primary external interface is specified as 10.0.0.0/8, while the external route of the secondary external interface is specified as 10.1.7.0/24. Data packets to network 10.1.7.0/24 are then routed via the secondary external interface, although the routing entry for the primary external interface also matches them. Explanation: the routing entry for the secondary external interface refers to a smaller network
(10.1.7.0/24
– This rule does not apply in Stealth network mode with regard to the stealth manage-
– If the routing entries for the primary and secondary external interfaces are identical, tination address are routed via the secondary external interface.
– The routing settings for the secondary external interface only take effect when the secondary external interface is activated. Particular attention must be paid to this if the routing entries for the primary and secondary external interfaces overlap or are identical, whereby the priority of the secondary external interface has a filter effect, with the following result: data packets whose destination matches both the primary and secondary external interfaces are always routed via the secondary external interface, but only if this is activated.
– In temporary mode, “activated” signifies the following: the secondary external interface is only activated when specific conditions are met, and it is only then that the routing settings of the secondary external interface take effect.
– Network address 0.0.0.0/0 generally refers to the largest definable network, i.e., the Internet.
In Router network mode, the local network connected to the mGuard can be accessed via the secondary external interface as long as the specified firewall settings allow this.
Innominate Security Technologies
127
Network >> Interfaces >> General (continued); Secondary External Interface (continued)
Secondary External Interface (continued)
Probes for activation
Network Mode = Built-in mobile network modem
Operation Mode = temporary
128
Innominate Security Technologies
If the operating mode of the secondary external interface is set to temporary, the following is checked using periodic ping tests: can a specific destination or destinations be reached when data packets take the route based on all the routing settings specified for the mGuard – apart from those specified for the secondary external interface? Only if
none of the ping tests are successful does the mGuard assume that it is currently not possible to reach the destination(s) via the primary external interface (Ethernet interface or
WAN port of the mGuard). In this case, the secondary external interface is activated, which results in the data packets being routed via this interface (according to the routing setting for the secondary external interface).
The secondary external interface remains activated until the mGuard detects in subsequent ping tests that the destination(s) can be reached again. If this condition is met, the data packets are routed via the primary external interface again and the secondary external interface is deactivated.
Therefore, the purpose of the ongoing ping tests is to check whether specific destinations can be reached via the primary external interface. When they cannot be reached, the secondary external interface is activated until they can be reached again.
Type / Destination
Specify the ping Type of the ping request packet that the mGuard is to send to the device with the IP address specified under Destination.
Multiple ping tests can be configured for different destinations.
Success/failure:
A ping test is successful if the mGuard receives a positive reresponse is positive, the partner can be reached.
I15020_en_03
Network menu
Network >> Interfaces >> General (continued); Secondary External Interface (continued) [...]
Ping types:
– IKE Ping:
Determines whether a VPN gateway can be reached at the IP address specified.
– ICMP Ping:
Determines whether a device can be reached at the IP address specified.
This is the most common ping test. However, the response to this ping test is disabled on some devices. This means that they do not respond even though they can be reached.
– DNS Ping:
Determines whether an operational DNS server can be reached at the IP address specified.
A generic request is sent to the DNS server with the specified IP address, and every DNS server that can be reached responds to this request.
Probe Interval (seconds)
Please note the following when programming ping tests:
It is useful to program multiple ping tests. This is because it is possible that an individual tested service is currently undergoing maintenance. This type of scenario should not result in the secondary external interface being activated and an expensive dial-up connection being established via the telephone network.
Because the ping tests generate network traffic, the number of tests and their frequency should be kept within reasonable limits. You should also avoid activating the secondary external interface too early. The timeout time for the individual ping requests is 4 seconds. This means that after a ping test is started, the next ping test starts after 4 seconds if the previous one was unsuccessful.
To take these considerations into account, make the following settings.
The ping tests defined above under Probes for activation... are performed one after the other. When the ping tests defined are performed once in sequence, this is known as a test run.
Test runs are continuously repeated at intervals. The interval entered in this field specifies how long the mGuard waits after starting a test run before it starts the next test run. The test runs are not necessarily completed: as soon as one ping test in a test run is successful, the subsequent ping tests in this test run are omitted. If a test run takes longer than the interval specified, then the subsequent test run is started directly after it.
I15020_en_03 Innominate Security Technologies
129
Network >> Interfaces >> General (continued); Secondary External Interface (continued) [...]
Number of times all probes need to fail during subsequent runs before the secondary external interface is activated
Specifies how many sequentially performed test runs must return a negative result before the mGuard activates the secondary external interface. The result of a test run is negative if
none of the ping tests it contains were successful.
The number specified here also indicates how many consecutive test runs must be successful after the secondary external interface has been activated before this interface is deactivated again.
DNS Mode Only relevant if the secondary external interface is activated in
temporary mode:
The DNS mode selected here specifies which DNS server the mGuard uses for temporary connections established via the secondary external interface.
– Use primary DNS settings untouched
– DNS Root Servers
– Provider defined (via PPP dial-out)
– User defined (servers listed below)
Use primary DNS settings untouched
The DNS servers defined under Network --> DNS server (see
“Network >> NAT” on page 161) are used.
DNS Root Servers
Requests are sent to the root name servers on the Internet whose IP addresses are stored on the mGuard. These addresses rarely change.
User defined name servers
Provider defined (via PPP dial-out)
The domain name servers of the Internet service provider that provide access to the Internet are used.
User defined (servers listed below)
If this setting is selected, the mGuard will connect to the domain name servers listed under User defined name servers.
The IP addresses of domain name servers can be entered in this list. The mGuard uses this list for communication via the secondary external interface – as long as the interface is activated temporarily and User defined is specified under DNS
Mode (see above) in this case.
130
Innominate Security Technologies I15020_en_03
Network menu
Network Mode: Router
When “Router” is selected as the network mode and “static” is selected as the router
Network >> Interfaces >> General (“Router” network mode)
Internal Networks Internal IPs (trusted port)
The internal IP is the IP address via which the mGuard can be accessed by devices in the locally connected network.
The default settings in Router/PPPoE/PPTP/Modem mode are as follows:
– IP address: 192.168.1.1
– Netmask: 255.255.255.0
IP
You can also specify other addresses via which the mGuard can be accessed by devices in the locally connected network.
For example, this can be useful if the locally connected network is divided into subnetworks. Multiple devices in different subnetworks can then access the mGuard via different addresses.
IP address via which the mGuard can be accessed via its LAN port.
I15020_en_03 Innominate Security Technologies
131
Network >> Interfaces >> General (“Router” network mode) [...]
The subnet mask of the network connected to the LAN port.
Netmask
Use VLAN If the IP address should be within a VLAN, set this option to
Yes.
VLAN ID
OSPF Area
– A VLAN ID between 1 and 4095.
– For an explanation of the term “VLAN”, please refer to the
– If you want to delete entries from the list, please note that the first entry cannot be deleted.
(only active if OSPF is enabled in the “Dynamic Routing” menu)
– Links the static addresses/routes of the internal network
interface to an OSPF area (see “Network >> Dynamic
Additional Internal
Routes
Network
Gateway
An OSPF area cannot be assigned to the WAN interface in “DHCP” router mode.
Additional routes can be defined if further subnetworks are connected to the locally connected network.
Specify the network in CIDR format (see “CIDR (Classless
The gateway via which this network can be accessed.
DMZ Networks
Only available with the
DMZ IPs
IP
Netmask
IP address via which the mGuard can be accessed by devices in the network connected to the DMZ port.
The default settings in Router/PPPoE/PPTP/Modem mode are as follows:
– IP address: 192.168.3.1
– Netmask: 255.255.255.0
You can also specify other addresses via which the mGuard can be accessed by devices in the networks connected to the
DMZ port. For example, this can be useful if the network connected to the DMZ port is divided into subnetworks. Multiple devices in different subnetworks can then access the mGuard via different addresses.
IP address via which the mGuard can be accessed via its DMZ port.
Default: 192.168.3.1
The subnet mask of the network connected to the DMZ port.
Default: 255.255.255.0
132
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> General (“Router” network mode) [...]
OSPF Area (only active if OSPF is enabled in the “Dynamic Routing” menu)
– Links the static addresses/routes of the DMZ network in-
terface to an OSPF area (see “Network >> Dynamic Rout-
Additional DMZ
Routes
Network
Gateway
An OSPF area cannot be assigned to the WAN interface in “DHCP” router mode.
Additional routes can be defined if further subnetworks are connected to the DMZ.
Specify the network in CIDR format (see “CIDR (Classless
Default: 192.168.3.0/24
The gateway via which this network can be accessed.
Default: 192.168.3.254
Secondary External Interface
I15020_en_03 Innominate Security Technologies
133
“Router” network mode, “static” router mode
Network >> Interfaces >> General (“Router” network mode, “static” router mode)
External Networks External IPs
(untrusted port)
The addresses via which the mGuard can be accessed by devices on the WAN port side. If the transition to the Internet takes place here, the external IP address of the mGuard is assigned by the Internet service provider (ISP).
IP/Netmask
– IP address and subnet mask of the WAN port.
Use VLAN: Yes / No
– If the IP address should be within a VLAN, set this option to Yes.
VLAN ID
– A VLAN ID between 1 and 4095.
–
An explanation can be found under “VLAN” on page
– If you want to delete entries from the list, please note that the first entry cannot be deleted.
OSPF Area (only active if OSPF is enabled in the “Dynamic
Routing” menu)
– Links the static addresses/routes of the external network
interface to an OSPF area (see “Network >> Dynamic
An OSPF area cannot be assigned to the WAN interface in “DHCP” router mode.
134
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> General (“Router” network mode, “static” router mode) [...]
Additional External
Routes
In addition to the default route via the default gateway specified below, additional external routes can be specified.
Network/Gateway
Internal modem Displays the status of the internal modem (mobile network
3G and the internal an-
IP of default gateway The IP address of a device in the local network (connected to the LAN port) or the IP address of a device in the external network (connected to the WAN port) can be specified here.
If the mGuard establishes the transition to the Internet, this IP address is assigned by the Internet service provider (ISP).
If the mGuard is used within the LAN, the IP address of the default gateway is assigned by the network administrator.
If the local network is not known to the external
specify your local network under Network >> NAT
DMZ Networks
Internal Networks
Secondary External Interface
“Router” network mode, “DHCP” router mode
There are no additional setting options for “Router” network mode, “DHCP” router mode.
Network >> Interfaces >> General (“Router” network mode, “DHCP” router mode)
Internal Networks
Secondary External Interface
I15020_en_03 Innominate Security Technologies
135
“Router” network mode, “PPPoE” router mode
When “Router” is selected as the network mode and “PP-
PoE” is selected as the router mode
Network >> Interfaces >> General (“Router” network mode, “PPPoE” router mode)
PPPoE For access to the Internet, the Internet service provider (ISP) provides the user with a user ID (login) and password. These are requested when you attempt to establish a connection to the Internet.
PPPoE Login
PPPoE Password
The user ID (login) that is required by the Internet service provider (ISP) when you attempt to establish a connection to the
Internet.
The password that is required by the Internet service provider when you attempt to establish a connection to the Internet.
Request PPPoE Service Name?
When Yes is selected, the PPPoE client of the mGuard requests the service name specified below from the PPPoE server. Otherwise, the PPPoE service name is not used.
PPPoE Service Name PPPoE service name
Automatic Re-connect?
If Yes is selected, specify the time in the Re-connect daily at field. This feature is used to schedule Internet disconnection and reconnection (as required by many Internet service providers) so that they do not interrupt normal business operations.
When this function is enabled, it only takes effect if synchroni-
Re-connect daily at Specified time at which the Automatic Re-connect function
(see above) should be performed.
Internal Networks
Secondary External Interface
136
Innominate Security Technologies I15020_en_03
“Router” network mode, “PPTP” router mode
Network menu
When “Router” is selected as the network mode and “PPTP” is selected as the router mode
Network >> Interfaces >> General (“Router” network mode, “PPTP” router mode)
PPTP For access to the Internet, the Internet service provider (ISP) provides the user with a user ID (login) and password. These are requested when you attempt to establish a connection to the Internet.
PPTP Login
PPTP Password
The user ID (login) that is required by the Internet service provider when you attempt to establish a connection to the Internet.
The password that is required by the Internet service provider when you attempt to establish a connection to the Internet.
Local IP Mode Via DHCP:
If the address data for access to the PPTP server is provided by the Internet service provider via DHCP, select Via DHCP.
Local IP
Modem IP
In this case, no entry is required under Local IP.
Static (from field below):
If the address data for access to the PPTP server is not supplied by the Internet service provider via DHCP, the local IP address must be specified.
The IP address via which the mGuard can be accessed by the
PPTP server.
The address of the PPTP server of the Internet service provider.
Internal Networks
Secondary External Interface
This menu item is not included in the scope of functions for mGuard rs2000 Switch or
I15020_en_03 Innominate Security Technologies
137
“Router” network mode, “Modem” router mode
rs4000 rs4000,
Network >> Interfaces >> General (“Router” network mode, “Modem” router mode)
Modem/Built-in
Modem/Built-in mobile network modem
1
138
Innominate Security Technologies
Built-in Modem network mode is also available for the adapter (optional).
Built-in mobile network modem mode is also available for the
For all of the devices mentioned above, data traffic is routed via the serial interface and not via the mGuard WAN port when in Modem or Built-in (mobile network) Modem network mode and from there it continues as follows.
– A - data traffic is routed via the externally accessible serial interface (serial port) to which an external modem must be connected.
– B – data traffic is routed via the built-in (mobile network) modem/built-in ISDN terminal adapter, if available.
In both cases, the connection to the ISP and therefore the Internet is established via the telephone network using a modem or ISDN terminal adapter.
In Modem network mode, the serial interface of the mGuard is not available for the PPP
dial-in option or for configuration purposes (see page 148).
After selecting Modem
1
as the network mode, specify the required parameters for the
Enter the connection settings for an external modem on the Modem / Console tab
The configuration of the internal networks is described in the next section.
rs with built-in modem or ISDN terminal adapter, Built-in Modem is available as an option and in the case of the
I15020_en_03
6.1.2
Dial-out
Network menu
Network >> Interfaces >> Dial-out
PPP dial-out options
This menu item is not included in the scope of functions for mGuard rs2000 Switch or
These settings are only necessary when the mGuard is to establish a data link to the WAN (Internet) via one of these interfaces.
– Via the primary external interface (Modem or Built-in (mobile network)
Modem network mode)
– Via the secondary external interface (also available in Stealth or Router network mode)
Phone number to call Phone number of the Internet service provider. The connection to the Internet is established after establishing the telephone connection.
Command syntax: together with the previously set ATD modem command for dialing, the following dial sequence, for example, is created for the connected modem: ATD765432.
A compatible pulse dialing procedure that works in all scenarios is used as standard.
Special dial characters can be used in the dial sequence.
I15020_en_03 Innominate Security Technologies
139
Network >> Interfaces >> Dial-out [...]
HAYES special dial characters
– W: instructs the modem to insert a dialing pause at this point until the dial tone can be heard.
Used when the modem is connected to a private branch exchange. An outside line must be obtained first for out-
Authentication the phone number of the relevant subscriber can be dialed.
Example: ATD0W765432
– T: switch to tone dialing.
Insert the special dial character T before the phone number if the faster tone dialing procedure is to be used (with tone-compatible telephone connections). Example:
ATDT765432
PAP / CHAP / None
PAP = Password Authentication Protocol, CHAP = Challenge
Handshake Authentication Protocol. These terms describe procedures for the secure transmission of authentication data using the Point-to-Point Protocol.
If the Internet service provider requires the user to log in using a user name and password, then PAP or CHAP is used as the authentication method. The user name, password, and any other data that must be specified by the user to establish a connection to the Internet are given to the user by the Internet service provider.
The corresponding fields are displayed depending on whether
PAP, CHAP or None is selected. Enter the corresponding data in these fields.
If authentication is via PAP:
140
Innominate Security Technologies
User name
Password
PAP server authentication
User name specified during Internet service provider login to access the Internet.
Password specified during Internet service provider login to access the Internet.
Yes/No
The following two input fields are shown when Yes is selected:
I15020_en_03
Network menu
Network >> Interfaces >> Dial-out [...]
Server user name
Server password
Subsequent fields
User name and password that the mGuard requests from the server. The mGuard only allows the connection if the server returns the agreed user name/password combination.
See under “If “None” is selected as the authentication method”
If authentication is via CHAP:
I15020_en_03
Local name A name for the mGuard that it uses to log into the Internet service provider. The service provider may have several customers and it uses this name to identify who is attempting to dial in.
After the mGuard has logged into the Internet service provider with this name, the service provider also compares the password specified for client authentication (see below).
Remote name
The connection can only be established successfully if the name is known to the service provider and the password matches.
A name given to the mGuard by the Internet service provider for identification purposes. The mGuard will not establish a connection to the service provider if the ISP does not give the correct name.
Password that must be specified during Internet service provider login to access the Internet.
Secret for client authentication
CHAP server authentication
Yes/No
The following two input fields are shown when Yes is selected:
Secret for server authentication
Password that the mGuard requests from the server. The mGuard only allows the connection if the server returns the agreed password.
Subsequent fields
See under “If “None” is selected as the authentication method”
If “None” is selected as the authentication method
In this case, the fields that relate to the PAP or CHAP authentication methods are hidden.
Innominate Security Technologies
141
Network >> Interfaces >> Dial-out [...]
Only the fields that define further settings remain visible below.
Other common settings
Network >> Interfaces >> Dial-out
PPP dial-out options Dial on demand Yes / No
Whether Yes or No: the telephone connection is always established by the mGuard.
If set to Yes (default): this setting is useful for telephone connections where costs are calculated according to the connection time.
The mGuard only commands the modem to establish a telephone connection when network packets are actually to be transferred. It also instructs the modem to terminate the telephone connection as soon as no more network packets are to be transmitted for a specific time (see value in Idle timeout field). By doing this, however, the mGuard is not constantly available externally, i.e., for incoming data packets.
142
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> Dial-out [...]
The mGuard also often or sporadically establishes a connection via the modem, or keeps a connection longer, if the following conditions apply:
– Often: the mGuard is configured so that it synchronizes its system time (date and time) regularly with an external NTP server.
– Sporadically: the mGuard acts as a DNS server and must perform a DNS request for a client.
– After a restart: an active VPN connection is set to Started. If this is the case, the mGuard establishes a connection after every restart.
– After a restart: for an active VPN connection, the gateway of the partner is specified as the host name. After a restart, the mGuard must request the IP address that corresponds to the host name from a DNS server.
–
Often: VPN connections are set up and DPD messages are sent regularly (see “Dead
– Often: the mGuard is configured to send its external IP address regularly to a DNS service, e.g., DynDNS, so that it can still be accessed via its host name.
– Often: the IP addresses of partner VPN gateways must be requested from the
DynDNS service or they must be kept up to date by new queries.
– Sporadically: the mGuard is configured so that SNMP traps are sent to the remote server.
– Sporadically: the mGuard is configured to permit and accept remote access via
HTTPS, SSH or SNMP. (The mGuard then sends reply packets to every IP address from which an access attempt is made (if the firewall rules permit this access)).
– Often: the mGuard is configured to connect to an HTTPS server at regular intervals
in order to download any configuration profiles available there (see “Management >>
Idle timeout
When No is selected, the mGuard establishes a telephone connection using the connected modem as soon as possible after a restart or activation of Modem network mode. This remains permanently in place, regardless of whether or not data is transmitted. If the telephone connection is then interrupted, the mGuard attempts to restore it immediately. Thus a permanent connection is created, like a permanent line. By doing coming data packets.
Yes / No
Only considered when Dial on demand is set to Yes.
When set to Yes (default), the mGuard terminates the telephone connection as soon as no data traffic is transmitted over the time period specified under Idle time. The mGuard gives the connected modem the relevant command for terminating the telephone connection.
When set to No, the mGuard does not give the connected modem a command for terminating the telephone connection.
I15020_en_03 Innominate Security Technologies
143
Network >> Interfaces >> Dial-out [...]
Idle time (seconds)
Local IP
Remote IP
Netmask
Default: 300. If there is still no data traffic after the time specified here has elapsed, the mGuard can terminate the telephone connection (see above under Idle timeout).
IP address of the serial interface of the mGuard that now acts as the WAN interface. If this IP address is assigned dynamically by the Internet service provider, use the preset value:
0.0.0.0.
Otherwise, e.g., for the assignment of a fixed IP address, enter this here.
IP address of the partner. When connecting to the Internet, this is the IP address of the Internet service provider, which is used to provide access to the Internet. As the Point-to-Point
Protocol (PPP) is used for the connection, the IP address does not usually have to be specified. This means you can use the preset value: 0.0.0.0.
The subnet mask specified here belongs to both the Local IP address and the Remote IP address. Normally all three values
(Local IP, Remote IP, Netmask) are either fixed or remain set to 0.0.0.0.
Enter the connection settings for an external modem on the
144
Innominate Security Technologies I15020_en_03
6.1.3
Dial-in
Network menu
rs4000 rs4000,
Network >> Interfaces >> Dial-in
PPP dial-in options
This menu item is not included in the scope of functions for
rs4000 rs4000, mGuard rs2000 Switch or
Should only be configured if the mGuard is to permit PPP dial-in via one of the following:
– A modem connected to the serial interface
– A built-in modem (as option for the mGuard rs)
– A built-in mobile network modem (for the mGuard 3G)
PPP dial-in can be used to access the LAN (or the mGuard for configuration purposes)
If the modem is used for dialing out by acting as the primary external interface (Modem network mode) of the mGuard or as its secondary external interface (when activated in
Stealth or Router network mode), it is not available for the PPP dial-in option.
I15020_en_03 Innominate Security Technologies
145
Network >> Interfaces >> Dial-in [...]
Modem (PPP)
rs4000 industrial
Incoming Rules (PPP)
Modem (PPP)
Off / On
This option must be set to “Off” if no serial interface is to be used for the PPP dial-in option.
If this option is set to On, the PPP dial-in option is available.
The connection settings for the connected external modem should be made on the Modem / Console tab.
TA)
Off / Built-in Modem / External Modem
This option must be set to Off if no serial interface should be used for the PPP dial-in option.
If this option is set to External Modem, the PPP dial-in option is available. An external modem must then be connected to the serial interface. The connection settings for the connected external modem should be made on the Modem / Console tab.
If this option is set to Built-in Modem, the PPP dial-in option is available. In this case, the modem connection is not established via the serial socket on the front. Instead it is established via the terminal strip on the bottom where the built-in modem or built-in ISDN terminal adapter is connected to the telephone network. The connection settings for the built-in modem should be made on the Modem / Console tab.
If the Built-in Modem option is used, the serial interface can also be used. For the options for using the serial interface, see
Local IP
Remote IP
PPP Login name
IP address of the mGuard via which it can be accessed for a
PPP connection.
IP address of the partner of the PPP connection.
User ID that must be specified by the PPP partner in order to access the mGuard via a PPP connection.
PPP Password The password that must be specified by the PPP partner in order to access the mGuard via a PPP connection.
Firewall rules for PPP connections to the LAN interface.
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 contains further subsequent rules that could also apply, these rules are ignored.
The following options are available:
Protocol All means TCP, UDP, ICMP, GRE, and other IP protocols
146
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> Dial-in [...]
From IP / To IP
Outgoing Rules (PPP)
0.0.0.0/0 means all IP addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
From Port / To Port (only evaluated for TCP and UDP protocols)
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).
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.
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.
Freely selectable comment for this rule.
Comment
Log
Log entries for unknown connection attempts
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
Yes / No
When set to Yes, all connection attempts that are not covered by the rules defined above are logged.
Firewall rules for outgoing PPP connections from the LAN interface.
The parameters correspond to those under Incoming Rules (PPP).
These outgoing rules apply to data packets that are sent out via a data link initiated by PPP dial-in.
I15020_en_03 Innominate Security Technologies
147
6.1.4
Modem / Console
Some mGuard models have a serial interface that can be accessed externally, while the
rs is also available with a built-in modem as an option (see “Network >>
Options for using the serial interface
The serial interface can be used alternatively as follows:
Primary external interface
(This menu item is not included in the scope of functions for the
As a primary external interface, if the network mode is set to Modem under Network >>
Interfaces on the General tab (see “Network >> Interfaces” on page 111 and “General” on
In this case, data traffic is not processed via the WAN port (Ethernet interface), but via the serial interface.
Secondary external interface (This menu item is not included in the scope of functions for the
As a secondary external interface, if Secondary External Interface is activated and
In this case, data traffic is processed (permanently or temporarily) via the serial interface.
For dialing in to the LAN or for configuration purposes
(This menu item is not included in the scope of functions for the
– A modem is connected to the serial interface of the mGuard. This modem is connected to the telephone network (fixed-line or GSM network).
(The connection to the telephone network is established via the terminal strip on the adapter.)
148
Innominate Security Technologies I15020_en_03
Network menu
This enables a remote PC that is also connected to the telephone network via a modem or ISDN adapter to establish a PPP (Point-to Point Protocol) dial-up connection to the mGuard.
This method is referred to as a PPP dial-in option. It can be used for access to the LAN, which is located behind the mGuard or for configuration of the mGuard. Dial-in is the interface definition used for this connection type in firewall selection lists.
In order to access the LAN with a Windows computer using the dial-up connection, a network connection must be set up on this computer in which the dial-up connection to the mGuard is defined. In addition, the IP address of the mGuard (or its host name) must be defined as the gateway for this connection so that the connections to the LAN can be routed via this address.
To access the web configuration interface of the mGuard, you must enter the IP address of the mGuard (or its host name) in the address line of the web browser.
– The serial interface of the mGuard is connected to the serial interface of a PC.
On the PC, the connection to the mGuard is established using a terminal program and the configuration is implemented using the command line of the mGuard.
If an external modem is connected to the serial interface, you may have to enter corresponding settings below under External Modem, regardless of the use of the serial interface and the modem connected to it.
Network >> Interfaces >> Modem / Console
Serial Console
The following settings for the Baudrate and Hardware handshake are only valid for a configuration connection where a terminal or PC with terminal program is connected to the serial interface as described above.
The settings are not valid when an external modem is connected. Settings for this are made further down under External Modem.
Baudrate
Hardware handshake
RTS/CTS
The transmission speed of the serial interface is specified via the selection list.
Off / On
When set to On, flow is controlled by means of RTS and CTS signals.
Serial console via USB No / Yes
When No is selected, the mGuard smart² uses the USB connection solely as a power supply.
When Yes is selected, the mGuard smart² provides an additional serial interface for the connected computer through the
USB interface. The serial interface can be accessed on the vides a console through the serial interface, which can then be used in the terminal program.
Windows requires a special driver. This can be downloaded directly from the mGuard. The relevant link is located on the right-hand side next to the “Serial console via USB” dropdown menu.
I15020_en_03 Innominate Security Technologies
149
Network >> Interfaces >> Modem / Console [...]
External Modem
This menu item is not included in the scope of functions for
rs2000
, mGuard rs2000 Switch or
Hardware handshake
RTS/CTS
Baudrate
Off / On
When set to On, flow is controlled by means of RTS and CTS signals for PPP connections.
Default: 57600.
Transmission speed for communication between the mGuard and modem via the serial connecting cable between both devices.
This value should be set to the highest value supported by the modem. If the value is set lower than the maximum possible speed that the modem can reach on the telephone line, the telephone line will not be used to its full potential.
Yes / No Handle modem transparently (for dial-in only)
Modem init string means that the mGuard does not initialize the modem. The subsequently configured modem initialization sequence is not observed. Thus, either a modem is connected which can answer calls itself (default profile of the modem contains “auto answer”) or a null modem cable to a computer can be used instead of the modem, and the PPP protocol is used over this.
Specifies the initialization sequence that the mGuard sends to the connected modem.
Default: ''\d+++\dATH OK
Consult the modem user manual for the initialization sequence for this modem.
The initialization sequence is a sequence of character strings expected by the modem and commands that are then sent to the modem so that the modem can establish a connection.
150
Innominate Security Technologies I15020_en_03
Network menu
The preset initialization sequence has the following meaning:
’’ (two simple quotation marks placed directly after one another)
\d+++\dATH
OK
The empty character string inside the quotation marks means that the mGuard does not initially expect any information from the connected modem, but instead sends the following text directly to the modem.
The mGuard sends this character string to the modem in order to determine whether the modem is ready to accept commands.
Specifies that the mGuard expects the OK character string from the modem as a response to \d+++\dATH.
On many modem models it is possible to save modem default settings to the modem itself. However, this option should not be used.
Initialization sequences should be configured externally instead (i.e., on the mGuard). In the event of a modem fault, the modem can then be replaced quickly and smoothly without changing the modem default settings.
If the external modem is to be used for incoming calls without the modem default settings being entered accordingly, then you have to inform the modem that it should accept incoming calls after it rings.
(a space followed by “AT&S0=1”, followed by a space, followed by “OK”) to the initialization sequence.
Depending on their default settings, some external modems require a physical connection to the DTR cable of the serial interface in order to operate correctly.
Because the mGuard models do not provide this cable at the external serial interface, the lowed by “OK”) must be appended to the above initialization sequence. According to the extended HAYES command set, this sequence means that the modem does not use the
DTR cable.
If the external modem is to be used for outgoing calls, it is connected to a private branch exchange, and if this private branch exchange does not generate a dial tone after the connection is opened, then the modem must be instructed not to wait for a dial tone before dialing. lowed by a space, followed by “OK”) to the initialization sequence.
In order to wait for the dial tone, the control character “W” should be inserted in the Phone
number to call after the digit for dialing an outside line.
I15020_en_03 Innominate Security Technologies
151
COM server for mGuard platforms with serial interface
The mGuard platforms with a serial interface have an integrated COM server as of firmware
8.0. This enables serial interface data exchange via an IP connection.
Three options are available.
– RFC (Telnet server, complies with RFC 2217).
In this mode, the serial interface can be configured via client software in the network.
The Telnet server is available via the port which is defined under “Local port” .
– RAW client
The interface can be configured here (“Serial parameters” ). The settings of the serial
– RAW server
Behaves in the same way as the RAW client. However, the RAW server responds to
incoming connections via the port which is configured under “Local port” .
Additional settings for mGuard platforms with serial interface
Network >> Interfaces >> Modem / Console (mGuard platforms with serial interface)
COM Server Type Here you can select the way that the COM server should operate.
Remote IP
Possible options are: RFC 2217, RAW client, RAW server.
Defines the IP address of the partner.
Remote port
Available when the type is set to RAW client.
Default: 10.1.0.254.
Defines the port to which the RAW client sends the data.
Available when the type is set to RAW client.
Values: 1 - 65535.
Default: 3001.
152
Innominate Security Technologies I15020_en_03
Network menu
Network >> Interfaces >> Modem / Console (mGuard platforms with serial interface) [...]
Prefer VPN if applicable
Yes / No
Available when the type is set to RAW client.
Local port
Serial parameters
In order that the mGuard can connect to the COM server via the VPN tunnel, Yes must be selected. Otherwise, the packets will be sent to the default gateway of the mGuard.
Defines the port that the COM server should respond to.
Available when the type is set to RFC
Values: 1 - 65535.
Default: 3001
Defines the parity and stop bits for the serial interface.
COM Server Allowed Networks
Access rules can be defined for the COM server to prevent unauthorized access to it.
The default rule does not allow any access via the external interface.
From IP
– 1 stop bit, no parity (default)
– 1 stop bit, even parity
– 1 stop bit, odd parity
– 2 stop bits, no parity
– 2 stop bits, even parity
– 2 stop bits, odd parity
0.0.0.0/0 means all IP addresses.
To specify an address area, use CIDR format (see “CIDR
Interface
Action
Comment
Log
Interface for which the rule should apply.
Values: None, External, DMZ, VPN
Accept means that the data packets may pass through.
Reject means that the data packets are sent back. The sender is informed of their rejection.
Drop means that the data packets are not permitted to pass through. The sender is not informed of their whereabouts.
Freely selectable comment for this rule.
For each firewall rule you can specify whether the event is to be logged if the rule is applied.
I15020_en_03 Innominate Security Technologies
153
Primary External Interface – As a primary external interface, if the network mode is set to Built-in Modem under
and “General” on page 113). In this case, data traffic is not processed via the WAN port
(Ethernet interface), but via this modem.
Secondary External Interface
For the mGuard industrial rs with built-in modem/built-in ISDN modem (ISDN terminal adapter) rs is available with a built-in analog modem/built-in ISDN terminal adapter as an option. The built-in modem or built-in ISDN terminal adapter can be used as follows:
PPP dial-in options
– As a secondary external interface, if Secondary External Interface is activated and
Built-in Modem is selected under Network >> Interfaces on the General tab (see “Net-
113). In this case data traffic is
also processed via the serial interface.
–
For the PPP dial-in option (see “Options for using the serial interface” on page
Please note that the serial interface of the device also provides similar options for use (see rs with a built-in modem, normal data traffic can be routed via a modem connection (Modem network mode) and a second modem connec-
154
Innominate Security Technologies I15020_en_03
Network menu
For the mGuard industrial rs with built-in modem
Additionally for the with built-in modem (analog)
External Modem rs with built-in modem)
rs4000 industrial
Built-in Modem (analog) Country The country where the mGuard with built-in modem is operated must be specified here. This ensures that the built-in modem operates according to the applicable remote access guidelines in the respective country and that it recognizes and
Extension line
(regarding dial tone)
Yes / No
When set to No, the mGuard waits for the dial tone when the telephone network is accessed and the mGuard is calling the partner.
When set to Yes, the mGuard does not wait for a dial tone. Instead it begins dialing the partner immediately. This procedure may be necessary if the built-in modem of the mGuard is connected to a private branch exchange that does not emit a dial tone when it is “picked up”. When a specific number must be dialed to access an outside line, e.g., “0”, this number should be added to the start of the desired partner phone number that is to be dialed.
Speaker volume (builtin speaker)
Speaker control (builtin speaker)
These two settings specify which sounds should be emitted by the mGuard speaker and at what volume.
I15020_en_03 Innominate Security Technologies
155
For the mGuard industrial rs with built-in ISDN terminal adapter
Additionally for the with built-in modem
(ISDN)
External Modem rs with ISDN terminal adapter)
Built-in Modem (ISDN) 1st MSN
2nd MSN
ISDN protocol
Layer-2 protocol
For outgoing calls, the mGuard transmits the MSN (Multiple
Subscriber Number) entered here to the called partner. In addition, the mGuard can receive incoming calls via this MSN
(provided dial-in operation is enabled, see General tab).
Maximum of 25 alphanumeric characters; the following special characters can be used: *, #, : (colon)
If the mGuard should also receive incoming calls via another number for dial-in operation (if enabled), enter the second
MSN here.
The EuroISDN protocol (also known as NET3) is used in Germany and many other European countries.
Otherwise the ISDN protocol should be specified according to the country. If necessary, this must be requested from the relevant phone company.
The set of rules used by the ISDN terminal adapter of the local mGuard to communicate with its ISDN partner. This generally is the ISDN modem of the Internet service provider used to establish the connection to the Internet. It must be requested from the Internet service provider. PPP/ML-PPP is often used.
156
Innominate Security Technologies I15020_en_03
6.2
Network >> Ethernet
6.2.1
MAU settings
Network menu
Network >> Ethernet >> MAU settings
Port Mirroring
Only for devices with an internal switch
MAU Configuration
Port Mirroring
Receiver
The integrated switch controls port mirroring in order to monitor the network traffic. Here, you can decide which ports you want to monitor and the switch then sends copies of data packets from the monitored ports to a selected port.
The port mirroring function enables any packets to be forwarded to a specific recipient. You can select the receiver port or the mirroring of the incoming and outgoing packets from each switch port.
Configuration and status indication of the Ethernet connections:
Port Name of the Ethernet connection to which the row refers.
Media Type Media type of the Ethernet connection.
I15020_en_03 Innominate Security Technologies
157
Network >> Ethernet >> MAU settings [...]
Automatic Configuration
– Yes: tries to determine the required operating mode automatically.
– No: uses the operating mode specified in the “Manual
Configuration” column.
When connecting the EAGLE mGuard to a hub, please note the following: when Automatic Config-
uration is deactivated, the auto MDIX function is also deactivated. This means that the port of the
EAGLE mGuard must either be connected to the uplink port of the hub or connected to the hub using a cross-link cable.
Manual Configuration The desired operating mode when Automatic Configuration is set to No.
Current Mode
Port On
The current operating mode of the network connection.
Switches the Ethernet connection on or off.
The Port On function is not supported by the
The Port On function is supported with restrictions on: switched off
Link supervision cannot be switched off (however, this is possible in powerover-PCI mode)
Only visible when the “Link supervision” menu item under
Management >> Service I/O >> Alarm output is set to “Super-
vise”.
If link supervision is active, the alarm output is opened if one link does not indicate connectivity.
Port Mirroring
Address Resolution Table Port
Only for devices with an internal switch
MACs
The port mirroring function enables any packets to be forwarded to a specific recipient. You can select the receiver port or the mirroring of the incoming and outgoing packets from each switch port.
Name of the Ethernet connection to which the row refers.
Lists the MAC addresses of the connected Ethernet-capable devices
The switch can learn MAC addresses which belong to the ports of its connected Ethernet-capable devices. The contents of the list can be deleted by clicking on the button.
Port Statistics A statistic is displayed for each physically accessible port of the integrated Managed
Switch. The counter can be reset via the web interface or the following command:
Only for devices with an internal switch /Packages/mguard-api_0/mbin/action switch/reset-phy-counters
Port tx collisions
Name of the Ethernet connection to which the row refers.
Number of errors while sending the data
158
Innominate Security Technologies I15020_en_03
Network menu
Network >> Ethernet >> MAU settings [...] tx octets rx fcs errors rx good octets
6.2.2
Multicast
Data volume sent
Number of received frames with invalid checksum
Volume of the valid data received
Network >> Ethernet >> Multicast
Static Multicast Groups Multicast is a technology which enables data to be sent to a group of recipients, without the transmitter having to send it multiple times. The data replication takes place through the distributor within the network.
You can create a list of multicast addresses. The data is forwarded to the configured ports
General Multicast Configuration
Multicast Groups
IGMP Snooping
IGMP Snoop Aging
IGMP Query
The switch uses IGMP snooping to guarantee that multicast data is only forwarded via ports which are intended for this use.
Period, after which membership to the multicast group expires, in seconds.
IGMP is used to join and leave a multicast group. Here, the
IGMP version can be selected (V1 or V2, V3 is not supported)
IGMP Query Interval Interval in which IGMP queries are generated in seconds
Displays the multicast groups. The display contains all static entries and the dynamic entries which are discovered by IGMP snooping.
I15020_en_03 Innominate Security Technologies
159
6.2.3
Ethernet
Network >> Ethernet >> Ethernet
ARP Timeout ARP Timeout
MTU Settings
Service life of entries in the ARP table.
The entry can be in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes, and seconds [h:mm:ss].
MAC and IP addresses are assigned to each other in the ARP table.
MTU of the ... interface The maximum transfer unit (MTU) defines the maximum IP packet length that may be used for the relevant interface.
For a VLAN interface:
As VLAN packets contain 4 bytes more than those without VLAN, certain drivers may have problems processing these larger packets. Such problems can be solved by reducing the MTU to 1496.
160
Innominate Security Technologies I15020_en_03
Network menu
6.3
Network >> NAT
6.3.1
Masquerading
Network >> NAT >> Masquerading
Network Address Translation/IP Masquerading
Lists the rules established for NAT (Network Address Translation).
For outgoing data packets, the device can rewrite the specified sender IP addresses from its internal network to its own external address, a technique referred to as NAT (Network
Address Translation), see also NAT (Network Address Translation) in the glossary.
This method is used if the internal addresses cannot or should not be routed externally, e.g., because a private address area such as 192.168.x.x or the internal network structure should be hidden.
The method can also be used to hide external network structures from the internal de-
vices. To do so, set the Internal option under Outgoing on Interface. The Internal set-
ting allows for communication between two separate IP networks where the IP devices have not configured a (useful) default route or differentiated routing settings (e.g., PLCs
without the corresponding settings). The corresponding settings must be made under 1:1
This method is also referred to as IP masquerading.
Default setting: NAT is not active.
If the mGuard is operated in PPPoE/PPTP mode, NAT must be activated in order to access the Internet. If NAT is not activated, only VPN connections can be used.
If multiple static IP addresses are used for the WAN port, the first IP address in the list is always used for IP masquerading.
These rules do not apply in Stealth mode.
Outgoing on Interface External / External 2 / Any External
1
/ Internal
Specifies via which interface the data packets are sent so that the rule applies to them. Any External refers to the External and External 2 interfaces.
I15020_en_03 Innominate Security Technologies
161
Network >> NAT >> Masquerading [...]
Masquerading is defined, which applies for network data flows in Router mode. These data flows are initiated so that they lead to a destination device which can be accessed over the selected network interface on the mGuard.
To do this, the mGuard replaces the IP address of the initiator with a suitable IP address of the selected network interface in all associated data packets. The effect is the same as for the other values of the same variables. The IP address of the initiator is hidden from the destination of the data flow. In particular, the destination does not require any routes in order to respond in a data flow of this type (not even a default route
(default gateway)).
Set the firewall in order for the desired connections to be allowed. For incoming and outgoing rules, the source address must still correspond to the original sender if the firewall rules are used.
Please observe the outgoing rules when using the “External / External 2 / Any
Please observe the incoming rules when using the “Internal” setting (see “In-
1:1 NAT
From IP 0.0.0.0/0 means that all internal IP addresses are subject to the NAT procedure. To specify an address area, use CIDR for-
mat (see “CIDR (Classless Inter-Domain Routing)” on
Comment Can be filled with appropriate comments.
Lists the rules established for 1:1 NAT (Network Address Translation).
With 1:1 NAT, the sender IP addresses are exchanged so that each individual address is exchanged with another specific address, and is not exchanged with the same address for all data packets, as in IP masquerading. This enables the mGuard to mirror addresses from the real network to the virtual network.
Example: The mGuard is connected to network 192.168.0.0/24 via its LAN port and to network
10.0.0.0/24 via its WAN port. By using 1:1 NAT, the LAN computer with IP address
192.168.0.8 can be accessed via IP address 10.0.0.8 in the virtual network.
192.168.0.8
10.0.0.8
192.168.0.0/24 10.0.0.0/24
The mGuard claims the IP addresses entered for the “Virtual network” for the devices in its “Real network”. The mGuard returns ARP answers for all addresses from the specified
“Virtual network” on behalf of the devices in the “Real network”. Therefore, the IP addresses entered under “Real network” must not be used. They must not be assigned to other devices or used in any way, as an IP address conflict would otherwise occur in the virtual network. This even applies when no device exists in the “Real network” for one or more IP addresses from the specified “Virtual network”.
162
Innominate Security Technologies I15020_en_03
Network menu
Network >> NAT >> Masquerading [...]
Default setting: 1:1 NAT is not active.
1:1 NAT cannot be applied to the External 2 interface.
1:1 NAT is only used in Router network mode.
Real network
Virtual network
Netmask
The address of the network on the LAN port.
The address of the network on the WAN port.
The subnet mask as a value between 1 and 32 for the local
and external network address (see also “CIDR (Classless
Enable ARP
Comment
Yes / No (default: Yes)
When set to Yes, ARP requests sent to the virtual network are answered on behalf of the mGuard. This means that hosts located in the real network can be accessed via their virtual address.
When set to No, ARP requests sent to the virtual network remain unanswered. This means that hosts in the real network cannot be accessed.
Can be filled with appropriate comments.
1
I15020_en_03 Innominate Security Technologies
163
6.3.2
IP and Port Forwarding
Network >> NAT >> IP and Port Forwarding
IP and Port Forwarding Lists the rules defined for port forwarding (DNAT = Destination NAT).
Port forwarding performs the following: the headers of incoming data packets from the external network, which are addressed to the external IP address (or one of the external IP addresses) of the mGuard and to a specific port of the mGuard, are rewritten in order to forward them to a specific computer in the internal network and to a specific port on this computer. In other words, the IP address and port number in the header of incoming data packets are changed.
This method is also referred to as Destination NAT.
Port forwarding cannot be used for connections initiated via the External 2
1 interface.
1
External 2 is only for devices with a serial interface.
The rules defined here have priority over the settings made under Network
Security >> Packet Filter >> Incoming Rules.
Protocol: TCP / UDP /
GRE
From IP
Specify the protocol to which the rule should apply.
GRE
GRE protocol IP packets can be forwarded. However, only one GRE connection is supported at any given time. If more than one device sends GRE packets to the same external IP address, the mGuard may not be able to feed back reply packets correctly. We recommend only forwarding GRE packets from specific transmitters. These could be ones that have had a forwarding rule set up for their source address by entering the transmitter address in the “From IP” field, e.g.,
193.194.195.196/32.
The sender address for forwarding.
0.0.0.0/0 means all addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
164
Innominate Security Technologies I15020_en_03
Network menu
Network >> NAT >> IP and Port Forwarding [...]
From Port
Incoming on IP
Incoming on Port
Redirect to IP
Redirect to Port
Comment
Log
The sender port for forwarding.
any refers to any port.
Either the port number or the corresponding service name can be specified here, e.g., pop3 for port 110 or http for port 80.
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
– Specify the external IP address (or one of the external IP addresses) of the mGuard here, or
– Use the variable %extern (if the external IP address of the mGuard is changed dynamically so that the external IP address cannot be specified).
If multiple static IP addresses are used for the WAN port, the %extern variable always refers to the first IP address in the list.
The original destination port specified in the incoming data packets.
Either the port number or the corresponding service name can be specified here, e.g., pop3 for port 110 or http for port 80.
This information is not relevant for the “GRE” protocol. It is ignored by the mGuard.
The internal IP address to which the data packets should be forwarded and into which the original destination addresses are translated.
The port to which the data packets should be forwarded and into which the original port data is translated.
Either the port number or the corresponding service name can be specified here, e.g., pop3 for port 110 or http for port 80.
This information is not relevant for the “GRE” protocol. It is ignored by the mGuard.
Freely selectable comment for this rule.
For each individual port forwarding rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
I15020_en_03 Innominate Security Technologies
165
6.4
Network >> DNS
6.4.1
DNS server
Network >> DNS >> DNS server
DNS If the mGuard is to initiate a connection to a partner on its own (e.g., to a VPN gateway or mGuard must determine which IP address belongs to the host name. To do this, it connects to a domain name server (DNS) to query the corresponding IP address there. The
IP address determined for the host name is stored in the cache so that it can be found directly (i.e., more quickly) for other host name resolutions.
With the Local Resolving of Hostnames function, the mGuard can also be configured to respond to DNS requests for locally used host names itself by accessing an internal, previously configured directory.
The locally connected clients can be configured (manually or via DHCP) so that the local address of the mGuard is used as the address of the DNS server to be used. If the mGuard is operated in Stealth mode, the management IP address of the mGuard (if this is configured) must be used for the clients, or the IP address 1.1.1.1 must be entered as the local address of the mGuard.
DNS cache state
Used DNS servers
Servers to query
Status of the host name resolution
DNS servers for which the associated IP address was queried.
– DNS Root Servers
Requests are sent to the root name servers on the Internet whose IP addresses are stored on the mGuard. These addresses rarely change.
– Provider defined (e.g., via PPPoE or DHCP)
The domain name servers of the Internet service provider that provide access to the Internet are used. Only select this setting if the mGuard operates in PPPoE, PPTP,
Modem mode or in Router mode with DHCP.
– User defined (servers listed below)
If this setting is selected, the mGuard will connect to the domain name servers listed under User defined name
servers.
166
Innominate Security Technologies I15020_en_03
Network menu
Network >> DNS >> DNS server [...]
Local Resolving of Hostnames
User defined name servers
The IP addresses of domain name servers can be entered in this list. If these should be used by the mGuard, select the
“User defined (servers listed below)” option under Servers to
query.
You can configure multiple entries with assignment pairs of host names and IP addresses for various domain names.
You have the option to define, change (edit), and delete assignment pairs of host names and IP addresses. You can also activate or deactivate the resolution of host names for a domain. In addition, you can delete a domain with all its assignment pairs.
Creating a table with assignment pairs for a domain:
• Open a new row and click on the Edit button in this row.
Changing or deleting assignment pairs belonging to a domain:
• Click on Edit in the relevant table row.
After clicking on Edit, the DNS Records tab is displayed:
I15020_en_03
Domain for the hosts The name can be freely assigned, but it must adhere to the rules for assigning domain names. It is assigned to every host name.
Enabled Yes / No
Switches the Local Resolving of Hostnames function on (Yes) or off (No) for the domain specified in the field above.
Resolve IP-Addresses also assigned IP address for host names.
Hostnames
Yes: same as for “No”. It is also possible to determine the host names assigned to an IP address.
The table can have any number of entries.
A host name may be assigned to multiple IP addresses. Multiple host names may be assigned to one IP address.
TTL
IP
Abbreviation for Time To Live. Value specified in seconds.
Default: 3600 (=
Specifies how long called assignment pairs may be stored in the cache of the calling computer.
The IP address assigned to the host name in this table row.
Innominate Security Technologies
167
Example: Local Resolving of Hostnames
The “Local Resolving of Hostnames” function is used in the following scenario,
A plant operates a number of identically structured machines, each one as a cell. The local networks of cells A, B, and C are each connected to the plant network via the Internet using the mGuard. Each cell contains multiple control elements, which can be addressed via their
IP addresses. Different address areas are used for each cell.
A service technician should be able to use her/his notebook on site to connect to the local network for machine A, B or C and to communicate with the individual controllers. So that the technician does not have to know and enter the IP address for every single controller in machine A, B or C, host names are assigned to the IP addresses of the controllers in accordance with a standardized diagram that the service technician uses. The host names used for machines A, B, and C are identical, i.e., the controller for the packing machine in all three machines has the host name “pack”, for example. However, each machine is assigned an
The service technician can connect her/his notebook to the local network at machine A, B or
C and use the same host names in each of these networks to communicate with the corresponding machine controllers.
The notebook can obtain the IP address to be used, the name server, and the domain from the mGuard via DHCP.
Notebook of service technician
IP addresses and host names with domain
Plant network
(Ethernet)
Figure 6-1
Machine A Controller A
Controller B
Controller C
10.1.30.1/24 fold.cell-a.example.com
10.1.30.2/24 fill.cell-a.example.com
10.1.30.3/24 pack.cell-a.example.com
Switch
10.1.30.0/24
Machine B
Controller A
Controller B
Controller C
10.1.31.1/24 fold.cell-b.example.com
10.1.31.2/24 fill.cell-b.example.com
10.1.31.3/24 pack.cell-b.example.com
Switch
10.1.31.0/24
Machine C
Controller A
Controller B
Controller C
Switch
10.1.32.0/24
Local Resolving of Hostnames
Host
10.1.32.1/24 fold.cell-c.example.com
10.1.32.2/24 fill.cell-c.example.com
10.1.32.3/24 pack.cell-c.example.com
Domain name
168
Innominate Security Technologies I15020_en_03
Network menu
6.4.2
DynDNS
Network >> DNS >> DynDNS
DynDNS In order for a VPN connection to be established, at least one partner IP address must be known so that the partners can contact each other. This condition is not met if both participants are assigned IP addresses dynamically by their respective Internet service providers. In this case, a DynDNS service such as DynDNS.org or DNS4BIZ.com can be of assistance. With a DynDNS service, the currently valid IP address is registered under a fixed name.
If you have registered with one of the DynDNS services supported by the mGuard, you can enter the corresponding information in this dialog box.
3G, be aware that DynDNS is not permitted by all mobile network providers.
Register this mGuard at a DynDNS Service?
Select Yes if you have registered with a DynDNS provider and if the mGuard is to use this service. The mGuard then reports its current IP address to the DynDNS service (i.e., the one assigned for its Internet connection by the Internet service provider).
Refresh Interval (sec) Default: 420 (seconds). The mGuard informs the DynDNS service of its new IP address whenever the IP address of its Internet connection is changed. In addition, the device can also report its IP address at the interval specified here. This setting has no effect for some DynDNS providers, such as
DynDNS.org, as too many updates can cause the account to be closed.
DynDNS Provider The providers in this list support the same protocol as the mGuard. Select the name of the provider with whom you are registered, e.g., DynDNS.org, TinyDynDNS, DNS4BIZ.
If your provider is not in the list, select DynDNS-compatible and enter the server and port for this provider.
DynDNS Server
Only visible when DynDNS Provider is set to DynDNS-com-
patible.
Name of the server for the DynDNS provider.
I15020_en_03 Innominate Security Technologies
169
Network >> DNS >> DynDNS [...]
DynDNS Port
DynDNS
Login
DynDNS Password
DynDNS Hostname
Only visible when DynDNS Provider is set to DynDNS-com-
patible.
Name of the port for the DynDNS provider.
Enter the user ID assigned by the DynDNS provider here.
Enter the password assigned by the DynDNS provider here.
The host name selected for this mGuard at the DynDNS service, providing you use a DynDNS service and have entered the corresponding data above.
The mGuard can then be accessed via this host name.
170
Innominate Security Technologies I15020_en_03
Under Windows XP
Network menu
6.5
Network >> DHCP
The Dynamic Host Configuration Protocol (DHCP) can be used to automatically assign the network configuration set here to the computer connected directly to the mGuard. You can specify the DHCP settings for the internal interface (LAN port) under Internal DHCP and the
DHCP settings for the external interface (WAN port) under External DHCP. The “External
The DHCP server also operates in Stealth mode.
In multi stealth mode, the external DHCP server of the mGuard cannot be used if a VLAN
ID is assigned as the management IP.
IP configuration for Windows computers: when you start the DHCP server of the mGuard, you can configure the locally connected computers so that they obtain their IP addresses automatically.
• In the Start menu, select “Control Panel, Network Connections”.
• Right-click on the LAN adapter icon and select “Properties” from the context menu.
• On the “General” tab, select “Internet Protocol (TCP/IP)” under “This connection uses the following items”, then click on the “Properties” button.
• Make the appropriate entries and settings in the “Internet Protocol Properties (TCP/IP)” dialog box.
6.5.1
Internal/External DHCP
Network >> DHCP >> Internal DHCP
Mode DHCP mode
I15020_en_03
Disabled / Server / Relay
Set this option to Server if the mGuard is to operate as an independent DHCP server. The corresponding setting options
are then displayed below on the tab (see “Server” ).
Set this option to Relay if the mGuard is to forward DHCP requests to another DHCP server. The corresponding setting
options are then displayed below on the tab (see “Relay” ).
In mGuard Stealth mode, Relay DHCP mode is not supported. If the mGuard is in Stealth mode and Relay DHCP mode is selected, this setting will be ignored.
However, DHCP requests from the computer and the corresponding responses are forwarded due to the nature of Stealth mode.
If this option is set to Disabled, the mGuard does not answer any DHCP requests.
Innominate Security Technologies
171
Network >> DHCP >> Internal DHCP [...]
DHCP mode Server
If DHCP mode is set to Server, the corresponding setting options are displayed below as follows.
DHCP Server Options
172
Innominate Security Technologies
Enable dynamic IP address pool
DHCP lease time
DHCP range start
DHCP range end
Local netmask
Set this option to Yes if you want to use the IP address pool specified under DHCP range start and DHCP range end (see below).
Set this option to “No” if only static assignments should be made using the MAC addresses (see below).
With enabled dynamic IP address pool:
When the DHCP server and the dynamic IP address pool have been activated, you can specify the network parameters to be used by the computer:
DHCP range start/end
The start and end of the address area from which the DHCP server of the mGuard should assign IP addresses to locally connected computers.
Time in seconds for which the network configuration assigned to the computer is valid. The client should renew its assigned configuration shortly before this time expires. Otherwise it may be assigned to other computers.
With enabled dynamic IP address pool
The start of the address area from which the DHCP server of the mGuard should assign IP addresses to locally connected computers.
With enabled dynamic IP address pool
The end of the address area from which the DHCP server of the mGuard should assign IP addresses to locally connected computers.
Specifies the subnet mask of the computers. Default:
255.255.255.0
I15020_en_03
Network menu
Network >> DHCP >> Internal DHCP [...]
Broadcast address
Default gateway
DNS server
WINS server
Static Mapping
[according to MAC address]
Specifies the broadcast address of the computers.
Specifies which IP address should be used by the computer as the default gateway. Usually this is the internal IP address of the mGuard.
Address of the server used by the computer to resolve host names in IP addresses via the Domain Name Service (DNS).
If the DNS service of the mGuard is to be used, enter the internal IP address of the mGuard here.
Address of the server used by the computer to resolve host names in addresses via the Windows Internet Naming Service
(WINS).
To find out the MAC address of your computer, proceed as follows:
Windows 95/98/ME:
• Start winipcfg in a DOS box.
Windows NT/2000/XP:
• Start ipconfig /all in a command prompt. The MAC address is displayed as the “Physical Address”.
Linux:
• Call /sbin/ifconfig or ip link show in a shell.
The following options are available:
– Client/computer MAC address (without spaces or hyphens)
– Client's IP address
Client IP Address
The static IP address of the computer to be assigned to the
MAC address.
Static assignments take priority over the dynamic
IP address pool.
Static assignments must not overlap with the dynamic IP address pool.
Do not use one IP address in multiple static assignments, otherwise this IP address will be assigned to multiple MAC addresses.
Current Leases
Only one DHCP server should be used per subnetwork.
The current IP addresses (leases) for the internal and external
DHCP servers assigned by the DHCP server are displayed with MAC address, IP address, and expiration (timeout).
I15020_en_03 Innominate Security Technologies
173
Network >> DHCP >> Internal DHCP [...]
DHCP mode Relay
If DHCP mode is set to Relay, the corresponding setting options are displayed below as follows.
DHCP Relay Options
In mGuard Stealth mode, Relay DHCP mode is not supported. If the mGuard is in Stealth mode and Relay DHCP mode is selected, this setting will be ignored. However, DHCP requests from the computer and the corresponding responses are forwarded due to the nature of Stealth mode.
DHCP Servers to relay to
A list of one or more DHCP servers to which DHCP requests should be forwarded.
Append Relay Agent
Information (Option
82)
When forwarding, additional information for the DHCP servers to which information is being forwarded can be appended according to RFC 3046.
174
Innominate Security Technologies I15020_en_03
6.6
Network >> Proxy Settings
6.6.1
HTTP(S) Proxy Settings
Network menu
A proxy server can be specified here for the following activities performed by the mGuard itself:
– CRL download
– Firmware update
– Regular configuration profile retrieval from a central location
– Restoring of licenses
Network >> Proxy Settings >> HTTP(S) Proxy Settings
HTTP(S) Proxy Settings Use Proxy for HTTP and HTTPS
When set to Yes, connections that use the HTTP or HTTPS protocol are transmitted via a proxy server whose address and port should also be specified.
Secondary External
Interface Uses Proxy
Default: No
This option should only be set to Yes if the connection (HTTP or HTTPS) of the secondary external interface is also to be es-
tablished via a proxy server (see “Secondary External Inter-
Proxy Authentication
HTTP(S) Proxy Server Host name or IP address of the proxy server
Port
Login
Password
User name for proxy server login
Password for proxy server login
I15020_en_03 Innominate Security Technologies
175
6.7
Network >> Mobile Network
The following mobile network standards are supported.
– 3G/UMTS
– HSDPA+
– CDMA EV-DO
– EDGE
– GPRS
In addition, the GPS and GLONASS positioning systems are supported for positioning and time synchronization. Note that the time synchronization and position data from the positioning systems can be manipulated by interference signals (GPS spoofing).
Establishing a mobile network connection
To establish a mobile network connection, a matching antenna must be connected to the device (see device user documentation).
The mGuard also requires at least one valid mini SIM card in ID-000 format, via which it assigns and authenticates itself to a mobile network.
3G can be equipped with two SIM cards. The SIM card in slot
SIM 1 is the primary SIM card which is normally used to establish the connection. If this connection fails, the device can turn to the second SIM card in slot SIM 2. You can set whether, and under which conditions, the connection to the primary SIM card is restored.
The state of the SIM cards is indicated via two LEDs on the front of the
3G. The SIM1 and SIM2 LEDs light up green when the SIM card is active. If a PIN has not been entered, the LED flashes green.
Quality of the mobile network connection
The signal strength of the mobile network connection is indicated by three LEDs on the front
3G. The LEDs function as a bar graph.
Table 6-1
LED 1
Lower LED
Off
Off
Off
Green
LED indication of signal strength
LED 2
Middle LED
Off
Off
Green
Green
LED 3
Upper LED
Off
Yellow
Yellow
Yellow
Signal strength
...
111 dBm Extremely poor to no network reception
...
...
...
89 dBm
67 dBm
51 dBm
Adequate network reception
Good network reception
Very good network reception
For stable data transmission, we recommend at least good network reception. If the network reception is only adequate, only text messages can be sent and received.
as a WAN interface is not available. The mobile network function is preset. The
The status of the mobile network connection can be queried via SNMP. SNMP traps are sent in the following cases:
176
Innominate Security Technologies I15020_en_03
Network menu
– Incoming text message
– Incoming call
– Mobile network connection error
You can switch SNMP support on and off under “Management >> SNMP” .
You can increase the amount of detail shown per entry in the log file of the mobile network connection. To do so, you need to set the “GSM_DEBUG” variable to “yes” via the console or SNMP.
6.7.1
General
I15020_en_03 Innominate Security Technologies
177
Network >> Mobile Network >> General
Mobile Network State Power state of the mobile network / Positioning engine
Indicates the state of the mobile network engine.
Engine is powered down
Mobile network and positioning disabled: mobile network and GPS switched off
Engine is powered up
Only positioning possible: mobile network disabled, GPS enabled
Mobile network connection for sending/receiving text
messages and calls, without packet data transmission:
SIM card inserted, PIN entered correctly
Mobile network connection for sending/receiving text messages and calls, with packet data transmission:
– SIM card inserted
– PIN entered correctly
– Router mode or secondary router mode set to “Built-in mobile network modem”
– APN entered correctly
– PPP authentication stored correctly
Signallevel
The optimum received power is 100% signal strength and -
Provider
Local Area Code and
Cell-ID of the base station
LAC: area code, location in the mobile network
CID: unique mobile phone cell ID
PLMN: provider (Public Land Mobile Network)
System ID and Network ID of the CDMA cell (only Verzion)
(Only for “Verizon CDMA (US)” provider selection)
SID: System Identification Number
NID: Network Identification Number
PLMN: provider (Public Land Mobile Network)
Radio Access Technology
PPP connection
Current Provider
GSM/EDGE/UTRAN/HSUPA/HSDPA/CDMA
Shows the current mobile network standard.
Shows the current status of packet transmission.
Name of the mobile network provider
178
Innominate Security Technologies I15020_en_03
Network menu
Network >> Mobile Network >> General [...]
Provider selection
Radio Settings
No mobile networking: mobile network connection disabled
Generic GSM/UMTS Provider: mobile network connection via the SIM card provider
Verizon CDMA (US): in the USA, mobile network connection without SIM card, via MEID code which is printed on the
CDMA Mobile Directory Number MDN
Verizon OTASP
AT&T 3G (US): in the USA, mobile network connection via
AT&T
(Only for “Verizon CDMA (US)” provider selection)
Phone number (Mobile Directory Number – MDN) assigned to the mGuard by Verizon. Valid for the North American Numbering Plan (NANP).
The number is only displayed once successfully registered with Verizon (Verizon OTASP) (see below).
(Only for “Verizon CDMA (US)” provider selection)
In order that the mGuard can be operated in the Verizon mobile network, the necessary configurations must be requested and downloaded from Verizon once.
This is only possible if a mobile network connection has already been established to the Verizon network (CDMA).
The configuration is downloaded by clicking on the “Verizon registration” button (OTASP method).
Following successful registration, the MDN is displayed under
“CDMA Mobile Directory Number MDN”.
GSM Frequencies Default: World (all frequencies)
– GSM off
– Europe/Asia (900/1800 MHz)
– North America (850/1900 MHz)
– Europe/Asia (900 MHz)
– Europe/Asia (1800 MHz)
– North America (850 MHz)
– North America (1900 MHz)
3G/UMTS Frequencies Default: World (all frequencies)
– UMTS off
– World (850/1900/2100 MHz)
– North America (850/1900 MHz)
– Europe/Asia (2100 MHz)
– Other countries (850/2100 MHz)
– North America (850 MHz)
– North America (1900 MHz)
– World (800 MHz)
– World (900 MHz)
I15020_en_03 Innominate Security Technologies
179
Network >> Mobile Network >> General [...]
CDMA Frequencies
Connection Supervision
Mobile Network Supervision
Daily relogin
Daily relogin at
Default: CDMA 800/1900 MHz
– CDMA off
– CDMA 800 MHz
– CDMA 1900 MHz
– CDMA 800/1900 MHz
The connection to the mobile network provider is renewed daily at a specified time. Otherwise, the mobile network operator regularly resets the connection from their side.
Default: No
Time at which the connection is renewed. “Yes” must be se-
lected under “Daily relogin” for this to take effect.
For this to work correctly, the time must be successfully synchronized (realtime clock, NTP server, GPS/GLONASS)
Default: 0 h : 0 m
Values: 0 - 23 hours and 0 - 59 minutes
You can use the following probe targets to check whether data can actually be transmitted with an active mobile network connection with packet data transmission.
To do so, probe targets (hosts) are pinged at specific intervals to see whether at least one of the targets can be reached. If the defined targets cannot be reached after specified intervals, the mobile network connection is reestablished.
If SIM cards are available, the supervision runs as follows.
– If a probe target was reached, the connection to the provider of the SIM 1 card is maintained.
– If none of the probe targets could be reached, the connection switches to the provider of the other SIM card.
– If the SIM is used primarily.
back 1
The mobile network connection is also monitored. The mobile network modem is restarted if an AT command times out (timeout 30 seconds)
Probe status Indicates whether supervision is activated.
Supervision is only activated under the following conditions:
– SIM card inserted
– PIN entered correctly
– Router mode or network mode set to “Built-in mobile network modem”
– APN entered correctly
– PPP authentication stored correctly
180
Innominate Security Technologies I15020_en_03
Network menu
Network >> Mobile Network >> General [...]
Probe targets
Probe Interval
Number of times all probes need to fail before the mobile network connection is considered stalled
Here you can enter the probe targets as host names or IP addresses.
The ping type can be configured separately for each probe target:
– ICMP Ping (ICMP echo request, ICMP echo reply)
– DNS Ping (DNS query to UDP port 53)
– IKE Ping (IPsec IKE query to UDP port 500)
Ping types
– IKE Ping:
Determines whether a VPN gateway can be reached at the IP address specified.
– ICMP Ping:
Determines whether a device can be reached at the IP address specified.
This is the most common ping test. However, the response to this ping test is disabled on some devices. This means that they do not respond even though they can be reached.
– DNS Ping:
Determines whether an operational DNS server can be reached at the IP address specified.
A generic request is sent to the DNS server with the specified IP address, and every DNS server that can be reached responds to this request.
The probe targets are processed in the specified order.
Indicates the time between two tests in minutes
Value: 2 - 60 (default: 5)
Number of attempts before the mobile network connection is considered to be aborted.
Value: 1 - 5 (default: 3)
I15020_en_03 Innominate Security Technologies
181
6.7.2
SIM Settings
3G can be equipped with two SIM cards. The SIM card in slot
SIM 1 is the primary SIM card which is normally used to establish the connection. If this con-
The SIM card in slot 1 takes over the mobile network connection in these cases:
– If the mGuard is restarted
– When logging into the mobile network provider again
– In the event of an error with the mobile network connection of SIM 2
–
The SIM card in slot 2 takes over the mobile network connection if the connection via SIM 1 fails. The SIM card in slot 2 maintains the mobile network connection until one of the aforementioned cases occurs.
If SIM 2 is also unable to establish a mobile network connection, the interval for successive logon attempts is increased to 60 seconds.
182
Innominate Security Technologies I15020_en_03
Network menu
Network >> Mobile Network >> SIM Settings
Current SIM Slot
Primary SIM slot
State
Roaming
Current Provider
Activation
State
PIN of the SIM card
Roaming
Provider selection
Indicates whether SIM 1 or SIM 2 is used.
Indicates the state of the SIM card:
– SIM state unknown
– SIM inserted and authorized
– Invalid SIM
– SIM inserted
No SIM found
If roaming is enabled, a mobile network device can also dial into another network.
The mobile network that the mGuard has dialed into is displayed here.
– Not registered: the mGuard has not dialed into any mobile network
– Registered to home network: the mGuard has dialed into the mobile network provided
– Registered to foreign network: the MGUARD has registered with a foreign mobile network
Name of the mobile network provider in use
You can prevent or enable the use of the SIM card.
– SIM tray inserted (without SIM card)
– No SIM tray (neither the SIM card nor tray are available)
– Wrong PIN
– PIN required
– PUK required (if the PIN is incorrectly entered too often)
– SIM error (the SIM card could not be accessed)
– SIM ready
The SIM card can be protected with a PIN. The PIN is saved in the mGuard. The PIN is not displayed in the web browser.
However, it is possible to overwrite or delete it.
A PIN is used in the following cases:
– When the mGuard is restarted
– When the SIM card is replaced
– When the PIN is changed
– When the SIM card is activated
– For login to a mobile network provider
Yes / No
Roaming enables or prevents dialing into foreign mobile networks. Dialing into another network can incur additional costs.
When roaming is disabled, you can select a fixed provider.
You can restrict the SIM card registration to a provider from the list.
This selection is only active when roaming is disabled.
I15020_en_03 Innominate Security Technologies
183
Network >> Mobile Network >> SIM Settings [...]
Secondary SIM slot
Access Point Name
(APN) of the Provider
PPP authentication
PPP Login name
PPP Password
...
Maximum runtime of the fallback SIM until switching back to the primary SIM
Enter the name of the access gateway for the packet transmission of your mobile network provider. The APN can be obtained from your mobile network provider.
This is required by some providers for the transmission of packet data. The access data must be entered for this.
Enter the PAP or CHAP user ID to log into the access gateway of the mobile network provider. This information can be obtained from your mobile network provider.
Only visible when PPP authentication is set to “Yes”.
Enter the PAP or CHAP user password to log into the access gateway of the mobile network provider. This information can be obtained from your mobile network provider.
Only visible when PPP authentication is set to “Yes”.
Indicates the duration in hours until the device switches back to SIM
If set to “0”, SIM 2 remains active until the device dials into the mobile network again.
Values: 0 - 24 hours.
184
Innominate Security Technologies I15020_en_03
Network menu
6.7.3
Mobile Network Notifications
3G can send and receive text messages.
Text messages can be sent via the following mechanisms:
– Web interface
– Console
Text messages can be sent to freely definable mobile network recipients for selectable
You can also send a text message via the console. To do so, you must enter the recipient number followed by a space and then add the message:
/Packages/mguard-api_0/mbin/action gsm/sms “<recipient number> <message>”
Incoming text messages can be used to control VPN connections.
I15020_en_03 Innominate Security Technologies
185
Network >> Mobile Network >> Mobile Network Notifications
Mobile Network Notifications
Any text message recipient can be linked to predefined events and a freely definable message. The list is processed from top to bottom.
NOTE: Depending on the configuration, a very high number of text messages may be sent. It is recommended that you select a mobile network tariff that has a flat rate for text messages sent.
Text message recipient number
Event
Specifies a recipient number for the text message.
When the selected event occurs, the linked recipient number is selected and the event is sent to them as a text message.
A text message can also be stored and sent.
A complete list of all events can be found under “Event table”
Selector A configured VPN connection can be selected here, which is monitored via text message.
Text message content Here you can enter the text that is sent as a text message.
160 characters maximum (7-bit ASCII, no umlauts, no special characters, no control characters)
The text is freely definable. You can use blocks from the event table which can be inserted as placeholders in plain text (\A and \V) or in machine-readable format (\a and \v). Time stamps in the form of a placeholder (\T or \t (machine read-
able)) can also be inserted (see “Examples for timestamps” on
Incoming
Send text message
Incoming text messages can be used to start or stop VPN connections. The text message must contain a configured token and the corresponding command for the relevant VPN connection.
Text message command vpn/start <token> or openvpn/start <token> vpn/stop <token> or openvpn/stop <token>
The token is defined in the VPN settings (IPsec and Open-
VPN): “IPsec VPN >> Connections >> Edit >> General” and
“OpenVPN Client >> Connections >> Edit >> General” .
Displays the last text message received.
Last incoming text message
Current incoming voice call
Recipient number
Displays the telephone number of the current incoming caller.
Message
Enter the telephone number of the recipient of the text message (22 characters maximum) here.
Here you can enter the text that is sent as a text message.
Send text message now
160 characters maximum (7-bit ASCII, no umlauts, no special characters, no control characters)
The message is sent when you click on the button.
186
Innominate Security Technologies I15020_en_03
Network menu
Network >> Mobile Network >> Mobile Network Notifications [...]
Text message character set In firmware versions prior to 8.3, the approach was to try and send a maximum number of characters in one text message. Since some telecommunications providers do not adhere to standards, some text messages were not sent accurately (word-for-word). This led to problems in automated applications.
In order to ensure word-for-word transmission, the characters used needed to be restricted to the following basic character set:
– (space)
– 0-9
– a-z
– A-Z
– ! " # % & ( ) * + , - / : ; < = > ?
Restrict outgoing text message to basic character set
Yes / No
In order to force the use of the basic character set, Yes must be selected.
Place outgoing voice call
Outgoing
Recipient number
Place voice call now
Last outgoing text message
Status
Outgoing voice call
When Yes is selected, a text message sent by the mGuard is not translated into the language set for the web user interface; it is always sent in English. This does not affect e-mail notifications that are sent.
Enter the telephone number of the recipient of the call (22 characters maximum) here.
The call is placed when you click on the button.
Displays the last text message sent.
Status of the current outgoing call.
Displays the telephone number of the recipient of the current outgoing call.
I15020_en_03 Innominate Security Technologies
187
6.7.4
Positioning system
Network >> Mobile Network >> Positioning system
Settings
Current position
Enable Positioning engine
Update System time
When you enable this function, the position of the mGuard is determined.
Enables time synchronization through the positioning system in use.
Indicates whether valid positioning data is available for the mGuard.
Validity of the positional data
Number of Satellites Displays the number of available GPS/GLONASS satellites for the mGuard which are available for position determination.
At least two satellites must be available. Four available satellites are required for precise position determination. The longitude and latitude can be precisely determined to 10 m.
Values: 0 - 24
Latitude of the current position
Displays the current latitude of the mGuard position.
Displays the current longitude of the mGuard position.
Longitude of the current position
Show in OpenStreet-
Map
The position data of the mGuard is displayed. A working Internet connection is required for this.
188
Innominate Security Technologies I15020_en_03
Network menu
6.8
Network >> Dynamic Routing
In larger company networks, the use of dynamic routing protocols can make it easier for the network administrator to create and manage routes or even eliminate the need for this.
The OSPF (Open Shortest Path First) routing protocol allows participating routers to exchange and adapt the routes for transmitting IP packets in their autonomous network in realtime (dynamically). The best route to each subnetwork is determined for all participating routers and entered in routing tables for the devices. Changes in the network topology are automatically sent to neighboring OSPF routers and eventually distributed by them to all participating OSPF routers.
This menu is only available when the mGuard is in “Router” network mode. An OSPF area cannot be assigned to the WAN interface in “DHCP” router mode.
6.8.1
OSPF
I15020_en_03 Innominate Security Technologies
189
Network >> Dynamic Routing >> OSPF
OSPF can be configured for internal, external, and DMZ interfaces. If OSPF is to be used in IPsec connections, the OSPF packets (multicast) must be encapsulated in a GRE tunnel.
Enabling
Multiple OSPF areas can be configured in order to distribute local routes and learn external routes. The status of all learned routes is displayed in a table.
Enable OSPF Yes / No
When No is selected (default): OSPF is disabled on the device.
When Yes is selected: dynamic routing using the OSPF protocol is enabled on the device. New routes are learned and distributed by neighboring OSPF routers.
An OSPF area cannot be assigned to the WAN interface in “DHCP” router mode.
OSPF Settings
OSPF Hostname
Router ID
OSPF Areas
New setting options under “Network >> Interfaces” , “IPsec VPN >> Connections” , and “Net-
If an OSPF Hostname is assigned here, this is communicated to the participating OSPF routers instead of the global host name.
The Router ID in the form of an IP address must be unique within the autonomous system. It can otherwise be freely selected and typically corresponds to the IP address of the WAN or LAN interface of the mGuard.
The autonomous system is segmented using OSPF Areas.
The routes between OSPF routers are exchanged within an area. The mGuard can belong to one or more OSPF areas.
Distribution between neighboring areas is also possible using the “Transition Area” (see below).
The Name can be freely selected (default: ID). An OSPF router is clearly identified by its ID.
In general, the ID can be freely selected. If an OSPF area is assigned the ID 0, it becomes the “Transition Area”. This area is used to exchange routing information between two neighboring areas and then distribute it.
Stub Area: Yes / No
If the OSPF area is a stub area, select Yes.
Authentication: None / Simple / Digest
Authentication of the mGuard within the OSPF area can be performed using the “Simple” or “Digest” method. The corresponding passwords and digest keys are assigned for the al-
located interfaces (see “Additional Interface Settings” ).
190
Innominate Security Technologies I15020_en_03
Network menu
Network >> Dynamic Routing >> OSPF
Additional Interface
Settings
Interface: Internal / External / DMZ
Selects the interface for which the settings apply. If no settings are made here, the default settings apply (i.e., OSPF is enabled for the interface and the passwords are not assigned).
Passive Interface: Yes / No (default: No)
When No is selected, OSPF routes are learned and distributed by the interface.
When Yes is selected, no routes are distributed.
Authentication: None / Digest
If Digest is selected, “Digest” is always used for authentication at the selected interface – regardless of the authentication method already assigned to an OSPF area.
The authentication method (None / Simple / Digest) that has already been assigned to an OSPF area is therefore ignored and not used.
Simple Authentication Password: password for authentication of the OSPF router (for “Simple” authentication method)
Digest Key: digest key for authentication of the OSPF router
(for “Digest” authentication method)
Digest Key ID: digest key ID for authentication of the OSPF router (for “Digest” authentication method)
(1 - 255)
Route Redistribution Statically entered routes in the kernel routing table can also be distributed using OSPF.
Rules can be created for locally connected networks and networks that are connected via a gateway.
The networks whose routes are to be distributed using OSPF
can be specified in “access lists” via the “Distribution Settings”
.
By default, an access list is not selected for locally connected networks and networks reachable via a gateway. This means that all corresponding routes in the kernel routing table are distributed using OSPF if a rule and OSPF are enabled.
Type: Locally Connected Routes / Remotely Connected
Routes
Metric: metric used to distribute the routes. Unit representing the quality of a connection when a specific route is used.
Access List: distributes the routes according to the selected
access list (see “Distribution Settings” ). If None is selected, all
routes are distributed.
I15020_en_03 Innominate Security Technologies
191
Network >> Dynamic Routing >> OSPF
Status Dynamic Routes
(learned by OSPF)
The status of all routes learned using OSPF is displayed.
Remote Net: dynamically learned remote network.
Gateway: gateway to reach the remote network.
Metric: metric for the learned route.
192
Innominate Security Technologies I15020_en_03
Network menu
6.8.2
Distribution Settings
Dynamic routes are automatically distributed using the OSPF protocol. For statically entered routes in the kernel routing table, it must be specified whether they should also be distributed using OSPF.
If a rule is selected for either the “Locally Connected Routes” or “Remotely Connected
Routes” type, by default (Access List = None) all corresponding routes are distributed using OSPF if OSPF is enabled.
Rules can be created via Distribution Settings which determine the routes that are not learned dynamically that should be distributed using OSPF. These include:
–
Locally configured networks (see “Network >> Interfaces” on page
–
Static routes entered as external, internal or DMZ networks (see “Network >> Interfac-
–
Routes entered in the kernel routing table via OpenVPN (see “OpenVPN Client menu”
–
Routes entered in the kernel routing table via the GRE tunnel configuration (see “Net-
Network >> Dynamic Routing >> Distribution Settings >> Edit >> Access List Settings
Access List Settings Name The Name must be unique and must not be assigned more than once.
Rules Lists the access list rules. These apply for routes that are not distributed dynamically using OSPF.
Permit (default) / Deny
Permit means that the route to the entered network is distributed using OSPF.
Deny means that the route to the entered network is not distributed using OSPF.
Network whose distribution is permitted or denied by rules.
I15020_en_03 Innominate Security Technologies
193
6.9
Network >> GRE Tunnel
Generic Routing Encapsulation (GRE) is a network protocol that is used to encapsulate other protocols (including the OSPF routing protocol) and to transport them in a GRE tunnel via unicast IP connections. OSPF routes can therefore be learned and distributed via IPsec
VPN connections.
To ensure that GRE packets are routed through a secure IPsec tunnel, a preconfigured
IPsec connection can be selected for each GRE tunnel.
6.9.1
General
Network >> GRE Tunnel >> Edit >> General
Options
NOTE: In order to route the GRE tunnel through an encrypted IPsec connection, its local and remote end points must be located inside the IPsec connection.
Local endpoint of the
GRE tunnel
Remote endpoint of the GRE tunnel
Use IPsec VPN connection for securing the tunnel
Routes to the tunnel
Local IP address from which the tunnel will be started. The IP address must already be configured for the mGuard itself
under “Network >> Interfaces” .
Remote IP address where the tunnel ends. This IP address must also be configured at the remote network or computer.
For the selected IPsec connection, it is checked whether the
GRE tunnel is routed through and therefore protected by this connection, i.e., whether both end points are in the IPsec networks (local and remote).
All remote networks that should be reached encapsulated via the GRE tunnel are entered here. Several routes can be configured for each GRE tunnel.
0.0.0.0/0 means all IP addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
Dynamic Routing OSPF Area
Links the virtual GRE interface to an OSPF area (see “Network
OSPF Metric Unit representing the quality of a connection through the GRE tunnel.
194
Innominate Security Technologies I15020_en_03
Network menu
Network >> GRE Tunnel >> Edit >> General
Local IP address of the interface
Local netmask of the interface
IP address of the virtual GRE interface (required in order to exchange routing information between OSPF routers).
An IP address in the same network must be configured at the partner for the GRE interface.
Subnet mask of the virtual GRE interface.
6.9.2
Firewall
I15020_en_03
Incoming/outgoing firewall
only relate to the GRE connection defined on these tabs.
If multiple GRE connections have been defined, you can restrict the outgoing or incoming access individually for each connection. Any attempts to bypass these restrictions can be logged.
By default, the GRE firewall is set to allow all connections for the GRE connection.
However, the extended firewall settings defined and explained above apply independent-
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 contains further subsequent rules that could also apply, these rules are ignored.
Innominate Security Technologies
195
Network >> GRE Tunnel >> Edit >> Firewall
Incoming General firewall setting
Accept all incoming connections: the data packets of all incoming connections are allowed.
Drop all incoming connections: the data packets of all incoming connections are discarded.
Accept Ping only: the data packets of all incoming connections are discarded, except for ping packets (ICMP).
Use the firewall ruleset below: displays further setting options. (This menu item is not included in the scope of functions rs2000 Switch or
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-
From Port/To Port
Action
Comment
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
Incoming:
– From IP:
– To IP:
Outgoing:
–
–
From IP:
To IP:
IP address in the VPN tunnel
1:1 NAT address or the actual address
1:1 NAT address or the actual address
IP address in the VPN tunnel
(only evaluated for TCP and UDP protocols)
– 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
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.
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.
Freely selectable comment for this rule.
196
Innominate Security Technologies I15020_en_03
Network menu
Network >> GRE Tunnel >> Edit >> Firewall
Log
Outgoing
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
Log entries for unknown connection attempts
When set to Yes, all connection attempts that are not covered by the rules defined above are logged.
The explanation provided under “Incoming” also applies to “Outgoing”.
I15020_en_03 Innominate Security Technologies
197
198
Innominate Security Technologies I15020_en_03
Authentication menu
7 Authentication menu
7.1
Authentication >> Administrative Users
7.1.1
Passwords
Administrative Users refers to users who have the right (depending on their authorization level) to configure the mGuard (root and administrator authorization levels) or to use it (user authorization level).
Authentication >> Administrative Users >> Passwords root
To log into the corresponding authorization level, the user must enter the password assigned to the relevant authorization level (root, admin or user).
Root Password
(Account: root)
Grants full rights to all parameters of the mGuard.
Background: only this authorization level allows unlimited access to the mGuard file system.
admin Administrator Password (Account: admin)
User name (cannot be modified): root
Default root password: root
• To change the root password, enter the old password in the Old Password field, then the new password in the two corresponding fields below.
Grants the rights required for the configuration options accessed via the web-based administrator interface.
User name (cannot be modified): admin
Default password: mGuard
I15020_en_03 Innominate Security Technologies
199
Authentication >> Administrative Users >> Passwords [...] user Disable VPN until the user is authenticated via HTTP
If a user password has been specified and activated, the user must always enter this password after an mGuard restart in order to enable mGuard VPN connections when attempting to access any HTTP URL.
To use this option, specify the new user password in the corresponding entry field.
This option is set to No by default.
If set to Yes, VPN connections can only be used once a user has logged into the mGuard via HTTP.
mobile
(only
User Password
Mobile Password
As long as authentication is required, all HTTP connections are redirected to the mGuard.
Changes to this option only take effect after the next restart.
There is no default user password. To set one, enter the desired password in both entry fields.
There is no default user password. To set one, enter the desired password in both entry fields.
200
Innominate Security Technologies I15020_en_03
Authentication menu
7.1.2
RADIUS Filters
Group names can be created here for administrative users whose password is checked using a RADIUS server when accessing the mGuard. Each of these groups can be assigned an administrative role.
Authentication >> Administrative Users >> RADIUS Filters
This menu item is not included in the scope of functions for
The mGuard only checks passwords using RADIUS servers if you have activated RA-
DIUS authentication:
–
For shell access, see menu: Management >> System Settings >> Shell Access
–
For web access, see menu: Management >> Web Settings >> Access
The RADIUS filters are searched consecutively. When the first match is found, access is granted with the corresponding role (admin, netadmin, audit).
After a RADIUS server has checked and accepted a user's password, it sends the mGuard a list of filter IDs in its response.
These filter IDs are assigned to the user in a server database. They are used by the mGuard for assigning the group and hence the authorization level as “admin”, “netadmin” or “audit”.
If authentication is successful, this is noted as part of the mGuard's logging process. Other user actions are logged here using the original name of the user. The log messages are forwarded to a SysLog server, provided a SysLog server has been approved by the mGuard.
The following actions are recorded:
– Login
– Logout
– Start of a firmware update
– Changes to the configuration
– Password changes for one of the predefined users (root, admin, netadmin, audit, and
user).
I15020_en_03 Innominate Security Technologies
201
Authentication >> Administrative Users >> RADIUS Filters [...]
RADIUS Filters for Administrative Access
Group / Filter ID The group name may only be used once. Two lines must not have the same value.
Answers from the RADIUS server with a notification of successful authentication must have this group name in their filter
ID attribute.
Up to 50 characters are allowed (printable UTF-8 characters only) without spaces.
Authorized for access as
Each group is assigned an administrative role.
admin: Administrator
netadmin: Administrator for the network
audit: Auditor
The netadmin and audit authorization levels relate to access
202
Innominate Security Technologies I15020_en_03
Authentication menu
7.2
Authentication >> Firewall Users
To prevent private surfing on the Internet, for example, every outgoing connection is
blocked under Network Security >> Packet Filter >> DMZ. VPN is not affected by this.
Under Network Security >> User Firewall, different firewall rules can be defined for certain
users, e.g., outgoing connections are permitted. This user firewall rule takes effect as soon as the relevant firewall user(s) (to whom this user firewall rule applies) has (or have) logged
in, see “Network Security >> User Firewall” on page 245.
7.2.1
Firewall Users
Administrative access simultaneously via X.509 authentication and via login to the mGuard user firewall is not possible with the Safari browser.
Authentication >> Firewall Users >> Firewall Users
Users Lists the firewall users by their assigned user names. Also specifies the authentication method.
Enable user firewall
Under the Network Security >> User Firewall menu item, fire-
wall rules can be defined and assigned to specific firewall users.
When set to Yes, the firewall rules assigned to the listed users are applied as soon as the corresponding user logs in.
Enable group authentication
User Name
If activated, the mGuard forwards login requests for unknown users to the RADIUS server. If successful, the response from the RADIUS server will contain a group name. The mGuard then enables user firewall templates containing this group name as the template user.
The RADIUS server must be configured to deliver this group name in the “Access Accept” packet as a “Filter-ID=<groupname>” attribute.
Name specified by the user during login.
I15020_en_03 Innominate Security Technologies
203
Authentication >> Firewall Users >> Firewall Users[...]
Authentication Method Local DB: when Local DB is selected, the password assigned to the user must be entered in the User Password column in addition to the User Name that must be entered on login.
User Password
RADIUS: if RADIUS is selected, the user password can be stored on the RADIUS server.
Only active if Local DB is selected as the authentication method.
7.2.2
Access
Authentication >> Firewall Users >> Access
Authentication via HTTPS
NOTE: For authentication via an external interface, please consider the following:
If a firewall user can log in via an “unsecure” interface and the user leaves the session without logging out correctly, the login session may remain open and could be misused by another unauthorized person.
An interface is “unsecure”, for example, if a user logs in via the Internet from a location or a computer to which the IP address is assigned dynamically by the Internet service provider – this is usually the case for many Internet users. If such a connection is temporarily interrupted, e.g., because the user logged in is being assigned a different IP address, this user must log in again.
However, the old login session under the old IP address remains open. This login session could then be used by an intruder, who uses this “old” IP address of the authorized user and accesses the mGuard using this sender address. The same thing could also occur if an (authorized) firewall user forgets to log out at the end of a session.
This hazard of logging in via an “unsecure interface” is not completely eliminated, but the time is limited by setting the configured timeout for the user firewall template used. See
204
Innominate Security Technologies I15020_en_03
Authentication menu
Authentication >> Firewall Users >> Access[...]
Interface Internal / External / External 2 / Dial-in
1
/
VPN / DMZ 2
Specifies which mGuard interfaces can be used by firewall users to log into the mGuard. For the interface selected, web access via HTTPS must be enabled: Management, Web Set-
tings menu, Access tab page (see “Access” on page 60).
In Stealth network mode, both the Internal and
External interfaces must be enabled so that firewall users can log into the mGuard.
(Two rows must be entered in the table for this.)
1
2
DMZ is only for devices with a DMZ interface.
7.2.3
Status
When the user firewall is activated, its status is displayed here.
7.3
Authentication >> RADIUS
I15020_en_03
A RADIUS server is a central authentication server used by devices and services for checking user passwords. The password is not known to these devices and services. Only one or a number of RADIUS servers know the password.
The RADIUS server also provides the device or service that a user wishes to access with further information about the user, e.g., the group to which the user belongs. In this way, all user settings can be managed centrally.
In order to activate RADIUS authentication, Yes must be set under Authentication >> Fire-
Under Authentication >> RADIUS Servers, a list of RADIUS servers used by the mGuard is generated. This list is also used when RADIUS authentication is activated for administrative access (SSH/HTTPS).
Innominate Security Technologies
205
When RADIUS authentication is active, the login attempt is forwarded from a non-predefined user (not: root, admin, netadmin, audit or user) to all RADIUS servers listed here.
The first response received by the mGuard from one of the RADIUS servers determines whether or not the authentication attempt is successful.
Authentication >> RADIUS Servers
RADIUS servers RADIUS timeout
This menu item is not included in the scope of functions for RADIUS retries
Specifies the time (in seconds) the mGuard waits for a response from the RADIUS server. Default: 3 (seconds).
Specifies how often requests to the RADIUS server are re-
RADIUS NAS Identifier A NAS ID (NAS identifier) is sent with every RADIUS request, except when the field remains empty.
All common characters on the keyboard (except for umlauts) can be used as the NAS ID.
Server
The NAS ID is a RADIUS attribute that can be used by the client to be identified by the RADIUS server. The NAS ID can be used instead of an IP address to identify the client. It must be unique within the range of the RADIUS server.
Name of the RADIUS server or its IP address.
We recommend entering IP addresses as servers instead of names, where possible. Otherwise, the mGuard must first resolve the names before it can send authentication queries to the RADIUS server. This takes time when logging in. Also, it may not always be possible to perform authentication if name resolution fails (e.g., because the
DNS is not available or the name was deleted from the DNS).
206
Innominate Security Technologies I15020_en_03
I15020_en_03
Authentication menu
Via VPN If Yes is selected, the mGuard authentication query is always sent via an encrypted VPN tunnel if a suitable one is available.
If No is selected, a query of this type is always sent unencrypted outside the VPN.
If Yes has been selected under Via VPN, then the mGuard supports queries from a RA-
DIUS server through its VPN connection. This happens automatically whenever the RA-
DIUS server belongs to the remote network of a configured VPN tunnel and the mGuard has an internal IP address belonging to the local network of the same VPN tunnel. This makes the authentication query dependent on the availability of a VPN tunnel.
During configuration, ensure that the failure of a single VPN tunnel does not prevent administrative access to the mGuard.
Port
Secret
The port number used by the RADIUS server.
RADIUS server password.
This password must be the same as on the mGuard. The mGuard uses this password to exchange messages with the
RADIUS server and to encrypt the user password. The RA-
DIUS server password is not transmitted in the network.
The password is important for security since the mGuard can be rendered vulnerable to attack at this point if passwords are too weak. We recommend a password with at least 32 characters and several special characters. It must be changed on a regular basis.
If the RADIUS secret is discovered, an attacker can read the user password for the RADIUS authentication queries. An attacker can also falsify
RADIUS responses and gain access to the mGuard if they know the user names. These user names are transmitted as plain text with the RA-
DIUS request. The attacker can thus simulate RA-
DIUS queries and thereby find out user names and the corresponding passwords.
Administrative access to the mGuard should remain possible while the RADIUS server password is being changed. Proceed as follows to ensure this:
• Set up the RADIUS server for the mGuard a second time with a new password.
• Also set this new password on the RADIUS server.
• On the mGuard, delete the line containing the old password.
Innominate Security Technologies
207
7.4
Authentication >> Certificates
Authentication is a fundamental element of secure communication. The X.509 authentication method relies on certificates to ensure that the “correct” partners communicate with each other and that no “incorrect” partner is involved in communication. An “incorrect” communication partner is one who falsely identifies themselves as someone they are not (see
glossary under “X.509 certificate” on page 405).
Certificate
Self-signed certificates
A certificate is used as proof of the identity of the certificate owner. The relevant authorizing body in this case is the CA (certification authority). The digital signature on the certificate is provided by the CA. By providing this signature, the CA confirms that the authorized certificate owner possesses a private key that corresponds to the public key in the certificate.
The name of the certificate issuer appears under Issuer on the certificate, while the name of the certificate owner appears under Subject.
A self-signed certificate is one that is signed by the certificate owner and not by a CA. In selfsigned certificates, the name of the certificate owner appears under both Issuer and Sub-
ject.
Self-signed certificates are used if communication partners want to or must use the X.509 authentication method without having or using an official certificate. This type of authentication should only be used between communication partners that know and trust each other.
Otherwise, from a security point of view, such certificates are as worthless as, for example, a home-made passport without the official stamp.
Certificates are shown to all communication partners (users or machines) during the connection process, providing the X.509 authentication method is used. In terms of the mGuard, this could apply to the following applications:
– Authentication of communication partners when establishing IPsec VPN connections
(see “IPsec VPN >> Connections” on page 275, “Authentication” on page 295).
– Authentication of communication partners when establishing OpenVPN connections
(see “OpenVPN Client >> Connections >> Edit >> Authentication” on page 320).
–
–
Management of the mGuard via HTTPS (see “Management >> Web Settings” on page
Certificate, machine certificate
Certificates can be used to identify (authenticate) oneself to others. The certificate used by the mGuard to identify itself to others shall be referred to as the “machine certificate” here, in line with Microsoft Windows terminology.
A “certificate”, “certificate specific to an individual” or “user certificate showing a person” is one used by operators to authenticate themselves to partners (e.g., an operator attempting to access the mGuard via HTTPS and a web browser for the purpose of remote configuration). A certificate specific to an individual can also be saved on a chip card and then inserted by its owner in the card reader of their computer when prompted by a web browser
208
Innominate Security Technologies I15020_en_03
Remote certificate
CA Certificates
Authentication menu
A certificate is thus used by its owner (person or machine) as a form of ID in order to verify that they really are the individual they identify themselves as. As there are at least two communication partners, the process takes place alternately: partner A shows their certificate to partner B; partner B then shows their certificate to partner A.
Provision is made for the following so that A can accept the certificate shown by B, i.e., the certificate of its partner (thus allowing communication with B): A has previously received a copy of the certificate from B (e.g., by data carrier or e-mail) which B will use to identify itself to A. A can then verify that the certificate shown by B actually belongs to B by comparing it with this copy. With regard to the mGuard interface, the certificate copy given here by partner B to A is an example of a remote certificate.
For reciprocal authentication to take place, both partners must thus provide the other with a copy of their certificate in advance in order to identify themselves. A installs the copy of the certificate from B as its remote certificate. B then installs the copy of the certificate from A as its remote certificate.
Never provide the PKCS#12 file (file name extension: *.p12) as a copy of the certificate to the partner in order to use X.509 authentication for communication at a later time. The
PKCS#12 file also contains the private key that must be kept secret and must not be given
to a third party (see “Creation of certificates” on page 210).
To create a copy of a machine certificate imported in the mGuard, proceed as follows:
• On the “Machine Certificates” tab page, click on Current Certificate File next to the
The certificate shown by a partner can also be checked by the mGuard in a different way, i.e., not by consulting the locally installed remote certificate on the mGuard. To check the authenticity of possible partners in accordance with X.509, the method described below of consulting CA certificates can be used instead or as an additional measure, depending on the application.
CA certificates provide a way of checking whether the certificate shown by the partner is really signed by the CA specified in the partner's certificate.
A CA certificate is available as a file from the relevant CA (file name extension: *.cer, *.pem or *.crt). For example, this file may be available to download from the website of the relevant
CA.
The mGuard can then check if the certificate shown by the partner is authentic using the CA certificates loaded on the mGuard. However, this requires all CA certificates to be made available to the mGuard in order to form a chain with the certificate shown by the partner. In addition to the CA certificate from the CA whose signature appears on the certificate shown by the partner to be checked, this also includes the CA certificate of the superordinate CA,
and so forth, up to the root certificate (see glossary under “CA certificate” on page 399).
Authentication using CA certificates enables the number of possible partners to be extended without any increased management effort because it is not compulsory to install a remote certificate for each possible partner.
I15020_en_03 Innominate Security Technologies
209
Creation of certificates
Authentication methods
To create a certificate, a private key and the corresponding public key are required. Programs are available so that any user can create these keys. Similarly, a corresponding certificate with the corresponding public key can also be created, resulting in a self-signed certificate. (Additional information about self-creation can be downloaded from www.innominate.com
. It is available in the download area in an application note entitled
“How to obtain X.509 certificates”.)
A corresponding certificate signed by a CA must be requested from the CA.
In order for the private key to be imported into the mGuard with the corresponding certificate, these components must be packed into a PKCS#12 file (file name extension: *.p12).
The mGuard uses two methods of X.509 authentication that are fundamentally different.
– The authentication of a partner is carried out based on the certificate and remote certificate. In this case, the remote certificate that is to be consulted must be specified for each individual connection, e.g., for VPN connections.
– The mGuard consults the CA certificates provided to check whether the certificate shown by the partner is authentic. This requires all CA certificates to be made available to the mGuard in order to form a chain with the certificate shown by the partner through to the root certificate.
“Available” means that the relevant CA certificates must be installed on the mGuard (see
“CA Certificates” on page 217) and must also be referenced during the configuration of the
relevant application (SSH, HTTPS, and VPN).
Whether both methods are used alternatively or in combination varies depending on the application (VPN, SSH, and HTTPS).
Restrictions using the Safari browser
Please note that during administrative access to the mGuard via an X.509 certificate using the Safari browser all sub-CA certificates must be installed in the browser's truststore.
210
Innominate Security Technologies I15020_en_03
I15020_en_03
Authentication menu
Authentication for SSH
The partner shows the following:
The mGuard authenticates the partner using:
Certificate (specific to individual), signed by CA
Certificate (specific to individual), self-signed
1
All CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
PLUS (if required)
Remote certificates, if used as a filter
1
(See “Management >> System Settings” on page 35, “Shell Access” on page 42)
Authentication for HTTPS
The partner shows the following:
The mGuard authenticates the partner using:
Certificate (specific to individual), signed by CA
1
Certificate (specific to individual), self-signed
1
2
All CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
PLUS (if required)
Remote certificates, if used as a filter
2
The partner can additionally provide sub-CA certificates. In this case, the mGuard can form the set union for creating the chain from the CA certificates provided and the self-configured CA certificates. The corresponding root CA certificate must always be available on the mGuard.
(See “Management >> Web Settings” on page 59, “Access” on page 60)
Innominate Security Technologies
211
Authentication for VPN
The partner shows the following:
The mGuard authenticates the partner using:
Machine certificate, signed by CA
Machine certificate, self- signed
Remote certificate
Or all CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
NOTE: It is not sufficient to simply install the certificates to be used on the mGuard under
Authentication >> Certificates. In addition, the mGuard certificate imported from the pool
that is to be used must be referenced in the relevant applications (VPN, SSH, HTTPS).
The remote certificate for authentication of a VPN connection (or the tunnels of a VPN
connection) is installed in the IPsec VPN >> Connections menu.
212
Innominate Security Technologies I15020_en_03
Authentication menu
7.4.1
Certificate settings
Authentication >> Certificates >> Certificate settings
Certificate settings The settings made here relate to all certificates and certificate chains that are to be checked by the mGuard.
This generally excludes the following:
– Self-signed certificates from partners
– All remote certificates for VPN
Check the validity period of certificates and CRLs
No: the validity period specified in certificates and CRLs is ignored by the mGuard.
Wait for synchronization of the system time
The validity period specified in certificates and CRLs is only observed by the mGuard if the current date and time are known to the mGuard:
– Through the built-in clock (for the
–
By synchronizing the system clock (see “Time and Date” on page 37)
Until this point, all certificates to be checked are considered invalid for security reasons.
I15020_en_03 Innominate Security Technologies
213
Authentication >> Certificates >> Certificate settings[...]
Enable CRL checking Yes: when CRL checking is enabled, the mGuard consults the
CRL (certificate revocation list) and checks whether or not the certificates that are available to the mGuard are blocked.
CRLs are issued by the CAs and contain the serial numbers of blocked certificates, e.g., certificates that have been reported stolen.
On the CRL tab page (see “CRL” on page 221), specify the or-
igin of the mGuard revocation lists....
When CRL checking is enabled, a CRL must be configured for each issuer of certificates on the mGuard. Missing CRLs result in certificates being considered invalid.
Revocation lists are verified by the mGuard using an appropriate CA certificate. Therefore, all CA certificates that belong to a revocation list (all sub-
CA certificates and the root certificate) must be imported on the mGuard. If the validity of a revocation list cannot be proven, it is ignored by the mGuard.
If the use of revocation lists is activated together with the consideration of validity periods, revocation lists are ignored if (based on the system time) their validity has expired or has not yet started.
CRL download interval If Enable CRL checking is set to Yes (see above), select the time period after which the revocation lists should be downloaded and applied.
On the CRL tab page (see “CRL” on page 221), specify the or-
igin of the mGuard revocation lists.
If CRL checking is enabled, but CRL download is set to Never, the CRL must be manually loaded on the mGuard so that CRL checking can be performed.
214
Innominate Security Technologies I15020_en_03
Authentication menu
7.4.2
Machine Certificates
The mGuard authenticates itself to the partner using a machine certificate loaded on the mGuard. The machine certificate acts as an ID card for the mGuard, which it shows to the relevant partner.
For a more detailed explanation, see “Authentication >> Certificates” on page 208.
By importing a PKCS#12 file, the mGuard is provided with a private key and the corresponding machine certificate. Multiple PKCS#12 files can be loaded on the mGuard, enabling the mGuard to show the desired self-signed or CA-signed machine certificate to the partner for various connections.
In order to use the machine certificate installed at this point, it must be referenced addition-
ally during the configuration of applications (SSH, VPN) so that it can be used for the relevant connection or remote access type.
Example of imported machine certificates :
Authentication >> Certificates >> Machine Certificates
Machine Certificates Shows the currently imported X.509 certificates that the mGuard uses to authen-
Importing a new machine certificate
To import a (new) certificate, proceed as follows:
Requirement:
The PKCS#12 file (file name extension: *.p12 or *.pfx) is saved on the connected computer.
Proceed as follows:
• Click on Browse... to select the file.
I15020_en_03 Innominate Security Technologies
215
Using the short name:
• In the Password field, enter the password used to protect the private key of the
PKCS#12 file.
• Click on Import.
Once imported, the loaded certificate appears under Certificate.
• Remember to save the imported certificate along with the other entries by clicking on the Apply button.
Shortname
When importing a machine certificate, the CN attribute from the certificate subject field is suggested as the short name here (providing the Shortname field is empty at this point).
This name can be adopted or another name can be chosen.
• A name must be assigned, whether it is the suggested one or another. Names must be unique and must not be assigned more than once.
During the configuration of
–
SSH (Management >> System Settings, Shell Access menu)
–
HTTPS (Management >> Web Settings, Access menu)
–
VPN connections (IPsec VPN >> Connections menu)
the certificates imported on the mGuard are provided in a selection list.
The certificates are displayed under the short name specified for each individual certificate on this page.
For this reason, name assignment is mandatory.
Creating a certificate copy
You can create a copy of the imported machine certificate (e.g., for the partner in order to authenticate the mGuard). This copy does not contain the private key and can therefore be made public at any time.
To do this, proceed as follows:
• Click on Current Certificate File next to the Download Certificate row for the relevant machine certificate.
• Enter the desired information in the dialog box that opens.
216
Innominate Security Technologies I15020_en_03
Authentication menu
7.4.3
CA Certificates
CA certificates are certificates issued by a certification authority (CA). CA certificates are used to check whether the certificates shown by partners are authentic.
The checking process is as follows: the certificate issuer (CA) is specified as the issuer in the certificate transmitted by the partner. These details can be verified by the same issuer
Example of imported CA certificates:
Authentication >> Certificates >> CA Certificates
Trusted CA Certificates Displays the current imported CA certificates.
Importing a CA certificate
To import a (new) certificate, proceed as follows:
The file (file name extension: *.cer, *.pem or *.crt) is saved on the connected computer.
Proceed as follows:
• Click on Browse... to select the file.
• Click on Import. Once imported, the loaded certificate appears under Certificate.
• Save the imported certificate by clicking on Apply.
I15020_en_03 Innominate Security Technologies
217
Shortname
When importing a CA certificate, the CN attribute from the certificate subject field is suggested as the short name here (providing the Shortname field is empty at this point). This name can be adopted or another name can be chosen.
• You must assign a name. The name must be unique.
Using the short name
During the configuration of
–
SSH (Management >> System Settings, Shell Access menu)
–
HTTPS (Management >> Web Settings, Access menu)
–
VPN connections (IPsec VPN >> Connections menu)
the certificates imported on the mGuard are provided in a selection list. The certificates are displayed under the short name specified for each certificate in this selection list. Name assignment is mandatory.
Creating a certificate copy
A copy can be created from the imported CA certificate.
To do this, proceed as follows:
• Click on Current Certificate File next to the Download Certificate row for the relevant CA certificate. A dialog box opens in which you can enter the required information.
218
Innominate Security Technologies I15020_en_03
Authentication menu
7.4.4
Remote Certificates
A remote certificate is a copy of the certificate that is used by a partner to authenticate itself to the mGuard.
Remote certificates are files (file name extension: *.cer, *.pem or *.crt) received from possible partners by trustworthy means. You load these files on the mGuard so that reciprocal authentication can take place. The remote certificates of several possible partners can be loaded.
The remote certificate for authentication of a VPN connection (or the tunnels of a VPN con-
nection) is installed in the IPsec VPN >> Connections menu.
For a more detailed explanation, see “Authentication >> Certificates” on page 208.
Example of imported remote certificates:
Authentication >> Certificates >> Remote Certificates
Trusted remote Certificates Displays the current imported remote certificates.
Importing a new certificate Requirement:
The file (file name extension: *.cer, *.pem or *.crt) is saved on the connected computer.
Proceed as follows:
• Click on Browse... to select the file.
• Click on Import.
Once imported, the loaded certificate appears under Certificate.
• Remember to save the imported certificate along with the other entries by clicking on the Apply button.
Shortname
When importing a remote certificate, the CN attribute from the certificate subject field is suggested as the short name here (providing the Shortname field is empty at this point). This name can be adopted or another name can be chosen.
• A name must be assigned, whether it is the suggested one or another. Names must be unique and must not be assigned more than once.
I15020_en_03 Innominate Security Technologies
219
Using the short name: During the configuration of
–
SSH (Management >> System Settings, Shell Access menu)
–
HTTPS (Management >> Web Settings, Access menu)
the certificates imported on the mGuard are provided in a selection list. The certificates are displayed under the short name specified for each certificate in this selection list. Name assignment is mandatory.
Creating a certificate copy
A copy can be created from the imported remote certificate.
To do this, proceed as follows:
• Click on Current Certificate File next to the Download Certificate row for the relevant remote certificate. A dialog box opens in which you can enter the required information.
220
Innominate Security Technologies I15020_en_03
Authentication menu
7.4.5
CRL
Authentication >> Certificates >> CRL
CRL CRL stands for certificate revocation list.
The CRL is a list containing serial numbers of blocked certificates. This page is used for the configuration of sites from which the mGuard should download CRLs in order to use them.
Certificates are only checked for revocations if the Enable CRL checking option is set to
Yes (see “Certificate settings” on page 213).
A CRL with the same issuer name must be present for each issuer name specified in the certificates to be checked. If such a CRL is not present and CRL checking is enabled, the certificate is considered invalid.
Issuer Information read directly from the CRL by the mGuard:
Shows the issuer of the relevant CRL.
Last Update
Next Update
Information read directly from the CRL by the mGuard:
Time and date of issue of the current CRL on the mGuard.
Information read directly from the CRL by the mGuard:
Time and date when the CA will next issue a new CRL.
URL
Download via VPN if applicable
This information is not influenced or considered by the CRL download interval.
Specify the URL of the CA where CRL downloads are obtained if the CRL should be downloaded on a regular basis, as defined under CRL download interval on the Certificate set-
tings tab page (see “Certificate settings” on page 213).
If set to Yes, the mGuard uses a VPN tunnel to access the
URL where the CRL is available for download. For this to happen, a suitable VPN tunnel must be configured, activated, and allow access. Otherwise, the CRL downloads from this URL will not be forwarded via a VPN tunnel.
I15020_en_03 Innominate Security Technologies
221
Authentication >> Certificates >> CRL
Upload If the CRL is available as a file, it can also be loaded on the mGuard manually.
• To do this, click on Browse..., select the file, and click on
Import.
• Remember to save the imported CRL along with the other entries by clicking on the “Apply” button.
An up-to-date CRL file must always be used. For this reason, it is not included in the mGuard configuration.
When exporting an mGuard configuration and then importing it to another mGuard, the CRL file must be uploaded again.
CRL files might be deleted during a firmware update. In this case, the mGuard downloads the
CRL files from the specified URL again. Alternatively, it can be uploaded manually.
222
Innominate Security Technologies I15020_en_03
Network Security menu
8 Network Security menu
8.1
Network Security >> Packet Filter
The mGuard includes a Stateful Packet Inspection Firewall. The connection data of an active connection is recorded in a database (connection tracking). Rules therefore only have to be defined for one direction. This means that data from the other direction of the relevant connection, and only this data, is automatically allowed through.
A side effect is that existing connections are not aborted during reconfiguration, even if a corresponding new connection can no longer be established.
Default firewall settings
– All incoming connections are rejected (excluding VPN).
– Data packets of all outgoing connections are allowed through.
The firewall rules here have an effect on the firewall that is permanently active, with the exception of:
–
– User firewall. When a user logs in, for whom user firewall rules are defined, these rules
take priority (see “Network Security >> User Firewall” on page 245), followed by the
permanently active firewall rules.
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 contains further subsequent rules that could also apply, these rules are ignored.
Innominate Security Technologies
223
I15020_en_03
8.1.1
Incoming Rules
Network Security >> Packet Filter >> Incoming Rules
Incoming Lists the firewall rules that have been set up. They apply for incoming data links that have been initiated externally.
If no rule has been set, the data packets of all incoming connections (excluding VPN) are dropped (default setting).
General firewall setting
Accept all incoming connections: the data packets of all incoming connections are allowed.
Drop all incoming connections: the data packets of all incoming connections are discarded.
Accept Ping only: the data packets of all incoming connections are discarded, except for ping packets (ICMP). This setting allows all ping packets to pass through. The integrated protection against brute force attacks is not effective in this case.
Use the firewall ruleset below: displays further setting options. (This menu item is not included in the scope of functions rs2000 Switch, and
The following settings are only visible if “Use the firewall ruleset below” is set.
Interface External / External 2 / Any External
1
Protocol
Specifies via which interface the data packets are received so that the rule applies to them. Any External refers to the Exter-
nal and External 2 interfaces. These interfaces are only available on mGuard models that have a serial interface with external access.
All means TCP, UDP, ICMP, GRE, and other IP protocols
224
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> Incoming Rules [...]
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-
From Port / To Port
Action
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see IP/Port
(only evaluated for TCP and UDP protocols)
– 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 tab).
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.
Comment
Log
Log entries for unknown connection attempts?
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 saved under this name take effect
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
When set to Yes, all connection attempts that are not covered by the rules defined above are logged. (Default setting: No)
1
I15020_en_03 Innominate Security Technologies
225
8.1.2
Outgoing Rules
Network Security >> Packet Filter >> Outgoing Rules
Outgoing Lists the firewall rules that have been set up. They apply for outgoing data links that have been initiated internally in order to communicate with a remote partner.
A rule is defined by default that allows all outgoing connections. If no rule is defined, all outgoing connections are prohibited (excluding VPN).
General firewall setting
Accept all outgoing connections: the data packets of all outgoing connections are allowed.
Drop all outgoing connections: the data packets of all outgoing connections are discarded.
Accept Ping only: the data packets of all outgoing connections are discarded, except for ping packets (ICMP).
Use the firewall ruleset below: displays further setting options. (This menu item is not included in the scope of functions rs2000 Switch, and
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-
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see IP/Port
226
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> Outgoing Rules [...]
From Port / To Port (only evaluated for TCP and UDP protocols)
– any refers to any port.
– startport:endport (e.g., 110:120) refers to a port range.
Action
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 tab).
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.
Comment
Log
Log entries for unknown connection attempts?
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 saved under this name take effect
Freely selectable comment for this firewall rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
When set to Yes, all connection attempts that are not covered by the rules defined above are logged. (Default setting: No)
I15020_en_03 Innominate Security Technologies
227
8.1.3
DMZ
Network Security >> Packet Filter >> DMZ
Firewall rules for DMZ
WAN
DMZ
DMZ
DMZ
LAN
LAN
WAN
DMZ
Protocol
If no rule has been set, the data packets of all incoming connections (excluding VPN) are dropped
(default setting).
If no rule has been set, the data packets of all incoming connections (excluding VPN) are dropped
(default setting).
A rule is defined by default that allows all outgoing connections.
A rule is defined by default that allows all outgoing connections.
All means TCP, UDP, ICMP, GRE, and other IP protocols
228
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> DMZ [...]
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-
From Port / To Port
Action
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see IP/Port
(only evaluated for TCP and UDP protocols)
– 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 tab).
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.
Comment
Log
Log entries for unknown connection attempts?
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 saved under this name take effect
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
When set to Yes, all connection attempts that are not covered by the rules defined above are logged. (Default setting: No)
I15020_en_03 Innominate Security Technologies
229
8.1.4
Rule Records
Network Security >> Packet Filter >> Rule Records
Rule Records Initial Mode
Control
Active/Inactive/Disabled
Determines the output state of the firewall rule record following a reconfiguration or restart.
The “Active/Inactive” setting is only applicable if a pushbutton is connected. If the firewall rule records are controlled via a switch or VPN connection, they have priority.
If set to “Disabled”, the firewall rule record cannot be dynamically enabled. The firewall rule record is retained but has no influence.
Service input CMD 1-3, VPN connection
The firewall rule record can be switched via a pushbutton/switch or a VPN connection.
The pushbutton/switch must be connected to one of the ser-
Edit
State
Name
Action
Indicates the current state.
The firewall rule record can be freely named/renamed.
Activate/Deactivate
If set to “Deactivate”, the rule record is deactivated.
The following tab appears when you click on Edit:
230
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> Rule Records [...]
General A descriptive name for the set
The firewall rule record can be freely named/renamed.
Initial mode Active/Inactive/Disabled
Determines the output state of the firewall rule record following a reconfiguration or restart.
Controlling service input/CMD or VPN connection
The “Active/Inactive” setting is only applicable if a pushbutton is connected. If the firewall rule records are controlled via a switch or VPN connection, they have priority.
If set to “Disabled”, the firewall rule record cannot be dynamically enabled. It is retained but has no influence.
Service input CMD 1-3, VPN connection
The firewall rule record can be switched via a pushbutton/switch or a VPN connection.
The pushbutton/switch must be connected to one of the ser-
Firewall rules
Token for text message trigger
Incoming text messages can be used to activate or deactivate firewall rule records. The text message must contain the
“fwrules/active” or “fwrules/inactive” command followed by the token.
Deactivation Timeout Activated firewall rule records are deactivated after this time has elapsed.
Protocol
From IP
0 means the setting is disabled.
Time in h:mm:ss (1 day maximum)
The entry can be in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes, and seconds [h:mm:ss].
All means TCP, UDP, ICMP, GRE, and other IP protocols.
0.0.0.0/0 means all IP addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
From Port / To Port
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see IP/Port
(only evaluated for TCP and UDP protocols)
– 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 tab).
I15020_en_03 Innominate Security Technologies
231
Network Security >> Packet Filter >> Rule Records [...]
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.
Comment
Log
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 saved under this name take effect.
Freely selectable comment for this rule.
For each firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
If a connection associated with a firewall rule record has been established and is continuously creating data traffic, deactivation of the firewall rule record might not interrupt this connection as expected.
This happens because the (outgoing) response of a service on the LAN side creates an entry in the connection tracking table which enables a different (incoming) request from an external peer. This peer passes the firewall using the same parameters, however, it is not connected to the firewall rule record.
There are two ways to set up the mGuard so that it interrupts the associated connections when deactivating the firewall rule record.
–
Activate the “Allow TCP connections upon SYN only” option under Network Security >>
– In the firewall, block the outgoing connections that operate via the port that is the destination for the incoming connections.
If, for example, the firewall rule record enables incoming data traffic on port 22, an outgoing rule can be set up that deactivates any data traffic coming from port 22.
232
Innominate Security Technologies I15020_en_03
8.1.5
MAC Filtering
Network Security menu
The “Incoming” MAC filter is applied to frames that the mGuard receives at the WAN interface. The “Outgoing” MAC filter is applied to frames that the mGuard receives at the LAN interface. Data packets that are received or sent via a modem connection on models with a serial interface
1
are not picked up by the MAC filter because the Ethernet protocol is not used here.
In Stealth mode, in addition to the packet filter (Layer 3/4) that filters data traffic, e.g., according to ICMP messages or TCP/UDP connections, a MAC filter (Layer 2) can also be set. A MAC filter (Layer 2) filters according to MAC addresses and Ethernet protocols.
In contrast to the packet filter, the MAC filter is stateless. If rules are introduced, corresponding rules must also be created for the opposite direction.
If no rules are set, all ARP and IP packets are allowed to pass through.
When setting MAC filter rules, please note the information displayed on the screen. The rules defined here have priority over packet filter rules. The MAC filter does not support logging.
Network Security >> Packet Filter >> MAC Filtering
Incoming Source MAC
Destination MAC
Ethernet Protocol
Action
Specification of the source MAC address: xx:xx:xx:xx:xx:xx stands for all MAC addresses.
Specification of the destination MAC address: xx:xx:xx:xx:xx:xx stands for all MAC addresses. ff:ff:ff:ff:ff:ff stands for the broadcast MAC address to which all ARP requests are sent, for example.
%any stands for all Ethernet protocols.
Additional protocols can be specified in name or hexadecimal format, for example:
– IPv4 or 0800
– ARP or 0806
Accept means that the data packets may pass through.
Drop means that the data packets are not permitted to pass through (they are dropped).
1
rs4000/rs2000 rs4000/rs2000,
I15020_en_03 Innominate Security Technologies
233
Network Security >> Packet Filter >> MAC Filtering [...]
Outgoing
Comment Freely selectable comment for this rule.
The explanation provided under “Incoming” also applies to “Outgoing”.
234
Innominate Security Technologies I15020_en_03
Network Security menu
8.1.6
IP/Port Groups
IP and port groups enable the easy creation and management of firewall and NAT rules in complex network structures.
IP addresses, IP areas, and networks can be grouped in IP groups and identified by a name.
Likewise, ports or port ranges can be grouped in port groups.
If a firewall or NAT rule is created, instead of IP addresses/IP areas or ports/port ranges, the
IP or port groups can be selected directly in the corresponding fields and assigned the rule.
Network Security >> Packet Filter >> IP/Port Groups
IP Groups Name The IP group can be freely named/renamed.
Edit
Comment Freely selectable comment for this group/rule.
The following tab appears when you click on Edit:
IP Group Settings
Port Groups
Edit
Name
Comment
Entries
The IP group can be freely named/renamed.
Freely selectable comment for this group/rule.
IP address area (e.g., 192.168.3.1-192.168.3.10) or a net-
Name
Comment
The port group can be freely named/renamed.
Freely selectable comment for this group/rule.
The following tab appears when you click on Edit:
Port Group Settings
I15020_en_03
Name The port group can be freely named/renamed.
Innominate Security Technologies
235
Network Security >> Packet Filter >> IP/Port Groups [...]
Freely selectable comment for this group/rule.
Comment
Entries The entries can specify a port (e.g., range (e.g., 110:120 or 110-120).
pop3 or 110) or a port
236
Innominate Security Technologies I15020_en_03
8.1.7
Advanced
The following settings affect the basic behavior of the firewall.
Network Security menu
Network Security >> Packet Filter >> Advanced
Consistency checks
This menu item is not included in the scope of functions for
Maximum size of
“ping” packets (ICMP
Echo Request) mGuard rs2000 Switch or
Refers to the length of the entire packet including the header.
The packet length is normally 64 bytes, but it can be larger. If oversized packets are to be blocked (to prevent bottlenecks), a maximum value can be specified. This value should be more than 64 bytes in order to not block normal ICMP echo requests.
I15020_en_03 Innominate Security Technologies
237
Network Security >> Packet Filter >> Advanced [...]
Enable TCP/UDP/ICMP consistency checks
When set to Yes, the mGuard performs a range of tests to check for incorrect checksums, packet sizes, etc. and drops packets that fail these tests.
Allow TCP keepalive packets without TCP flags
This option is set to Yes by default.
TCP packets without flags set in their TCP header are normally rejected by firewalls. At least one type of Siemens controller with older firmware sends TCP keepalive packets without TCP flags set. These are therefore discarded as invalid by the mGuard.
Network Modes
(Router/PPTP/PPPoE)
When set to Yes, forwarding of TCP packets where no TCP flags are set in the header is enabled. This only applies when
TCP packets of this type are sent within an existing TCP connection established in the regular way.
TCP packets without TCP flags do not result in a new entry in
mGuard is restarted, the corresponding packets are still rejected and connection problems can be observed as long as no packets with flags belonging to the connection are sent.
These settings affect all the TCP packets without flags. The
Yes option therefore weakens the security functions provided by the mGuard.
This option can be used to control the behavior of the mGuard when ICMP messages are received from the external network via the primary/secondary external interface.
ICMP via primary external interface for the mGuard
ICMP via secondary external interface for the mGuard
ICMP via DMZ interface for the mGuard
Regardless of the setting specified here, incoming
ICMP packets are always accepted if SNMP access is activated.
Drop: all ICMP messages to the mGuard are dropped.
Allow ping requests: only ping messages (ICMP type 8) to the mGuard are accepted.
Stealth Mode Allow forwarding of
GVRP frames
Allow forwarding of
STP frames
Allow all ICMPs: all ICMP message types to the mGuard are accepted.
Yes / No
The GARP VLAN Registration Protocol (GVRP) is used by
GVRP-capable switches to exchange configuration information.
If this option is set to Yes, GVRP packets are allowed to pass through the mGuard in Stealth mode.
Yes / No
The Spanning Tree Protocol (STP) (802.1d) is used by bridges and switches to detect and allow for loops in the cabling.
If this option is set to Yes, STP packets are allowed to pass through the mGuard in Stealth mode.
238
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> Advanced [...]
Allow forwarding of
DHCP frames
Connection Tracking Maximum table size
Allow TCP connections upon SYN only
Timeout for established TCP connections
Timeout for closed
TCP connections
Yes / No
When set to Yes, the client is allowed to obtain an IP address via DHCP – regardless of the firewall rules for outgoing data traffic.
This option is set to Yes by default.
This entry specifies an upper limit. This is set to a value that can never be reached during normal practical operation. However, it can be easily reached in the event of attacks, thus providing additional protection. If there are special requirements in your operating environment, this value can be increased.
Connections established from the mGuard are also counted.
This value must therefore not be set too low, as this will otherwise cause malfunctions.
Yes / No, default: No
SYN is a special data packet used in TCP/IP connection establishment that marks the beginning of the connection establishment process.
No (default): the mGuard also allows connections where the beginning has not been registered. This means that the mGuard can perform a restart when a connection is present without interrupting the connection.
Yes: the mGuard must have registered the SYN packet of an existing connection. Otherwise, the connection is aborted.
If the mGuard performs a restart while a connection is present, this connection is interrupted. Attacks on and the hijacking of existing connections are thus prevented.
If a TCP connection is not used during the time period specified here, the connection data is deleted.
A connection translated by NAT (not 1:1 NAT) must then be reestablished.
If Yes is set under “Allow TCP connections upon SYN only”, all
expired connections must be reestablished.
Default setting: 120 days
The entry can be in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes, and seconds [h:mm:ss].
The timeout blocks a TCP port-to-port connection for an extended period after the connection is closed. This is necessary as packets belonging to the closed TCP connection may still arrive in a packet-based network after the connection is closed. Without time-controlled blocking, old packets could be assigned to a new connection accidentally.
Default setting: 1 hour
The entry can be in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes, and seconds [h:mm:ss].
I15020_en_03 Innominate Security Technologies
239
Network Security >> Packet Filter >> Advanced [...]
Abort existing connections upon firewall reconfiguration
Yes / No, default: Yes
When set to Yes, the existing connections are reset if the following applies:
–
Yes is set under “Allow TCP connections upon SYN only”
– The firewall rules have been adjusted
– The value was changed from No to Yes (even without changing the firewall rules)
After changing the firewall rules, the mGuard behaves in the same way as after a restart. However, this only applies to the forwarded connections. Existing TCP connections are interrupted, even if they are allowed according to the new firewall rules. Connections to the device are not affected, even if the firewall rules have been changed for remote access.
If set to No, the connections remain, even if the firewall rules changed would not allow them or would abort them.
FTP
IRC
Yes / No
If an outgoing connection is established to call data for the
FTP protocol, two methods of data transmission can be used:
With “active FTP”, the called server establishes an additional counter-connection to the caller in order to transmit data over this connection.
With “passive FTP”, the client establishes this additional connection to the server for data transmission.
FTP must be set to Yes (default) so that additional connections can pass through the firewall.
Yes / No
PPTP
H.323
Similar to FTP: for IRC chat over the Internet to work properly, incoming connections must be allowed following active connection establishment. IRC must be set to Yes (default) in order for these connections to pass through the firewall.
Yes / No, default: No
Must be set to Yes if VPN connections are to be established using PPTP from local computers to external computers without the aid of the mGuard.
Must be set to Yes if GRE packets are to be forwarded from the internal area to the external area.
Yes / No, default: No
Protocol used to establish communication sessions between two or more devices. Used for audio-visual transmission. This protocol is older than SIP.
240
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> Packet Filter >> Advanced [...]
SIP
OPC Classic
Yes / No, default: No
SIP (Session Initiation Protocol) is used to establish communication sessions between two or more devices. Often used in
IP telephony.
When set to Yes, it is possible for the mGuard to track the SIP and add any necessary firewall rules dynamically if further
PCP channels are established to the same session.
When NAT is also activated, one or more locally connected computers can communicate with external computers by SIP via the mGuard.
This function can only be activated when a suitable license key (OPC Inspector) is installed.
With OPC Classic, communication always starts via TCP port
135. The client and server then negotiate one or more additional connections on new ports. To enable these connections, in the past all ports of an interconnected firewall had to
be open. If OPC Classic is activated, it is enough to only en-
able TCP port 135 for a client/server pair using the firewall rules.
The mGuard inspects the user data of the packets (deep packet inspection). It checks in the user data sent via this port whether a new connection has been negotiated, and opens the negotiated port. To do so, communication between the client and the server on port 135 must be enabled in both directions.
If OPC Classic is activated, NAT procedures can be used. If
OPC server/client must be activated on the LAN interface of the mGuard.
If Sanity check for OPC Classic is activated, only OPC pack-
Sanity check for OPC
Classic the newly negotiated ports.
Timeout for OPC Classic connection expectations
Configures the timeout during which OPC traffic is expected.
An existing OPC connection may negotiate another connec-
tion on a new port. If “Sanity check for OPC Classic” is acti-
vated, these connections must only be OPC connections.
The mGuard creates a new dynamic firewall rule if it detects in
OPC traffic that a new OPC connection should be established.
The dynamic firewall rule immediately accepts new OPC connections with the negotiated parameters.
If the timeout for the dynamic firewall expires, the rule is deleted. New connections with these parameters are then no longer accepted.
Already established connections are not closed.
I15020_en_03 Innominate Security Technologies
241
8.1.8
Firewall for the mGuard rs2000, mGuard rs2000 3G, and mGuard rs2000 Switch rs2000 Switch have a simple “2-click firewall”. This either permits or rejects all incoming and outgoing connections.
No advanced settings are provided. Furthermore, access via this firewall is not logged
(see Logging >> Browse local logs).
Incoming Rules
– Accept all incoming connections
– Drop all incoming connections
– Accept Ping only
This setting allows all ping packets to pass through. The integrated protection against brute force attacks is not effective in this case.
Outgoing Rules
– Accept all outgoing connections
– Drop all outgoing connections
– Accept Ping only
This setting allows all ping packets to pass through. The integrated protection against brute force attacks is not effective in this case.
These variables are also available on other devices. However, other devices also have ad-
vanced settings (see “Incoming Rules” on page
242
Innominate Security Technologies I15020_en_03
Network Security menu
8.2
Network Security >> DoS Protection
8.2.1
Flood Protection
Network Security >> DoS Protection >> Flood Protection
TCP Outgoing: default setting: 75 Maximum number of new incoming/outgoing TCP connections
(SYN) per second
Incoming: default setting: 25
Maximum values for the number of incoming and outgoing
TCP connections allowed per second.
They are set to a value that can never be reached during normal practical operation. However, they can be easily reached in the event of attacks, thus providing additional protection.
If there are special requirements in your operating environment, these values can be increased.
I15020_en_03 Innominate Security Technologies
243
Network Security >> DoS Protection >> Flood Protection [...]
ICMP Maximum number of incoming/outgoing
“ping” frames (ICMP
Echo Request) per second
Outgoing: default setting: 5
Incoming: default setting: 3
Maximum values for the number of incoming and outgoing
“ping” packets allowed per second.
They are set to a value that can never be reached during normal practical operation. However, they can be easily reached in the event of attacks, thus providing additional protection.
Stealth Mode Maximum number of incoming/outgoing
ARP requests or ARP replies per second each
If there are special requirements in your operating environment, these values can be increased.
The value 0 means that no “ping” packets are allowed through or in.
Default setting: 500
Maximum values for the number of incoming and outgoing
ARP requests or replies allowed per second.
They are set to a value that can never be reached during normal practical operation. However, they can be easily reached in the event of attacks, thus providing additional protection.
If there are special requirements in your operating environment, these values can be increased.
244
Innominate Security Technologies I15020_en_03
8.3
Network Security >> User Firewall
Network Security menu
The user firewall is used exclusively by firewall users, i.e., users who are registered as fire-
Each firewall user can be assigned a set of firewall rules, also referred to as a template.
When firewall rule records (templates) are added, deleted or changed, this immediately affects all users who are logged in. Existing connections are interrupted. One exception is
changing user firewall rules if “Abort existing connections upon firewall reconfiguration” is
set to “No” under Network Security >> Packet Filter >> Advanced. In this case, a network
connection that exists due to a previously permitted rule is not interrupted.
8.3.1
User Firewall Templates
All defined user firewall templates are listed here. A template can consist of several firewall rules. A template can be assigned to several users.
Defining a new template:
• In the template table, click on the Edit button to the right of the “(unnamed)” entry under
“Name”.
• If the “(unnamed)” entry cannot be seen, open another row in the table.
Editing a set of rules:
• Click on the Edit button to the right of the relevant entry.
Network Security >> User Firewall >> User Firewall Templates
Enabled Activates/deactivates the relevant template.
General
Name Name of the template. The name is specified when the template is created.
The following tab appears when you click on Edit:
I15020_en_03 Innominate Security Technologies
245
Network Security >> User Firewall >> User Firewall Templates [...]
Options A descriptive name for the template
The user firewall template can be freely named/renamed.
Enabled Yes / No
When set to Yes, the user firewall template becomes active as soon as firewall users log into the mGuard who are listed on the Template users tab (see below) and who have been assigned this template. It does not matter from which computer and under what IP address the user logs in. The assignment of the firewall rules to a user is based on the authentication data that the user enters during login (user name, password).
Comment
Timeout
Optional explanatory text.
Default: 8 hours.
Specifies the time at which point the firewall rules are deactivated. If the user session lasts longer than the timeout time specified here, the user has to log in again.
Timeout type
The entry can be in seconds [ss], minutes and seconds
[mm:ss] or hours, minutes, and seconds [h:mm:ss].
static / dynamic
With a static timeout, users are logged out automatically as soon as the set timeout time has elapsed. With dynamic timeout, users are logged out automatically after all the connections have been closed by the user or have expired on the mGuard, and the set timeout time has elapsed.
An mGuard connection is considered to have expired if no more data is sent for this connection over the following periods.
Connection expiration period after non-usage
– TCP
5 days (this value can be set, see “Timeout for established TCP
– UDP
– ICMP
– Others
VPN connection the connection. (These 120 seconds also apply to connections closed by the user.)
30 seconds data traffic in both directions
30 seconds
Specifies the VPN connection for which this user firewall rule is valid.
This requires existing remote access through the VPN tunnel to the web interface.
246
Innominate Security Technologies I15020_en_03
Network Security menu
Network Security >> User Firewall >> User Firewall Templates >> Edit > ...
Template users
Specify the names of the users here. The names must correspond to those that have been
Firewall rules
I15020_en_03
Source IP
Protocol
From Port/To Port
To IP
Comment
IP address from which connections are allowed to be established. If this should be the address from which the user logged into the mGuard, the placeholder “%authorized_ip” should be used.
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 contains further subsequent rules that could also apply, these rules are ignored.
All means TCP, UDP, ICMP, GRE, and other IP protocols.
(only evaluated for TCP and UDP protocols)
– any refers to any port.
– startport:endport (e.g., 110:120) > 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
0.0.0.0/0 means all IP addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
Freely selectable comment for this rule.
Innominate Security Technologies
247
Network Security >> User Firewall >> User Firewall Templates >> Edit > ... [...]
Log For each firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
248
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
9 CIFS Integrity Monitoring menu
CIFS Integrity Checking
CIFS Antivirus Scan Connector
In Stealth network mode, CIFS integrity checking is not possible without a management
IP address and the CIFS server for the anti-virus scan is not supported.
There are two options for checking network drives for viruses using CIFS integrity monitoring.
– CIFS Integrity Checking
– CIFS Antivirus Scan Connector
When CIFS Integrity Checking is performed, the Windows network drives are checked to determine whether certain files (e.g., *.exe, *.dll) have been changed. Changes to these files indicate a possible virus or unauthorized intervention.
The CIFS Antivirus Scan Connector enables the mGuard to perform a virus scan on rors a drive externally in order to perform the virus scan. Additional anti-virus software is required for this procedure. Set the necessary read access for your anti-virus software.
Setting options for CIFS Integrity Checking
–
Which network drives are known to the mGuard (see “CIFS Integrity Monitoring >> Im-
–
What type of access is permitted (see “CIFS Integrity Monitoring >> CIFS Integrity
–
At what intervals the drives should be checked (see “CIFS Integrity Monitoring >> CIFS
–
Which file types should be checked (see “CIFS Integrity Monitoring >> CIFS Integrity
– Warning method when a change is detected (e.g.,
itoring >> CIFS Integrity Checking >> Settings” on page 253 or via SNMP, see “CIFS
Setting options for the CIFS Antivirus Scan Connector
–
Which network drives are known to the mGuard (see “CIFS Integrity Monitoring >> Im-
–
What type of access is permitted (read or read/write access, see “CIFS Integrity Moni-
Innominate Security Technologies
249
I15020_en_03
Requirements:
9.1
CIFS Integrity Monitoring >> Importable Shares
The network drives that the mGuard should check regularly can be specified here.
In order for the network drives to be checked, you must also refer to these network drives in one of the two methods (CIFS Integrity Checking or CIFS Antivirus Scan Connector).
The references to the network drives can be set as follows:
–
For CIFS Integrity Checking, see “Checked CIFS Share” on page
–
For CIFS Antivirus Scan Connector, see “CIFS Antivirus Scan Connector” on page
9.1.1
Importable Shares
CIFS Integrity Monitoring >> Importable Shares
Importable CIFS Shares Name
Server
Share
Name of the network drive to be checked (internal name used in the configuration).
IP address or DNS host name of the authorizing server.
Name of the network drive made available by the authorizing server.
Click on the Edit button to make the settings.
250
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> Importable Shares >> Edit
Identification for Reference Name Name of the network drive to be checked (internal name used in the configuration).
Location of the Importable
Share
IP address of the server
IP address of the server whose network drive is to be checked.
Authentication for mounting the Share
Imported share's name
Domain/Workgroup
Directory on the above authorized server that is to be checked.
Name of the workgroup to which the network drive belongs.
NetBIOS name for Windows 95/98 computers.
NetBIOS name (Windows 95/98 only)
Login
Password
Login for the server.
Password for login.
I15020_en_03 Innominate Security Technologies
251
Integrity database
9.2
CIFS Integrity Monitoring >> CIFS Integrity Checking
When CIFS Integrity Checking is performed, the Windows network drives are checked to determine whether certain files (e.g., *.exe, *.dll) have been changed. Changes to these files indicate a possible virus or unauthorized intervention.
If a network drive that is to be checked is reconfigured, an integrity database must be created.
This integrity database is used as the basis for comparison when checking the network drive regularly. The checksums of all files to be monitored are recorded here. The integrity database is protected against manipulation.
The database is either created explicitly due to a specific reason (see CIFS Integrity Moni-
toring >> CIFS Integrity Checking >> Settings >> Edit >> Management, Possible Actions) or
on the first regular check of the drive.
The integrity database must be created again following intentional manipulation of the relevant files of the network drive. Unauthorized manipulation of the relevant files cannot be detected if there is no (valid) integrity database.
252
Innominate Security Technologies I15020_en_03
9.2.1
Settings
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings
General Integrity certificate
(Used to sign integrity databases)
Used to sign and check the integrity database so that it cannot be replaced or manipulated by an intruder without being detected.
For information about certificates, please refer to “Machine
Send notifications via e-mail
After every check: an e-mail is sent to the address specified below after every check.
No: an e-mail is not sent to the address specified below.
Just in case of a failure or difference: an e-mail is sent to the address specified below if a deviation is detected during
CIFS Integrity Checking or if the check could not be carried out due to an access error.
Target address for email notifications
Subject prefix for email notifications
An e-mail is sent to this address either after every check or only if a deviation is detected during CIFS Integrity Checking or if the check could not be carried out due to an access error.
Text entered in the subject field of the e-mail.
I15020_en_03 Innominate Security Technologies
253
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings [...]
Checking of Shares State – No check is currently being performed
– The share check has been suspended
– A drive check is currently in progress
– An integrity database is currently being created
– The share has not yet been checked. Probably no integrity database exists.
– Last check finished successfully
– The process failed due to an unforeseen condition, please consult the logs
– Last check was aborted due to timeout.
– The integrity database is missing or incomplete.
– The signature of the integrity database is invalid.
– The integrity database was created with a different hash algorithm.
– The integrity database is the wrong version.
– The share which is to be checked is not available.
– The share which is to be used as checksum memory is not available.
– A file could not be read due to an I/O failure. Please consult the report.
– The directory tree could not be traversed due to an I/O failure. Please consult the report.
– The signature has not yet been checked
– The signature is valid
Enabled No: a check is not triggered for this network drive. The mGuard has not connected this drive. The status cannot be viewed.
Action
Checked CIFS Share
Checksum Memory
Yes: a check is triggered regularly for this network drive.
Suspended: the check has been suspended until further notice. The status can be viewed.
Name of the network drive to be checked (specified under
CIFS Integrity Monitoring >> Importable Shares >> Edit).
In order to perform the check, the mGuard must be provided with a network drive for storing the files.
The checksum memory can be accessed via the external network interface.
Click on the Edit button to make further settings for checking network drives.
254
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Checked Share
Settings Enabled No: a check is not triggered for this network drive. The mGuard has not connected this drive. The status cannot be viewed.
Yes: a check is triggered regularly for this network drive.
Suspended: the check has been suspended until further notice. The status can be viewed.
Checked CIFS Share Name of the network drive to be checked (specified under
CIFS Integrity Monitoring >> Importable Shares >> Edit).
Patterns for filenames Specific file types are checked (e.g., only executable files such as *.exe and *.dll).
The rules can be defined under CIFS Integrity Monitoring >>
CIFS Integrity Checking >> Filename Patterns.
Do not check files that are changed in normal operation, as this could trigger false alarms.
Do not check files that are simultaneously opened
exclusively by other programs, as this can lead to access conflicts.
I15020_en_03 Innominate Security Technologies
255
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Checked Share [...]
Time Schedule Every Sunday, Every Monday, Every Tuesday, ... , Every day,
Several times a day, Continuous
You can start the check every day, several times a day or on a specific weekday.
The mGuard system time must be set for the time schedule to work properly.
Integrity checks are not performed if the system time is not synchronized.
This can be carried out manually or via NTP (see
A check is only started if the mGuard is operating at the set time. If it is not operating at the time, a check is not performed later when the mGuard is started up again.
Checksum Memory
Starting at
Time at which the check starts (hour, minute).
Maximum time a check may take h
Maximum duration of the check sequence in minutes.
You can therefore ensure that the check is completed in good time (e.g., before a shift starts).
Checksum Algorithm SHA-1
MD5
SHA-256
Checksum algorithms such as MD5, SHA-1 or SHA-256 are used to check whether a file has been changed.
SHA-256 is more secure than SHA-1, but it takes longer to process.
256
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Checked Share [...]
To be stored on CIFS share
In order to perform the check, the mGuard must be provided with a network drive for storing the files.
The checksum memory can be accessed via the external network interface.
The same network drive can be used as the checksum memory for several different drives to be checked. The base name of the checksum files must then be clearly selected in this case.
The mGuard recognizes which version the checksum files on the network drive must have.
Basename of the checksum files (May be prefixed with a directory.)
For example, if it is necessary to restore the contents of the network drive from a backup following a malfunction, old checksum files are provided in this case and the mGuard would detect the deviations. In this case, the integrity data-
base must be recreated (see CIFS Integrity Monitoring >>
CIFS Integrity Checking >> Settings >> Edit >> Management,
The checksum files are stored on the network drive specified above. They can also be stored in a separate directory. The directory name must not start with a backslash (\).
Example: Checksumdirectory\integrity-checksum
“Checksumdirectory” is the directory and contains the files beginning with “integrity-checksum”.
I15020_en_03 Innominate Security Technologies
257
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Management
Last Check Summary Last check was OK: no deviations found.
Deviations detected during the last check: x
The exact deviations are listed in the check report.
The process failed due to an unforeseen condition, please consult the log entries.
Report
UNC notation of the imported share
The check report is displayed here. It can be downloaded by clicking on the “Download the report” button.
The report is stored on the checked network drive as a log file with the file name “integrity-check-log.txt”. On every check, the results of the new check are added to the log file. When the file size reaches 32 MB, the file is renamed “integrity-checklog.txt.1” (backup file). A new log file (“integrity-check-log.txt”) containing the results of the current check is created. When it renamed log.txt.1” and the existing “integrity-check-log.txt.1” file is irrevocably overwritten. The integrity of the log files is ensured by creating checksums.
Click on the “Validate the report” button to check whether the report is unchanged from the definition in the mGuard (according to the signature and certificate).
\\Servername\networkdrive\
258
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Management [...]
Start of the last check Weekday, month, day, HH:MM:SS (UTC).
The local time may differ from this time.
Duration of the last check
Example: the standard time in Germany is Central European
Time (CET), which is UTC plus one hour. Central European
Summer Time applies in summer, which is UTC plus two hours.
Duration of the check in hours and minutes.
(Only displayed if a check has been carried out.)
(Only displayed if a check has been carried out.) Start of the current check
Progress of the current check
(Only displayed if a check is currently active.)
Current check
Possible Actions
Status
Starting at
Progress
Number of detected deviations
Status of the integrity check
Start time
Progress as a percentage and the number of checked files
Number of differences detected
Estimated completion time
Estimated completion time for the check
Start an integrity check right now
Before an integrity check is performed, an integrity database should be created first.
If an integrity database is not available, an integrity database will be created instead of performing the check. This procedure cannot be seen.
Before an integrity check is started, an access check should be performed first. The absence of the proper access permissions can therefore be detected at an early stage.
Please note that the integrity check and the ac-
cess check create the same integrity database or overwrite the existing one.
Click on the Start a check button to start the integrity check.
The result of the check can be viewed in the test report by clicking on the “Downloaded the report” button.
Only displayed if a check is not currently active.
I15020_en_03 Innominate Security Technologies
259
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Settings >> Edit >> Management [...]
Start an access check Click on the “Start an access check” button to check whether there are files present on the imported network drive that the mGuard cannot access.
Please note that the integrity check and the ac-
cess check create the same integrity database or overwrite the existing one.
(Re-)Build the integrity database
The result of the check can be viewed in the test report by clicking on the “Downloaded the report” button.
Before generating an integrity database, an access check should be performed first. The absence of the proper access permissions can therefore be detected at an early stage.
Please note that the integrity check and the ac-
cess check create the same integrity database or overwrite the existing one.
The mGuard creates a database with checksums in order to check whether files have been changed. A change to executable files indicates a virus.
However, if these files have been changed intentionally, a new database must be created by clicking on the Initialize button in order to prevent false alarms.
The creation of an integrity database is also recommended if network drives have been newly set up. Otherwise, an integrity database is set up during the first scheduled check instead of a check being performed.
Click on the Cancel button to stop the integrity check.
Cancel the current operation
Erase reports and the integrity database
Click on the Erase button to delete all existing reports/databases.
A new integrity database must be created for any further integrity checks. This can be initiated by clicking on the Initialize button. Otherwise, a new integrity database is created automatically on the next scheduled check. This procedure cannot be seen.
260
Innominate Security Technologies I15020_en_03
9.2.2
Filename Patterns
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Filename Patterns
Sets of Filename Patterns Name Freely definable name for a set of rules for the files to be checked.
This name must be selected under CIFS Integrity Monitor-
ing >> CIFS Integrity Checking >> Settings >> Edit in order for the pattern to be activated.
Click on the Edit button to define a set of rules for the files to be checked and save this under the defined name.
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Set of Filename Patterns >> Edit
Rules for files to check Filename pattern The following rules apply:
**\*.exe means that the files located in a specific directory and with file extension *.exe are checked (or excluded).
Only one placeholder (*) is permitted per directory or file name.
Placeholders represent characters, e.g., win*\*.exe returns files with the extension *.exe that are located in a directory that begins with win...
** at the start means that any directory is searched, even those at the top level (if this is empty). This cannot be combined with other characters (e.g., c** is not permitted).
Example: Name\**\*.exe refers to all files with the extension
*.exe that are located in the “Name” directory and any subdirectories.
I15020_en_03 Innominate Security Technologies
261
CIFS Integrity Monitoring >> CIFS Integrity Checking >> Set of Filename Patterns >> Edit [...]
Missing files trigger an alarm. Missing files are files that were present during initialization.
An alarm is also triggered if additional files are present.
Include in check Include: the files are included in the check.
(Each file name is compared with the patterns in sequence.
The first hit determines whether the file is to be included in the integrity check. The file is not included if no hits are found.)
Exclude: the files are excluded from the check.
262
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
9.3
CIFS Integrity Monitoring >> CIFS AV Scan Connector
The CIFS server for the anti-virus scan is not supported in Stealth network mode without a management IP address.
CIFS Antivirus Scan Connector
The CIFS Antivirus Scan Connector enables the mGuard to perform a virus scan on rors a drive externally in order to perform the virus scan. Additional anti-virus software is required for this procedure. Set the necessary read access for your anti-virus software.
9.3.1
CIFS Antivirus Scan Connector
CIFS Integrity Monitoring >> CIFS AV Scan Connector
CIFS Server Enable the server No: CIFS server is not available
Yes: CIFS server is available
I15020_en_03 Innominate Security Technologies
263
CIFS Integrity Monitoring >> CIFS AV Scan Connector [...]
Accessible as External / Internal / DMZ
Displays the virtual network drive provided by the mGuard for the CIFS Antivirus Scan Connector function.
This path is displayed in UNC notation. By means of copy and paste, it can be directly used on the PC that is to use the virtual
network drive (see “Accessing the virtual network (CIFS Anti-
Three UNC addresses (for the internal and external interface and DMZ) are displayed in “Router” network mode, while one
UNC address is displayed in “Stealth” network mode.
Access to the virtual network drive can be prevented as a re-
sult of the settings in the “Allowed Networks” section. Enter a
rule here accordingly, especially if access via the external interface is required.
Depending on the mGuard configuration, further access options can be established via other IP addresses, such as access via VPN tunnels or via incoming calls (for dial-in, see
Allowed Networks
Server's workgroup
Login
Password
Exported share's name
Name of the CIFS server workgroup.
Login for the server.
Password for login.
Name for the computers that are to use the CIFS server to access the consolidated drives (the drives are connected under this name).
Allow write access No: read-only access
Yes: read and write access
These rules allow external access to the CIFS server of the mGuard.
In Router mode with NAT or port forwarding, the port numbers for the CIFS server have priority over the rules for port forwarding (port forwarding is set
From IP
Access to the CIFS server is approved internally via incoming calls (dial-in) and VPN as standard, and can be restricted or expanded via the firewall rules.
A different default setting can also be defined using these rules.
Enter the address of the computer/network from which remote access is permitted or forbidden in this field.
IP address: 0.0.0.0/0 means all addresses. To specify an ad-
dress area, use CIDR format (see “CIDR (Classless Inter-Do-
264
Innominate Security Technologies I15020_en_03
CIFS Integrity Monitoring menu
CIFS Integrity Monitoring >> CIFS AV Scan Connector [...]
Interface Internal / External / External 2 / DMZ / VPN / GRE / Dial-in
1
Specifies to which interface the rule should apply.
If no rules are set or if no rule applies, the following default settings apply:
– Remote access is permitted via Internal, VPN, DMZ, and
Dial-in.
– Access via External, External 2, and GRE is denied.
Specify the access options according to your requirements.
If you want to deny access via Internal, VPN, DMZ or Dial-in, you must implement this explicitly by means of corresponding firewall rules, for example, by specifying Drop as the action.
Consolidated Imported
Shares
Action
Comment
Log
Enabled
CIFS Share
Exported in Subdirectory
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.
Freely selectable comment for this rule.
For each individual rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
No: this network drive is not mirrored.
Yes: this network drive is mirrored and made available.
Name of the network drive to be imported (created under CIFS
Integrity Monitoring >> Importable Shares >> Edit).
The content of the included drive is located in this directory.
1
I15020_en_03 Innominate Security Technologies
265
Accessing the virtual network (CIFS Antivirus Scan Connector)
The virtual network drive provided by the mGuard for the CIFS Antivirus Scan Connector can be integrated in Windows Explorer. To do this, open the “Tools, Map Network Drive...” menu in Windows Explorer and enter the path using UNC notation.
This path is displayed under “CIFS Integrity Monitoring >> CIFS AV Scan Connector >> Accessible as”.
\\<External IP of mGuard>\<Name of the exported share>
\\<Internal IP of mGuard>\<Name of the exported share>
Example
\\10.1.66.49\exported-av-share
\\192.168.66.49\exported-av-share
Alternatively, you can enter the “net use” command in the command line. For more detailed information, please refer to the Microsoft product information.
Notes
– A DNS name can also be used instead of the IP address.
– The authorized network drive cannot be found using the browse or search function.
– The “Exported share's name” must always be added.
– Windows does not automatically display the authorized network drive upon connection of the mGuard.
266
Innominate Security Technologies I15020_en_03
10 IPsec VPN menu
10.1
IPsec VPN >> Global
10.1.1
Options
IPsec VPN menu
IPsec VPN >> Global >> Options
Options Allow packet forwarding between VPN connections
This option should only be set to Yes on an mGuard communicating between two different
VPN partners.
To enable communication between two VPN partners, the local network of the communicating mGuard must be configured so that the remote networks containing the VPN partners are included. The opposite setup (local and remote network swapped round) must also be implemented
for the VPN partners (see “Type: Tunnel, Remote”
Yes is not supported in Stealth network mode.
I15020_en_03 Innominate Security Technologies
267
IPsec VPN >> Global >> Options [...]
No (default): VPN connections exist separately.
Yes: “hub and spoke” feature enabled: a control center diverts
VPN connections to several branches that can also communicate with each other.
The setting is also valid for OpenVPN and GRE connections.
With a star VPN connection topology, mGuard partners can also exchange data with one another. In this case, it is recommended that the local mGuard consults CA certificates for the
Archive diagnostic messages for VPN connections:
The CMD contact is only available on the
In the event of “hub and spoke”, 1:1 NAT of the partner is not supported.
No / Only when started via nph-vpn.cgi, CMD input or
“Start” button on the web interface
No (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. Set this option to No if it is sufficient.
Only when started via nph-vpn.cgi, CMD input or “Start” button on the web interface:
If the option of diagnosing VPN connection problems using the mGuard logging function is too impractical or insufficient, select this option. This may be the case if the following conditions apply:
– In certain application environments, e.g., the mGuard is “operated” by means of a machine controller 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 temporarily disconnected from its power source – which causes all the log entries to be deleted.
268
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Global >> Options [...]
Archive diagnostic messages only upon failure: Yes / No
– The relevant log entries of the mGuard that could be useful may be deleted because the mGuard regularly deletes older log entries on account of its limited memory capacity.
– If an mGuard is being used as the central VPN partner, e.g., in a remote maintenance center as the gateway for the VPN connections of numerous machines, the messages 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 operations 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 the “Start” button on the web interface
– Via the CGI interface nph-vpn.cgi using the “synup” command (see application note: “How to use the CGI Interface”). (Application notes are available in the download area at www.innominate.com
.)
– Archived log entries are not affected by a restart. They
can be downloaded as part of the support snapshot (Sup-
port >> Advanced menu item, Snapshot tab). A snapshot
provides your dealer's support team with additional options for more efficient troubleshooting than would be possible without archiving.
Only visible if archiving is enabled. If only log entries generated for failed connection attempts are to be archived, set this option to Yes. If set to No, all log entries will be archived.
I15020_en_03 Innominate Security Technologies
269
TCP Encapsulation
This function is used to encapsulate data packets to be transmitted via a VPN connection in
TCP packets. Without this encapsulation, under certain circumstances it is possible for VPN connections that important data packets belonging to the VPN connection may not be correctly transmitted due to interconnected NAT routers, firewalls or proxy servers, for example.
Firewalls, for example, may be set up to prevent any data packets of the UDP protocol from passing through or (incorrectly implemented) NAT routers may not manage the port numbers correctly for UDP packets.
TCP encapsulation avoids these problems because the packets belonging to the relevant
VPN connection are encapsulated in TCP packets, i.e., they are hidden so that only TCP packets appear for the network infrastructure.
The mGuard may receive VPN connections encapsulated in TCP, even when it is positioned behind a NAT gateway in the network and thus cannot be reached by the VPN partner under its primary external IP address. To do this, the NAT gateway must forward the cor-
responding TCP port to the mGuard (see “Listen for incoming VPN connections, which are
TCP encapsulation can only be used if an mGuard (Version 6.1 or later) is used at both ends of the VPN tunnel.
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.
For the TCP encapsulation to work through an HTTP proxy (without the “Path Finder”
function), the proxy must be named explicitly in the proxy settings (Network >> Proxy Set-
tings menu item) (i.e., it must not be a transparent proxy) and this proxy must also under-
stand and permit the HTTP method CONNECT.
VPN Client, the function must be enabled on both sides of the connection (server and client).
TCP encapsulation does not work in conjunction with authentication via pre-shared key
(PSK).
270
Innominate Security Technologies I15020_en_03
IPsec VPN menu
TCP encapsulation with enabled “Path Finder” function
(Only when used with mGuard Secure VPN Client.)
TCP encapsulation with enabled “Path Finder” function improves the behavior of the standard TCP encapsulation described above. If a VPN connection is started by the mGuard Secure VPN Client, which is positioned behind a proxy server or a firewall, the
“Path Finder” function must be enabled in the mGuard Secure VPN Client as well as in the mGuard (server). The data packets to be transmitted via the VPN connection are encapsu-
As devices in the TCP encapsulation, the mGuard devices for the machine controllers initiate VPN data traffic to the maintenance center and encapsulate the data packets sent to it.
As soon as a connection is initiated, the maintenance center also automatically encapsulates the data packets sent to the relevant VPN partner.
initiated by mGuard
devices on the machine control
-
VPN connections
Maintenance
Machine controller 1
Machine controller 2
Machine controller 3
Maintenance center mGuard
Required basic settings
– IPsec VPN menu item, Global, Options tab:
Listen for incoming VPN connections, which are encapsulated: Yes
– Connections submenu,
General tab:
Address of the remote site's VPN gateway: %any
Connection startup: Wait mGuard devices on machine controllers
Required basic settings
– IPsec VPN menu item, Global, Options tab:
Listen for incoming VPN connections, which are encapsulated: No
– Connections submenu, General tab:
Address of the remote site's VPN gateway: fixed
IP address or host name
Connection startup: Initiate or Initiate on traffic
Encapsulate the VPN traffic in TCP: Yes
Figure 10-1 TCP encapsulation in an application scenario with a maintenance center and machines maintained remotely via VPN connections
I15020_en_03 Innominate Security Technologies
271
IPsec VPN >> Global >> Options
TCP Encapsulation Listen for incoming
VPN connections, which are encapsulated
Default setting: No. Only set this option to Yes if the TCP Encapsulation function is used. Only then can the mGuard allow connection establishment with encapsulated packets.
For technical reasons, the RAM requirements increase with each interface that is used to listen out for VPN connections encapsulated in TCP. If multiple interfaces need to be used for listening, then the device must have at least 64 Mbytes of RAM.
TCP port to listen on
Server ID (0-63)
The interfaces to be used for listening are determined by the mGuard according to the settings on the active VPN connections that have “%any” configured as the partner. The decisive setting is specified under “Interface to use for gateway setting
%any”.
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 partner as the TCP port of the server, which accepts the encapsu-
lated connection (IPsec VPN >> Connections menu item,
Edit, General tab).
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 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 Default setting: No
VPN
Only set this option to Yes if the mGuard should accept a VPN
Client connection from an mGuard Secure VPN Client that is positioned behind a proxy server or a firewall.
The “Path Finder” function must also be enabled in the mGuard Secure VPN Client.
272
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Global >> Options [...]
TCP port to listen on 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 partner as the TCP port of
the server, which accepts the encapsulated connection.
IP Fragmentation IKE Fragmentation 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).
UDP packets can be oversized if an IPsec connection is established between the participating devices via IKE and certificates are exchanged. Some routers are not capable of forwarding large UDP packets if they are fragmented over the transmission path (e.g.,
Some faulty devices forward the first fragment only, resulting in connection failure.
If two mGuard devices communicate with each other, it is possible to ensure at the outset that only small UDP packets are to be transmitted. This prevents packets from being fragmented during transmission, which can result in incorrect routing by some routers.
If you want to use this option, set it to Yes.
If this option is set to Yes, the setting only takes effect if the partner is an mGuard with firmware Version 5.1.0 or later installed. In all other cases, the setting has no effect, negative or otherwise.
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.
I15020_en_03 Innominate Security Technologies
273
10.1.2
DynDNS Monitoring
IPsec VPN >> Global >> Options
DynDNS Monitoring Watch hostnames of remote VPN Gateways?
Yes / No
If the mGuard has the address of a VPN partner in the form of
with a DynDNS service, then the mGuard can check the relevant DynDNS at regular intervals to determine whether any changes have occurred. If so, the VPN connection will be established to the new IP address.
Refresh Interval (sec) Default: 300
274
Innominate Security Technologies I15020_en_03
Requirements for a VPN connection
IPsec VPN menu
10.2
IPsec VPN >> Connections
A general requirement for a VPN connection is that the IP addresses of the VPN partners are known and can be accessed.
– mGuard devices provided in stealth network mode are preset to the “multiple clients” you can select a different stealth configuration than the “multiple clients” configuration or use another network mode.
– In order to successfully establish an IPsec connection, the VPN partner must support
IPsec with the following configuration:
– Authentication via pre-shared key (PSK) or X.509 certificates
– ESP
– Diffie-Hellman group 2 or 5
– DES, 3DES or AES encryption
– MD5, SHA-1 or SHA-2 hash algorithms
– Tunnel or transport mode
– Quick mode
– Main mode
– SA lifetime (1 second to 24 hours)
If the partner is a computer running Windows 2000, the Microsoft Windows 2000 High
Encryption Pack or at least Service Pack 2 must be installed.
– If the partner is positioned downstream of a NAT router, the partner must support NAT-
T. Alternatively, the NAT router must know the IPsec protocol (IPsec/VPN passthrough). For technical reasons, only IPsec tunnel connections are supported in both cases.
– Authentication using “Pre Shared Key” in Aggressive mode is not supported when using “XAuth”/“Mode Config”. For example, if a connection is to be established to the mGuard server by the iOS client, a certificate must be used for authentication.
I15020_en_03 Innominate Security Technologies
275
10.2.1
Connections
Lists all the VPN connections that have been defined.
Each connection name listed here can refer to an individual VPN connection or a group of
VPN connection tunnels. You have the option of defining several tunnels under the transport and/or tunnel settings of the relevant entry.
You also have the option of defining new VPN connections, activating and deactivating VPN connections, changing (editing) the VPN connection or connection group properties, and deleting connections.
IPsec VPN >> Connections
License status Licensed peers
Used by IPsec
Used by OpenVPN
Remaining
Number of partners to which a VPN connection can be established simultaneously based on the VPN licenses currently installed.
Partners that currently have a VPN connection established using the IPsec protocol.
Partners that currently have a VPN connection established using the OpenVPN protocol.
Number of remaining partners to which another VPN connection can be established based on the VPN licenses currently installed and depending on the existing VPN connections.
Defining a new VPN connection/VPN connection tunnel
• In the connections table, click on the Edit button to the right of the “(unnamed)” entry under “Name”.
• If the “(unnamed)” entry cannot be seen, open another row in the table.
Editing a VPN connection/VPN connection tunnel
• Click on the Edit button to the right of the relevant entry.
URL for starting, stopping, querying the status of a VPN connection
The following URL can be used to start and stop VPN connections that are in “Started” or
“Stopped” initial mode or to query their connection status:
276
Innominate Security Technologies I15020_en_03
Example
IPsec VPN menu https://server/nph-vpn.cgi?name=verbindung&cmd=(up|down|status) wget --no-check-certificate "https://admin:[email protected]/nph-vpn.cgi?name=Athen&cmd=up"
The --no-check-certificate option ensures that the HTTPS certificate on the mGuard does not undergo any further checking.
It may also be necessary to encode the password for the URL if it contains special characters.
A command like this relates to all connection tunnels that are grouped together under the
respective name (in this example, Athen). This is the name that is listed under IPsec VPN
>> Connections >> Edit >> General as “A descriptive name for the connection” . In the event
of ambiguity, the URL call only affects the first entry in the list of connections.
It is not possible to communicate with the individual tunnels of a VPN connection. If individual tunnels are deactivated, they are not started. Starting and stopping in this way therefore
If the status of a VPN connection is queried using the URL specified above, then the following responses can be expected:
Table 10-1 Status of a VPN connection
Answer Meaning 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 partner could not be resolved in an IP address (DNS).
ready active
The response “void” is also issued by the CGI interface, even if no error occurred. 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.
The connection is ready to establish tunnels or allow incoming queries regarding tunnel setup.
At least one tunnel has already been established for the connection.
Defining a VPN connection/VPN connection tunnel
Depending on the network mode of the mGuard, the following page appears after clicking on Edit.
I15020_en_03 Innominate Security Technologies
277
10.2.2
General
IPsec VPN >> Connections >> Edit >> General
Options A descriptive name for the connection
The connection can be freely named/renamed. If several con-
nection tunnels are defined under Transport and Tunnel
Settings (“More...” button), 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-
Initial Mode
– Same firewall settings
– Same IKE options set
Disabled / Stopped / Started
The “Disabled” setting deactivates the VPN connection permanently; 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).
Regardless of the initial mode, the VPN connections can be started or stopped via a button 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 partners or partners downstream of a NAT router)
278
Innominate Security Technologies I15020_en_03
I15020_en_03
IPsec VPN menu
Address of the remote site's VPN gateway
Internet
Figure 10-2
VPN gateway of the partner
The address of the transition to the private network where the remote communication partner is located.
– If the mGuard should actively initiate and establish the connection to the remote partner, specify the IP address or host name of the partner here.
– If the VPN gateway of the partner does not have a fixed and known IP address, the
DynDNS service (see glossary) can be used to simulate a fixed and known address.
– If the mGuard should be ready to allow a connection to the local mGuard that was actively initiated and established by a remote partner with any IP address, specify %any.
This setting should also be selected for a VPN star configuration if the mGuard is connected to the control center.
The mGuard can then be “called” by a remote partner if this partner has been dynamithat changes. In this scenario, you may only specify an IP address if the remote “calling” partner also has a fixed and known IP address.
%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 partner, 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 298) must be specified.
%any must be selected if the partner 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 270): a fixed IP ad-
dress or a host name must be specified if this mGuard is to initiate the VPN connection and encapsulate 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 partner.
Innominate Security Technologies
279
IPsec VPN >> Connections >> Edit >> General
Options Interface to use for gateway setting %any
Internal, External, External 2, Dial-in, DMZ, Implicitly selected by the IP address specified to the right
External 2 and Dial-in are only for devices with a serial inter-
Selection of the Internal option is not permitted in Stealth mode.
This interface setting is only considered when “%any” is entered 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 connection 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 partners without a known IP address. If an IP address or host name is entered for the partner, then this is used for the implicit assignment to an interface.
The mGuard can be used as a “single-leg router” in Router mode when Internal is selected, as both encrypted and decrypted 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 applies to VPN connections with a specific partner.
DMZ can only be selected in Router mode. Here, VPN connections can be established to hosts in the DMZ and IP packets can be routed from the DMZ in a VPN connection.
Implicitly selected by the IP address specified to the
right: an IP address is used instead of a dedicated interface.
280
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
Connection startup Initiate / Initiate on traffic / Wait
Initiate
The mGuard initiates the connection to the partner. The fixed
IP address of the partner or its name must be entered in the
Address 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.))
If one partner is initiated on data traffic, Wait or
Initiate must be selected for the other partner.
Wait
The mGuard is ready to allow the connection to the mGuard that a remote partner actively initiates and establishes.
If %any is entered under Address of the remote
site's VPN gateway, Wait must be selected.
Controlling service input
None / Service input CMD 1-3
The VPN connection can be switched via a connected pushbutton/switch.
The pushbutton/switch must be connected to one of the ser-
If starting and stopping the VPN connection via the CMD contact is enabled, only the CMD contact is authorized to do this.
However, if a pushbutton is connected to the CMD contact (instead of a switch – see below), the connection can also be established and released using the CGI script command nph-vpn.cgi or via a text message, which has the same rights.
If a VPN connection is controlled via a VPN switch, then VPN redundancy cannot be activated.
I15020_en_03 Innominate Security Technologies
281
IPsec VPN >> Connections >> Edit >> General [...]
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 and deactivate another.
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 traffic.
The VPN connection is established again when data traffic resumes.
Time in hours, minutes and/or seconds (0: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
[h:mm:ss].
0 means the setting is disabled.
Token for text message trigger
Incoming text messages can be used to start or stop VPN connections. The text message must contain the “vpn/start” or
“vpn/stop” command followed by the token.
282
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
Encapsulate the VPN traffic in TCP
No / TCP Encapsulation / Path Finder (default: No)
tion if the mGuard is to encapsulate its own outgoing data traffic for the VPN connection it initiated. In this case, the number of the port where the partner receives the encapsulated data packets must also be specified.
TPC Encapsulation can also be used with the “Path Finder”
Path Finder if the partner also supports the “Path Finder” function. The number of the port where the partner receives the encapsulated data packets must then also be specified.
The “Path Finder” function can only be used to establish a VPN connection by the mGuard as the client if the HTTP(S) proxy has been configured without proxy authentication.
When TCP Encapsulation/Path Finder is selected, the mGuard will not attempt to establish the VPN connection using standard IKE encryption (UDP port 500 and 4500). Instead, the connection is always encapsulated using TCP.
Connection startup setting when using TCP Encapsulation/Path Finder
– If the mGuard is to establish a VPN connection to a maintenance 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 connection
(Only visible if “Encapsulate the
VPN traffic in TCP” is set to TCP
Encapsulation or Path
Finder.)
Default: 8080 (TCP Encapsulation) or 443 (Path Finder)
Number of the port where the encapsulated data packets are received by the partner. The port number specified here must be the same as the one specified for the mGuard of the partner
under TCP port to listen on (IPsec VPN >> Global >> Options
menu item).
Mode Configuration The mGuard supports the “Extended Authentication” (XAuth) authentication mode and the frequently required “Mode Config” protocol extension, including split tunneling as server and as client (e.g., iOS support). Network settings and DNS and WINS configurations are communicated to the IPsec client by the IPsec server.
I15020_en_03 Innominate Security Technologies
283
IPsec VPN >> Connections >> Edit >> General [...]
Mode Configuration Off / Server / Client (default: Off)
In order to communicate via an IPsec VPN connection as the server or client with partners that require “XAuth” and “Mode
Config”, select “Server” or “Client”.
Off: do not use “Mode Config”.
Server: communicate the IPsec network configuration to the partner.
Client: accept and apply the IPsec network configuration communicated by the partner.
“Mode Config” cannot be used in conjunction with
“VPN redundancy” (“VPN redundancy” on page 387) or in “VPN Aggressive Mode” (“Aggres-
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.
If a connection is to be established to the mGuard server by the iOS client, a
X.509 certificate must be used for authentication.
The Machine Certificate of the mGuard, installed on the iOS client, must use the external server IP address or DNS name of the mGuard as the common
name (CN) of the certificate (see “Authentication >> Certificates” ).
284
Innominate Security Technologies
(Local) IP Networks 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 tunneling extension.
Entry in CIDR format (see “CIDR (Classless Inter-Domain
I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
(Remote) IP Networks From pool / From table below
From pool: the server dynamically selects remote IP networks from the specified pool according to the selected tranche size.
From table below: (only for connections between two mGuard devices)
Enables entry of several remote networks in CIDR format (see
(Remote) DNS
(Remote) WINS
Address of the DNS server used to resolve host names in IP addresses via the Domain Name Service (DNS).
Address of the server used to resolve host names in addresses via the Windows Internet Naming Service (WINS).
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”. The mGuard receives the necessary values (IP address/IP network) for configuring the connection (local and remote network) from the remote server.
I15020_en_03
(Local) IP Networks No NAT / Masquerade (not active in Stealth modes “autodetect” and “static”)
The mGuard can masquerade its local network behind the received IP address. To do this, the local network must be spec-
ified in CIDR format (see “CIDR (Classless Inter-Domain Rout-
If the connection is not masqueraded (no NAT), the local network must be manually entered in the remote server.
(Local) XAuth Login Some remote servers require an XAuth user name and an
XAuth password in order to authenticate the client.
Corresponding XAuth password (Local) XAuth Password
(Remote) IP Networks Fixed / From Server
Fixed: the remote network on the server side is manually set and fixed and must also be set manually on the client side (local client).
From Server: the remote network(s) on the server side is/are communicated to the local client using the split tunneling extension.
If the remote server does not use split tunneling, 0.0.0.0/0 is used.
Innominate Security Technologies
285
IPsec VPN >> Connections >> Edit >> General [...]
Transport and Tunnel Settings
Type: Tunnel
Type: Transport
Enabled
Comment
Type
Yes / No
Specify whether the connection tunnel should be active (Yes) or not (No).
Freely selectable comment text. Can be left empty.
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, transmitted to the VPN gateway of the partner – the “tunnel end”.
The transmitted datagrams are then decrypted and the original datagrams are restored. These are then forwarded to the destination computer.
If the default route (0.0.0.0/0) is entered as the remote partner, the rules specified under “Network
>> NAT >> IP and Port Forwarding” are given priority.
This ensures that incoming connections to the
WAN interface of the mGuard can continue using port forwarding. In this case, this data is not transmitted via VPN.
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.
286
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
Local / Remote - for
Tunnel connection type
(network ↔ network)
NAT settings (Tunnel type only)
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: here, specify the address of the network or computer which is located downstream of the remote VPN gateway.
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.
IPsec tunnel
Transport and Tunnel Settings (“More...” button)
Internet
Local
Network
VPN gateway
Remote
Network
Remote
Click on the “More...” button to make further settings. The “IPsec VPN >> Connections >>
Transport and Tunnel Settings >> General” window opens.
Displayed when
Tunnel type is selected
I15020_en_03 Innominate Security Technologies
287
IPsec VPN >> Connections >> Edit >> General [...]
Type: Tunnel, Local 1:1 NAT
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. It is not translated into an IP address that is identical for all devices (as is the case with Masquerade).
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 partner.
The data packets of local devices are assigned a source address according to the address set under Local and are transmitted via the VPN tunnel.
After clicking on the “More...” button, 1:1 NAT rules can be specified 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.
Type: Tunnel, Local, 1:1
NAT, “More...” button
288
Innominate Security Technologies
Real network
Virtual network
Netmask
Configures the “From IP” address for 1:1 NAT.
Configures the translated IP address for 1:1 NAT.
The subnet mask as a value between 1 and 32 for the real and
virtual network address (see also “CIDR (Classless Inter-Do-
I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
Comment Can be filled with appropriate comments.
Local 1:1 NAT networks must be specified in ascending order, beginning with the smallest network up to the largest network.
Type: Tunnel, Local Masquerade
Type: Tunnel,
Remote
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 Conntrack 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.
1:1 NAT
I15020_en_03 Innominate Security Technologies
289
IPsec VPN >> Connections >> Edit >> General [...]
Type: Tunnel,
Remote
With 1:1 NAT, the IP addresses of devices of the tunnel partner are exchanged so that each individual address is translated into another specific address. It is not translated into an
IP address that is identical for all devices (as is the case with
Masquerade).
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 defined here under Local.
The data packets are assigned a destination address from the network that is set under Remote. If necessary, the source address is also replaced (see Local). The data packets are then transmitted via the VPN tunnel.
Masquerade
Protocol Protocol
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 Conntrack 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.
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.
290
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> General [...]
Dynamic Routing Add kernel route to remote net to allow
OSPF route redistribution
(Only active if OSPF is activated)
If Yes is selected, the kernel route to the remote net will be added to allow OSPF route redistribution.
I15020_en_03 Innominate Security Technologies
291
Tunnel setting IPsec/L2TP
If clients should connect via the mGuard by IPsec/L2TP, activate the L2TP server and make the following entries in the fields specified below:
– Type: Transport
– Protocol: UDP
– Local: %all
– Remote: %all
–
PFS: No (“Perfect Forward Secrecy (PFS)” on page
Specifying a default route over the VPN
Address 0.0.0.0/0 specifies a default route over the VPN.
With this address, all data traffic where no other tunnel or route exists is routed through this
VPN tunnel.
A default route over the VPN should only be specified for a single tunnel.
In Stealth mode, a default route over the VPN cannot be used.
Option of tunnel groups
The new VPN license model allows tunnel groups to be created with all VPN licenses.
The license no longer limits the number of tunnels established, but instead the number of connected partners (VPN peers). If several tunnels are established to a partner, only one partner is counted, which is an improvement over the old model.
If Address of the remote site's VPN gateway is specified as %any, there may be many mGuard devices or many networks on the remote side.
A very large address area is then specified in the Remote field for the local mGuard. A part of this address area is used on the remote mGuard devices for the network specified for each of them under Local.
This is illustrated as follows: the entries in the Local and Remote fields for the local and remote mGuard devices could be made as follows:
Local mGuard
Local
10.0.0.0/8
Remote
10.0.0.0/8
Remote mGuard A
Local
> 10.1.7.0/24
Remote
10.0.0.0/8
Remote mGuard B
Local
> 10.3.9.0/24
Remote
10.0.0.0/8 etc.
In this way, by configuring a single tunnel, you can establish connections for a number of peers.
292
Innominate Security Technologies I15020_en_03
IPsec VPN menu
Masquerade
Can only be used for Tunnel VPN type.
Example
Network address for masquerading
A control center has one VPN tunnel each for a large number of branches. One local network with numerous computers is installed in each of the branches, and these computers are connected to the control center via the relevant VPN tunnel. In this case, the address area could be too small to include all the computers at the various VPN tunnel ends.
Masquerading solves this problem:
The computers connected in the network of a branch appear under a single IP address by means of masquerading for the VPN gateway of the control center. In addition, this enables the local networks in the various branches to all use the same network address locally. Only the branch can establish VPN connections to the control center.
Specify the IP address area for which masquerading is used.
The sender address in the data packets sent by a computer via the VPN connection is only replaced by the address specified in the Local field (see above) if this computer has an IP address from this address area.
The address specified in the Local field must have the subnet mask “/32” to ensure that only one IP address is signified.
Masquerade can be used in the following network modes: Router, PPPoE, PPTP, Modem, Built-in Modem, Built-in mobile network modem, and Stealth (only “multiple clients” in Stealth mode).
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 connection.
I15020_en_03 Innominate Security Technologies
293
1:1 NAT
With 1:1 NAT in VPN, it is still possible to enter the network addresses actually used to specify the tunnel beginning and end, independently of the tunnel parameters agreed with the partner:
Local network
Remote network
IPsec tunnel
Internet network address for
1:1 NAT
Internet
Internet network address for remote 1:1 NAT
294
Innominate Security Technologies I15020_en_03
10.2.3
Authentication
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> Authentication
Authentication Authentication method
There are two options:
– X.509 Certificate (default)
– Pre-Shared Secret (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 implementations. 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 partner
– How the mGuard authenticates the remote partner
How the mGuard authenticates itself to the partner
I15020_en_03 Innominate Security Technologies
295
IPsec VPN >> Connections >> Edit >> Authentication
Local X.509 Certificate Specifies which machine certificate the mGuard uses as authentication to the VPN partner.
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-
If None is displayed, a certificate must be installed first. None must not be left in place, as this results in no X.509 authentication.
How the mGuard authenticates the remote partner
The following definition relates to how the mGuard verifies the authenticity of the VPN remote partner.
The table below shows which certificates must be provided for the mGuard to authenticate the VPN partner if the VPN partner shows one of the following certificate types when a connection is established:
– A machine certificate signed by a CA
– A self-signed machine certificate
For additional information about the table, see “Authentication >> Certificates” on
Authentication for VPN
The partner shows the following:
The mGuard authenticates the partner using:
Machine certificate, signed by CA
Machine certificate, self- signed
Remote certificate
Or all CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner
Remote certificate
According to this table, the certificates that must be provided are the ones the mGuard uses to authenticate the relevant VPN partner.
296
Innominate Security Technologies I15020_en_03
Requirement
Self-signed machine certificate
IPsec VPN menu
The following instructions assume that the certificates have already been correctly installed 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 partner is checked for revocations.
However, an existing VPN connection is not immediately terminated by a withdrawn certificate if the CRL update is being performed during the existing VPN connection. Nevertheless, it is no longer possible to exchange keys again (rekeying) or restart the VPN connection.
Remote CA Certificate
If the VPN partner authenticates itself with a self-signed machine certificate:
• Select the following entry from the selection list:
“No CA certificate, but the Remote Certificate below”
•
Install the remote certificate under Remote Certificate (see “Installing the remote certif-
It is not possible to reference a remote certificate loaded under the Authentication >> Cer-
Machine certificate signed by the CA
If the VPN partner authenticates itself with a machine certificate signed by a CA:
It is possible to authenticate the machine certificate shown by the partner as follows:
– Using CA certificates
– Using the corresponding remote certificate
Authentication using a CA certificate:
Only the CA certificate from the CA that signed the certificate shown by the VPN partner should be referenced here (selection from list). The additional CA certificates that form the chain to the root CA certificate together with the certificate shown by the partner must be in-
stalled on the mGuard under the Authentication >> Certificates menu item.
The selection list contains all CA certificates that have been loaded on the mGuard under
the Authentication >> Certificates menu item.
The other option is “Signed by any trusted CA”.
With this setting, all VPN partners are accepted, providing they log in with a signed CA certificate issued by a recognized certification authority (CA). The CA is recognized if the relevant CA certificate and all other CA certificates have been loaded on the mGuard. These then form the chain to the root certificate together with the certificates shown.
Authentication using the corresponding remote certificate:
• Select the following entry from the selection list:
“No CA certificate, but the Remote Certificate below”
•
Install the remote certificate under Remote Certificate (see “Installing the remote certif-
It is not possible to reference a remote certificate loaded under the Authentication >> Cer-
I15020_en_03 Innominate Security Technologies
297
Requirement
Installing the remote certificate
The remote certificate must be configured if the VPN partner is to be authenticated using a remote certificate.
To import a certificate, proceed as follows:
The certificate file (file name extension: *.pem, *.cer or *.crt) is saved on the connected computer.
• Click on Browse... to select the file.
• Click on Upload.
The contents of the certificate file are then displayed.
IPsec VPN >> Connections >> Edit >> Authentication
VPN Identifier Authentication method: CA certificate
The following explanation applies if the VPN partner 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 partner, then it is possible 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 partner. It must match the data in the machine certificate of the mGuard.
Valid values:
– Empty, i.e., no entry (default). The “Subject” entry (previously 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.
298
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> Authentication [...]
Remote Specifies what must be entered as a subject in the machine certificate of the VPN partner for the mGuard to accept this
VPN partner as a communication partner.
It is then possible to restrict or enable access by VPN partners, which the mGuard would accept in principle based on certificate 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
“Distinguished Name” was previously used instead of “Subject”.
Access enabled for all subjects:
If the Remote field is left empty, then any subject entries are permitted in the machine certificate shown by the VPN partner. It is then no longer necessary to identify or define the subject in the certificate.
Restricted access to certain subjects:
In the certificate, the certificate owner is specified in the Subject field. The entry is comprised 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 partner 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 certificates to be filtered can have any value.
Please note the following when setting a subject filter:
The number and the order of the attributes must correspond to that of the certificates for which the filter is used.
Please note this is case-sensitive.
I15020_en_03 Innominate Security Technologies
299
IPsec VPN >> Connections >> Edit >> Authentication [...]
Authentication Authentication method: Pre-Shared Secret (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 Secret Key (PSK) input field.
To achieve security comparable to that of 3DES, the string should consist of around 30 randomly selected characters, and should include upper and lower case characters and digits.
When PSK is used together with the “Aggressive Mode (insecure)” setting,
a fixed Diffie-Hellman algorithm must be selected under IKE Options for the
initiator of the connection.
When PSK is used together with the “Aggressive Mode (insecure)” setting,
all Diffie-Hellman algorithms should be selected under IKE Options for the
responder of the connection.
When using a fixed Diffie-Hellman algorithm, it must be the same for all con-
nections using the “Aggressive Mode (insecure)” setting.
300
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> Authentication [...]
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.
VPN Identifier
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. Another reason may be to achieve faster connection establishment 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 authentication, which are to be implemented by means of a
NAT gateway, must use unique VPN identifiers on both the client and the gateway.
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.,
– An e-mail address (e.g.,
I15020_en_03 Innominate Security Technologies
301
10.2.4
Firewall
Incoming/outgoing firewall
While the settings made under the Network Security menu item only relate to non-VPN con-
nections (see above under “Network Security menu” on page 223), the settings here only
relate to the VPN connection defined on these tabs.
If multiple VPN connections have been defined, you can restrict the outgoing or incoming access individually for each connection. Any attempts to bypass these restrictions can be logged.
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-
302
Innominate Security Technologies
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 contains 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 tunnel.
If the Allow packet forwarding between VPN connections option is set to Yes on the Glob-
al tab, 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.
I15020_en_03
IPsec VPN menu
If the mGuard has been configured to forward SSH connection packets (e.g., by permitting 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 tunnel despite the fact that this is prohibited by its firewall rules.
IPsec VPN >> Connections >> Edit >> Firewall
Incoming General firewall setting
Accept all incoming connections: the data packets of all incoming connections are allowed.
Drop all incoming connections: the data packets of all incoming connections are discarded.
Accept Ping only: the data packets of all incoming connections are discarded, except for ping packets (ICMP).
Use the firewall ruleset below: displays further setting options. (This menu item is not included in the scope of functions rs2000 Switch or
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-
From Port/To Port
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
Incoming:
– From IP:
– To IP:
Outgoing:
–
–
From IP:
To IP:
IP address in the VPN tunnel
1:1 NAT address or the actual address
1:1 NAT address or the actual address
IP address in the VPN tunnel
(only evaluated for TCP and UDP protocols)
– 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
I15020_en_03 Innominate Security Technologies
303
IPsec VPN >> Connections >> Edit >> Firewall
Action
Outgoing
Comment
Log
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.
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
Log entries for unknown connection attempts
When set to Yes, all connection attempts that are not covered by the rules defined above are logged.
The explanation provided under “Incoming” also applies to “Outgoing”.
304
Innominate Security Technologies I15020_en_03
10.2.5
IKE Options
IPsec VPN menu
I15020_en_03 Innominate Security Technologies
305
IPsec VPN >> Connections >> Edit >> IKE Options
ISAKMP SA (Key
Exchange)
Algorithms
Decide on which encryption method should be used with the administrator of the partner.
Encryption
3DES-168 is the most commonly used method and is therefore set by default.
The following generally applies: the more bits an encryption algorithm has (specified by the appended number), the more secure it is. The relatively new AES-256 method is therefore the most secure, however it is still not used that widely.
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 partner.
The algorithm designated as “Null” does not contain encryption.
Hash
Leave this set to All algorithms. It then does not matter whether the partner is operating 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.
See above.
Algorithms
Perfect Forward
Secrecy (PFS)
Method for providing increased security during data transmission. With IPsec, the keys for data exchange are renewed at defined intervals.
With PFS, new random numbers are negotiated with the partner instead of being derived from previously agreed random numbers.
The partner must have the same entry. We recommend enabling this setting for security reasons.
Select Yes, if the partner supports PFS.
Set Perfect Forward Secrecy (PFS) to No if the partner is an IPsec/L2TP client.
306
Innominate Security Technologies I15020_en_03
IPsec VPN menu
IPsec VPN >> Connections >> Edit >> IKE Options
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 of the keys agreed for ISAKMP SA. Default setting: 3600 seconds (1 hour). The maximum permitted lifetime is 86400 seconds (24 hours).
IPsec SA Lifetime Lifetime in seconds of the keys agreed for IPsec SA.
Default setting: 28800 seconds (8 hours). The maximum permitted lifetime is 86400 seconds (24 hours).
Traffic 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 this (Hard
Limit).
Re-key Margin for Lifetimes
Applies to ISAKMP
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 subtracted 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.
Re-key Fuzz
Keying tries
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 ignored.
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.
Number of attempts to negotiate new keys with the partner.
The value 0 results in unlimited attempts for connections initiated by the mGuard, otherwise it results in 5 attempts.
I15020_en_03 Innominate Security Technologies
307
IPsec VPN >> Connections >> Edit >> IKE Options
Dead Peer Detection If the partner supports the Dead Peer Detection (DPD) protocol, the relevant partners can detect whether or not the IPsec connection is still valid and whether it needs to be established 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 partner is still available.
Default setting: 30 seconds.
Timeout for absent sign of life after which peer is assumed dead
Duration in seconds after which the connection to the partner should be declared dead if there has been no response to the
Keep Alive requests.
Default setting: 120 seconds.
If the mGuard finds that a connection is dead, it responds according to the setting under Connec-
tion startup (see definition of this VPN connection under Connection startup on the General tab).
308
Innominate Security Technologies I15020_en_03
IPsec VPN menu
10.3
IPsec VPN >> L2TP over IPsec
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.
Allows VPN connections to the mGuard to be established using the IPsec/L2TP protocol.
In doing so, the L2TP protocol is driven using an IPsec transport connection in order to establish a tunnel connection to a Point-to-Point Protocol (PPP). Clients are automatically assigned IP addresses by the PPP.
In order to use IPsec/L2TP, the L2TP server must be activated and one or more IPsec connections with the following properties must be defined:
– Type: Transport
– Protocol: UDP
– Local: %all
– Remote: %all
– PFS: No
See
–
IPsec VPN >> Connections >> Edit >> General on page
–
IPsec VPN >> Connections >> Edit >> IKE Options, Perfect Forward Secrecy (PFS) on
10.3.1
L2TP Server
IPsec VPN >> L2TP over IPsec >> L2TP Server
Settings Start L2TP Server for
IPsec/L2TP?
Local IP for L2TP connections
Remote IP range start/end
If you want to enable IPsec/L2TP connections, set this option to Yes.
It is then possible to establish L2TP connections to the mGuard via IPsec, which dynamically assign IP addresses to the clients within the VPN.
If set as shown in the screenshot above, the mGuard will inform the partner that its address is 10.106.106.1.
If set as shown in the screenshot above, the mGuard will assign the partner an IP address between 10.106.106.2 and
10.106.106.254.
I15020_en_03 Innominate Security Technologies
309
IPsec VPN >> L2TP over IPsec >> L2TP Server
Status Displays information about the L2TP status if this connection type has been selected.
10.4
IPsec VPN >> IPsec Status
Reload
Restart
Edit
Displays information about the current status of the configured IPsec connections.
Waiting: displays all VPN connections that have not yet been established which will be started by means of initiation on data traffic or which are waiting for a connection to be established.
Pending: displays all VPN connections that are currently attempting to establish a connection.
The ISAKMP SA has been established and authentication of the connections was completed successfully. If the connection remains in “connection establishment” status the other parameters may not match: does the connection type (Tunnel, Transport) correspond? If “Tunnel” is selected, do the network areas match on both sides?
Established: displays all VPN connections that have successfully established a connection.
The VPN connection has been successfully established and can be used. However, if this is not possible, the VPN gateway of the partner is causing problems. In this case, deactivate and reactivate the connection to reestablish the connection.
Buttons
To update the displayed data, if necessary, click on the Reload button.
If you want to disconnect and then restart a connection, click on the corresponding Restart button.
If you want to reconfigure a connection, click on the corresponding Edit button.
310
Innominate Security Technologies I15020_en_03
ISAKMP SA
IPsec SA
IPsec VPN menu
Connection, ISAKMP SA Status, IPsec SA Status
Local
Remote
– Local IP address
– Local port
– ID = subject of an
X.509 certificate
– Remote IP address
– Local port
– ID = subject of an
X.509 certificate
– Name of the connection
– Local networks ... Remote networks
State, lifetime, and encryption algorithm for the connection (bold = active)
State, lifetime, and encryption algorithm for the connection (bold = active)
In the event of problems, it is recommended that you check the VPN logs of the partner to which the connection was established. This is because detailed error messages are not forwarded to the initiating computer for security reasons.
I15020_en_03 Innominate Security Technologies
311
312
Innominate Security Technologies I15020_en_03
OpenVPN Client menu
11 OpenVPN Client menu
Requirements for a VPN connection
11.1
OpenVPN Client >> Connections
With OpenVPN, an encrypted VPN connection can be established between the mGuard as the OpenVPN client and a partner (OpenVPN server). The OpenSSL library is used for encryption and authentication. Data is transported using the TCP or UDP protocols.
A general requirement for a VPN connection is that the IP addresses of the VPN partners are known and can be accessed.
– mGuard devices provided in stealth network mode are preset to the “multiple clients” you can select a different stealth configuration than the “multiple clients” configuration or use another network mode.
– In order to successfully establish an OpenVPN connection, the VPN partner must support the OpenVPN protocol as the OpenVPN server.
11.1.1
Connections
Lists all the VPN connections that have been defined.
Each connection name listed here can refer to an individual VPN connection. You also have the option of defining new VPN connections, activating and deactivating VPN connections, changing (editing) the VPN connection properties, and deleting connections.
OpenVPN Client >> Connections
License status Licensed peers Number of partners to which a VPN connection can be established simultaneously based on the VPN licenses currently installed.
I15020_en_03 Innominate Security Technologies
313
OpenVPN Client >> Connections[...]
Used by IPsec
Used by OpenVPN
Remaining
Partners that currently have a VPN connection established using the IPsec protocol.
Partners that currently have a VPN connection established using the OpenVPN protocol.
Number of remaining partners to which another VPN connection can be established based on the VPN licenses currently installed and depending on the existing VPN connections.
Defining a new VPN connection
• In the connections table, click on the Edit button to the right of the “(unnamed)” entry under “Name”.
• If the “(unnamed)” entry cannot be seen, open another row in the table.
Editing a VPN connection
• Click on the Edit button to the right of the relevant entry.
Depending on the network mode of the mGuard, the following page appears after clicking on Edit.
314
Innominate Security Technologies I15020_en_03
11.1.2
General
OpenVPN Client menu
.
OpenVPN Client >> Connections >> Edit >> General
Options A descriptive name for the connection
The connection can be freely named/renamed.
Initial Mode Disabled / Stopped / Started
The “Disabled” setting deactivates the VPN connection permanently; 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).
Regardless of the initial mode, the VPN connections can be started or stopped via a button on the web interface, via text message, a switch or a pushbutton.
I15020_en_03 Innominate Security Technologies
315
Connection
316
Innominate Security Technologies
Controlling service input
None / Service input CMD 1-3
The VPN connection can be switched via a connected pushbutton/switch.
The pushbutton/switch must be connected to one of the ser-
If starting and stopping the VPN connection via the CMD contact is enabled, only the CMD contact is authorized to do this.
However, if a pushbutton is connected to the CMD contact (instead of a switch – see below), the connection can also be established and released via a text message, which has the same rights.
Deactivation Timeout Time, after which the VPN connection is stopped, if it has been started via a text message, switch, pushbutton 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.
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
[h:mm:ss].
0 means the setting is disabled.
Token for text message trigger
Address of the remote site's VPN gateway
IP address or host name of the VPN gateway of the partner
Protocol
Incoming text messages can be used to start or stop VPN connections. The text message must contain the “openvpn/start” or “openvpn/stop” command followed by the token.
TCP / UDP
The network protocol used by the OpenVPN server must likewise be selected here in the mGuard.
Local Port
Remote Port
The port of the local OpenVPN client from which the connection to an OpenVPN server is initiated.
Values: 1 - 65535; default: %any (selection left to the partner)
Port on the remote OpenVPN server that should respond to requests from the OpenVPN client.
Values: 1 - 65535; default: 1194
I15020_en_03
11.1.3
Tunnel Settings
OpenVPN Client menu
Tunnel Settings Remote networks Addresses of networks that are located behind the OpenVPN server (VPN gateway of the partner) (CIDR format).
I15020_en_03 Innominate Security Technologies
317
318
Innominate Security Technologies
Learn remote networks from server
Yes (default) / No
When set to Yes, remote networks are automatically learned from the server if the server is configured accordingly.
The routes to remote networks are only known to the mGuard if the corresponding VPN connection is established.
If this VPN connection is not in place, network traffic will not be blocked to the relevant IP addresses, instead it will be possible to send network traffic unencrypted via a different interface.
In this case, the appropriate firewall rules must be set.
Routes to remote networks behind the OpenVPN server can also be overwritten on other interfaces by higher priority routes, e.g., if there are routes with a smaller destination network.
If, for example, 10.0.0.0/8 is a route via the Open-
VPN interface and 10.1.0.0/16 is a route via the external interface, network traffic will be sent unencrypted to IP address 10.1.0.1 via the external interface.
Dynamically learned remote networks
Use Compression
When set to No, the statically entered routes will be used.
Dynamically learned remote networks are displayed.
Yes / No / Adaptive
You can select whether compression should always be applied, should never be applied or should be applied adaptively
(adapted according to the type of traffic).
I15020_en_03
Data Encryption
OpenVPN Client menu
Encryption Algorithm Blowfish (default) / AES (128) / AES (192) / AES (256)
Decide on which encryption algorithm should be used with the administrator of the partner.
If possible, use the AES (256) encryption algorithm for security reasons.
Dead Peer Detection
Key Renegotiation
Key Renegotiation
Interval
Encryption
The Blowfish encryption algorithm is used by default as it is widely used with OpenVPN.
The following generally applies: the more bits an encryption algorithm has (specified by the appended number), the more secure it is. The longer the key, the more time-consuming the encryption procedure.
Yes (default) / No
When set to Yes, the mGuard will attempt to negotiate a new key when the old one expires.
Duration after which the validity of the current key expires and a new key is negotiated between the server and client.
If the partner supports Dead Peer Detection, the relevant partners can detect whether the
OpenVPN connection is still valid or whether it needs to be established again.
Delay between requests for a sign of life
Duration after which DPD Keep Alive requests should be transmitted. These requests test whether the partner is still available.
Time in h:mm:ss
Default: 0:00:00 (DPD is disabled)
Timeout for absent sign of life after which peer is assumed dead
Duration after which the connection to the partner should be declared dead if there has been no response to the Keep Alive requests.
Time in h:mm:ss
If there is no response, the connection is initiated again by the mGuard.
Default: 0:00:00 (DPD is disabled)
I15020_en_03 Innominate Security Technologies
319
11.1.4
Authentication
OpenVPN Client >> Connections >> Edit >> Authentication
Authentication Authentication method
There are three ways in which the mGuard can authenticate itself as an OpenVPN client to the OpenVPN server:
– X.509 Certificate (default)
– Login/Password
– X.509 Certificate + Login/Password
The page contains different setting options depending on the method chosen.
Login
Password
Authentication method: Login/Password
User ID that the mGuard uses to authenticate itself to the
OpenVPN server.
Agreed password that is used together with a user ID for authentication.
To achieve adequate security, the string should consist of around 30 randomly selected characters, and should include upper and lower case characters and digits.
Authentication method: X.509 Certificate
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 partner
– How the mGuard authenticates the remote partner
320
Innominate Security Technologies I15020_en_03
OpenVPN Client menu
OpenVPN Client >> Connections >> Edit >> Authentication
Local X.509 Certificate Specifies which machine certificate the mGuard uses as authentication to the VPN partner.
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-
If None is displayed, a certificate must be installed first. None must not be left in place, as this results in no X.509 authentication.
CA Certificate Only the CA certificate from the certification authority (CA) that signed the certificate shown by the VPN partner (OpenVPN server) should be referenced here (selection from list).
Verification with a CA certificate is also required if the “Login/Password” authentication method is selected.
The additional CA certificates that form the chain to the root
CA certificate together with the certificate shown by the part-
If None is displayed, a certificate must be imported first. None must not be left in place, as this results in no authentication of the VPN server.
The selection list contains all CA certificates that have been
imported into the mGuard under the Authentication >> Certificates menu item.
With this setting, all VPN partners are accepted, providing they log in with a signed CA certificate issued by a recognized certification authority (CA). The CA is recognized if the relevant CA certificate and all other CA certificates have been loaded on the mGuard. These then form the chain to the root certificate together with the certificates shown.
I15020_en_03 Innominate Security Technologies
321
11.1.5
Firewall
Incoming/outgoing firewall
While the settings made under the Network Security menu item only relate to non-VPN con-
nections (see above under “Network Security menu” on page 223), the settings here only
relate to the VPN connection defined on these tabs.
If multiple VPN connections have been defined, you can restrict the outgoing or incoming access individually for each connection. Any attempts to bypass these restrictions can be logged.
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-
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 contains further subsequent rules that could also apply, these rules are ignored.
In Single 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 tunnel.
If the Allow packet forwarding between VPN connections option is set to Yes under the
IPsec VPN menu item on the IPsec >> Global tab, 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. This applies for OpenVPN connections as well as for IPsec connections.
If the outgoing data packets are included in the same connection definition, 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 permitting 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 tunnel despite the fact that this is prohibited by its firewall rules.
322
Innominate Security Technologies I15020_en_03
OpenVPN Client menu
OpenVPN Client >> Connections >> Edit >> Firewall
Incoming General firewall setting
Accept all incoming connections: the data packets of all incoming connections are allowed.
Drop all incoming connections: the data packets of all incoming connections are discarded.
Accept Ping only: the data packets of all incoming connections are discarded, except for ping packets (ICMP).
Use the firewall ruleset below: displays further setting options. (This menu item is not included in the scope of functions rs2000 Switch or
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-
From Port/To Port
Action
Comment
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
Incoming:
– From IP:
– To IP:
Outgoing:
–
–
From IP:
To IP:
IP address in the VPN tunnel
1:1 NAT address or the actual address
1:1 NAT address or the actual address
IP address in the VPN tunnel
(only evaluated for TCP and UDP protocols)
– 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
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.
Freely selectable comment for this rule.
I15020_en_03 Innominate Security Technologies
323
OpenVPN Client >> Connections >> Edit >> Firewall
Log
Outgoing
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
Log entries for unknown connection attempts
When set to Yes, all connection attempts that are not covered by the rules defined above are logged.
The explanation provided under “Incoming” also applies to “Outgoing”.
324
Innominate Security Technologies I15020_en_03
OpenVPN Client menu
11.1.6
NAT
The IP address (OpenVPN client IP address) that the mGuard uses as the OpenVPN client is assigned to it by the OpenVPN server of the partner.
If NAT is not used, the local networks of the mGuard, from which the OpenVPN connection should be used, must be statically configured in the OpenVPN server. It is therefore recommended that you use NAT, i.e., that local routes (local IP addresses within the private address area) are rewritten to the OpenVPN client IP address so that devices in the local network can use the OpenVPN connection.
OpenVPN Client >> Connections >> Edit >> NAT
Local NAT
I15020_en_03
Network Address
Translation/IP Masquerading
In the default setting (0.0.0.0/0), all networks positioned behind the mGuard are masqueraded and can use the OpenVPN connection.
Network
For outgoing data packets, the device can rewrite the specified sender IP addresses from its internal network to its Open-
VPN client IP address, a technique referred to as NAT (Network Address Translation).
This method is used if the internal addresses cannot or should not be routed externally, e.g., because a private address area such as 192.168.x.x or the internal network structure should be hidden.
0.0.0.0/0 means that all internal IP addresses are subject to the NAT procedure. To specify an address area, use CIDR for-
mat (see “CIDR (Classless Inter-Domain Routing)” on
The masquerading of remote networks can be configured under Network >> NAT >> Masquer-
In order to access devices in the local network of the mGuard from the remote network, IP and port forwarding must be used (see below).
Comment
Freely selectable comment for this rule.
Innominate Security Technologies
325
OpenVPN Client >> Connections >> Edit >> NAT
IP and Port Forwarding Lists the rules defined for IP and port forwarding (DNAT = Destination NAT).
IP and port forwarding performs the following: the headers of incoming data packets from the OpenVPN tunnel, which are addressed to the OpenVPN client IP address of the mGuard and to a specific port of the mGuard, are rewritten in order to forward them to a specific computer in the internal network and to a specific port on this computer. In other words, the IP address and port number in the header of incoming data packets are changed.
This method is also referred to as Destination NAT.
If port forwarding is used, the packets pass through the mGuard firewall
without taking into consideration the rules configured under Network Secu-
rity >> Packet Filter >> Incoming Rules.
Protocol: TCP / UDP /
GRE
From IP
Specify the protocol to which the rule should apply (TCP / UDP
/ GRE).
GRE
GRE protocol IP packets can be forwarded. However, only one GRE connection is supported at any given time. If more than one device sends GRE packets to the same external IP address, the mGuard may not be able to feed back reply packets correctly.
We recommend only forwarding GRE packets from specific transmitters. These could be ones that have had a forwarding rule set up for their source address by entering the transmitter address in the “From IP” field, e.g., 193.194.195.196/32.
The sender address for forwarding.
0.0.0.0/0 means all addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Rout-
Name of IP groups, if defined. When a name is specified for an IP group, the IP addresses, IP areas or networks saved
under this name are taken into consideration (see “IP/Port
From Port The sender port for forwarding.
any refers to any port.
Either the port number or the corresponding service name can be specified here, e.g., pop3 for port 110 or http for port 80.
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
326
Innominate Security Technologies I15020_en_03
OpenVPN Client menu
OpenVPN Client >> Connections >> Edit >> NAT
Incoming on Port
Redirect to IP
Comment
Log
The original destination port specified in the incoming data packets.
Either the port number or the corresponding service name can be specified here, e.g., pop3 for port 110 or http for port 80.
This information is not relevant for the “GRE” protocol. It is ignored by the mGuard.
The internal IP address to which the data packets should be forwarded and into which the original destination addresses are translated.
Freely selectable comment for this rule.
For each individual port forwarding rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
I15020_en_03 Innominate Security Technologies
327
328
Innominate Security Technologies I15020_en_03
SEC-Stick menu
12 SEC-Stick menu
The mGuard supports the use of an SEC-Stick, which is an access protector for IT systems.
The SEC-Stick is a product of the team2work company: www.team2work.de
The SEC-Stick is a key. The user inserts it into the USB port of a computer with an Internet connection, and can then set up an encrypted connection to the mGuard in order to securely access defined services in the office or home network. The Remote Desktop Protocol, for example, can be used within the encrypted and secure SEC-Stick connection to control a
PC remotely in the office or at home, as if the user was sitting directly in front of it.
In order for this to work, access to the business PC is protected by the mGuard and the mGuard must be configured for the SEC-Stick to permit access because the user of this remote computer, into which the SEC-Stick is inserted, authenticates herself/himself to the mGuard using the data and software stored on her/his SEC-Stick.
The SEC-Stick establishes an SSH connection to the mGuard. Additional tunnels can be
I15020_en_03 Innominate Security Technologies
329
12.1
Global
SEC-Stick >> Global >> Access
SEC-Stick Access
This menu item is not included in the scope of functions for
Access via the SEC-Stick requires a license. This access function can only be used if the corresponding license has been purchased and installed.
Enable SEC-Stick service
Set this option to Yes to specify that the SEC-Stick being used at a remote location or its owner is able to log in. In this case,
SEC-Stick remote access must also be enabled (next option).
Set this option to Yes to enable SEC-Stick remote access.
Enable SEC-Stick remote access
Remote SEC-Stick
TCP Port
Default: 22002
If this port number is changed, the new port number only applies for access via the External, External 2, DMZ, GRE or
VPN interface. Port number 22002 still applies for internal access.
330
Innominate Security Technologies I15020_en_03
SEC-Stick menu
SEC-Stick >> Global >> Access [...]
Concurrent session limits
Delay between requests for a sign of life
Default: 120 seconds
Values from 0 to 3600 seconds can be set. Positive values indicate that the mGuard is sending a query to the partner within the encrypted SSH connection to find out whether it can still be accessed. The request is sent if no activity was detected from the partner for the specified number of seconds (e.g., due to network traffic within the encrypted connection).
The value entered relates to the functionality of the encrypted
SSH connection. As long as the functions are working properly, the SSH connection is not terminated by the mGuard as a result of this setting, even when the user does not perform any actions during this time.
As the number of simultaneously open sessions is limited (see
Maximum number of cumulative concurrent sessions for all
users), it is important to terminate sessions that have expired.
Therefore, the request for a sign of life is preset to 120 seconds in the case of Version 7.4.0 or later. If a maximum of three requests for a sign of life are issued, this causes an expired session to be detected and removed after six minutes.
In previous versions, the preset was “0”. This means that no requests for a sign of life are sent.
Please note that sign of life requests generate additional traffic.
Maximum number of missing signs of life
Specifies the maximum number of times a sign of life request to the partner may remain unanswered. For example, if a sign of life request should be made every 15 seconds and this value is set to 3, then the SEC-Stick client connection is deleted if a sign of life is not detected after approximately 45 seconds.
The number of simultaneous sessions is limited for SEC-Stick connections. Approximately 0.5 Mbytes of memory space is required for each session to ensure the maximum level of security.
The restriction does not affect existing sessions; it only affects newly established connections.
0 to 2147483647 Maximum number of cumulative concurrent sessions for all users
Specifies the number of connections that are permitted for all users simultaneously. When “0” is set, no session is permitted.
Maximum number of concurrent sessions for one user
0 to 2147483647
Specifies the number of connections that are permitted for one user simultaneously. When “0” is set, no session is permitted.
I15020_en_03 Innominate Security Technologies
331
SEC-Stick >> Global >> Access [...]
Allowed Networks Lists the firewall rules that have been set up for SEC-Stick remote access.
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 contains further subsequent rules that could also apply, these rules are ignored.
The rules specified here only take effect if Enable SEC-Stick remote access is set to
Yes. Internal access is also possible when this option is set to No. A firewall rule that would refuse Internal access does therefore not apply in this case.
Multiple rules can be specified.
From IP Enter the address of the computer/network from which remote access is permitted or forbidden in this field.
Interface
IP address 0.0.0.0/0 means all addresses. To specify an ad-
dress area, use CIDR format (see “CIDR (Classless Inter-Domain Routing)” on page 25).
Internal / External / External 2 / DMZ / VPN / GRE / Dial-in
1
Specifies to which interface the rule should apply.
If no rules are set or if no rule applies, the following default settings apply:
– Remote SEC-Stick access is permitted via Internal, DMZ,
VPN, and Dial-in.
– Access via External, External 2 and GRE is refused.
Specify the access options according to your requirements.
If you want to refuse access via Internal, DMZ,
VPN or Dial-in, you must implement this explicitly by means of corresponding firewall rules, for example, by specifying Drop as an action.
1
Action
Comment
Log
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.
Freely selectable comment for this rule.
For each individual firewall rule, you can specify whether the use of the rule:
– Should be logged – set Log to Yes
– Should not be logged – set Log to No (default setting)
332
Innominate Security Technologies I15020_en_03
SEC-Stick menu
12.2
Connections
SEC-Stick >> Connections >> SEC-Stick connections
SEC-Stick connections List of defined SEC-Stick connections. Click on the down arrow at the top left of the screen if you want to add a new connection. An existing connection can be edited by clicking on Edit.
Not all of the SEC-Stick functions can be configured via the web interface of the mGuard.
Enabled
User Name
To use a defined SEC-Stick connection, the Enabled option must be set to Yes.
An SEC-Stick connection with a uniquely assigned user name must be defined for every owner of a SEC-Stick who has authorized access. This user name is used to uniquely identify the defined connections.
Name
Company
Name of the person.
Name of the company.
The following page appears when you click on Edit:
General
I15020_en_03
Enabled
User Name
Comment
Contact
As above
As above
Optional comment text.
Optional comment text.
A descriptive name of the user
Optional name of the person (repeated).
Innominate Security Technologies
333
SEC-Stick >> Connections >> SEC-Stick connections [...]
Company Optional: As above
SSH Port Forwarding
SSH public key
(including ssh-dss or ssh-rsa)
Enter the SSH public key belonging to the SEC-Stick in ASCII format in this field. The secret equivalent is stored on the SEC-
Stick.
List of allowed access and SSH port forwarding relating to the SEC-Stick of the corresponding user.
IP
Port
IP address of the computer to which access is enabled.
Port number to be used when accessing the computer.
334
Innominate Security Technologies I15020_en_03
QoS menu
13 QoS menu
Switch.
QoS (Quality of Service) refers to the quality of individual transmission channels in IP networks. This relates to the allocation of specific resources to specific services or communication types so that they work correctly. The necessary bandwidth, for example, must be provided to transmit audio or video data in realtime in order to reach a satisfactory communication level. At the same time, slower data transfer by FTP or e-mail does not threaten the overall success of the transmission process (file or e-mail transfer).
13.1
Ingress Filters
An ingress filter prevents the processing of certain data packets by filtering and dropping them before they enter the mGuard processing mechanism. The mGuard can use an ingress filter to avoid processing data packets that are not needed in the network. This results in a faster processing of the remaining, i.e., required data packets.
Using suitable filter rules, administrative access to the mGuard can be ensured with high probability, for example.
Packet processing on the mGuard is generally defined by the handling of individual data packets. This means that the processing performance depends on the number of packets to be processed and not on the bandwidth.
Filtering is performed exclusively according to features that are present or may be present in each data packet: the sender and recipient IP address specified in the header, the specified Ethernet protocol, the specified IP protocol, the specified TOS/DSCP value, and/or the
VLAN ID (if VLANs have been set up). As the list of filter rules must be applied to each individual data packet, it should be kept as short as possible. Otherwise, the time spent on filtering could be longer than the time actually saved by setting the filter.
Please note that not all specified filter criteria should be combined. For example, it does not make sense to specify an additional IP protocol in the same rule that contains the ARP
Ethernet protocol. Nor does it make sense to specify a transmitter or sender IP address if the IPX Ethernet protocol is specified (in hexadecimal format).
13.1.1
Internal/External
I15020_en_03
Internal: settings for the ingress filter at the LAN interface
Innominate Security Technologies
335
External: settings for the ingress filter at the WAN interface
QoS >> Ingress Filters >> Internal/External
Enabling Enable Ingress QoS
Filter
Measurement Unit
Use VLAN
VLAN ID
Ethernet Protocol
IP Protocol
From IP
No (default): this feature is disabled. If filter rules are defined, they are ignored.
Yes: this feature is enabled. Data packets may only pass through and be forwarded to the mGuard for further evaluation and processing if they comply with the filter rules defined below.
Filters can be set for the LAN port (Internal tab page) and the
WAN port (External tab page).
kbps or Packet/s
Specifies the unit of measurement for the numerical values entered under Guaranteed and Upper Limit.
If a VLAN is set up, the relevant VLAN ID can be specified to allow the relevant data packets to pass through. To do this, this option must be set to Yes.
Specifies that the VLAN data packets that have this VLAN ID may pass through. (To do this, the Use VLAN option must be set to Yes.)
Specifies that only data packets of the specified Ethernet protocol may pass through. Possible entries: ARP, IPV4, %any.
Other entries must be in hexadecimal format (up to 4 digits).
(The ID of the relevant protocol in the Ethernet header is entered here. It can be found in the publication of the relevant standard.)
All/TCP/UDP/ICMP/ESP
Specifies that only data packets of the selected IP protocol may pass through. When set to All, no filtering is applied according to the IP protocol.
Specifies that only data packets from a specified IP address may pass through.
0.0.0.0/0 stands for all addresses, i.e., in this case no filtering is applied according to the IP address of the sender. To spec-
ify an address area, use CIDR format (see “CIDR (Classless
Inter-Domain Routing)” on page 25).
336
Innominate Security Technologies I15020_en_03
QoS menu
QoS >> Ingress Filters >> Internal/External[...]
To IP
Current TOS/DSCP
Guaranteed
Upper Limit
Comment
Specifies that only data packets that should be forwarded to the specified IP address may pass through.
Entries correspond to From IP, as described above.
0.0.0.0/0 stands for all addresses, i.e., in this case no filtering is applied according to the IP address of the sender.
Each data packet contains a TOS or DSCP field. (TOS stands for Type of Service, DSCP stands for Differentiated Services
Code Point). The traffic type to which the data packet belongs is specified here. For example, an IP phone will write a different entry in this field for outgoing data packets compared to an
FTP program.
When a value is selected here, only data packets with this value in the TOS or DSCP field may pass through. When set to All, no filtering according to the TOS/DSCP value is applied.
The number entered specifies how many data packets per second or kbps can pass through at all times – according to the option set under Measurement Unit (see above). This applies to the data stream that conforms to the rule set criteria specified on the left (i.e., that may pass through). The mGuard
may drop the excess number of data packets in the event of capacity bottlenecks if this data stream delivers more data packets per second than specified.
The number entered specifies the maximum number of data packets per second or kbps that can pass through – according to the option set under Measurement Unit (see above). This applies to the data stream that conforms to the rule set criteria specified on the left (i.e., that may pass through). The mGuard drops the excess number of data packets if this data stream delivers more data packets per second than specified.
Optional comment text.
I15020_en_03 Innominate Security Technologies
337
13.2
Egress Queues
The services are assigned corresponding priority levels. In the event of connection bottlenecks, the outgoing data packets are placed in egress queues (i.e., queues for pending packets) according to the assigned priority level and are then processed according to their priority. Ideally, the assignment of priority levels and bandwidths should result in a sufficient bandwidth level always being available for the realtime transmission of data packets, while other packets, e.g., FTP downloads, are temporarily set to wait in critical cases.
The main application of egress QoS is the optimal utilization of the available bandwidth on a slow computer from overloading in the protected network.
The Egress Queues feature can be used for all interfaces and for VPN connections.
13.2.1
Internal/External/External 2/Dial-in
Internal: settings for egress queues on the LAN interface
External: settings for egress queues on the external WAN interface
338
Innominate Security Technologies I15020_en_03
External 2: settings for egress queues on the secondary external interface
QoS menu
Dial-in: settings for egress queues for packets for a PPP dial-up connection (dial-in)
I15020_en_03 Innominate Security Technologies
339
13.3
Egress Queues (VPN)
13.3.1
VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in
VPN via Internal: settings for egress queues
VPN via External: settings for egress queues
VPN via External 2: settings for egress queues
340
Innominate Security Technologies I15020_en_03
VPN via Dial-in: settings for egress queues
QoS menu
All of the tab pages listed above for Egress Queues for the Internal, External, External 2, and
Dial-in interfaces, and for VPN connections routed via these interfaces, have the same setting options.
In all cases, the settings relate to the data that is sent externally into the network from the relevant mGuard interface.
QoS menu >> Egress Queues >> Internal/External/External 2/Dial-in
QoS menu >> Egress Queues (VPN) >> VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in
Enabling Enable Egress QoS No (default): this feature is disabled.
Yes: this feature is enabled. This option is recommended if the interface is connected to a network with low bandwidth. This enables bandwidth allocation to be influenced in favor of particularly important data.
Total Bandwidth/Rate
Queues
Bandwidth/Rate Limit kbps or Packet/s
Total maximum bandwidth that is physically available – specified in kbps or packets per second.
Name
In order to optimize prioritization, the total bandwidth specified here should be slightly lower than the actual amount. This prevents a buffer overrun on the transferring devices, which would result in adverse effects.
The default name for the egress queue can be adopted or another can be assigned. The name does not specify the priority level.
Guaranteed Bandwidth that should be available at all times for the relevant queue. Based on the selection under Bandwidth/Rate Limit
(kbps OR Packet/s), meaning that the unit of measurement does not have to be specified explicitly here.
The total of all guaranteed bandwidths must be less than or equal to the total bandwidth.
I15020_en_03 Innominate Security Technologies
341
QoS menu >> Egress Queues >> Internal/External/External 2/Dial-in
QoS menu >> Egress Queues (VPN) >> VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in[...]
Upper Limit Maximum bandwidth available that may be set for the relevant queue by the system. Based on the selection under Band-
width/Rate Limit (kbps OR Packet/s), meaning that the unit of measurement does not have to be specified explicitly here.
Priority
The value must be greater than or equal to the guaranteed bandwidth. The value unlimited can also be specified, which means that there is no further restriction.
Low/Medium/High
Comment
Specifies with which priority the affected queue should be processed, provided the total available bandwidth has not been exhausted.
Optional comment text.
342
Innominate Security Technologies I15020_en_03
I15020_en_03
QoS menu
13.4
Egress Rules
This page defines the rules for the data that is assigned to the defined egress queues
(see above) in order for the data to be transmitted with the priority assigned to the relevant queue.
Rules can be defined separately for all interfaces and for VPN connections.
13.4.1
Internal/External/External 2/Dial-in
Internal: settings for egress queue rules
External: settings for egress queue rules
External 2: settings for egress queue rules
Dial-in: settings for egress queue rules
Innominate Security Technologies
343
13.4.2
Egress Rules (VPN)
VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in
VPN via Internal: settings for egress queue rules
VPN via External: settings for egress queue rules
VPN via External 2: settings for egress queue rules
VPN via Dial-in: settings for egress queue rules
All of the tab pages listed above for Egress Rules for the Internal, External, External 2, and
Dial-in interfaces, and for VPN connections routed via these interfaces, have the same setting options.
In all cases, the settings relate to the data that is sent externally into the network from the relevant mGuard interface.
344
Innominate Security Technologies I15020_en_03
QoS menu
QoS menu >> Egress Rules >> Internal/External/External 2/Dial-in
QoS menu >> Egress Rules (VPN) >> VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in
Default Default Queue Name of the egress queue (user-defined).
The names of the queues are displayed as listed or specified under Egress Queues on the Internal/External/VPN via Exter-
nal tab pages. The following default names are defined: Default/Urgent/Important/Low Priority.
Traffic that is not assigned to a specific egress queue under
Rules remains in the default queue. You can specify which egress queue should be used as the default queue in this selection list.
Rules The assignment of specific data traffic to an egress queue is based on a list of criteria. If the criteria in a row apply to a data packet, it is assigned to the egress queue specified in the row.
Example: for audio data to be transmitted, you have defined
a queue with guaranteed bandwidth and priority under Egress
Protocol
From IP
From Port
To IP
To Port fine the rules here for how audio data is detected and specify that this data should belong to the Urgent queue.
All/TCP/UDP/ICMP/ESP
Protocol(s) relating to the rule.
IP address of the network or device from which the data originates.
0.0.0.0/0 means all IP addresses. To specify an address area,
use CIDR format (see “CIDR (Classless Inter-Domain Routing)” on page 25).
Assign the traffic from this source to the queue selected under
Queue Name in this row.
Port used at the source from which data originates (only evaluated for TCP and UDP protocols).
– any refers to any port.
– startport:endport (e.g., 110:120) refers to a port area.
Individual ports can be specified using the port number or the corresponding service name (e.g., 110 for pop3 or pop3 for
110).
IP address of the network or device to which the data is sent.
Entries correspond to From IP, as described above.
Port used at the source where the data is sent. Entries correspond to From Port, as described above.
I15020_en_03 Innominate Security Technologies
345
QoS menu >> Egress Rules >> Internal/External/External 2/Dial-in
QoS menu >> Egress Rules (VPN) >> VPN via Internal/VPN via External/VPN via External 2/VPN via Dial-in [...]
Current TOS/DSCP Each data packet contains a TOS or DSCP field. (TOS stands for Type of Service, DSCP stands for Differentiated Services
Code Point). The traffic type to which the data packet belongs is specified here. For example, an IP phone will write a different entry in this field for outgoing data packets compared to an
FTP program that uploads data packet to a server.
New TOS/DSCP
When you select a value here, only the data packets that have this TOS or DSCP value in the corresponding fields are chosen. These values are then set to a different value according to the entry in the New TOS/DSCP field.
If you want to change the TOS/DSCP values of the data packets that are selected using the defined rules, enter the text that should be written in the TOS/DSCP field here.
Queue Name
Comment
For a more detailed explanation of the Current TOS/DSCP and New TOS/DSCP options, please refer to the following
RFC documents:
– RFC 3260 “New Terminology and Clarifications for Diffserv”
– RFC 3168 “The Addition of Explicit Congestion Notification (ECN) to IP”
– RFC 2474 “Definition of the Differentiated Services Field
(DS Field)”
– RFC 1349 “Type of Service in the Internet Protocol Suite”
Name of the egress queue to which traffic should be assigned.
Optional comment text.
346
Innominate Security Technologies I15020_en_03
Redundancy menu
14 Redundancy menu
To use the redundancy function, both mGuards must have the same firmware.
With activated redundancy function, VLAN can not be used in stealth mode.
14.1
Redundancy >> Firewall Redundancy
14.1.1
Redundancy
I15020_en_03 Innominate Security Technologies
347
Redundancy >> Firewall Redundancy >> Redundancy
General Redundancy state Shows the current status.
Enable redundancy No (default): firewall redundancy is disabled.
Yes: firewall redundancy is enabled.
This function can only be activated when a suitable license key is installed.
Further conditions apply if VPN redundancy is to be enabled
at the same time, see “VPN redundancy” on page 387.
Fail-over switching time
Waiting time prior to switching
Maximum time that is allowed to elapse in the event of errors before switching to the other mGuard.
10 000 milliseconds, default: 0
Time the redundancy system ignores an error.
The connectivity and availability checks ignore an error until it is still present after the time set here has elapsed.
Priority of this device high/low
Specifies the priority associated with the presence notifications (CARP).
Set the priority to high on the mGuard that you want to be active. The mGuard on standby is set to low.
Both mGuard devices in a redundant pair may either be set to different priorities or be assigned the high priority.
Never set both mGuard devices in a redundant pair to low priority.
348
Innominate Security Technologies I15020_en_03
Redundancy menu
Redundancy >> Firewall Redundancy >> Redundancy
Passphrase for availability checks
On an mGuard which is part of a redundant pair, checks are constantly performed to determine whether an active mGuard is available and whether it should remain active. A variation of the CARP (Common Address Redundancy Protocol) is used here.
CARP uses SHA-1 HMAC encryption together with a password. This password must be set so it is the same for both mGuard devices. It is used for encryption and is never transmitted in plain text.
The password is important for security since the mGuard is vulnerable at this point. We recommend a password with at least 20 characters and numerous special characters (printable UTF-8 characters). It must be changed on a regular basis.
When changing the password, proceed as follows:
Check the status of the set password before you enter a new one.
There is only a valid password available and you are only permitted to enter a new password if you can see a green check mark to the right of the entry field.
Set the new password on both mGuard devices. It does not matter which order you do this in but the same password must be used in both cases. If you inadvertently enter an incor-
As soon as a redundant pair has been assigned a new password, it automatically negotiates when it can switch to the new password without interruption.
The status is displayed using symbols. We recommend observing this status for security reasons.
A red cross indicates that the mGuard has a new password that it wants to use. However, the old password is still in use.
A yellow check mark indicates that the new password is already in use but that the old password can still be accepted in case the other mGuard still uses it.
If no symbol is shown, it means that no password is being used. For example, this may be because redundancy has not been activated or the firmware is booting up.
I15020_en_03 Innominate Security Technologies
349
Redundancy >> Firewall Redundancy >> Redundancy
If an mGuard fails while the password is being changed, the following scenarios apply:
– Password replacement has been started on all mGuard devices and then interrupted because of a network error, for example. This scenario is rectified automatically.
– Password replacement has been started on all mGuard devices. However, an mGuard then fails and must be replaced.
Examine the remaining mGuard to determine whether the process of changing the password has been completed. If you can see a green check mark, you must set the new password directly on the mGuard that is being replaced.
If you cannot see a green check mark, it means that the password has not yet been changed on the remaining mGuard. In this case, you must change the password again on the mGuard that is still in operation. Wait until the green check mark appears. Only then should you replace the mGuard that has failed. Configure the replacement mGuard with the new password immediately on setting up redundancy.
– Password replacement has been started but not performed on all mGuard devices because they have failed. Password replacement must be started as soon as a faulty mGuard is back online. If an mGuard has been replaced, it must first be configured with the old password before it is connected.
How to proceed in the event of an incorrect password
If you have inadvertently entered an incorrect password on an mGuard, proceed as follows.
If you can still remember the old password, proceed as follows:
• Reconfigure the mGuard on which the incorrect password was entered so that it uses the old password.
• Wait until the mGuard indicates that the old password is being used.
• Then enter the correct password.
If you have forgotten the old password, proceed as follows:
• Check whether you can read the old password out from the other mGuard.
• If the other mGuard is disabled or missing, you can simply enter the correct new password on the active mGuard on which you inadvertently set the incorrect password.
Make sure that the other mGuard is assigned the same password before operating it again.
• If the other mGuard is already using the new password, you must make sure that the mGuard with the incorrect password is not active or able to be activated, e.g., by removing the cable at the LAN or WAN interface.
In the case of remote access, you can enter a destination for the connectivity check that will not respond. Prior to provoking this kind of error, check that there is no redundancy error on any of the mGuard devices. One mGuard must be active and the other must be on standby. It might be necessary to rectify any errors displayed and only then use this method. After that, follow these steps:
– Replace the incorrect password with a different one.
– Enter this password on the active mGuard too.
– Restart the mGuard that is not active. You can do this, for example, by reconnecting the Ethernet cable or restoring the old settings for the connectivity check.
350
Innominate Security Technologies I15020_en_03
Redundancy menu
Redundancy >> Firewall Redundancy >> Redundancy
Virtual interfaces External virtual Router
ID
1, 2, 3, ... 255 (default: 51)
Only in Router network mode.
This ID is sent by the redundant pair with each presence notification (CARP) via the external interface and is used to identify the redundant pair.
This ID must be the same for both mGuard devices. It is used to differentiate the redundant pair from other redundant pairs that are connected to the same Ethernet segment through their external interface.
External virtual IP addresses
Please note that CARP uses the same protocol and port as
VRRR (Virtual Router Redundancy Protocol). The ID set here must be different to the IDs on other devices which use VRRR or CARP and are located in the same Ethernet segment.
Default: 10.0.0.100
Only in Router network mode.
These are IP addresses which are shared by both mGuard devices as virtual IP addresses of the external interface. These
IP addresses must be the same for both mGuard devices.
These addresses are used as a gateway for explicit static routes for devices located in the same Ethernet segment as the external network interface of the mGuard.
The active mGuard can receive ICMP queries via this IP address. It reacts to these ICMP requests depending on the
menu settings under Network Security >> Packet Filter >> Ad-
No subnet masks or VLAN IDs are set up for the virtual IP addresses as these attributes are defined by the actual external
IP address. For each virtual IP address, an actual IP address must be configured whose IP network accommodates the virtual address. The mGuard transmits the subnet mask and
VLAN setting from the actual external IP address to the corresponding virtual IP address.
The applied VLAN settings define whether standard MTU settings or VLAN MTU settings are used for the virtual IP address.
Firewall redundancy cannot function correctly if no actual IP address and subnet mask are available.
I15020_en_03 Innominate Security Technologies
351
Redundancy >> Firewall Redundancy >> Redundancy
Internal virtual Router
ID
1, 2, 3, ... 255 (default: 51)
Only in Router network mode.
Internal virtual IP addresses
This ID is sent by the redundant pair with each presence notification (CARP) via the external and internal interface and is used to identify the redundant pair.
This ID must be set so it is the same for both mGuard devices.
It is used to differentiate the redundant pair from other Ethernet devices that are connected to the same Ethernet segment through their external/internal interface.
Please note that CARP uses the same protocol and port as
VRRR (Virtual Router Redundancy Protocol). The ID set here must be different to the IDs on other devices which use VRRR or CARP and are located in the same Ethernet segment.
As described under External virtual IP addresses, but with two
exceptions.
Under Internal virtual IP addresses, IP addresses are defined for devices which belong to the internal Ethernet segment. These devices must use the IP address as their default gateway. These addresses can be used as a DNS or NTP server when the mGuard is configured as a server for the protocols.
Encrypted state synchronisation
For each virtual IP address, an actual IP address must be configured whose IP network accommodates the virtual address.
The response to ICMP requests with internal virtual IP ad-
dresses is independent from the settings made under Network
Security >> Packet Filter >> Advanced.
Encrypt the state messages
Yes/No
If Yes is selected, state synchronization is encrypted.
Passphrase
The password is changed as described under “Passphrase for availability checks” on page 349.
Only deviate from the prescribed approach if an incorrect password has been inadvertently entered.
352
Innominate Security Technologies I15020_en_03
Redundancy menu
Redundancy >> Firewall Redundancy >> Redundancy
How to proceed in the event of an incorrect password
If you have inadvertently entered an incorrect password on an mGuard, you cannot simply reenter the password using the correct one. Otherwise, in the event of adverse circumstances, this may result in both mGuard devices being active.
Interface for state synchronisation
Case 1: only one mGuard has an incorrect password. The process of changing the password has not yet begun on the other mGuard.
• Reconfigure the mGuard on which the incorrect password was entered so that it uses the old password.
• Wait until the mGuard indicates that the old password is being used.
• Then enter the correct password.
Case 2: the other mGuard is already using the new password.
• The status of both mGuard devices must be such that they are using an old password but expecting a new one (red cross). To ensure that this is the case, enter random passwords successively.
• Finally, generate a secure password and enter it on both mGuard devices. This password is used immediately without any coordination.
During this process, the state of the mGuard on standby may briefly switch to “outdated”.
However, this situation resolves itself automatically.
Encryption Algorithm DES, 3DES, AES-128, AES-192, AES-256
Hash Algorithm MD5, SH1, SHA-256, SHA-512
Interface which is used for state synchronization
Internal Interface/Dedicated Interface is a reserved, direct Ethernet interface or a dedicated LAN segment, via which the state synchronization is sent.
The redundant pair can be connected through an additional dedicated Ethernet interface or an interconnected switch.
On a Dedicated Interface, presence notifications (CARP) are also listened for on the third Ethernet interface. Presence notifications (CARP) are also transmitted when the mGuard is active.
However, no additional routing is supported for this interface.
Frames received on this interface are not forwarded for security reasons.
The connection status of the third Ethernet interface can be queried via SNMP.
I15020_en_03 Innominate Security Technologies
353
Redundancy >> Firewall Redundancy >> Redundancy
IP of the dedicated interface
Only available when Dedicated Interface is selected.
IP
IP address used on the third network interface of the mGuard.
Default: 192.168.68.29
Netmask
Subnet mask used on the third network interface of the mGuard.
Default: 255.255.255.0
Use VLAN
When Yes is selected, a VLAN ID is used for the third network interface.
VLAN ID
1, 2, 3, ... 4094 (default: 1)
VLAN ID when this setting is activated.
Disable the availability check at the external interface
Only available when Dedicated Interface is selected.
When Yes is selected, no presence notifications (CARP) are transmitted or received via the external interface. This can make sense in some scenarios for protection against external attacks.
354
Innominate Security Technologies I15020_en_03
Redundancy menu
14.1.2
Connectivity Checks
Targets can be configured for the internal and external interface in the connectivity check.
It is important that these targets are actually connected to the specified interface. An ICMP echo reply cannot be received by an external interface when the corresponding target is connected to the internal interface (and vice versa). When the static routes are changed, the targets may easily not be checked properly.
Redundancy >> Firewall Redundancy >> Connectivity Checks
External interface Kind of check Specifies whether a connectivity check is performed on the external interface, and if so, how.
If at least one target must respond is selected, it does not matter whether the ICMP echo request is answered by the primary or secondary target.
The request is only sent to the secondary target if the primary target did not offer a suitable answer. In this way, configurations can be supported where the devices are only provided with ICMP echo requests if required.
If all targets of one set must respond is selected, then both targets must answer. If no secondary target is specified, then only the primary target must answer.
If Ethernet link detection only is selected, then only the state of the Ethernet connection is checked.
I15020_en_03 Innominate Security Technologies
355
Redundancy >> Firewall Redundancy >> Connectivity Checks
Primary targets for
ICMP echo requests
This is an unsorted list of IP addresses used as targets for
ICMP echo requests. We recommend using the IP addresses of routers, especially the IP addresses of default gateways or the actual IP address of the other mGuard.
Default: 10.0.0.30, 10.0.0.31 (for new addresses)
Each set of targets for state synchronization can contain a maximum of ten targets.
Internal interface
Secondary targets for
ICMP echo requests
See above
Only used if the check of the primary targets has failed.
Failure of a secondary target is not detected in normal operation.
Default: 10.0.0.30 (10.0.0.31 for new addresses)
Each set of targets for state synchronization can contain a maximum of ten targets.
Kind of check
Primary targets for
ICMP echo requests
Specifies whether a connectivity check is performed on the internal interface, and if so, how.
The settings are the same as those for the external interface.
See above
Factory default: 192.168.1.30 (192.168.1.31
Secondary targets for
ICMP echo requests
See above
Factory default: 192.168.1.30 (192.168.1.31
356
Innominate Security Technologies I15020_en_03
Redundancy menu
14.2
Redundancy >> FW Redundancy Status
14.2.1
Redundancy Status
I15020_en_03 Innominate Security Technologies
357
Redundancy >> FW Redundancy Status >> Redundancy Status
Current State Possible states:
booting: the mGuard is starting.
faulty: the mGuard is not (yet) connected properly.
outdated: state synchronization of the databases is not (yet) up-to-date.
on_standby: the mGuard is ready for activation if the other mGuard fails.
becomes_active: the mGuard is becoming active because the other mGuard has failed.
active: the mGuard is active.
Status of the Components Availability Check
Connectivity Checks
State Replication
Virtual Interface Controller
becomes_standby: the mGuard is switching from the active state to standby mode. The state is changed to outdated since the status database has to be updated first.
Relates to the status of the availability check for the internal or external interface.
The availability check has three possible results.
– Presence notifications (CARP) are not received from any other mGuard device.
– Another mGuard is available which is to become or remain active.
– Another mGuard is available which is active but is to go
“on_standby”.
Indicates whether the check was successful.
Each interface is checked separately.
When synchronizing the state, various databases are checked to see whether everything is up-to-date. With one redundant pair, only one database is active while the other is on standby. Any change made to this state is also displayed.
– The Connection Tracking Table relates to the firewall state database.
– IPsec VPN Connections (with activated VPN redundancy)
All virtual interfaces are checked together to see whether the forwarding of packets is allowed.
358
Innominate Security Technologies I15020_en_03
Redundancy menu
Redundancy >> FW Redundancy Status >> Redundancy Status
State History The table starts with the most recent state.
The abbreviations are as follows:
B Firmware status +
-
T System time
-
+
Firmware started up completely
Firmware not yet started up completely
Valid system time
Invalid system time
O Timeout of the previous state
A Availability check ?
s
-
+ f
Timeout
No timeout
Unknown state
Another mGuard is available. This mGuard is active
(or is currently being enabled).
Another mGuard is available. This mGuard is on standby (or is currently switching to standby).
C
R
Connectivity check
State synchronization
o
?
u
+ f s t
?
No other mGuard available
Unknown state
Check of all components was successful
Check of at least one component has failed
Unknown state
Database is up-to-date
Database is obsolete
Database switching to “on_standby”
Database switching to “active”
I15020_en_03 Innominate Security Technologies
359
14.2.2
Connectivity Status
Redundancy >> FW Redundancy Status >> Connectivity Status
External Interface Summarized result success/fail
Result of the connectivity check for the external interface.
The fail result is also displayed until the specific result of the connectivity check is known.
Ethernet link status
Number of check intervals
Kind of check
The last two intervals of the connectivity check are taken into consideration for the combined result. success is only displayed if both were successful.
success (longer due to waiting time) is displayed, if the
time an error was present was shorter than set under “Waiting
time prior to switching” in the Redundancy >> Firewall Redun-
Shows whether the Ethernet connection has been established.
Number of completed check intervals. When the counter is full, a message is displayed in front of the number.
Repeats the setting for the connectivity check (see Kind of
360
Innominate Security Technologies I15020_en_03
Redundancy menu
Redundancy >> FW Redundancy Status >> Connectivity Status
Check interval Shows the time (in milliseconds) between the starts of the checks.
Timeout per interval and set of targets
This value is calculated from the set fail-over switching time.
Shows the time (in milliseconds) after which a target is classed as “no response” if no response to the ICMP echo request has been received.
This value is calculated from the set fail-over switching time.
Waiting time prior to reporting an error
(except for link errors)
Time the redundancy system ignores an error.
The connectivity and availability checks ignore an error until it is still present after the time set here has elapsed.
This value is set under “Waiting time prior to switching” in the
Redundancy >> Firewall Redundancy >> Redundancy menu.
Internal Interface
Results of the last 16 intervals (youngest first)
A green plus indicates a successful check.
A red minus indicates a failed check.
Results of the primary targets
Only visible when a primary target is set (see Primary targets
Shows the results of the ICMP echo requests in chronological order. The most recent result is at the front.
“sR” indicates a cycle during which ICMP echo requests have been correctly transmitted and received. Missing answers are indicated by a “/” and requests that have not been transmitted are indicated by a “_”.
Results of the secondary targets
Only visible when a secondary target is set (see Secondary
Summarized result
Ethernet link status
Number of check intervals
Check interval
Timeout per interval and set of targets
Results of the last 16 intervals (youngest first)
I15020_en_03 Innominate Security Technologies
361
14.3
Ring/Network Coupling
Ring/network coupling with restrictions:
– mGuard delta: the internal side (switch ports) cannot be switched off
– mGuard pci: in driver mode, the internal network interface cannot be switched off
(however, this is possible in power-over-PCI mode)
14.3.1
Ring/Network Coupling
Redundancy >> Firewall Redundancy >> Ring/Network Coupling
Settings Enable Ring/Network
Coupling/Dual Homing
Yes/No
When activated, the status of the Ethernet connection is transmitted from one port to another in Stealth mode. This means that interruptions in the network can be traced easily.
Redundancy Port Internal/External
Internal: if the connection is lost/established on the LAN port, the WAN port is also disabled/enabled.
External: if the connection is lost/established on the WAN port, the LAN port is also disabled/enabled.
362
Innominate Security Technologies I15020_en_03
Logging menu
15 Logging menu
settings been made, the application of firewall rules, errors, etc.
Log entries are recorded in various categories and can be sorted and displayed according
to these categories (see “Logging >> Browse local logs” on page 365).
15.1
Logging >> Settings
15.1.1
Settings
All log entries are recorded in the RAM of the mGuard by default. Once the maximum memory space for log entries has been used up, the oldest log entries are automatically overwritten by new entries. In addition, all log entries are deleted when the mGuard is switched off.
To prevent this, log entries (SysLog messages) can be transmitted to an external computer
(SysLog server). This is particularly useful if you wish to manage the logs of multiple mGuard devices centrally.
Logging >> Settings
Remote Logging Activate remote UDP logging
Yes/No
If you want all log entries to be transmitted to the external log server (specified below), select Yes.
Log Server IP address Specify the IP address of the log server to which the log entries should be transmitted via UDP.
Log Server port
An IP address must be specified, not a host name. This function does not support name resolution because it might not be possible to make log entries if a DNS server failed.
Specify the port of the log server to which the log entries should be transmitted via UDP. Default: 514
I15020_en_03 Innominate Security Technologies
363
Logging >> Settings
Verbose Logging
If SysLog messages should be transmitted to a SysLog server via a VPN tunnels, the IP address of the SysLog server must be located in the network that is specified as the Remote network in the definition of the VPN connection.
The internal IP address must be located in the network that is specified as
Local in the definition of the VPN connection (see IPsec VPN >> Connections >> Edit >> General).
–
If the IPsec VPN >> Connections >> Edit >> General, Local option is set to 1:1 NAT
(see Page 288), the following applies:
The internal IP address must be located in the specified local network.
–
If the IPsec VPN >> Connections >> Edit >> General, Remote option is set to 1:1
NAT (see Page 289), the following applies:
The IP address of the SysLog server must be located in the network that is specified as Remote in the definition of the VPN connection.
Verbose modem logging
Only available if an internal or external modem is available and switched on.
– Internal modem: mGuard 3G, rs with internal analog modem or ISDN modem
– External modem: mGuard
Verbose logging
Verbose mobile network logging
Verbose logging
364
Innominate Security Technologies I15020_en_03
15.2
Logging >> Browse local logs
Logging menu
The corresponding checkboxes for filtering entries according to their category are displayed below the log entries, depending on which mGuard functions were active.
To display one or more categories, enable the checkboxes for the desired categories and click on Reload logs.
I15020_en_03 Innominate Security Technologies
365
15.2.1
Log entry categories
Common
Log entries that cannot be assigned to other categories.
Network Security logged.
Logged events are shown here if the logging of events was selected when defining the firewall rules (Log = Yes).
Log ID and number for tracing errors
Log entries that relate to the firewall rules listed below have a log ID and number. This log
ID and number can be used to trace the firewall rule to which the corresponding log entry relates and that led to the corresponding event.
Firewall rules and their log ID
– Packet filters:
Network Security >> Packet Filter >> Incoming Rules menu
Network Security >> Packet Filter >> Outgoing Rules menu
Log ID: fw-incoming or fw-outgoing
– Firewall rules for VPN connections:
IPsec VPN >> Connections >> Edit >> Firewall menu, Incoming/Outgoing
Log ID: vpn-fw-in or vpn-fw-out
– Firewall rules for web access to the mGuard via HTTPS:
Management >> Web Settings >> Access menu
Log ID: fw-https-access
– Firewall rules for access to the mGuard via SNMP:
Management >> SNMP >> Query menu
Log ID: fw-snmp-access
– Firewall rules for SSH remote access to the mGuard:
Management >> System Settings >> Shell Access menu
Log ID: fw-ssh-access
– Firewall rules for the user firewall:
Network Security >> User Firewall menu, Firewall rules
Log ID: ufw-
– Rules for NAT, port forwarding:
Network >> NAT >> IP and Port Forwarding menu
Log ID: fw-portforwarding
– Firewall rules for the serial interface:
Network >> Interfaces >> Dial-in menu
Incoming Rules
Log ID: fw-serial-incoming
Outgoing Rules
Log ID: fw-serial-outgoing
366
Innominate Security Technologies I15020_en_03
Logging menu
Searching for firewall rules on the basis of a network security log
If the Network Security checkbox is enabled so that the relevant log entries are displayed, the Jump to firewall rule search field is displayed below the Reload logs button.
Proceed as follows if you want to trace the firewall rule referenced by a log entry in the Net-
work Security category and which resulted in the corresponding event:
1.
Select the section that contains the log ID and number in the relevant log entry,
Copy
General messages:
When activating a configuration profile on a blade:
When retrieving a configuration profile from a blade:
2.
Copy this section into the Jump to firewall rule field.
3.
Click on Lookup.
The configuration page containing the firewall rule that the log entry refers to is displayed.
Blade troller:
(The areas enclosed by < and > are replaced by the relevant data in the log entries.)
Blade[<bladenr>] online
Blade[<bladenr>] is mute
Blade[<bladenr>] not running
Reading timestamp from blade[<bladenr>]
Push configuration to blade[<bladenr>] reconfiguration of blade[<bladenr>] returned <returncode> blade[<bladenr>] # <text>
Pull configuration from blade[<bladenr>]
Pull configuration from blade[<bladenr>] returned <returncode>
I15020_en_03 Innominate Security Technologies
367
CIFS AV Scan Connector
This log contains CIFS server messages. This server is used by the mGuard itself for share purposes.
In addition, messages that occur when connecting the network drives and are grouped together and provided by the CIFS server are also visible.
CIFS Integrity Checking
Messages relating to the integrity check of network drives are displayed in this log.
In addition, messages that occur when connecting the network drives and are required for the integrity check are also visible.
DHCP server/relay
Messages from the services defined under “Network -> DHCP”.
SNMP/LLDP
Messages from services defined under “Management -> SNMP”.
IPsec VPN
Lists all VPN events.
The format corresponds to standard Linux format.
There are special evaluation programs that present information from the logged data in a more easily readable format.
OpenVPN Client
Lists all OpenVPN events.
Dynamic Routing
Lists all Dynamic Routing events.
368
Innominate Security Technologies I15020_en_03
Support menu
16 Support menu
16.1
Support >> Tools
16.1.1
Ping Check
Support >> Tools >> Ping Check
Ping Check Aim: to check whether a partner can be accessed via a network.
Procedure:
• Enter the IP address or host name of the partner in the Hostname/IP Address field.
Then click on Ping.
A corresponding message is then displayed.
16.1.2
Traceroute
Support >> Tools >> Traceroute
Traceroute Aim: to determine which intermediate points or routers are located on the connection path to a partner.
Procedure:
• Enter the host name or IP address of the partner whose route is to be determined in the Hostname/IP Address field.
• If the points on the route are to be output with IP addresses instead of host names (if applicable), activate the Do not resolve IP addresses to hostnames checkbox.
• Then click on Trace.
A corresponding message is then displayed.
Innominate Security Technologies
369
I15020_en_03
16.1.3
DNS Lookup
Support >> Tools >> DNS Lookup
DNS Lookup Aim: to determine which host name belongs to a specific IP address or which IP address belongs to a specific host name.
Procedure:
• Enter the IP address or host name in the Hostname field.
• Click on Lookup.
The response, which is determined by the mGuard according to the DNS configuration, is then returned.
16.1.4
IKE Ping
Support >> Tools >> IKE Ping
IKE Ping Aim: to determine whether the VPN software for a VPN gateway is able to establish a VPN
Procedure:
• Enter the name or IP address of the VPN gateway in the Hostname/IP Address field.
• Click on Ping.
• A corresponding message is then displayed.
370
Innominate Security Technologies I15020_en_03
16.2
Support >> Advanced
16.2.1
Hardware
This page lists various hardware properties of the mGuard.
Support menu
I15020_en_03
16.2.2
Snapshot
This function is used for support purposes.
It creates a compressed file (in tar.gz format) containing all active configuration settings and log entries that could be relevant for error diagnostics.
This file does not contain any private information such as private machine certificates or passwords. However, any pre-shared keys of VPN connections are contained in the snapshots.
To create a snapshot, proceed as follows:
• Click on Download.
• Save the file (under the name “snapshot.tar.gz”).
Provide the file to the support team of your dealer, if required.
Innominate Security Technologies
371
372
Innominate Security Technologies I15020_en_03
Redundancy
17 Redundancy
There are several different ways of compensating for errors using the mGuard so that an existing connection is not interrupted.
– Firewall redundancy: two identical mGuard devices can be combined to form a redundant pair, meaning one takes over the functions of the other if an error occurs.
– VPN redundancy: an existing firewall redundancy forms the basis for VPN redundancy. In addition, the VPN connections are designed so that at least one mGuard in a redundant pair operates the VPN connections.
– Ring/network coupling: in ring/network coupling, another method is used. Parts of a network are designed as redundant. In the event of errors, the alternative path is selected.
17.1
Firewall redundancy
Using firewall redundancy, it is possible to combine two identical mGuard devices into a redundant pair (single virtual router). One mGuard takes over the functions of the other if an error occurs. Both mGuard devices run synchronously, meaning an existing connection is not interrupted when the device is switched.
I15020_en_03
Figure 17-1 Firewall redundancy (example)
Basic requirements for firewall redundancy
A license is required for the firewall redundancy function. It can only be used if the corresponding license has been purchased and installed.
– Only identical mGuard devices can be used together in a redundant pair.
– In Router network mode, firewall redundancy is only supported with the “static” Router mode.
– The Stealth network mode is currently not supported.
–
For further restrictions, see “Requirements for firewall redundancy” on page 376 and
“Limits of firewall redundancy” on page 386.
Innominate Security Technologies
373
17.1.1
Components in firewall redundancy
Firewall redundancy is comprised of several components:
– Connectivity check
Checks whether the necessary network connections have been established.
– Availability check
Checks whether an active mGuard is available and whether this should remain active.
– State synchronization of the firewall
The mGuard on standby receives a copy of the current firewall database state.
– Virtual network interface
Provides virtual IP addresses and MAC addresses that can be used by other devices as routes and default gateways.
– State monitoring
Coordinates all components.
– Status indicator
Shows the user the state of the mGuard.
Connectivity check
On each mGuard in a redundant pair, checks are constantly made as to whether a connection is established through which the network packets can be forwarded.
Each mGuard checks its own internal and external network interfaces independently of each other. Both interfaces are tested for a continuous connection. This connection must be in place, otherwise the connectivity check will fail.
ICMP echo requests can also be sent (optional). The ICMP echo requests can be set using
the Redundancy >> Firewall Redundancy >> Connectivity Checks menu.
Availability check
On each mGuard in a redundant pair, checks are also constantly performed to determine whether an active mGuard is available and whether it should remain active. A variation of the CARP (Common Address Redundancy Protocol) is used here.
The active mGuard constantly sends presence notifications through its internal and external network interface while both mGuard devices listen. If a dedicated Ethernet link for state synchronization of the firewall is available, the presence notification is also sent via this link.
In this case, the presence notification for the external network interface can also be suppressed.
The availability check fails if an mGuard does not receive any presence notifications within a certain time. The check also fails if an mGuard receives presence notifications with a lower priority than its own.
The data is always transmitted through the physical network interface and never through the virtual network interface.
374
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
State synchronization
The mGuard on standby receives a copy of the state of the mGuard that is currently active.
This includes a database containing the forwarded network connections. This database is filled and updated constantly by the forwarded network packets. It is protected against unauthorized access. The data is transmitted through the physical LAN interface and never through the virtual network interface.
To keep internal data traffic to a minimum, a VLAN can be configured to store the synchronization data in a separate multicast and broadcast domain.
Virtual IP addresses
Each mGuard is configured with virtual IP addresses. The number of virtual IP addresses depends on the network mode used. Both mGuard devices in a redundant pair must be assigned the same virtual IP addresses. The virtual IP addresses are required by the mGuard to establish virtual network interfaces.
Two virtual IP addresses are required in Router network mode, while others can be created.
One virtual IP address is required for the external network interface and the other for the internal network interface.
These IP addresses are used as a gateway for routing devices located in the external or internal LAN. In this way, the devices can benefit from the high availability resulting from the use of both redundant mGuard devices.
The redundant pair automatically defines MAC addresses for the virtual network interface.
These MAC addresses are identical for the redundant pair. In Router network mode, both mGuard devices share a MAC address for the virtual network interface connected to the external and internal Ethernet segment.
In Router network mode, the mGuard devices support forwarding of special UDP/TCP ports from a virtual IP address to other IP addresses, provided the other IP addresses can be reached by the mGuard. In addition, the mGuard also masks data with virtual IP addresses when masquerading rules are set up.
State monitoring
State monitoring is used to determine whether the mGuard is active, on standby or has an error. Each mGuard determines its own state independently, based on the information provided by other components. State monitoring ensures that two mGuard devices are not active at the same time.
Status indicator
The status indicator contains detailed information on the firewall redundancy state. A sum-
mary of the state can be called up using the Redundancy >> Firewall Redundancy >> Re-
dundancy or Redundancy >> Firewall Redundancy >> Connectivity Checks menus.
Innominate Security Technologies
375
17.1.2
Interaction of the firewall redundancy components
During operation, the components work together as follows: both mGuard devices perform ongoing connectivity checks for both of their network interfaces (internal and external). In addition, an ongoing availability check is performed. Each mGuard listens continuously for presence notifications (CARP) and the active mGuard also sends them.
Based on the information from the connectivity and availability checks, the state monitoring function is made aware of the state of the mGuard devices. State monitoring ensures that the active mGuard mirrors its data onto the other mGuard (state synchronization).
17.1.3
Firewall redundancy settings from previous versions
Existing configuration profiles on firmware version 6.1.x (and earlier) can be imported with certain restrictions. For information, please contact Innominate.
17.1.4
Requirements for firewall redundancy
– To use the redundancy function, both mGuards must have the same firmware.
– The firewall redundancy function can only be activated when a valid license key is installed.
(See under: Redundancy >> Firewall Redundancy >> Redundancy >> Enable redun- dancy)
–
Redundancy >> Firewall Redundancy >> Redundancy >> Interface which is used for state synchronization
The Dedicated interface value is only accepted on mGuards which have more than
– Each set of targets for the connectivity check can contain more than ten targets (A failover time cannot be guaranteed without an upper limit).
Redundancy >> Firewall Redundancy >> Redundancy
–
>> External interface >> Primary targets for ICMP echo requests
–
>> External interface >> Secondary targets for ICMP echo requests
–
>> Internal interface >> Primary targets for ICMP echo requests
–
>> Internal interface >> Secondary targets for ICMP echo requests
If “at least one target must respond” or “all targets of one set must respond” is selected
under External interface >> Kind of check, then External interface >> Primary targets
for ICMP echo requests cannot be left empty. This also applies to the internal interface.
– In Router network mode, at least one external and one internal virtual IP address must be set. A virtual IP address cannot be listed twice.
376
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
17.1.5
Fail-over switching time
The mGuard calculates the intervals for the connectivity check and availability check automatically according to the variables under Fail-over switching time.
Connectivity check
64-kbyte ICMP echo requests are sent for the connectivity check. They are sent on layer 3 of the Internet protocol. When VLAN is not used, 18 bytes for the MAC header and checksum are added to this with the Ethernet on layer 2. The ICMP echo reply is the same size.
a single target and adds up the bytes for the ICMP echo request and reply.
The timeout on the mGuard following transmission includes the following:
– The time required by the mGuard to transmit an ICMP echo reply. If other data traffic is expected, the half-duplex mode is not suitable here.
– The time required for the transmission of the ICMP echo request to a target. Consider the latency during periods of high capacity utilization. This applies especially when routers forward the request. The actual latency may be twice the value of the configured latency in unfavorable circumstances (connectivity check error).
– The time required on each target for processing the request and transmitting the reply to the Ethernet layer. Please note that the full-duplex mode is also used here.
– The time for transmission of the ICMP echo reply to the mGuard.
Table 17-1 Frequency of the ICMP echo requests
Fail-over switching time
1 s
3 s
10 s
ICMP echo requests per target
10 per second
Timeout on the mGuard after transmission
100 ms
3.3 per second
1 per second
300 ms
1 s
Bandwidth per target
6560 bps
2187 bps
656 bps
If secondary targets are configured, then additional ICMP echo requests may occasionally be sent to these targets. This must be taken into account when calculating the ICMP echo request rate.
The timeout for a single ICMP echo request is displayed in Table 17-1. This does not indi-
cate how many of the responses can be missed before the connectivity check fails. The check tolerates a negative result for one of two back-to-back intervals.
Availability check
Presence notifications (CARP) measure up to 76 bytes on layer 3 of the Internet protocol.
When VLAN is not used, 18 bytes for the MAC header and checksum are added to this with the Ethernet on layer 2. The ICMP echo reply is the same size.
Table 17-2 shows the maximum frequency at which the presence notifications (CARP) are
sent from the active mGuard. It also shows the bandwidth used in the process. The fre-
quency depends on the mGuard priority and the Fail-over switching time.
Innominate Security Technologies
377
Table 17-2 also shows the maximum latency tolerated by the mGuard for the network that
is used to transmit the presence notifications (CARP). If this latency is exceeded, the redundant pair can exhibit undefined behavior.
Table 17-2
Fail-over switching time
1 s
3 s
10 s
Frequency of the presence notifications (CARP)
Presence notifications (CARP) per second
High priority Low priority
Maximum latency
50 per second 25 per second
16.6 per second 8.3 per second
5 per second 2.5 per second
20 ms
60 ms
200 ms
Bandwidth on layer 2 for the high priority
378
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
17.1.6
Error compensation through firewall redundancy
Firewall redundancy is used to compensate for hardware failures.
Figure 17-2
Figure 17-2 shows a diagram containing various error locations (not related to the network
mode)
Each of the mGuard devices in a redundant pair is located in a different area (A and B). The mGuard in area A is connected to switch A1 through its external Ethernet interface and to switch A2 through its internal Ethernet interface. mGuard B is connected accordingly to switches B1 and B2. In this way, the switches and mGuard devices connect an external
Ethernet network to an internal Ethernet network. The connection is established by forwarding network packets (in Router network mode).
Firewall redundancy compensates for errors displayed in Figure 17-2 if only one occurs at
any given time. If two errors occur simultaneously, they are only compensated if they occur in the same area (A or B).
For example, if one of the mGuard devices fails completely due to a power outage, then this is detected. A connection failure is compensated if the connection fails completely or partially. When the connectivity check is set correctly, a faulty connection caused by the loss of data packets or an excessive latency is detected and compensated. Without the connectivity check, the mGuard cannot determine which area caused the error.
A connection failure between switches on a network side (internal/external) is not compen-
Innominate Security Technologies
379
17.1.7
Handling firewall redundancy in extreme situations
The situations described here only occur rarely.
Restoration in the event of a network lobotomy
A network lobotomy occurs if a redundant pair is separated into two mGuard devices operating independently of one another. In this case, each mGuard deals with its own tracking information as the two mGuard devices can no longer communicate via layer 2. A network lobotomy can be triggered by a rare and unfortunate combination of network settings, network failures, and firewall redundancy settings.
Each mGuard is active during a network lobotomy. The following occurs after the network lobotomy has been rectified: if the mGuard devices have different priorities, the device with the higher priority becomes active and the other switches to standby. If both mGuard devices have the same priority, an identifier sent with the presence notifications (CARP) determines which mGuard becomes active.
Both mGuard devices manage their own firewall state during the network lobotomy. The active mGuard retains its state. Connections on the other mGuard, which were established during the lobotomy, are dropped.
Fail-over when establishing complex connections
Complex connections are network protocols which are based on different IP connections.
One example of this is the FTP protocol. In an FTP protocol, the client establishes a control channel for a TCP connection. The server is then expected to open another TCP connection of is up while the control channel on port 21 of the server is being established.
needs to create a firewall rule on the mGuard which allows the client to establish a control channel to the FTP server. The mGuard enables the server to establish a data channel automatically, regardless of whether the firewall rules allow for this.
The tracking of complex connections is part of the firewall state synchronization process.
However, to keep the latency short, the mGuard forwards the network packets independently from the firewall state synchronization update that has been triggered by the network packets themselves.
Therefore, it may be the case for a very brief period that a state change for the complex connection is not forwarded to the mGuard on standby if the active mGuard fails. In this case, tracking of the connection from the mGuard which is active after the fail-over is not continued correctly. This cannot be corrected by the mGuard. The data link is then reset or interrupted.
Fail-over when establishing semi-unidirectional connections
A semi-unidirectional connection refers to a single IP connection (such as UDP connections) where the data only travels in one direction after the connection is established with a bidirectional handshake.
The data flows from the responder to the initiator. The initiator only sends data packets at the very start.
The following applies only to certain protocols which are based on UDP. Data always flows in both directions on TCP connections.
380
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
If the firewall of the mGuard is set up to only accept data packets from the initiator, the firewall accepts all related responses per se. This happens regardless of whether or not a relevant firewall rule is available.
A scenario is conceivable in which the mGuard allows the initiating data packet to pass through and then fails before the relevant connection entry has been made in the other mGuard. The other mGuard may then reject the responses as soon as it becomes the active mGuard.
The mGuard cannot correct this situation due to the single-sided connection. As a countermeasure, the firewall can be configured so that the connection can be established in both directions. This is normally already handled via the protocol layer and no additional assignment is required.
Loss of data packets during state synchronization
If data packets are lost during state synchronization, this is detected automatically by the mGuard, which then requests the active mGuard to send the data again.
This request must be answered within a certain time, otherwise the mGuard on standby is assigned the “outdated” state and asks the active mGuard for a complete copy of all state information.
The response time is calculated automatically from the fail-over switching time. This is longer than the time for presence notifications (CARP), but shorter than the upper limit of the fail-over switching time.
Loss of presence notifications (CARP) during transmission
A one-off loss of presence notifications (CARP) is tolerated by the mGuard, but it does not tolerate the loss of subsequent presence notifications (CARP). This applies to the availability check on each individual network interface, even when these are checked simultaneously. It is therefore very unlikely that the availability check will fail as a result of a very brief network interruption.
Loss of ICMP echo requests/replies during transmission
ICMP echo requests or replies are important for the connectivity check. Losses are always observed, but are tolerated under certain circumstances.
The following measures can be used to increase the tolerance level on ICMP echo requests.
–
Select at least one target must respond under Kind of check in the Redundancy >> Fire-
wall Redundancy >> Connectivity Checks menu.
– Also define a secondary set of targets here. The tolerance level for the loss of ICMP echo requests can be further increased by entering the targets of unreliable connections under both sets (primary and secondary) or listing them several times within a set.
Innominate Security Technologies
381
Restoring the primary mGuard following a failure
If a redundant pair is defined with different priorities, the secondary mGuard becomes active if the connection fails. The primary mGuard becomes active again after the failure has been rectified. The secondary mGuard receives a presence notification (CARP) and returns to standby mode.
State synchronization
If the primary mGuard becomes active again after a failure of the internal network connection, it may contain an obsolete copy of the firewall database. This database must, therefore, be updated before the connection is reestablished. The primary mGuard ensures that it receives an up-to-date copy before becoming active.
17.1.8
Interaction with other devices
Virtual and actual IP addresses
With firewall redundancy in Router network mode, the mGuard uses actual IP addresses to communicate with other network devices.
Virtual IP addresses are used in the following two cases:
– Virtual IP addresses are used when establishing and operating VPN connections.
– If DNS and NTP services are used according to the configuration, they are offered to internal virtual IP addresses.
The usage of actual (management) IP addresses is especially important for the connectivity check and availability check. Therefore, the actual (management) IP address must be configured so that the mGuard can establish the required connections.
The following are examples of how and why mGuard communication takes place:
– Communication with NTP servers to synchronize the time
– Communication with DNS servers to resolve host names (especially those from VPN partners)
– To register its IP address with a DynDNS service
– To send SNMP traps
– To forward log messages to a SysLog server
– To download a CRL from an HTTP(S) server
– To authenticate a user through a RADIUS server
– To download a configuration profile through an HTTPS server
– To download a firmware update from an HTTPS server
With firewall redundancy in Router network mode, devices connected to the same LAN segment as the redundant pair must use their respective virtual IP addresses as gateways for their routes. If these devices were to use the actual IP address of either of the mGuard devices, this would work until that particular mGuard failed. However, the other mGuard would then not be able to take over.
382
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
Targets for the connectivity check
If a target is set for ICMP echo requests as part of the connectivity check, these requests must be answered within a certain time, even if the network is busy with other data. The network path between the redundant pair and these targets must be set so that it is also able to forward the ICMP responses when under heavy load. Otherwise, the connectivity check for an mGuard could erroneously fail.
Targets can be configured for the internal and external interface in the connectivity check
(see “Connectivity Checks” on page 355). It is important that these targets are actually con-
nected to the specified interface. An ICMP echo reply cannot be received by an external interface when the target is connected to the internal interface (and vice versa). When the static routes are changed, it is easy to forget to adjust the configuration of the targets accordingly.
The targets for the connectivity check should be well thought out. Without a connectivity check, all it takes are two errors for a network lobotomy to occur.
A network lobotomy is prevented if the targets for both mGuard devices are identical and all targets have to answer the request. However, the disadvantage of this method is that the connectivity check fails more often if one of the targets does not offer high availability.
In Router network mode, we recommend defining a highly available device as the target on the external interface. This can be the default gateway for the redundant pair (e.g., a virtual router comprised of two independent devices). In this case, either no targets or a selection of targets should be defined on the internal interface.
Please also note the following information when using a virtual router consisting of two independent devices as the default gateway for a redundant pair. If these devices use VRRP to synchronize their virtual IP, then a network lobotomy could split the virtual IP of this router into two identical copies. These routers could use a dynamic routing protocol and only one may be selected for the data flows of the network being monitored by the mGuard. Only this router should keep the virtual IP. Otherwise, you can define targets which are accessible via this route in the connectivity check. In this case, the virtual IP address of the router would not be a sensible target.
Redundant group
Several redundant pairs can be connected within a LAN segment (redundant group). You define a value as an identifier (through the router ID) for each virtual instance of the redundant pair. As long as these identifiers are different, the redundant pairs do not come into conflict with each other.
Data traffic
In the event of a high latency in a network used for state synchronization updates or a serious data loss on this network, the mGuard on standby is assigned the “outdated” state. This does not occur, however, as long as no more than two back-to-back updates are lost. This is because the mGuard on standby automatically requests a repeat of the update. The la-
tency requirements are the same as those detailed under“Fail-over switching time” on page
Innominate Security Technologies
383
Sufficient bandwidth
The data traffic generated as a result of the connectivity check, availability check, and state synchronization uses bandwidth on the network. The connectivity check also generates complicated calculations. There are several ways to limit this or stop it completely.
If the influence on other devices is unacceptable:
– The connectivity check must either be deactivated, or must only relate to the actual IP address of the other mGuard.
– The data traffic generated by the availability check and state synchronization must be moved to a separate VLAN.
– Switches must be used which allow separation of the VLANs.
Dedicated interface reserved, direct Ethernet interface or a dedicated LAN segment, via which the state synchronization is sent. This separates the load physically from the internal LAN segment.
384
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
17.1.9
Transmission capacity with firewall redundancy
These values apply to Router network mode when the data traffic for state synchronization is transmitted without encryption. If the transmission capacity described here is exceeded, in the event of errors the switching time may be longer than that set.
Platform Transmission capacity with firewall redundancy
frames/s
150 Mbps
1
, bidirectional, not more than 12,750 frames/s with with
, not more than 5250 frames/s
, not more than 5250 frames/s
1 in each direction.
Fail-over switching time
The fail-over switching time can be set to 1, 3 or 10 seconds in the event of errors.
Innominate Security Technologies
385
17.1.10
Limits of firewall redundancy
– In Router network mode, firewall redundancy is only supported with the “static” mode.
– Access to the mGuard via the HTTPS, SNMP, and SSH management protocols is only possible with an actual IP address from each mGuard. Access attempts to virtual addresses are rejected.
– The following features cannot be used with firewall redundancy.
– A secondary external Ethernet interface
– A DHCP server
– A DHCP relay
– A SEC-Stick server
– A user firewall
– CIFS Integrity Monitoring
– The redundant pair must have the same configuration. Take this into account when making the following settings:
– NAT settings (masquerading, port forwarding, and 1:1 NAT)
– Flood protection
– Packet filter (firewall rules, MAC filter, advanced settings)
– Queues and rules for QoS
– Some network connections may be interrupted following a network lobotomy. (See
“Restoration in the event of a network lobotomy” on page 380).
– After a fail-over, semi-unidirectional or complex connections that were established
– Firewall redundancy does not support the mGuard pci in Driver mode.
– State synchronization does not replicate the connection tracking entries for ICMP echo
requests forwarded by the mGuard. Therefore, ICMP echo replies can be dropped according to the firewall rules if they only reach the mGuard after the fail-over is completed. Please note that ICMP echo replies are not suitable for measuring the fail-over switching time.
– Masquerading involves hiding the transmitter behind the first virtual IP address or the first internal IP address. This is different to masquerading on the mGuard without firewall redundancy. When firewall redundancy is not activated, the external or internal IP address hiding the transmitter is specified in a routing table.
386
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
17.2
VPN redundancy
VPN redundancy can only be used together with firewall redundancy.
The concept is the same as for firewall redundancy. In order to detect an error in the system environment, the activity is transmitted from the active mGuard to the mGuard on standby.
At any given point in time, at least one mGuard in the redundant pair is operating the VPN connection (except in the event of a network lobotomy).
Basic requirements for VPN redundancy
VPN redundancy does not have any of its own variables. It currently does not have its own menu in the user interface – it is activated together with firewall redundancy instead.
VPN redundancy can only be used if the corresponding license has been purchased and installed on the mGuard.
As VPN connections must be established for VPN redundancy, a corresponding VPN license is also necessary.
If you only have the license for firewall redundancy and VPN connections are installed, VPN redundancy cannot be activated. An error message is displayed as soon as an attempt is made to use firewall redundancy.
Only identical mGuard devices can be used together in a redundant pair.
17.2.1
Components in VPN redundancy
The components used in VPN redundancy are the same as described under firewall redundancy. One additional component is available here – VPN state synchronization. A small number of components are slightly expanded for VPN redundancy. However, the connectivity check, availability check, and firewall state synchronization are all performed in the same way as before.
VPN state synchronization
The mGuard supports the configuration of firewall rules for the VPN connection.
VPN state synchronization monitors the state of the different VPN connections on the active mGuard. It ensures that the mGuard on standby receives a valid, up-to-date copy of the
VPN state database.
As with state synchronization of the firewall, VPN state synchronization sends updates from the active mGuard to the mGuard on standby. If requested to do so by the mGuard on standby, the active mGuard sends a complete record of all state information. third Ethernet interface for the VPN state synchronization.
As with the state synchronization of the firewall, the data traffic for the VPN state synchroni-
zation for the dedicated interface is transmitted when a variable is set. Under Redundancy
>> Firewall Redundancy >> Redundancy set the Interface which is used for state synchro-
nization to Dedicated Interface.
Innominate Security Technologies
387
Establishing VPN connections
In VPN redundancy, the virtual network interface is used for an additional purpose – to establish, accept, and operate the VPN connections. The mGuard only listens on the first virtual IP address.
In Router network mode, it listens at the first external and internal virtual IP addresses.
State monitoring
State monitoring is used to monitor state synchronization on both the VPN and firewall.
Status indicator
The status indicator shows additional detailed information on the status of VPN state synchronization. This is located directly next to the information for firewall state synchronization.
As an ancillary effect, the status indicator of the VPN connection can also be seen on the mGuard on standby. You can, therefore, find the contents of the VPN state database repli-
cated under the normal status indicator for the VPN connection (under IPsec VPN >> IPsec
Only the state of the synchronization process is shown in the status indicator for firewall re-
dundancy (Redundancy >> FW Redundancy Status >> Redundancy Status).
17.2.2
Interaction of the VPN redundancy components
The individual components interact in the same way as described for firewall redundancy.
VPN state synchronization is also controlled by state monitoring. The state is recorded and updates are sent.
Certain conditions must be met for the states to occur. VPN state synchronization is taken into account here.
17.2.3
Error compensation through VPN redundancy
However, the VPN section can hinder the other VPN gateways in the event of a network lobotomy. The independent mGuard devices then have the same virtual IP address for communicating with the VPN partners. This can result in VPN connections being established and disconnected in quick succession.
388
Innominate Security Technologies I15020_en_03
Redundancy
17.2.4
Setting the variables for VPN redundancy
If the required license keys are installed, VPN redundancy is automatically activated at the
There is no separate menu for VPN redundancy. The existing firewall redundancy variables are expanded.
Expanded functions with VPN redundancy activated Table 17-3
Redundancy >> Firewall Redundancy >> Redundancy
General Enable redundancy Firewall redundancy and VPN redundancy are activated or deactivated.
Virtual interfaces External virtual IP addresses
Only in Router network mode.
The mGuard uses the first external virtual IP address as the address from which it sends and receives IKE messages.
Internal virtual IP addresses
The external virtual IP address is used instead of the actual primary IP address of the external network interface.
The mGuard no longer uses the actual IP address to send or answer IKE messages.
ESP data traffic is handled similarly, but is also accepted and processed by the actual IP address.
As described under External virtual IP addresses, but for inter-
nal virtual IP addresses.
I15020_en_03 Innominate Security Technologies
389
17.2.5
Requirements for VPN redundancy
– VPN redundancy can only be activated if a license key is installed for VPN redundancy and a VPN connection is activated.
– mGuard rs4000 mGuard
If a VPN connection is controlled via a VPN switch, then VPN redundancy cannot be activated.
(See under: IPsec VPN >> Global >> Options >> VPN Switch)
During VPN state synchronization, the state of the VPN connection is sent continuously from the active mGuard to the one on standby so that it always has an up-to-date copy in the event of errors. The only exception is the state of the IPsec replay window. Changes there are only transmitted sporadically.
The volume of the data traffic for state synchronization does not depend on the data traffic sent over the VPN tunnels. The data volumes for state synchronization are defined by a range of parameters that are assigned to the ISAKMP SAs and IPsec SAs.
17.2.6
Handling VPN redundancy in extreme situations
The conditions listed under “Handling firewall redundancy in extreme situations” on page
380 also apply to VPN redundancy. They also apply when the mGuard is used exclusively
for forwarding VPN connections. The mGuard forwards the data flows via the VPN tunnels and rejects incorrect packets, regardless of whether firewall rules have been defined for the
VPN connections or not.
An error interrupts the flow of data traffic
An error that interrupts the data traffic running via the VPN tunnels represents an extreme situation. In this case, the IPsec data traffic is briefly vulnerable to replay attacks. (A replay attack is the repetition of previously sent encrypted data packets using copies which have been saved by the attacker.) The data traffic is protected by sequential numbers. Independent sequential numbers are used for each direction in an IPsec tunnel. The mGuard drops
ESP packets which have the same sequential number as a packet that has already been decrypted for a specific IPsec tunnel by the mGuard. This mechanism is known as the IPsec
replay window.
The IPsec replay window is only replicated sporadically during state synchronization, as it is very resource-intensive. Therefore, the active mGuard may have an obsolete IPsec replay window following a fail-over. An attack is then possible until the real VPN partner has sent the next ESP packet for the corresponding IPsec SA, or until the IPsec SA has been renewed.
To avoid having an insufficient sequential number for the outgoing IPsec SA, VPN redundancy adds a constant value to the sequential number for each outgoing IPsec SA before the mGuard becomes active. This value is calculated so that it corresponds to the maximum number of data packets which can be sent through the VPN tunnel during the maximum failover switching time. In the worst case (1 Gigabit Ethernet and a switching time of 10 seconds), this is 0.5% of an IPsec sequence. At best, this is only one per thousand.
Adding a constant value to the sequential number prevents the accidental reuse of a sequence number already used by the other mGuard shortly before it failed. Another effect is that ESP packets sent from the previously active mGuard are dropped by the VPN partner if new ESP packets are received earlier from the mGuard that is currently active. To do this, the latency on the network must differ from the fail-over switching time.
390
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
An error interrupts the initial establishment of the ISAKMP standby can continue the process seamlessly, as the state of the SA is replicated synchronously. The response to an IKE message is only sent from the active mGuard after the mGuard on standby has confirmed receipt of the corresponding VPN state synchronization update.
When an mGuard becomes active, it immediately repeats the last IKE message which should have been sent from the previously active mGuard. This compensates for cases where the previously active mGuard has sent the state synchronization but has failed before it could send the corresponding IKE message.
SA SA is only delayed by the switching time during a fail-over.
If an error interrupts the renewal of an ISAKMP SA, this is compensated in the same way as during the initial establishment of the SA. The old ISAKMP SA is also kept for Dead Peer
Detection until the renewal of the ISAKMP SA is complete.
If an error interrupts the renewal of an IPsec SA, this is compensated in the same way as during the initial establishment of the SA. Until renewal of the ISAKMP SA is complete, the old outgoing and incoming IPsec SAs are retained until the VPN partner notices the change.
VPN state synchronization ensures that the old IPsec SAs are retained throughout the entire time that the mGuard remains on standby. When the device becomes active, it can then continue with the encryption and decryption of the data traffic without the need for further action.
Loss of data packets during VPN state synchronization
State synchronization can cope with the loss of one of two back-to-back update packets. If more data packets are lost, this can result in a longer switching time in the event of errors.
The mGuard on standby has an obsolete machine certificate
X.509 certificates and private keys used by a redundant pair to authenticate itself as a VPN partner may need to be changed. The combination of a private key and certificate is hereafter referred to as a machine certificate.
Each mGuard in a redundant pair must be reconfigured in order to switch the machine certificate. Both mGuard devices also require the same certificate so that their VPN partners view them as one and the same virtual VPN device.
As each mGuard has to be reconfigured individually, it may be the case that the mGuard on standby has an obsolete machine certificate for a brief period.
being established, this procedure cannot be continued with an obsolete machine certificate.
As a countermeasure, VPN state synchronization replicates the machine certificate from the active mGuard to the mGuard on standby. In the event of a fail-over, the mGuard on standby will only use this to complete the process of establishing the ISAKMP SAs where this has already been started.
If the mGuard on standby establishes new ISAKMP SAs after a fail-over, it uses the machine certificate that has already been configured.
Innominate Security Technologies
391
VPN state synchronization therefore ensures that the currently used machine certificates are replicated. However, it does not replicate the configuration itself.
The mGuard on standby has an obsolete Pre-Shared Key (PSK)
Pre-Shared Keys (PSK) also need to be renewed on occasion in order to authenticate VPN partners. The redundant mGuard devices may then have a different PSK for a brief period.
In this case, only one of the mGuard devices can establish a VPN connection as most VPN partners only accept one PSK. The mGuard does not offer any countermeasures for this.
We therefore recommend using X.509 certificates instead of PSKs.
If VPN state synchronization replicates the PSKs being sent to the mGuard on standby for a prolonged period, an incorrect configuration remains concealed during this period, making it difficult to detect.
17.2.7
Interaction with other devices
Resolving host names
If host names are configured as VPN gateways, the mGuard devices in a redundant pair must be able to resolve the host names for the same IP address. This applies especially
If the host names are resolved from the mGuard on standby to another IP address, the VPN connection to this host is interrupted following a fail-over. The VPN connection is reestablished through another IP address. This takes place directly after the fail-over. However, a short delay may occur, depending (among other things) on what value is entered under
DynDNS Monitoring for the Refresh Interval (sec).
Obsolete IPsec replay window
IPsec data traffic is protected against unauthorized access. To this end, each IPsec tunnel is assigned an independent sequential number. The mGuard drops ESP packets which have the same sequential number as a packet that has already been decrypted for a specific
IPsec tunnel by the mGuard. This mechanism is known as the IPsec replay window. It prevents replay attacks, where an attacker sends previously recorded data to simulate someone else's identity.
The IPsec replay window is only replicated sporadically during state synchronization, as it is very resource-intensive. Therefore, the active mGuard may have an obsolete IPsec replay window following a fail-over. This means that a replay attack is possible for a brief peor until the IPsec SA has been renewed. However, the traffic must be captured completely for this to occur.
392
Innominate Security Technologies I15020_en_03
Redundancy
Dead Peer Detection
Please note the following point for Dead Peer Detection.
With Dead Peer Detection, set a higher timeout than the upper limit for the Fail-over
switching time on the redundant pair.
(See under: IPsec VPN >> Connections >> Edit >> IKE Options, Delay between requests
Otherwise, the VPN partners may think that the redundant pair is dead, even though it is only dealing with a fail-over.
Data traffic
In the event of a high latency in a network used for state synchronization updates, the mGuard on standby is assigned the “outdated” state. The same thing also happens in the event of serious data losses on this network.
This does not occur, however, as long as no more than two back-to-back updates are lost.
This is because the mGuard on standby automatically requests a repeat of the update. The
latency requirements are the same as those detailed under“Fail-over switching time” on page 377.
Actual IP addresses
VPN partners may not send ESP traffic to the actual IP address of the redundant pair. VPN partners must always use the virtual IP address of the redundant pair to send IKE messages or ESP traffic.
I15020_en_03 Innominate Security Technologies
393
17.2.8
Transmission capacity with VPN redundancy
These values apply to Router network mode when the data traffic for state synchronization is transmitted without encryption. If the transmission capacity described here is exceeded, in the event of errors the switching time may be longer than that set.
Platform Transmission capacity with firewall redundancy
220 Mbps
50 Mbps, bidirectional
1
, not more than 5550 frames/s with with
17 Mbps, bidirectional
not more than 2300 frames/s
17 Mbps, bidirectional
not more than 2300 frames/s
1 means Mbps ed in each direction.
Fail-over switching time
The fail-over switching time can be set to 1, 3 or 10 seconds in the event of errors.
mGuard centerport² even under high load.
394
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
17.2.9
Limits of VPN redundancy
The limits documented above for firewall redundancy also apply to VPN redundancy (see
“Limits of firewall redundancy” on page 386). Further restrictions also apply.
– The redundant pair must have the same configuration with respect to the following:
– General VPN settings
– Each individual VPN connection
– The mGuard only accepts VPN connections on the first virtual IP address.
– In Router network mode, this means the first internal IP address and the first external IP address.
– The following features cannot be used with VPN redundancy:
– Dynamic activation of the VPN connections using a VPN switch or the CGI script rs4000 Switch and
– Archiving of diagnostic messages for VPN connections
– VPN connections are only supported in Tunnel mode. Transport mode does not take sufficient account of VPN connections.
– The upper limit of the fail-over switching time does not apply to connections which are encapsulated with TCP. Connections of this type are interrupted for a prolonged period during a fail-over. The encapsulated TCP connections must be reestablished by the initiating side after each fail-over. If the fail-over occurred on the initiating side, they can start immediately after the transfer. However, if the fail-over occurred on the answering side, the initiator must first detect the interruption and then reestablish the connection.
– VPN redundancy supports masquerading in the same way as without VPN redundancy. This applies when a redundant pair is masked by a NAT gateway with a dynamic IP address.
For example, a redundant pair can be hidden behind a DSL router, which masks the redundant pair with an official IP address. This DSL router forwards the IPsec data traffic
(IKE and ESP, UDP ports 500 and 4500) to the virtual IP addresses. If the dynamic IP address changes, all active VPN connections which run via the NAT gateway are reestablished.
The connections are reestablished by means of Dead Peer Detection (DPD) using the relevant configured time. This effect is beyond the influence of the mGuard.
– The redundancy function on the mGuard does not support path redundancy. Path redundancy can be achieved using other methods, e.g., by using a router pair. This router pair is seen on the virtual side of the mGuard devices. By contrast, on the other side, each of the routers has different connections.
Path redundancy must not use NAT mechanisms such as masquerading to hide the virtual IP addresses of the mGuard devices. Otherwise, a migration from one path to another would change the IP addresses used to mask the redundant pair. This would mean that all VPN connections (all ISAKMP SAs and all IPsec SAs) would have to be reestablished.
The connections are reestablished by means of Dead Peer Detection (DPD) using the relevant configured time. This effect is beyond the influence of the mGuard.
– In the event of path redundancy caused by a network lobotomy, the VPN connections are no longer supported. A network lobotomy must be prevented whenever possible.
Innominate Security Technologies
395
X.509 certificates for VPN authentication
The mGuard supports the use of X.509 certificates when establishing VPN connections.
This is described in detail under “Authentication” on page 295.
However, there are some special points to note when X.509 certificates are used for authenticating VPN connections in conjunction with firewall redundancy and VPN redundancy.
Switching machine certificates
A redundant pair can be configured so that it uses an X.509 certificate and the corresponding private key together to identify itself to a remote VPN partner as an individual virtual VPN instance.
These X.509 certificates must be renewed regularly. If the VPN partner is set to check the validity period of the certificates, these certificates must be renewed before their validity ex-
pires (see “Certificate settings” on page 213).
If a machine certificate is replaced, all VPN connections which use it are restarted by the mGuard. While this is taking place, the mGuard cannot forward any data via the affected
VPN connections for a certain period of time. This period depends on the number of VPN connections affected, the performance of the mGuard and VPN partners, and the latency of the mGuard devices on the network.
If this is not feasible for redundancy, the VPN partners of a redundant pair must be configured so that they accept all certificates whose validity is confirmed by a set of specific CA
certificates (see “CA Certificates” on page 217 and “Authentication” on page 295).
To do this, select Signed by any trusted CA under IPsec VPN >> Connections >> Edit >>
Authentication / Remote CA Certificate.
If the new machine certificate is issued from a different sub-CA certificate, the VPN partner must be able to recognize this before the redundant pair can use the new machine certificate.
The machine certificate must be replaced on both mGuard devices in a redundant pair.
However, this is not always possible if one cannot be reached. This might be the case in the event of a network failure, for example. The mGuard on standby may then have an obsolete machine certificate when it becomes active. This is another reason for setting the VPN partners so that they use both machine certificates.
The machine certificate is normally also replicated with the corresponding key during VPN state synchronization. In the event of a fail-over, the other mGuard can take over and even continue establishing incomplete ISAKMP SAs.
Switching the remote certificates for a VPN connection
The mGuard can be set to authenticate VPN partners directly using the X.509 certificates shown by these VPN partners. For this to happen, the relevant X.509 certificate must be set
on the mGuard. This is known as the Remote CA Certificate.
If a remote certificate is renewed, for a brief period, only one of the mGuard devices will have a new certificate. We therefore recommend authenticating the VPN partners using CA certificates instead of remote certificates in VPN redundancy.
396
Innominate Security Technologies I15020_en_03
I15020_en_03
Redundancy
Adding a new CA certificate to identify VPN partners
To do this, select Signed by any trusted CA under IPsec VPN >> Connections >> Edit >>
Authentication / Remote CA Certificate.
With this setting, a new CA certificate can be added without affecting the established VPN connections. However, the new CA certificates are used immediately. The X.509 certificate used by the VPN partner to authenticate itself to the mGuard can then be replaced with minimal interruption. The only requirement is ensuring that the new CA certificate is available first.
The mGuard can be set to check the validity period of the certificates provided by the VPN
partner (see “Certificate settings” on page 213). In this case, new trusted CA certificates
must be added to the mGuard configuration. These certificates should also have a validity period.
If the CRL check is activated (under Authentication >> Certificates >> Certificate settings),
one URL (where the corresponding CRL is available) must be maintained for each CA certificate. The URL and CRL must be published before the mGuard uses the CA certificates in order to confirm the validity of the certificates shown by the VPN partners.
Using X.509 certificates with limited validity periods and CRL checks
The use of X.509 certificates is described under “Certificate settings” on page 213 (“Authen-
tication >> Certificates >> Certificate settings” menu).
If X.509 certificates are used and Check the validity period of certificates and CRLs is set, the system time has to be correct. We recommend synchronizing the system time using a trusted NTP server. Each mGuard in a redundant pair can use the other as an additional
NTP server, but not as the only NTP server.
Innominate Security Technologies
397
398
Innominate Security Technologies I15020_en_03
Glossary
18 Glossary
Asymmetrical encryption
DES/3DES
AES
CA certificate
In asymmetrical encryption, data is encrypted with one key and decrypted with a second key. Both keys are suitable for encryption and decryption. One of the keys is kept secret by its owner (private key), while the other is made available to the public (public key), i.e., to potential communication partners.
A message encrypted with the public key can only be decrypted and read by the owner of the associated private key. A message encrypted with the private key can be decrypted by any recipient in possession of the associated public key. Encryption using the private key shows that the message actually originated from the owner of the associated public key.
Therefore, the expression “digital signature” is also often used.
However, asymmetrical encryption methods such as RSA are both slow and susceptible to certain types of attack. As a result, they are often combined with some form of symmetrical encryption (
“Symmetrical encryption” on page 406). On the other hand, concepts are
available enabling the complex additional administration of symmetrical keys to be avoided.
This symmetrical encryption algorithm (
veloped by IBM and checked by the NSA. DES was specified in 1977 by the American National Bureau of Standards (the predecessor of the National Institute of Standards and
Technology (NIST)) as the standard for American governmental institutions. As this was the very first standardized encryption algorithm, it quickly won acceptance in industrial circles, both inside and outside America.
DES uses a 56-bit key length, which is no longer considered secure as the available processing power of computers has greatly increased since 1977.
3DES is a version of DES. It uses keys that are three times as long, i.e., 168 bits in length.
Still considered to be secure today, 3DES is included in the IPsec standard, for example.
AES (Advanced Encryption Standard) has been developed by NIST (National Institute of
Standards and Technology) over the course of many years of cooperation with industry.
This symmetrical encryption standard has been developed to replace the earlier DES standard. AES specifies three different key lengths (128, 192, and 256 bits).
In 1997, NIST started the AES initiative and published its conditions for the algorithm. From the many proposed encryption algorithms, NIST selected a total of five algorithms for closer examination – MARS, RC6, Rijndael, Serpent, and Twofish. In October 2000, the Rijndael algorithm was adopted as the encryption algorithm.
How trustworthy is a certificate and the issuing CA (certification authority)? (
ing this CA's signature. This check only makes sense if there is little doubt that the CA certificate originates from an authentic source (i.e., is authentic). In the event of doubt, the CA certificate itself can be checked. If (as is usually the case) the certificate is a sub-CA certificate (i.e., a CA certificate issued by a sub-certification authority), then the CA certificate of the superordinate CA can be used to check the CA certificate of the subordinate instance.
If a superordinate CA certificate is in turn subordinate to another superordinate CA, then its
CA certificate can be used to check the CA certificate of the subordinate instance, etc. This
“chain of trust” continues down to the root instance (the root CA or certification authority).
The root CA's CA file is necessarily self-signed, since this instance is the highest available and is ultimately the basis of trust. No-one else can certify that this instance is actually the instance in question. A root CA therefore is a state or a state-controlled organization.
Innominate Security Technologies
399
I15020_en_03
Client/server
Datagram
Default route
The mGuard can use its imported CA certificates to check the authenticity of certificates shown by partners. In the case of VPN connections, for example, partners can only be authenticated using CA certificates. This requires all CA certificates to be installed on the mGuard in order to form a chain with the certificate shown by the partner. In addition to the
CA certificate from the CA whose signature appears on the certificate shown by the VPN partner to be checked, this also includes the CA certificate of the superordinate CA, and so forth, up to the root certificate. The more meticulously this “chain of trust” is checked in order to authenticate a partner, the higher the level of security will be.
In a client/server environment, a server is a program or computer which accepts and responds to queries from client programs or client computers.
In data communication, the computer establishing a connection to a server (or host) is also called a client. In other words, the client is the calling computer and the server (or host) is the computer called.
In the IP transmission protocol, data is sent in the form of data packets. These are known as
IP datagrams. An IP datagram is structured as follows
IP header TCP, UDP, ESP, etc. header Data (payload)
The IP header contains:
– The IP address of the sender (source IP address)
– The IP address of the recipient (destination IP address)
– The protocol number of the protocol on the superordinate protocol layer (according to the OSI layer model)
– The IP header checksum used to check the integrity of the received header
The TCP/UDP header contains the following information:
– The port of the sender (source port)
– The port of the recipient (destination port)
– A checksum covering the TCP header and information from the IP header (e.g., source and destination IP addresses)
If a computer is connected to a network, the operating system creates a routing table internally. The table lists the IP addresses that the operating system has identified based on the connected computers and the routes available at that time. Accordingly, the routing table contains the possible routes (destinations) for sending IP packets. If IP packets are to be sent, the computer's operating system compares the IP addresses stated in the IP packets with the entries in the routing table in order to determine the correct route. router's LAN port) has been relayed to the operating system as the default gateway (in the network card's TCP/IP configuration), then this IP address is used as the destination if all other IP addresses in the routing table are not suitable. In this case, the IP address of the router specifies the default route because all IP packets whose IP address has no counterpart in the routing table (i.e., cannot find a route) are directed to this gateway.
400
Innominate Security Technologies I15020_en_03
DynDNS provider
IP address
Glossary
Also known as Dynamic DNS provider. Every computer connected to the Internet has an IP address (IP = Internet Protocol). If the computer accesses the Internet via a dial-up modem,
ISDN or ADSL, its Internet service provider will assign it a dynamic IP address. In other words, the address changes for each online session. Even if a computer is online 24 hours a day without interruption (e.g., flat-rate), the IP address will change during the session.
If this computer needs to be accessible via the Internet, it must have an address that is known to the remote partner. This is the only way to establish a connection to the computer.
However, if the address of the computer changes constantly, this will not be possible. This problem can be avoided if the operator of the computer has an account with a DynDNS provider (DNS = Domain Name Server).
In this case, the operator can set a host name with this provider via which the computer should be accessible, e.g., www.example.com. The DynDNS provider also provides a small program that must be installed and run on the computer concerned. Every time a new Internet session is launched on the local computer, this tool sends the IP address used by the computer to the DynDNS provider. The domain name server registers the current assignment of the host name to the IP address and also informs the other domain name servers on the Internet accordingly.
If a remote computer now wishes to establish a connection to a computer that is registered with the DynDNS provider, then the remote computer can use the host name of the computer as the address. This establishes a connection to the responsible DNS in order to look up the IP address that is currently registered for this host name. The corresponding IP address is sent back from the DNS to the remote computer, which can then use it as the destination address. This now leads directly to the desired computer.
In principle, all Internet addresses are based on this procedure: first, a connection to a DNS is established in order to determine the IP address assigned to the host name. Once this has been accomplished, the established IP address is used to set up a connection to the required partner, which could be any site on the Internet.
Every host or router on the Internet/Intranet has its own unique IP address (IP = Internet Protocol). An IP address is 32 bits (4 bytes) long and is written as four numbers (each between
0 and 255), which are separated by a dot.
An IP address consists of two parts: the network address and the host address.
Network address Host address
All network hosts have the same network address, but different host addresses. The two parts of the address differ in length depending on the size of the respective network (networks are categorized as Class A, B or C).
Class A
Class B
Class C
1st byte
Network address
2nd byte
Network address
Network address
3rd byte
Host address
4th byte
Host address
Host address
I15020_en_03 Innominate Security Technologies
401
IPsec
Subject, certificate
The first byte of the IP address determines whether the IP address of a network device belongs to Class A, B or C. The following is specified:
Class A
Class B
Class C
Value of byte 1 Bytes for the network address
Bytes for the host address
1 - 126 1 3
128 - 191
192 - 223
2
3
2
1
Based on the above figures, the number of Class A networks worldwide is limited to 126.
Each of these networks can have a maximum of 256 x 256 x 256 hosts (3 bytes of address area). There can be 64 x 256 Class B networks and each of these networks can have up to
65,536 hosts (2 bytes of address area: 256 x 256). There can be 32 x 256 x 256 Class C networks and each of these networks can have up to 256 hosts (1 byte of address area).
Subnet mask
Normally, a company network with access to the Internet is only officially assigned a single
IP address, e.g., 123.456.789.21. The first byte of this example address indicates that this company network is a Class B network; in other words, the last two bytes are free to be used for host addressing. Accordingly, an address area for up to 65,536 possible hosts (256 x
256) can be computed.
Such a huge network is not practical and generates a need for subnetworks to be built. The subnet mask is used here. Like an IP address, the mask is 4 bytes long. The bytes representing the network address are each assigned the value 255. The primary purpose of doing this is to enable a portion of the host address area to be “borrowed” and used for addressing subnetworks. For example, if the subnet mask 255.255.255.0 is used on a Class
B network (2 bytes for the network address, 2 bytes for the host address), the third byte, which was actually intended for host addressing, can now be used for subnetwork addressing. This computes to potential support for 256 subnetworks, each with 256 hosts.
IP security (IPsec) is a standard that uses encryption to verify the authenticity of the sender and to ensure the confidentiality and integrity of the data in IP datagrams (
page 400). The components of IPsec are the Authentication Header (AH), the Encapsulat-
ing Security Payload (ESP), the Security Association (SA), and the Internet Key Exchange
(IKE).
At the start of the session, the systems involved in communication must determine which technique should be used and the implications of this choice, e.g., Transport Mode or Tun-
nel Mode.
In Transport Mode, an IPsec header is inserted between the IP header and the TCP or UDP header respectively in each IP datagram. Since the IP header remains unchanged, this mode is only suitable for host-to-host connections.
In Tunnel mode, an IPsec header and a new IP header are prefixed to the entire IP datagram. This means the original datagram is encrypted in its entirety and stored in the payload of the new datagram.
Tunnel Mode is used in VPN applications: the devices at the ends of the tunnel ensure that the datagrams are encrypted/decrypted; in other words, the actual datagrams are completely protected during transfer over a public network.
In a certificate, confirmation is provided by a certification authority (CA) that the certificate does actually belong to its owner. This is done by confirming specific owner properties. Furthermore, the certificate owner must possess the private key that matches the public key in
402
Innominate Security Technologies I15020_en_03
I15020_en_03
Glossary the certificate. (
“X.509 certificate” on page 405).
Example
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=XY, ST=Austria, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA/[email protected]
Validity
Not Before: Oct 29 17:39:10 2000 GMT
Subject: CN=anywhere.com,E=doctrans.de,C=DE,ST=Hamburg,L=Hamburg,O=Innominate,OU=Security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c4:40:4c:6e:14:1b:61:36:84:24:b2:61:c0:b5:
d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd:
9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9:
90:32:81:59:18:16:3f:19:f4:5f:11:68:36:85:f6:
1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25:
7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07:
50:0a:5d:83:61:d4:db:c9:7d:c3:2e:eb:0a:8f:62:
8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9:
f0:b4:95:f5:f9:34:9f:f8:43
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
email:[email protected]
Netscape Comment:
mod_ssl generated test server certificate
Netscape Cert Type:
SSL Server
Signature Algorithm: md5WithRSAEncryption
12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b:
3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7:
82:20:ed:f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9:
cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1:
4d:3f:16:4c:9b:19:56:6a:f2:af:89:54:52:4a:06:34:42:0d:
d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21:
44:e7:c5:09:d2:d5:94:9d:6c:13:07:2f:3b:7c:4c:64:90:bf:
ff:8e
The subject distinguished name (or subject for short) uniquely identifies the certificate owner. The entry consists of several components. These are known as attributes (see the example certificate above). The following table contains a list of possible attributes. The sequence of attributes in an X.509 certificate can vary.
CN
Abbreviation
E
OU
O
Name
Common name
E-mail address
Organizational unit
Organization
Explanation
Identifies the person or object to whom or which the certificate belongs.
Example: CN=server1
Specifies the e-mail address of the certificate owner.
Specifies the department within an organization or company.
Example: O=Development
Specifies the organization or company.
Example: O=Innominate
Innominate Security Technologies
403
NAT (Network Address
Translation)
Port number
Proxy
L
ST
C
Abbreviation
Locality
State
Country
Name Explanation
Specifies the place/locality.
Example: L=Hamburg
Specifies the state or county.
Example: ST=Bavaria
Two-letter code that specifies the country. (Germany=DE)
Example: C=DE
A filter can be set for the subject (i.e., the certificate owner) during VPN connections and remote service access to the mGuard using SSH or HTTPS. This would ensure that only certificates from partners are accepted that have certain attributes in the subject line.
Network Address Translation (NAT) (also known as IP masquerading) “hides” an entire network behind a single device, known as a NAT router. If you communicate externally via a
NAT router, the internal computers in the local network and their IP addresses remain hidden. The remote communication partner will only see the NAT router with its IP address.
In order to allow internal computers to communicate directly with external computers (on the
Internet), the NAT router must modify the IP datagrams that are sent from internal computers to remote partners and received by internal computers from remote partners.
If an IP datagram is sent from the internal network to a remote partner, the NAT router modifies the UDP and TCP headers of the datagram, replacing the source IP address and source port with its own official IP address and a previously unused port. For this purpose, the NAT router uses a table in which the original values are listed together with the corresponding new ones.
When a response datagram is received, the NAT router uses the specified destination port to recognize that the datagram is intended for an internal computer. Using the table, the
NAT router replaces the destination IP address and port before forwarding the datagram via the internal network.
A port number is assigned to each device in UDP and TCP protocol-based communication.
This number makes it possible to differentiate between multiple UDP or TCP connections between two computers and use them simultaneously.
Certain port numbers are reserved for specific purposes. For example, HTTP connections are usually assigned to TCP port 80 and POP3 connections to TCP port 110.
A proxy is an intermediary service. A web proxy (e.g., Squid) is often connected upstream of a large network. For example, if 100 employees access a certain website frequently over a web proxy, then the proxy only loads the relevant web pages from the server once and then distributes them as needed among the employees. Remote web traffic is reduced, which saves money.
404
Innominate Security Technologies I15020_en_03
PPPoE
PPTP
Router
Trap
X.509 certificate
I15020_en_03
Glossary
Acronym for Point-to-Point Protocol over Ethernet. A protocol based on the PPP and Ethernet standards. PPPoE is a specification defining how to connect users to the Internet via
Ethernet using a shared broadband medium such as DSL, wireless LAN or a cable modem.
Acronym for Point-to-Point Tunneling Protocol. This protocol was developed by Microsoft and U.S. Robotics, among others, for secure data transfer between two VPN nodes
(
VPN) via a public network.
A router is a device that is connected to different IP networks and communicates between them. To do this, the router has an interface for each network connected to it. A router must find the correct path to the destination for incoming data and define the appropriate interface for forwarding it. To do this, it takes data from a local routing table listing assignments between available networks and router connections (or intermediate stations).
SNMP (Simple Network Management Protocol) is often used alongside other protocols, in particular on large networks. This UDP-based protocol is used for central administration of network devices. For example, the configuration of a device can be requested using the
GET command and changed using the SET command; the requested network device must simply be SNMP-compatible.
An SNMP-compatible device can also send SNMP messages (e.g., should unexpected events occur). Messages of this type are known as SNMP traps.
A type of “seal” that certifies the authenticity of a public key (
asymmetrical encryption) and the associated data.
It is possible to use certification to enable the user of the public key (used to encrypt the data) to ensure that the received public key is indeed from its actual issuer (and thus from the instance that should later receive the data). A certification authority (CA) certifies the authenticity of the public key and the associated link between the identity of the issuer and its key. The certification authority verifies authenticity in accordance with its rules (for example, it may require the issuer of the public key to appear before it in person). After successful authentication, the CA adds its (digital) signature to the issuer's public key. This results in a certificate.
An X.509(v3) certificate thus consists of a public key, information about the key owner (the
Distinguished Name (DN)), authorized use, etc., and the signature of the CA (
Subject, certificate).
The signature is created as follows: the CA creates an individual bitstring from the bit string of the public key, owner information, and other data. This bitstring can be up to 160 bits in length and is known as the HASH value. The CA then encrypts this with its own private key and then adds it to the certificate. The encryption with the CA's private key proves the authenticity of the certificate (i.e., the encrypted HASH string is the CA's digital signature). If the certificate data is tampered with, then this HASH value will no longer be correct and the certificate will be rendered worthless.
The HASH value is also known as the fingerprint. Since it is encrypted with the CA's private key, anyone who has the corresponding public key can decrypt the bitstring and thus verify the authenticity of the fingerprint or signature.
The involvement of a certification authority means that it is not necessary for key owners to know each other. They only need to know the certification authority involved in the process.
The additional key information also simplifies administration of the key.
X.509 certificates can, for example, be used for e-mail encryption by means of S/MIME or
IPsec.
Innominate Security Technologies
405
Protocol, transmission protocol
Service provider
Spoofing, anti-spoofing
Symmetrical encryption
TCP/IP (Transmission
Control Protocol/Internet
Protocol)
VLAN
Devices that communicate with each other must follow the same rules. They have to “speak the same language”. Rules and standards of this kind are called protocols or transmission protocols. Some of the more frequently used protocols are IP, TCP, PPP, HTTP, and SMTP.
Service providers are companies or institutions that enable users to access the Internet or online services.
In Internet terminology, spoofing means supplying a false address. Using this false Internet address, a user can create the illusion of being an authorized user.
Anti-spoofing is the term for mechanisms that detect or prevent spoofing.
In symmetrical encryption, the same key is used to encrypt and decrypt data. Two examples of symmetrical encryption algorithms are DES and AES. They are fast, but also increasingly difficult to administrate as the number of users increases.
These are network protocols used to connect two computers on the Internet:
IP is the base protocol.
UDP is based on IP and sends individual packets. The packets may reach the recipient in a different order than that in which they were sent or they may even be lost.
TCP is used for connection security and ensures, for example, that data packets are forwarded to the application in the correct order.
UDP and TCP add port numbers between 1 and 65535 to the IP addresses. These distinguish the various services offered by the protocols.
A number of additional protocols are based on UDP and TCP. These include HTTP (Hyper
Text Transfer Protocol), HTTPS (Secure Hyper Text Transfer Protocol), SMTP (Simple Mail
Transfer Protocol), POP3 (Post Office Protocol, Version 3), and DNS (Domain Name Service).
ICMP is based on IP and contains control messages.
SMTP is an e-mail protocol based on TCP.
IKE is an IPsec protocol based on UDP.
ESP is an IPsec protocol based on IP.
On a Windows PC, the WINSOCK.DLL (or WSOCK32.DLL) provides a common interface for both protocols.
(
A VLAN (Virtual Local Area Network) divides a physical network into several independent logical networks, which exist in parallel.
Devices on different VLANs can only access devices within their own VLAN. Accordingly, assignment to a VLAN is no longer defined by the network topology alone, but also by the configured VLAN ID.
VLAN settings can be used as optional settings for each IP. A VLAN is identified by its VLAN
ID (1 - 4094). All devices with the same VLAN ID belong to the same VLAN and can, therefore, communicate with each other.
The Ethernet packet for a VLAN (according to IEEE 802.1Q) is extended by 4 bytes, with 12 bits available for recording the VLAN ID. VLAN IDs “0” and “4095” are reserved and cannot be used for VLAN identification.
406
Innominate Security Technologies I15020_en_03
VPN (Virtual Private Network)
Glossary
A Virtual Private Network (VPN) connects several separate private networks (subnetworks) via a public network (e.g., the Internet) to form a single common network. A cryptographic protocol is used to ensure confidentiality and authenticity. A VPN is therefore an inexpensive alternative to using permanent lines for building a nationwide company network.
I15020_en_03 Innominate Security Technologies
407
408
Innominate Security Technologies I15020_en_03
19 Appendix
User „root“ and „admin“
19.1
CGI actions
The following commands are executable by the users root and admin.
Row actions https://admin:[email protected]/nph-action.cgi?action=<ACTION>&name=<NAME> https://admin:[email protected]/nph-action.cgi?action=<ACTION>&rowid=<ROWID>
Table 19-1
Parameter
NAME
ROWID
Row actions – Parameter
Description
Name of the connection, rule record, integrity check
Unique ID from the configuration.
(gaiconfig --goto VPN_CONNECTION:0 --get-rowid)
Appendix
Table 19-2 Row actions – Actions
Action fwrules/inactive fwrules/active vpn/stop vpn/start
Description
Deactivates a firewall rule record
Activates a firewall rule record
Also stops an IPsec connection like "nph-vpn.cgi" but with less complexity
Also starts an IPsec connection like "nph-vpn.cgi" but with less complexity openvpn/stop openvpn/start
Stops an OpenVPN connection (New in 8.3.0)
Starts an OpenVPN connection (New in 8.3.0) cifsim/validaterep Validates the report of a CIFS/IM scan cifsim/check-start Starts a CIFS/IM check cifsim/init-start cifsim/cancel
Intializes a new CIFS/IM integrity-database
Cancels a running CIFS/IM job cifsim/erase-db Deletes the CIFS/IM database cifsim/access-scan Starts a quick file permission check of a share (New in 8.3.0)
Innominate Security Technologies
409
I15020_en_03
User firewall logout https://admin:[email protected]/nph-action.cgi?action=userfw/logout&name=<NAME> &ip=<IP>
Table 19-3
Parameter
NAME
IP
User firewall logout
Description
Username of the logged in user of the user firewall
The actual IP-Address of the logged in user of the user firewall
Simple commands
(Name or ID not required) https://admin:[email protected]/nph-action.cgi?action=<ACTION>
Parameter switch/purge-arlt switch/reset-phycounters
Description
Resets the Address Resolution Table in the internal switch
Resets the PHY counters inside the switch
User „mobile“, „root“ and
„admin“
The following commands are executable by the users mobile, root and admin. The user
mobile is available since firmware version 8.3.0.
Mobile actions https://admin:[email protected]/nph-action.cgi?action=gsm/call&dial=<NUMBER> &timeout=<TIMEOUT> https://admin:[email protected]/nph-action.cgi?action=gsm/sms&dial=<NUMBER> &msg=<MESSAGE>
Parameter
NUMBER
TIMEOUT
MESSAGE
Description
Telephone number of the destination (New in 8.3.0)
Time in seconds until the call is finished (New in 8.3.0)
Content of the short message (should be cleaned of special characters like umlauts) (New in 8.3.0)
410
Innominate Security Technologies I15020_en_03
I15020_en_03
Appendix
19.2
CGI status
The following commands are executable by the users root and admin.
Parameter Description
/network/modem/state Modem state https://admin:[email protected]/nph-status.cgi?path=/network/modem/state
Answer: online | offline
/network/ntp_state State of the NTP time synchronization https://admin:[email protected]/nph-status.cgi?path=/network/ntp_state
Answer: disabled | not_synced | synchronized
/system/time_sync State of the system time synchronization https://admin:[email protected]/nph-status.cgi?path=/system/time_sync
Answer: not_synced | manually | stamp | rtc | ntp | gps | gpslost
/ecs/status State of the ECS https://admin:[email protected]/nph-status.cgi?path=/ecs/status
Answer:
"1" for not present, "2" for removed, "3" for present an in synchronization,
"4" for not in synchronization and "8" for generic error
/vpn/con State of a VPN connection https://admin:[email protected]/nph-status.cgi?path=/vpn/con&name=<Verbindungsname>
Answer:
/vpn/con/<rowid>/armed=[yes|no]
Shows whether the connection is started or not
/vpn/con/<rowid>/ipsec=[down|some|up] Shows the IPsec state.
/vpn/con/<rowid>/isakmp=[up|down] Shows the ISAKMP state.
/vpn/con/<rowid>/sa_count=<number>
Number of configured tunnel
/vpn/con/<rowid>/sa_count_conf=<number>
Number of configured enabled tunnel
/fwrules State of a firewall rule record https://admin:[email protected]/nph-status.cgi?path=/fwrules&name=<rule record >
Answer:
/fwrules/<rowid>/expires=<seconds since 1.1.1970>
Expiration date – 0 for no expiration
/fwrules/<rowid>/state=[inactive|active]
Activation state of the firewall rule record
/cifs/im State of a share in the context of CIFS https://admin:[email protected]/nph-status.cgi?path=/cifs/im&name=<WS_SHARE>
Innominate Security Technologies
411
412
Innominate Security Technologies
Parameter
Answer:
Description
Actual check
/cifs/im/<rowid>/curr/all=<number>
Number of files
/cifs/im/<rowid>/curr/end=<seconds>
End time of the current check in seconds since 1.1.1970
/cifs/im/<rowid>/curr/numdiffs=<number>
Currently found number of diffs.
/cifs/im/<rowid>/curr/operation=[none|suspend|check|idb_build]
Current operation
/cifs/im/<rowid>/curr/scanned=<number>
Number of currently checked files
/cifs/im/<rowid>/curr/start=<seconds>
Start time in seconds since 1.1.1970
Last check
/cifs/im/<rowid>/last/duration=<number>
Number of seconds of the last duration
/cifs/im/<rowid>/last/numdiffs=<number>
Number of differences found during the last check
/cifs/im/<rowid>/last/start=<seconds> start time in seconds since 1.1.1970
Start time in seconds since 1.1.1970
/cifs/im/<rowid>/last/result=<see "Last Results“ below">
Log results
/cifs/im/<rowid>/log/fname=<filename of the log file>
/cifs/im/<rowid>/log/hash=<sha1 hash>
/cifs/im/<rowid>/log/result=<siehe "Log result" below>
I15020_en_03
I15020_en_03
Appendix
Parameter
Last results
Description
-1:
The share has not yet been checked. Probably no integrity database exists.
0:
Last check finished successfully.
1:
The process failed due to an unforeseen condition, please consult the logs.
2:
Last check was aborted due to timeout.
3:
The integrity database is missing or incomplete.
4:
The signature of the integrity database is invalid.
5:
The integrity database was created with a different hash algorithm.
6:
The integrity database is the wrong version.
7:
The share which is to be checked is not available.
8:
The share which is to be used as checksum memory is not available..
11:
A file could not be read due to an I/O failure. Please consult the report.
12:
The directory tree could not be traversed due to an I/O failure. Please consult the report.
Log result
unchecked – The signature has not been verified, yet.
valid – The signature is valid.
Emissing ERROR – The report is missing.
Euuid_mismatch ERROR – The report does not belong to this device or is not up to date.
Ealgo_mismatch ERROR – The report was created with a different hash algorithm.
Etampered ERROR – The report was tampered with.
Eunavail ERROR – The report is not available. For example the share might not be mounted.
Eno_idb – No report exists, because of a missing integrity database.
Innominate Security Technologies
413
414
Innominate Security Technologies I15020_en_03
advertisement
Key Features
- VPN router
- Firewall
- Anti-virus scanner
- Stealth mode
- Network router mode
- DMZ mode
- VPN gateway mode
- DHCP
- DNS
- SNMP
