Innominate mguard Version 6

Innominate mguard Version 6 Configuration Examples mguard smart mguard PCI mguard blade mguard industrial RS EAGLE mguard mguard delta Innominate Security Technologies AG Albert-Einstein-Str. 14 12489 Berlin, Germany Phone: +49 (0)30-6392 3300 Fax: +49 (0)30-6392 3307 contact@innominate.com http://www.innominate.com

Table of Contents 1 Disclaimer 5 2 Introduction 6 3 Factory Default Settings and Access to the GUI 6 4 Purposes of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) 7 4.1 Stealth Modes (autodetect, static, multiple clients) 7 4.2 Router Mode 8 4.3 PPPoE/PPTP Mode 8 4.4 Modem Mode 8 5 mguard operating in Stealth Mode 9 5.1 Management IP 10 5.2 Static Routes 10 5.3 DNS Server 11 6 mguard operating as DSL Router (PPPoE Mode) 12 6.1 Replacing an existing DSL Router with the mguard 12 6.2 Configuring the Interfaces 13 6.3 Network Address Translation (NAT) 14 6.4 DNS Server 14 6.5 Required IP Settings on the Clients 14 6.6 DynDNS Registration 15 7 mguard operating as Router (Router Mode) 16 7.1 Configuration of the Clients 16 7.2 Configuration of the mguard 17 7.2.1 Configuring the Interfaces 17 7.2.1.1 Additional internal/external Routes 18 7.2.2 Network Address Translation (NAT) 18 7.2.3 Internal DHCP Configuration 19 7.2.3.1 DHCP Server for the internal Network 19 7.2.3.2 DHCP Relay 20 7.2.4 External DHCP Configuration 21 7.2.5 DNS Sever 21 Document ID: UG206002508-017 Page 2 of 95

8 Firewall 22 8.1 Incoming/Outgoing Firewall 22 8.1.1 Basic Guidelines for setting up the Firewall 22 8.1.2 Example of a wrongly configured Firewall 22 8.2 Sets of Rules 23 8.3 MAC Filtering 25 8.3.1 Basic Rules for setting up MAC filtering 25 8.3.2 Examples MAC Filter Configuration 26 8.3.2.1 Novell IPX 26 8.3.2.2 Restricted IPv4 Access 27 8.4 1:1 NAT 28 8.5 User Firewall 30 8.5.1 Configuring Remote Users 30 8.5.2 RADIUS Servers 31 8.5.3 Configuring the User Firewall 31 8.5.3.1 General Settings 31 8.5.3.2 Template Users 32 8.5.3.3 Firewall Rules 32 8.5.4 Activating the User Firewall 33 9 Redundancy 34 9.1 Router Redundancy (Router Mode) 34 9.1.1 Configuration of the Interfaces 35 9.1.2 Redundancy Configuration 36 9.2 Firewall Redundancy (Multi Stealth Mode) 37 9.2.1 Configuration of the Interfaces 38 9.2.2 Redundancy Configuration 39 9.3 ICMP Checks 40 10 Quality of Service (Egress QoS) 41 11 Modem Support 44 11.1 Connecting an external Modem to the mguard 44 11.2 Dial-in Configuration 44 11.2.1 General Modem Settings 45 11.2.2 Configuring the Dial-in Connection on the mguard 46 11.2.3 Enabling HTTPS Remote Access 46 11.2.4 Required changes on the remote entity 47 11.3 Dial-out Configuration 48 11.3.1 General Modem Settings 48 11.3.2 Configuring the Dial-out Connection on the mguard 49 Document ID: UG206002508-017 Page 3 of 95

12 IPsec VPN 50 12.1 Limitations 50 12.2 VPN Configuration 51 12.2.1 Authentication Method 51 12.2.1.1 Pre-Shared Secret Key (PSK) 51 12.2.1.2 X.509 Certificates 52 12.2.2 VPN Firewall 55 12.2.3 IKE Options 56 12.2.3.1 ISAKMP SA/IPsec SA Lifetime 57 12.2.3.2 Dead Peer Detection (DPD) 57 12.3 mguard behind NAT Gateway 58 12.3.1 VPN initiating mguard behind NAT Gateway 58 12.3.2 VPN responding mguard behind NAT Gateway 58 12.3.3 Both mguards behind NAT Gateways 59 12.4 VPN Transport Connection between two mguard in Stealth Mode with PSK 60 12.4.1 Configuration of the Interfaces 60 12.4.2 VPN Configuration 61 12.5 VPN Tunnel between two mguards in Router/PPPoE Mode with Certificates 62 12.5.1 Configuration of the Interfaces 63 12.5.2 Required X.509 Certificates 63 12.5.3 Import of the Machine Certificates 63 12.5.4 VPN Configuration 64 12.6 VPN Tunnel between two mguards, Single-Stealth and PPPoE Mode, with Certificates 66 12.6.1 Configuration of the Interfaces 66 12.6.2 Required X.509 Certificates 67 12.6.3 Import of the Machine Certificates 67 12.6.4 VPN Configuration 68 12.7 VPN Tunnel between two mguards, Multi-Stealth and PPPoE Mode, with Certificates 71 12.7.1 Configuration of the Interfaces 71 12.7.2 Required X.509 Certificates 72 12.7.3 Import of the Machine Certificates 72 12.7.4 VPN Configuration 73 12.8 VPN 1-to-1 NAT for the local Network 75 12.8.1 VPN Tunnel between two Sites with the same internal Network 75 12.8.2 VPN Tunnel to different Locations with the same remote Network 77 12.9 VPN 1-to-1 NAT for the remote Network 79 12.10 VPN Tunnel Groups 82 12.10.1 Import of the required Certificates 82 12.10.2 VPN Configuration 83 12.11 Hub and Spoke 85 12.12 URL for starting, stopping and Status Query of a VPN Connection 86 12.13 mguard industrial RS: Activating a VPN Tunnel through an external push Button or on/off Switch _ 87 12.14 L2TP/IPSec Connection 88 12.14.1 Required X.509 Certificates 88 12.14.2 Configuration of the mguard 89 12.14.2.1 Import of the Machine Certificate 89 12.14.2.2 VPN Configuration 90 12.14.2.3 Starting the L2TP Server 93 12.14.3 Configuring the Windows Client 94 12.14.3.1 Certificate import through Microsoft Management Console (MMC) 94 12.14.3.2 Configuration of the L2TP/IPSec Dial-up Connection 95 Document ID: UG206002508-017 Page 4 of 95

1 Disclaimer Innominate Security Technologies AG June 2008 Innominate and mguard are registered trademarks of the Innominate Security Technologies AG. All other brand names or product names are trade names, service marks, trademarks, or registered trade marks of their respective owners. mguard technology is protected by the German patents #10138865 and #10305413. Further national and international patent applications are pending. No part of this documentation may be reproduced or transmitted in any form, by any means without prior written permission of the publisher. All information contained in this documentation is subject to change without previous notice. Innominate offers no warranty for these documents. This also applies without limitation for the implicit assurance of scalability and suitability for specific purposes. In addition, Innominate is neither liable for errors in this documentation nor for damage, accidental or otherwise, caused in connection with delivery, output or use of these documents. This documentation may not be photocopied, duplicated or translated into another language, either in part or in whole, without the previous written permission of Innominate Security Technologies AG. Document ID: UG206002508-017 Page 5 of 95

2 Introduction This guide should help you getting familiar with the configuration of the mguard. It explains on a basis of several examples how to configure the different operating modes on the mguard and the required steps. 3 Factory Default Settings and Access to the GUI The following table lists the factory default settings of the different models: Model Network mode Internal IP address Access from the internal network through mguard smart Stealth (autodetect) - https://1.1.1.1 mguard PCI Stealth (autodetect) - https://1.1.1.1 mguard industrial RS Stealth (autodetect) - https://1.1.1.1 EAGLE mguard Stealth (autodetect) - https://1.1.1.1 mguard blade Stealth (autodetect) - https://1.1.1.1 mguard blade Router 192.168.1.1 https://192.168.1.1 Control Unit mguard delta Router 192.168.1.1 https://192.168.1.1 By default, the firewall drops all incoming (except VPN) and allows all outgoing connections. The default passwords are: User = root Password = root User = admin Password = mguard Note: Before trying to access the device through the web browser, ensure that the web browser does not use a proxy and that a default gateway is defined on the client. Stealth mode: Obtaining access to the web interface depends on whether the external interface of the mguard is connected to the network or not. If the external interface is connected to the network, which means that the default gateway is reachable, you can access the web interface directly from the client through https://1.1.1.1. If the external interface of the mguard is NOT connected to the network, ensure first that the client does not receive its IP settings via DHCP. If this is the case, assign static IP settings to the client (e.g. IP Address=192.168.1.2, Subnet Mask=255.255.255.0, Default Gateway=192.168.1.1). Then assign a static MAC address to the IP address of the default gateway with the ARP command. To do this: Open a DOS prompt. Type the command ipconfig for obtaining the IP address of the default gateway. Execute the command: arp s <IP of the default gateway> 00-aa-aa-aa-aa-aa Now you can access the GUI from the client through https://1.1.1.1. Router mode: You need to assign the following IP settings to the client: The IP address must belong to the network 192.168.1.0/24, e.g. 192.168.1.100 Subnet mask = 255.255.255.0 Default gateway = 192.168.1.1 Now you can access the web interface from the client through https://192.168.1.1. Document ID: UG206002508-017 Page 6 of 95

4 Purposes of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) 4.1 Stealth Modes (autodetect, static, multiple clients) In Stealth mode, you simply need to interconnect the mguard between the clients which should be protected and the network. Reconfiguring the IP settings of the clients is not required. All processes which are listening on ports are hidden to the network and will not be detected by a port scanner. The mguard works completely transparent. Stealth - autodetect and static The Stealth modes autodetect or static can by used if the mguard should protect one single system (e.g. server) and if the NIC of the system has only one IP address. Otherwise multiple clients Stealth mode must be used. When using autodetect Stealth mode, the mguard detects the client s IP address automatically by analyzing the traffic which comes from the internal network and adopts the IP and MAC address of the client. Some entities do not generate traffic by itself (e.g. server, webcam). In this case the mguard will never get its IP settings. You need to use static Stealth mode and specify the clients IP and MAC address on the mguard. Stealth - multiple clients This mode is also called Multi Stealth mode. Use this mode to protect multiple clients or if the NIC of the system has more than one IP address. Note: Starting with version 6 VPN is also supported in Multi Stealth mode. Document ID: UG206002508-017 Page 7 of 95

4.2 Router Mode In Router mode the mguard works as router between two different networks. You need to configure the internal and external interfaces. The external interface may use static IP settings or receive them from a DHCP server. In Router mode the mguard may act as DHCP server for the internal and/or external network. 4.3 PPPoE/PPTP Mode In PPPoE mode the mguard works as DSL router between the internal network and the Internet. The external interface of the mguard needs to be connected to a DSL modem. The mguard will receive its external IP settings from the Internet Service Provider (ISP). The internal interface needs to be configured. In PPPoE mode the mguard may act as DHCP server for the internal network. PPTP is the equivalent to PPPoE and is used in certain countries, as for example in Austria. 4.4 Modem Mode The Modem mode can be used for accessing machines of the internal network or for sending data from the internal network through a phone line. This mode requires either an external modem connected to the serial port of the mguard or an mguard industrial RS with built-in modem or ISDN terminal adapter. All traffic directed to the WAN port is redirected to the internal serial port of the mguard and from there either over the external serial port where an external modem must be connected or over the built-in modem or ISDN terminal adaptor (mguard industrial RS, when equipped). Document ID: UG206002508-017 Page 8 of 95

5 mguard operating in Stealth Mode Using the mguard in Stealth mode is like Plug-and-Play. By default, a brand new mguard is in Stealth autodetect mode (except mguard delta and mguard blade control unit). You simple need to interconnect the mguard between the network and the entities which should be protected, but you should keep the following in mind. The network modes Stealth autodetect and Stealth static can only be used to protect one single entity with one (and only one) IP address. In Stealth autodetect mode the mguard analyzes the outgoing traffic and adapts the IP and MAC address of the client. If the client does not generate traffic by its own you need to use the Stealth static mode by specifying the clients IP and MAC address on the mguard. If more than one client should be protected by the mguard or if one single client has more than one IP address, the Stealth multiple clients mode must be used. From the internal client(s) you have access to the web interface of the mguard through https://1.1.1.1. From the external network you may access the mguard in autodetect and static Stealth mode by using the IP address of the client which is connected to the internal interface of the mguard, assuming that HTTPS remote access is enabled. For accessing the mguard from the external network in Stealth multiple clients mode, you need to assign a Management IP to the mguard. Document ID: UG206002508-017 Page 9 of 95

5.1 Management IP Note: Using a Management IP is supported for all Stealth modes (autodetect, static and multiple clients). After assigning a Management IP to the mguard you only can access the mguard through https://<management IP> and not through https://1.1.1.1 anymore (except in Stealth autodetect mode). You need to assign a Management IP to the device if the mguard is operated in Multi Stealth mode and if the device should be accessible from the external network through HTTPS/SSH or if the mguard should establish a VPN connection to a remote VPN gateway. From the menu, select Network -> Interfaces, tab General. The Management IP must belong to the network and must not be used by any other entity. Apart of this IP address you need to enter the subnet mask and the default gateway of the network. 5.2 Static Routes Static routes can be used for sending data through another gateway than the default gateway of the network by specifying the Network and the Gateway. Static routes do only have an effect on actions initiated by the mguard, as for example establishing VPN connections or online firmware updates. Document ID: UG206002508-017 Page 10 of 95

5.3 DNS Server By default, the mguard uses a predefined list of public available DNS servers (Servers to query = DNS Root Servers). If the mguard is located within a private network, accessing those servers may fail if the firewall of the gateway to the Internet does not allow DNS queries or if the Internet is not accessible. This would have an impact on actions initiated by the mguard where a DNS name must be resolved, as for example an online firmware update, establishing a VPN connection against a DynDNS name or the download of the anti virus database. These actions may also be delayed if the responses of the public available DNS servers take too long. If the mguard is located within a private network we recommend to set Servers to query = User defined and to enter the IP address of the DNS server. From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select User defined. Enter the IP address of the DNS server of the network. Document ID: UG206002508-017 Page 11 of 95

6 mguard operating as DSL Router (PPPoE Mode) In this example, we will use the mguard as DSL Router (PPPoE mode) for connecting the company s network to the Internet through a DSL modem. The following diagram illustrates the machines and addresses involved in the connection. 6.1 Replacing an existing DSL Router with the mguard Follow these steps if you want to replace an existing DSL router with the mguard in an already configured environment: Write down the internal IP address of the DSL router. You will need it later. In our example, the IP address is 192.168.1.254. Replace the DSL router with the mguard. Connect one single client to the internal interface of the mguard. The mguard (except mguard delta and mguard blade control unit) is in Stealth mode if you did not preconfigure it before installation. In this case you can access the mguard from the web browser through https://1.1.1.1. The default gateway can t be reached anymore due to the replacement of the DSL router. Therefore you need to perform the following steps on the client you use for configuring the mguard: º Open a DOS prompt. º Execute the command: arp a. This command lists all existing arp entries. If the IP address of the router appears in this list (in our example: 192.168.1.254) you need to delete this entry by using the command: arp d <IP address> (in our example: arp -d 192.168.1.254). º Now you need to assign a static MAC address to the IP address of the default gateway with the command: arp s <IP adresse> 00-aa-aa-aa-aa-aa (in our example: arp -s 192.168.1.254 00-aa-aa-aa-aa-aa). After doing this, you can access the mguard from the web browser through https://1.1.1.1 and configure it. Restart the switch for deleting possibly cached arp entries after configuring the mguard and reconnecting the internal network to the mguard. Document ID: UG206002508-017 Page 12 of 95

6.2 Configuring the Interfaces From the menu, select Network -> Interfaces, tab General. Network Mode Network Mode PPPoE PPPoE Login PPPoE Password Automatic Re-connect? Re-connect daily at Internal Networks Internal IPs Secondary External Interface Not required for this setup. Select PPPoE. Enter the user name you have received from your Internet Service Provider (ISP) for accessing the Internet. Enter the password you have received from your Internet Service Provider (ISP) for accessing the Internet. If this option is enabled, the mguard will reconnect to the ISP every day at the specified time. This feature allows moving the 24 hour reconnect of the DSL line outside the office hours. Using this feature requires that the system time was either entered manually on the mguard or synchronized with an NTP server. Enter the internal IP of the mguard into the field IP and the appropriate Netmask. The IP address must belong to the internal network. If you have replaced an existing DSL router, enter the IP setting used previously by the DSL router, in our example 192.168.1.254/255.255.255.0. Usually this IP address needs to be entered as default gateway on the clients. The mguard will reboot automatically after applying the changes due to the change of the network mode from Stealth to PPPoE. After the reboot you have access to the mguard through https://<internal IP of the mguard>, in our example: https://192.168.1.254. Document ID: UG206002508-017 Page 13 of 95

6.3 Network Address Translation (NAT) You must activate Network Address Translation (NAT) for gaining access to the Internet. From the menu, select Network Security -> NAT, tab Masquerading. Network Address Translation/IP Masquerading Outgoing on Interface Select External. From IP Enter the network and the appropriate subnet mask in CIDR-notation (e.g. 255.255.0.0 = 16, 255.255.255.0 = 24, 255.255.255.255 = 32) into the field From IP. A value of 0.0.0.0/0 means that all internal IP addresses will have access to the Internet (assuming an outgoing firewall rules allows this access). If only a special subnet should have access to the Internet, enter this subnet and the appropriate subnet mask (e.g. 192.168.1.0/24). If only one client should have access to the Internet, enter its IP address and the value 32 as subnet mask (e.g. 192.168.1.100/32). 1:1 NAT Not required for this setup. 6.4 DNS Server From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select Provider defined. Not required for this setup. 6.5 Required IP Settings on the Clients If the clients use static IP settings, you need to specify the internal IP of the mguard as default gateway and as DNS name server, in our example 192.168.1.254. Document ID: UG206002508-017 Page 14 of 95

6.6 DynDNS Registration If the mguard has a dynamic public IP address, it could be necessary that the mguard registers its public IP address under a fixed name in a DynDNS service. This could be the case for example: If you need remote HTTPS access to the device. If a VPN connection should be established to the device. If Pre-Shared Key (PSK) should be used for authentication in the VPN configuration. In the following screenshot, the mguard should register its public IP address under the name mguard in the DynDNS service dyndns.org. From the menu, select Network -> DNS, tab DynDNS. Document ID: UG206002508-017 Page 15 of 95

7 mguard operating as Router (Router Mode) The mguard shall be used as router between two different networks. The following diagram illustrates the machines and addresses involved in this configuration. The examples used in this chapter are taken from this setup. 7.1 Configuration of the Clients Internal network The clients of the internal network may either use static IP settings or receive them from the mguard (internal DHCP server) or from a DHCP server of the external network (DHCP relay) or from a DHCP server of the internal network. The clients of the internal network should use the internal IP address of the mguard as default gateway. External network The clients of the external network may either use static IP settings or receive them from the mguard (external DHCP server) or from a DHCP server of the internal network (DHCP relay) or from a DHCP server of the external network. Document ID: UG206002508-017 Page 16 of 95

7.2 Configuration of the mguard 7.2.1 Configuring the Interfaces From the menu, select Network -> Interfaces, tab General. Network Mode Network Mode External Networks Obtain external configuration via DHCP External IPs Additional External Routes IP of default gateway Internal Networks Internal IPs Additional Internal Routes Secondary External Interface Not required for this setup. Select Router. Enable this option, if the mguard should receive its external IP settings from a DHCP server. Otherwise you need to configure the external IP settings manually. Enter the external IP address of the mguard and the appropriate Netmask, in our example 10.1.0.64/255.255.0.0. Will be explained in the next chapter. Enter the IP address of the default gateway of the external network. Enter the internal IP of the mguard into the field IP and the appropriate Netmask. The IP address must belong to the internal network. This IP address should be specified as default gateway on every client of the internal network. Will be explained in the next chapter. Document ID: UG206002508-017 Page 17 of 95

7.2.1.1 Additional internal/external Routes If the internal network of the mguard contains another subnet, the mguard must know to which gateway packets addressed to the subnet need to be directed. This is achieved with the option Additional Internal Routes. In the following example an additional internal route needs to be defined for the network 192.168.2.0/24 with the gateway 192.168.1.1. Note: Do never specify an additional internal route with a gateway located in the external network or vice versa. This could cause a routing problem on the mguard. 7.2.2 Network Address Translation (NAT) Activate NAT if required. You need to activate NAT for example if the route to the internal network of the mguard is unknown to the external network. From the menu, select Network Security -> NAT, tab Masquerading. Network Address Translation/IP Masquerading Outgoing on Interface Select External. From IP Enter the network and the appropriate subnet mask in CIDR-notation (e.g. 255.255.0.0 = 16, 255.255.255.0 = 24, 255.255.255.255 = 32) into the field From IP. A value of 0.0.0.0/0 means that all internal IP addresses will have access to the Internet (assuming an outgoing firewall rule allows this access). If only a special subnet should have access to the Internet, enter this subnet and the appropriate subnet mask (e.g. 192.168.1.0/24). If only one client should have access to the Internet, enter its IP address and the value 32 as subnet mask (e.g. 192.168.1.100/32). 1:1 NAT Not required for this setup. Document ID: UG206002508-017 Page 18 of 95

7.2.3 Internal DHCP Configuration You need to configure the internal DHCP service if the clients of the internal network should receive their IP settings from the mguard or from a DHCP server which is located in the external network (DHCP relay). From the menu, select Network -> DHCP, tab Internal DHCP. 7.2.3.1 DHCP Server for the internal Network Mode DHCP Mode DHCP Server Options Enable dynamic IP address pool DHCP lease time DHCP range start DHCP range end Local netmask Broadcast address Default gateway DNS server WINS server Static Mapping Select Server. Enable this option if the clients should receive their IP address from the pool DHCP range start to DHCP range end. Disable this option if the assignment should be done statically based on the MAC address (refer to Static Mapping). Validity of the assigned IP settings in seconds. Start and end of the IP address range from which IP addresses will be assigned dynamically to the clients. Netmask to be used by the clients. Broadcast address to be used by the clients. IP address of the default gateway used by the clients. Usually this is the internal IP address of the mguard. IP address of the Domain Name Service (DNS) server which shall be used by the clients for resolving hostnames into IP addresses and vice versa. Enter the internal IP address of the mguard if the DNS service of the mguard shall be used. IP address of the WINS server which shall be used by the clients for resolving hostnames into IP addresses and vice versa, using the Windows Internet Naming Service (WINS). Use Static Mapping to assign fixed IP addresses to clients depending on their MAC address. When doing this, consider the following: º Statically assigned IP addresses have a higher priority than the dynamic IP address pool. º Static IP addresses and pool addresses must not overlap. Do not assign the same IP address to several MAC addresses. Otherwise the same IP address will be assigned to several clients. Document ID: UG206002508-017 Page 19 of 95

7.2.3.2 DHCP Relay Use DHCP relay if the clients of the internal network should receive their IP addresses from a DHCP server which is located in the external network. Mode DHCP mode DHCP Relay Options DHCP Servers to relay to Append Relay Agent Information (Option 82) Select Relay. Enter the IP address of the DHCP server of the external network. Enable this option if additional information for the DHCP server according to RFC 3046 should be appended. Note: The mguard must have a static external IP address when using DHCP relay and an according route to the internal network must be defined on the DHCP server. Document ID: UG206002508-017 Page 20 of 95

7.2.4 External DHCP Configuration You need to configure the external DHCP service if the clients of the external network should receive their IP settings from the mguard or from a DHCP server which is located in the internal network (DHCP relay). The required settings are according to the previous chapter and need to be configured through the menu Network -> DHCP, tab External DHCP. 7.2.5 DNS Sever You need to specify a DNS server if: The mguard itself needs to resolve hostnames, as it is the case for: o Anti Virus pattern downloads. o Applying online updates. o Requesting licenses from the device online. o Online license reload. o Resolving DynDNS names for establishing VPN connections. The clients of the internal network have the internal IP address of the mguard specified as DNS server. From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select User defined. Enter the IP address of the DNS server of the external network. Document ID: UG206002508-017 Page 21 of 95

8 Firewall 8.1 Incoming/Outgoing Firewall The incoming and outgoing firewall is configured through the menu Network Security -> Packet Filter, tabs Incoming Rules and Outgoing Rules. Outgoing rules are applied to packets from the internal (trusted) network directed to the external (untrusted) network, incoming rules to packets from the external (untrusted) to the internal (trusted) network. 8.1.1 Basic Guidelines for setting up the Firewall Keep the following guidelines in mind when setting up the firewall: The specified firewall rules will be checked one by one, starting with the first rule. If one rule matches the criteria, no matter whether the action is Reject, Accept or Drop, the subsequent rules will not be considered. Specified ports ( From Port and To Port ) are only considered if protocol is set to TCP or UDP. 8.1.2 Example of a wrongly configured Firewall In this example, access to HTTP servers should not be granted to the employees. The settings above contain a couple of errors: Line #1: The specified firewall rules will be checked one by one, starting with the first rule. If one rule matches the criteria, no matter whether the action is Reject, Accept or Drop, the subsequent rules will not be considered. The first rule will match in any case. Therefore the second rule will never be checked removing it would have the same effect. The order of the two rules needs to be changed. Line #2 From Port =80: HTTP requests issued by a web browser usually use a port number above 1024 and send their requests to port number 80. This rule will not have any effect due to From Port=80. In this case you need to specify From Port=any and To Port=80. The correct configuration would be: Document ID: UG206002508-017 Page 22 of 95

8.2 Sets of Rules Starting with version 5 summarizing firewall rules to a Set of Rules is supported. A Set of Rules can be specified as Action when configuring the incoming and/or outgoing firewall. Let s take a look at the following example: The incoming firewall should allow ftp, telnet and https access only to the servers 192.168.1.1, 192.168.1.23 and 192.168.1.145. In previous releases you needed to configure nine incoming firewall rules for allowing the access. Using a Set of Rules, which summarizes either the allowed protocols or the IP addresses of the target machines, will result in six firewall rules. Example 1: Set of Rules summarizes the IP addresses of the target machines The set is called Servers and allows the access to the target machines. The incoming firewall rules allow the access for the specified services (ftp, telnet and https) and refer to the Set of Rules with the name Servers (Action = Servers) which grants the access to the target machines. Document ID: UG206002508-017 Page 23 of 95

Example 2: Set of Rules summarizes the allowed services The set is called Allowed Access and allows the access for the specified services. The incoming firewall rules allow the access to the target machines and refer to the Set of Rules with the name Allowed Access (Action = Allowed Access) which grants the access for the specified services. Document ID: UG206002508-017 Page 24 of 95

8.3 MAC Filtering MAC filtering is configured through the menu Network Security -> Packet Filter, tab MAC Filtering. 8.3.1 Basic Rules for setting up MAC filtering The MAC filter is stateless in contrast to the IPv4 stateful inspection firewall. This means that rules must be defined for both directions, incoming and outgoing. If no MAC filter rules are applied, IPv4 and ARP frames are allowed to pass in both directions. All other Ethernet frames are dropped. IPv4 frames are always filtered additionally according to the IPv4 stateful inspection firewall rules defined for incoming and outgoing traffic. If the MAC filter allows other Ethernet frames than IPv4 and ARP, no filtering except for the MAC address will take place. All ARP and IPv4 frames will pass the MAC filter by default. If the MAC filter should restrict the access for specific MAC addresses then you need to define a final rule for IPv4, which rejects everything else. If not using statically configured ARP tables on your devices, all IP traffic will require ARP address resolution first, this may as well include the administrative access to the mguard. Therefore, restrictions to ARP traffic should be used with special care. xx is used as wildcard: º xx:xx:xx:xx:xx:xx means all MAC addresses. º 00:0c:be:xx:xx:xx means all MAC addresses which start with 00:0c:be. Note: MAC filtering is only supported for the Stealth mode. Document ID: UG206002508-017 Page 25 of 95

8.3.2 Examples MAC Filter Configuration 8.3.2.1 Novell IPX In the following example Novell IPX protocol should pass the mguard. The MAC filter is stateless in contrast to the IP firewall. Therefore, incoming and outgoing rules need to be defined for allowing the traffic in both directions. Source MAC = Destination MAC = xx:xx:xx:xx:xx:xx: No restriction on the MAC address should be applied. The hexadecimal value of the Novell IPX protocol is 8137, which needs to be entered as Ethernet Protocol. Document ID: UG206002508-017 Page 26 of 95

8.3.2.2 Restricted IPv4 Access In the following example the access through the IPv4 protocol should be allowed only for the machines of the external network which MAC addresses start with 00:0c:be. The MAC filter is stateless in contrast to the IP firewall. Therefore, incoming and outgoing rules need to be defined. Only MAC addresses from the external network which start with 00:0c:be should be granted access to the internal network. We need to specify 00:0c:be:xx:xx:xx as Source MAC for the incoming rule and as Destination MAC for the outgoing rule. The restriction should be applied for the IPv4 protocol. IPv4 needs to be entered as Ethernet Protocol. All ARP and IPv4 frames will pass the MAC filter by default. That s why we need to specify a second incoming and outgoing rule, which drops IPv4 packets from all other MAC addresses than specified in the first rules. If a packet was sent from a MAC address starting with 00:0c:be, the first rule will match and the access to the internal network is granted (assuming, that there is also an incoming firewall rule defined which does not block the packet). If the packet was sent by any other MAC address, the second rule will match and drop the packet. Document ID: UG206002508-017 Page 27 of 95

8.4 1:1 NAT Note: 1:1 NAT is not supported for the Stealth mode. 1:1 NAT can be used for connecting several subnets with the same network to the main network. In the following example two production sites, which use the same network 192.168.1.0/24, shall be connected to the corporate network with the network 10.1.0.0/16. The major advantage of using 1:1 NAT is that no additional routes need to be defined in the corporate network. An ARP daemon on the mguard ensures that routers of the external network know where to send packets directed to the internal network. The systems of the production sites can be reached directly from the corporate network through their mapped IP addresses. Both mguards have external IP addresses which belong to the corporate network (10.1.0.100 and 10.1.0.101). It is not a typo that the corporate network has a netmask of 16 and that a netmask of 24 is specified in the 1:1 NAT rule. Due to the flat netmask of the corporate network it is possible to use the virtual network 10.1.1.0/24 for accessing the systems of production site 1 and 10.1.2.0/24 for accessing the systems of production site 2. An ARP daemon on the mguard ensures that routers of the corporate network know where to send packets addressed to the networks 10.1.1.0/24 and 10.1.2.0/24. The client 192.168.1.10 of production site 1 can be reached from the corporate network by using the IP address 10.1.1.10, client 192.168.1.11 with the IP address 10.1.1.11, etc. The client 192.168.1.10 of production site 2 can be reached from the corporate network by using the IP address 10.1.2.10, client 192.168.1.11 with the IP address 10.1.2.11, etc. Of course, clients of production site 2 may also be reached from production site 1 through their mapped IP address and vice versa. Document ID: UG206002508-017 Page 28 of 95

1:1 NAT is configured through the menu Network Security -> NAT and mirrors addresses from the internal network to the external network. Depending on the specified netmask, the network address is masqueraded and the host address will be kept unchanged. In the following example, the mguard works as router between the networks 192.168.1.0/24 (internal) and 10.1.0.0/16 (external) and has the following 1:1 NAT rule defined. The virtual network 10.1.1.0/24 is used for accessing the internal network. The 1:1 NAT rule will cause the following masquerading: Internal External 192.168.1.1 <-> 10.1.1.1 192.168.1.2 <-> 10.1.1.2 192.168.1.3 <-> 10.1.1.3 192.168.1.254 <-> 10.1.1.254 For example, the client of the internal network with the IP address 192.168.1.27 can be reached from the external network using the IP address 10.1.1.27. Document ID: UG206002508-017 Page 29 of 95

8.5 User Firewall The User Firewall allows defining user specific firewall rules. The firewall rules are defined within User Firewall Templates and the users to which the firewall template should be applied must be assigned to the template. The user needs to log onto the device through HTTPS for activating the firewall rules. This can be done either from the internal or from the external network. Log onto the device from the external network requires that HTTPS remote access is enabled (menu Management -> Web Settings, tab Access). The mguard detects automatically through which interface the login happened and applies the firewall template to the incoming (login from the external network) or outgoing (login from the internal network) firewall. The login can only happen through one of the interfaces specified in the tab Access. The authentication of the user can be done either on the mguard locally (the passwords are stored on the mguard) or through a RADIUS server. In this example we want to setup a User Firewall which allows HTTP and FTP access for the users user1, user2, user3 and user4. 8.5.1 Configuring Remote Users From the menu, select Authentication -> Firewall Users, tab Firewall Users. Users Enable user firewall Enable group authentication Username Authentication Method User Password Enable this option for activating the user firewall. Group authentication makes the administration of the firewall users easier because not every single user needs to be specified on the mguard. If a user logs onto the device without being defined as firewall user, the mguard will send a request to the RADIUS server for the verification of the user. If the RADIUS server grants the access with an Access Accept packet and if this packet contains the attribute Filter-ID = <group name>, all firewall users will be accepted which belong to the group <group name>. Note: When configuring the User Firewall you need to enter the name of the group as Template User. Enter the name of the user. Select either RADIUS, if the authentication of the user should be done through a RADIUS server, or Local DB (the passwords will be stored on the mguard locally). If you have chosen RADIUS, you need to configure the RADIUS server in the tab RADIUS Servers. Otherwise the user s password needs to be entered in the column User Password. Enter the user s password if Local DB is selected as Authentication Method. Document ID: UG206002508-017 Page 30 of 95

8.5.2 RADIUS Servers If the remote user should be authenticated by a RADIUS server, configure the RADIUS server. Switch to the tab RADIUS Servers. RADIUS Servers RADIUS timeout RADIUS retries Server Port Secret Determines the time (in seconds) the mguard will wait for a response from the RADIUS server. Determines how often the mguard will send the request to the RADIUS server if the timeout was exceeded. IP address of the RADIUS server. Port number used by the RADIUS server. RADIUS server password. 8.5.3 Configuring the User Firewall From the menu, select Network Security -> User Firewall. Click New, enter a descriptive name for the firewall template and click Edit. 8.5.3.1 General Settings Options Enabled Comment Timeout Timeout type Select Yes for enabling the firewall template. You can enter an explanatory text which describes the template. Indicates the time in seconds at which point the firewall rules will be deactivated. If the user session lasts longer than the timeout defined here, the user will have to repeat the login process. Select whether the specified Timeout should be applied statically or dynamically. Note: After the log out the user can t establish new connections but he still can use already existing connections as long as they exist in the connection tracking table. Document ID: UG206002508-017 Page 31 of 95

8.5.3.2 Template Users Enter the names of users to which the firewall template should be applied. The names must correspond to those defined in the menu User Authentication -> Remote Users. If you have enabled Group Authentication, you need to enter the name of the group. 8.5.3.3 Firewall Rules The mguard determines automatically if the firewall template needs to be applied to the incoming or outgoing firewall, depending on whether the remote user logs in from the external or internal network. Firewall rules Source IP Protocol From Port To IP To Port Comment Log If %authorized_ip is specified, the firewall rules will be applied to data packets which were sent from the same machine (source IP address) from which the remote user has logged in. Data packets from other IP addresses will be dropped. If an IP address is specified, the firewall rules will be applied to data packets which were sent from this (source) IP address. Data packets from other IP addresses will be dropped. This option should be used for example if an administrator logs onto the device for enabling the user firewall for a technician who works on a different machine. Select All, TCP, UDP or ICMP. Specify the source port of the requests. This can be either any which means every port or a special port number or a range of ports (startport:endport). Port entries are only evaluated if Protocol is set to TCP or UDP. Use this field for restricting the access to a special subnet (e.g. 192.168.1.0/24) or to a single machine (e.g. 192.168.1.100/32). Specify the destination port of the requests. This can be either any which means every port or a special port number or a range of ports (startport:endport). Port entries are only evaluated if Protocol is set to TCP or UDP. Enter here an explanatory text. Select if data packets which match the rule shall be logged. Document ID: UG206002508-017 Page 32 of 95

8.5.4 Activating the User Firewall The remote user needs to log onto the mguard through https for activating the User Firewall. He needs to provide his username and password for the log in and set Access Type to User Firewall. A message in the log in screen informs the user if the log in succeeded. Document ID: UG206002508-017 Page 33 of 95

9 Redundancy 9.1 Router Redundancy (Router Mode) The redundancy feature allows two mguards to operate as one virtual router. A virtual IP address is shared among the mguards, with one designated as the master router and the other as backup. In case the master fails, the virtual IP address is mapped to the backup mguard s IP address. This backup becomes the master router. The state of the stateful firewall is synchronized between both mguards, so that in case of a fail over already existing connections will not be interrupted. The master sends messages using the Virtual Router Redundancy Protocol (VRRP) to the backup through the internal and external interface. The backup becomes the master if such messages are not received through the internal or external interface. Two mguards shall be configured to work as a redundant router. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Both mguards were configured in Router mode with static internal and external IP settings. We have used as virtual internal IP 192.168.1.254/24 and as virtual external IP 10.1.80.1/16. Devices connected to the internal network of the virtual router configuration must use the internal virtual IP as default gateway, in our example 192.168.1.254. Note: A VPN connection can not be established to the virtual external IP. Document ID: UG206002508-017 Page 34 of 95

9.1.1 Configuration of the Interfaces The following screenshot shows the configuration of the interfaces of both mguards (menu Network -> Interfaces). Both mguard were configured to use static external and internal IP settings. The options Use VLAN and VLAN ID were disabled and are not displayed in the screenshot. Document ID: UG206002508-017 Page 35 of 95

9.1.2 Redundancy Configuration Redundancy is configured through the menu Redundancy -> Firewall Redundancy. The following screenshot displays the redundancy configuration of both mguards. General Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase Virtual Router ID External IP of the 2 nd device Router Mode Internal Virtual Router ID Internal IP of the 2 nd device External virtual IP Internal Virtual IP Redundancy State displays which mguard currently acts as Master and which one as Backup. In the above example mguard 1 is the Master, mguard 2 the Backup. If mguard 1 would fail for some reasons then mguard 2 will become the Master. Must be enabled on both mguards. You should activate redundancy as last step after configuring the redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when the redundancy feature is activated. Priority defines which mguard will operate as Master. If the priorities are different, the mguard with the higher priority will operate as Master as long as there is no failure. If both mguards have the same priority and the Backup becomes the Master, it will continue working as Master, even if the other mguard becomes available again. The Authentication passphrase protects against misconfiguration among different virtual router configurations. The password must be the same on both mguards which form a virtual router. It will be transmitted in clear text and shouldn t be identical with other security relevant passwords. The Virtual Router ID identifies the virtual router and must be the same on both mguards. If there are several virtual router configurations in your network then each pair of mguards which build a virtual router must use the same Virtual Router ID but it must be different to other virtual router configurations. Enter the external IP of the other mguard, on mguard 1 the external IP of mguard 2 and vice versa. The Internal Virtual Router ID identifies the virtual router on the internal interface and must be the same on both mguards. Enter the internal IP of the other mguard, on mguard 1 the internal IP of mguard 2 and vice versa. External virtual IP specifies the external virtual IP of the virtual router configuration, in our example 10.1.80.1. Internal virtual IP specifies the internal virtual IP of the virtual router configuration, in our example 192.168.1.254. Devices connected to the internal network of the virtual router configuration should specify this IP address as default gateway. Document ID: UG206002508-017 Page 36 of 95

9.2 Firewall Redundancy (Multi Stealth Mode) Two mguards shall be configured to work as a redundant firewall. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Both mguards were configured to operate in Multi Stealth mode with a configured Management IP. In our example mguard 1 uses the Management IP 10.1.80.100 and mguard 2 10.1.80.101. Defined firewall rules must be the same on both devices. Note: It is not possible to gain access to the mguard through https://1.1.1.1 if a Management IP was specified. In this case you need to specify the Management IP for gaining access to the mguard. Document ID: UG206002508-017 Page 37 of 95

9.2.1 Configuration of the Interfaces The following screenshot shows the configuration of the interfaces of both mguards (menu Network -> Interfaces). Both mguards were configured to operate in Multi Stealth mode with an assigned Management IP. mguard 1 uses the Management IP 10.1.80.100, mguard 2 10.1.80.101. Document ID: UG206002508-017 Page 38 of 95

9.2.2 Redundancy Configuration Redundancy is configured through the menu Redundancy -> Firewall Redundancy. The following screenshot shows the redundancy configuration of both mguards. General Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase Virtual Router ID Management IP of the 2 nd device Router Mode Not required for this setup (ignored in Stealth mode). Redundancy State displays which mguard currently acts as Master and which one as Backup. In the above example mguard 1 is the Master, mguard 2 the Backup. If mguard 1 would fail for some reason then mguard 2 will become the Master. Must be enabled on both mguards. You should activate redundancy as last step after configuring the redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when the redundancy feature is activated. Priority defines which mguard will operate as Master. If the priorities are different, the mguard with the higher priority will operate as Master as long as there is no failure. If both mguards have the same priority and the Backup becomes the Master, it will continue working as Master, even if the other mguard becomes available again. The Authentication passphrase protects against misconfiguration among different redundant firewall configurations. The password must be the same on both mguards which form a redundant firewall. It will be transmitted in clear text and shouldn t be identical with other security relevant passwords. The Virtual Router ID identifies the redundant firewall configuration and must be the same on both mguards. If there are several redundant firewall configurations in your network then each pair of mguards which build a redundant firewall must use the same Virtual Router ID but it must be different to other redundant firewall configurations. Enter the Management IP of the other mguard, on mguard 1 the Management IP of mguard 2 and vice versa. Document ID: UG206002508-017 Page 39 of 95

9.3 ICMP Checks Using ICMP Checks is only required if the internal or external interfaces of the master and the backup are connected through several switches. If the direct internal or external Ethernet connection of the master fails, it switches into failure mode and the backup becomes the master due to the outstanding VRRP messages from the master. However, if the master and the backup are connected through several switches and if the connection between two switches fails, the master won t notice this and will still act as master whereas the backup will also become the master due to the outstanding VRRP messages. With ICMP Checks (ICMP echo requests), the master can check the connection to the backup and to the specified hosts and deactivate itself if needed. When enabling ICMP Checks, the mguards check automatically if they can reach each other. You don t need to add their IP addresses to the ICMP checks. The master switches into failure mode if none of the specified IP addresses can be reached. Document ID: UG206002508-017 Page 40 of 95

10 Quality of Service (Egress QoS) The term Egress Traffic describes data packets, which will leave the mguard through a physical (internal/external) or logical (VPN/IPsec) interface. Quality of Service for egress traffic (Egress QoS) ensures a certain network bandwidth to specified services. Quality of Service for egress traffic may also be used for limiting the bandwidth for specified services, networks or IP addresses. For example, transmitting VoIP data requires a higher guaranteed bandwidth for a comfortable conversation without interruptions than sending mails or ftp downloads. In case of network congestion, a higher bandwidth should be guaranteed for VoIP data. During network congestion, the outgoing data packets are put into Egress Queues and are then processed according to their priority (Low/Medium/Heigh). Egress Queues can be used for all interfaces and for VPN connections and can be configured for the following interfaces: Internal: Queues assigned to this interface are used for data packets directed to the internal network. Packets will be placed into this queue before being sent to the internal interface. External: Queues assigned to this interface are used for data packets directed to the external network. Packets will be placed into this queue before being sent to the external interface. External 2: Queues assigned to this interface are used for data packets directed to the secondary external network. Packets will be placed into this queue before being sent to the secondary external interface. Dial-in: Queues assigned to this interface are used for data packets directed to a dial-in connection. Packets will be placed into this queue before being sent to the dial-in connection. Egress Rules take care about the assignment of data packets to Egress Queues according to specified selection criteria (protocol, source IP or network, source port, destination IP or network, destination port, service (TOS/DSCP) indication). Example: Remote maintenance through the Internet In this example a machine of a production site is connected through VPN with the service centre of the manufacturer for maintenance purposes. The production site (internal 100Mbit/s) is connected through ADSL to the Internet (1Mbit/s downstream, 192kbit/s upstream). The service centre is connected through SDSL to the Internet (2.3Mbit/s). The technician at the service centre uses a desktop sharing application for accessing the control of the machine. The application requires a bandwidth of 64kbit/s for allowing a comfortable access. In parallel, the technician talks with the user of the machine over VoIP through the VPN connection. This also requires a bandwidth of 64kbit/s for a good voice quality with minimum delay. A log file with a size of several MByte is downloaded in the background through ftp. The bottleneck of the described scenario is the upstream of the ADSL connection which is limited to 192 kbit/s. Due to the download of the huge log file the VoIP call may be interrupted and the desktop sharing application may hang. This problem can be solved by using Egress QoS for the ipsec interface (VPN via External). This won t have any effect on the communication of the machine within the production site because in this example the bandwidth management is only restricted to the ipsec interface. First, Egress Queues for VoIP data and for the desktop sharing application need to be defined. Document ID: UG206002508-017 Page 41 of 95

The total Bandwidth Limit (kbit/s) was specified as 188 (kbit/s). In order for an optimal prioritization process, the total bandwidth entered here should be slightly lower than the actual amount. This prevents an overrun in the transferring device buffer, which would create adverse effects. In our example the value 188 (real upstream: 192kbit/s) was used. Two queues were configured, SC VoIP for VoIP data and SC RDA for the desktop sharing application. Both queues have a guaranteed bandwidth of 64kbit/s. A higher priority was assigned to VoIP data (High) than for the desktop application (Medium). The sum of all guaranteed bandwidth must be less or equal to the specified Total Bandwidth. The Upper Limit can be used for restricting the bandwidth for a specified service, IP address or network. Note: If no upper limit was specified, packets will only be processed by Egress QoS according to the specified rules during network congestion. If an upper limit was specified, according packets will always be processed by Egress QoS. If packets do not match to any of the defined rules they will be processed by the Default queue. If a queue is not used, its guaranteed bandwidth is available for other queues. After creating the queues, Egress Rules must be configured for assigning the selection criteria to the queues. Rule 1: The VoIP client was configured to set the TOS indication Minimize Delay in all VoIP packets. The selection criteria was configured with the parameters Protocol = All, From IP = 192.168.1.1/32 and Current TOS/DSCP = TOS: Minimize Delay. This rule was assigned to the VoIP queue (Queue Name = SC VoIP). Rule 2: The desktop sharing application on the machine can be accessed through TCP port 5632. The selection criteria was configured with the parameters Protocol = TCP, From IP = 192.168.1.1/32 and From Port = 5632. This rule was assigned to the desktop sharing application queue (Queue Name = SC RDA). Document ID: UG206002508-017 Page 42 of 95

In case of network congestion, packets directed to the ipsec interface with the source IP 192.168.1.1 and the TOS indication Minimize Delay will be processed by the queue SC VoIP with high priority. TCP packets from port 5632 directed to the ipsec interface will be processed by the queue SC RDA with medium priority. All other packets directed to the ipsec interface will be processed by the Default queue with low priority. Document ID: UG206002508-017 Page 43 of 95

11 Modem Support You can either connect an external modem to the serial port of the mguard (if the serial port is accessible) or use the built-in modem or ISDN terminal adapter of the mguard industrial RS (if the device was purchased with the feature). The phone line can be used for the following purposes: Dial-in: For getting administrative access to the mguard or for accessing the clients of the internal network through the phone line. Establishing a VPN connection to the mguard through the phone line is also supported. Dial-out: o Network mode Modem / Built-in Modem: For getting access to the Internet or for establishing VPN connections through a phone line. This feature can be used for remote services if the network, in which the mguard is located, does not have access to the Internet. All traffic directed to the WAN interface will be redirected to the phone line. o Network mode Router and Stealth: As temporary secondary external interface. This feature can be used for example for establishing VPN connections through a phone line temporarily if the access to the Internet fails due to a DSL problem. As permanent secondary external interface. 11.1 Connecting an external Modem to the mguard The following wiring is required for connecting the serial port of the mguard to a modem: Signal RJ12 mguard blade mguard industrial RS RJ11 EAGLE mguard SUB-D9: Female mguard delta SUB-D9: Male Modem GND 1 4 5 5 RXD 2 5 3 2 RTS 3 6 8 7 TXD 4 3 2 3 CTS 5 1 7 8 RJ11, RJ12: Pin 1 of the connector is on the left when viewing the connector with the locking tab down and the end with the cable in it toward you. 11.2 Dial-in Configuration A dial-in connection can be used for getting administrative access to the mguard or for accessing the clients of the internal network through the phone line. The dial-in could happen either through an external modem connected to the serial port of the mguard or through the built-in modem or ISDN terminal adapter of the mguard industrial RS. In this example an mguard industrial RS with built-in modem was configured to operate as router between the networks 192.168.1.0/24 and 10.1.0.0/16. The dial-in connection is used to gain administrative access to the mguard and for accessing the clients of the internal network. Document ID: UG206002508-017 Page 44 of 95

IP addresses must be assigned to the mguard and to the remote entity for the Point-To-Point connection (in our example 192.168.2.1 and 192.168.2.2). Those IP addresses must not belong to an existing network. 11.2.1 General Modem Settings From the menu, select Network -> Interfaces, tab Modem / Console. When using an external modem, specify the following settings in the section External Modem: External Modem Hardware handshake RTS/CTS Baudrate Handle modem transparently Modem init string Enable hardware handshake. The specified baudrate should be slightly higher than the baudrate supported by the phone line. Usually you can leave the default value (57600). Select No. This option is enabled by default due to backwards compatibility reasons. Enter the following modem init string. This init string should work with most modems. '' \d+++\dath OK ATZ OK ATS0=1&C0&D0E0 OK When using the built-in modem of the mguard industrial RS, select the general modem settings in the section Built-in Modem (analog). Document ID: UG206002508-017 Page 45 of 95

11.2.2 Configuring the Dial-in Connection on the mguard From the menu, select Network -> Interfaces, tab Dial-in. PPP dial-in options Modem (PPP) Local IP Remote IP PPP Login name PPP Password Select either External Modem or Built-in Modem, depending on whether an external modem is connected to the serial port or the built-in modem of the mguard industrial RS is used. Specify the IP address which will be assigned to the mguard for the PPP connection. This IP address must not belong to an existing network. Specify the IP address which will be assigned to the remote entity for the PPP connection. This IP address must not belong to an existing network. Specify the user name and password which need to be provided for the dial-in. Incoming Rules (PPP) / Outgoing Rules (PPP) Specifying incoming and/or outgoing rules is only required if the clients of the internal network should be reachable through the dial-in connection. If you only want to get administrative access to the mguard no rules need to be defined. 11.2.3 Enabling HTTPS Remote Access If the mguard should be administered through the dial-in connection you need to enable HTTPS remote access (menu Management -> Web Settings, tab Access). You don t need to specify a rule for the Allowed Networks. HTTPS remote access for the dial-in connection is allowed by default if HTTPS remote access is enabled. Document ID: UG206002508-017 Page 46 of 95

11.2.4 Required changes on the remote entity For accessing the internal clients of the mguard through the dial-in connection it could be required that you add a route to this network, using the Local IP of the mguard as gateway (in our example: network = 192.168.1.0/24, gateway = 192.168.2.1). At first you need to determine which interface is used for the PPP connection. On Windows, use the DOS command route print: C:\>route print =========================================================================== Interface List 0x1... MS TCP Loopback interface 0x4...00 11 43 45 ca 57... Intel(R) PRO/100 VE Network Connection 0xe0006...00 53 45 00 00 00... WAN (PPP/SLIP) Interface =========================================================================== Then use the DOS command route add to add the route to the internal network of the mguard, in our example: route add 192.168.1.0 mask 255.255.255.0 192.168.2.1 IF 0xe0006 Document ID: UG206002508-017 Page 47 of 95

11.3 Dial-out Configuration The purpose of using the dial-out feature depends on the used network mode: Modem / Built-in Modem: For getting access to the Internet or for establishing VPN connections through a phone line. This feature can be used for remote services if the network, in which the mguard is located, does not have access to the Internet. All traffic directed to the WAN interface will be redirected to the phone line. Router and Stealth Mode: o Using the phone line as secondary external interface temporarily. This feature can be used for example for establishing VPN connections through a phone line temporarily if the access to the Internet fails due to a DSL problem. o Using the phone line as secondary external interface permanently. 11.3.1 General Modem Settings From the menu, select Network -> Interfaces, tab Modem / Console. When using an external modem, specify the following settings in the section External Modem: External Modem Hardware handshake RTS/CTS Baudrate Handle modem transparently Modem init string Enable hardware handshake. The specified baudrate should be slightly higher than the baudrate supported by the phone line. Usually you can leave the default value (57600). Select No. This option is enabled by default due to backwards compatibility reasons. Enter the following modem init string. This init string should work with most modems. '' \d+++\dath OK ATZ OK ATS0=0&C0&D0E0X3 OK Use the option X3 only if the modem is connected to an extension line. When using the built-in modem of the mguard industrial RS, select the general modem settings in the section Built-in Modem (analog). Document ID: UG206002508-017 Page 48 of 95

11.3.2 Configuring the Dial-out Connection on the mguard Through which interface the dial-out happens depends on the selected network mode and the configuration of the Secondary External Interface (tab General): Network Mode Secondary External Interface Dial-out through Selected network mode Modem Off External modem Built-in Modem Off Built-in modem or ISDN terminal adapter of the mguard industrial RS Router or Stealth Modem External modem Router or Stealth Built-in modem Built-in modem or ISDN terminal adapter of the mguard industrial RS From the menu, select Network -> Interfaces, tab Dial-out. PPP dial-out options Phone number to call Authentication Dial on demand Idle timeout Idle time (seconds) Local IP Remote IP Netmask Telephone number of the ISP. Select None, PAP or CHAP. These are procedures used for the secure transfer of authentication data over Point-to-Point Protocol. If the ISP requires the user to login using user name and password, then PAP or CHAP is used as the authentication procedure. The user name, password and any other entries needed for the user to access the Internet are given to the user by the ISP. Depending if PAP, CHAP or None is selected, additional fields for entering the relevant data are displayed (e.g. User name and Password). No: The mguard establishes a telephone connection using a connected modem as soon as possible after a reboot or activation of the Modem network mode. This remains in place constantly, regardless of whether data is transferred or not. Yes: The mguard only commands the modem to establish a phone connection when network packages are to be transferred. It also instructs the modem to terminate the phone connection as soon as no more network packages are to be transferred for a specific time. Only considered when Dial on demand is set to Yes. When this option is enabled, the mguard terminates the phone connection as soon as no data transfer takes place over the defined idle period. If no data traffic is made after the specified time, the mguard can terminate the phone connection IP address of the mguard serial port that now acts as a WAN interface. Use 0.0.0.0 if the IP address is assigned dynamically by the ISP. Otherwise enter the fixed IP address. IP address of the remote peer. This is the IP address of the ISP used for access when connecting to the Internet. As PPP is used for the connection, the IP address is not normally specified. This means you can use the predefined value 0.0.0.0. Netmask which belongs to the Local IP and Remote IP. If you use fixed settings for those IP addresses you also need to enter the corresponding netmask. Otherwise use 0.0.0.0. Document ID: UG206002508-017 Page 49 of 95

12 IPsec VPN 12.1 Limitations The following operating modes are not supported. Pre-Shared Secret Key (PSK) with dynamic public IP PSK with dynamic public IP requires the Aggressive Mode which is currently not supported by the mguard. Possible alternatives are: Use static public IP addresses. Register the dynamically assigned IP address with a fixed name in a DynDNS services and refer to this name on other devices. Use X.509 certificates instead of PSK. Pre-Shared Secret Key (PSK) with NAT/NAT-T You can not use PSK with NAT/NAT-T because the mguard does not support Aggressive Mode in its current version. L2TP and NAT/NAT-T NAT/NAT-T can only be used for tunnel connections due to technical reasons. L2TP is a transport connection. VPN transport connection and NAT/IPSec passthrough NAT/IPSec passthrough can only be used for tunnel connections due to technical reasons. L2TP and mguard in Stealth mode The mguard does not provide a L2TP service for the Stealth mode. VPN in Multi-Stealth Mode A VPN connection between two mguards in Multi-Stealth mode can not be used if both mguards are located within the same network. Document ID: UG206002508-017 Page 50 of 95

12.2 VPN Configuration 12.2.1 Authentication Method 12.2.1.1 Pre-Shared Secret Key (PSK) Note: PSK can not be used if the VPN connection will be established across one or more gateways that have Network Address Translation (NAT) activated. This would require the Aggressive Mode which is currently not supported by the mguard. In this case using X.509 certificates is required. If a peer has a dynamic public IP address, this peer needs to register its current IP address under a fixed name in a DynDNS service and the remote peer must use this DynDNS name as address of the remote VPN gateway. Otherwise the Aggressive Mode would be required which is currently not supported by the mguard. Note: If you specify a DynDNS name as address of the remote VPN gateway you must activate DynDNS monitoring (menu IPsec VPN -> Global, tab DynDNS Monitoring). Otherwise the mguard won t notice if the IP address of the remote VPN gateway has changed and establishing the VPN tunnel might fail. The PSK needs to be entered when configuring the VPN connection. This will be done through the menu IPsec VPN -> Connections, tab Authentication. Set Authentication method to Pre-Shared Secret (PSK) and enter the Pre-Shared Secret Key. The used secret key must be the same on both peers. VPN connections using PSK use by default the IP address of the peers as VPN identifier. If another VPN identifier shall be used (e.g. hostname or email address), you can enter it into the field Remote or Local VPN Identifier respectively. If a hostname should be used as VPN identifier, the entered hostname must be preceded by the character @. Document ID: UG206002508-017 Page 51 of 95

12.2.1.2 X.509 Certificates Using X.509 certificates requires the following certificates: 1) A machine certificate (PKCS#12) for the mguard. The machine certificate needs to be uploaded through the menu Authentication -> Certificates, tab Machine Certificates. 2) The remote entity can either be authenticated by its host certificate or by the CA certificate which was used for signing the certificate of the remote entity. The host certificate needs to be uploaded when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). The CA certificate needs to be uploaded through the menu Authentication -> Certificates, tab CA Certificates. If a certificate chain was used for signing the remote certificate (e.g. Root CA -> Sub CA -> End Entity certificate), the complete certificate chain must be imported. When using the VPN Tunnel Groups feature, the CA certificate, which was used for signing the remote certificates, needs to be imported. This will be done through the menu Authentication -> Certificates, tab CA Certificates. X.509 certificates may be obtained either from as Certification Authority (e.g. VeriSign) or from the Microsoft CA Server or by using freeware tools like for example OpenSSL or XCA (http://xca.sourceforge.net). 1) Import of the mguard s machine certificate The machine certificate of the mguard needs to be imported through the menu Authentication -> Certificates, tab Machine Certificates. Click the down arrow to create a new line. Enter a name (Shortname) for the certificate. When configuring the VPN connection, the machine certificate will be selectable by this name. Click Browse and select the machine certificate of the mguard. Enter the Password which protects the certificate against unauthorized usage. Click Import. The certificate is uploaded to the device. When the upload is finished, the certificate identifying parameters are displayed. Click Apply. The machine certificate which should be used as Locale X.509 Certificate for a VPN connection needs to be selected by its shortname when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). Document ID: UG206002508-017 Page 52 of 95

2) Import of a CA certificate The CA certificate, which was used for signing the certificates of the remote entities, needs to be imported when using the VPN Tunnel Groups feature or when the remote certificate is authenticated by its CA certificate. The import will be done through the menu Authentication -> Certificates, tab CA Certificates. Click the down arrow to create a new line. Enter a name (Shortname) for the CA certificate. When configuring the VPN connection, the CA certificate will be selectable by this name. Click Browse and select the CA certificate. Click Import. The certificate is uploaded to the device. When the upload is finished, the certificate identifying parameters are displayed. Click Apply. Note: If a certificate chain was used for signing the remote certificate (e.g. Root CA -> Sub CA -> End Entity certificate), the complete certificate chain must be imported. When verifying the remote certificate against a CA certificate, you need to select the CA certificate by its shortname as Remote CA certificate when configuring the VPN connection (menu IPsec VPN - > Connections, tab Authentication). Document ID: UG206002508-017 Page 53 of 95

3) Import of the remote certificate If the remote entity is authenticated by its certificate, the host certificate needs to be imported when configuring the VPN connection. This will be done through the menu IPsec VPN -> Connections, tab Authentication. Set Authentication method to X.509 Certificate. Select as Local X.509 Certificate the mguard s machine certificate which should be used for the connection. Set Remote CA Certificate to No CA certificate, but the Remote Certificate below. Click Browse, select the remote certificate and click Upload. The certificate is uploaded to the device. When the upload is finished, the certificate identifying parameters are displayed. Click Apply. The mguard uses as default the subject name of the certificate (e.g. CN=mGuard 2, O=Innominate, OU=Support) as VPN identifier. If another VPN Identifier (e.g. hostname, email address or IP address) is required you can enter it into the fields Remote or Local respectively. Using another VPN identifier than the certificate s subject name requires that the identifier is present in the certificate as subject alternative name. If a hostname should be used as VPN identifier, the entered hostname must be preceded by the character @. When using the subject name as VPN identifier, the Remote VPN Identifier can be used as subject filter. If this line is empty, the complete subject must match, e.g. CN=mGuard, O=Innominate, OU=Support. The asterisk * can be used as wildcard, e.g. CN=*, O=Innominate, OU=Support. The number of the specified attributes must exactly match those of the certificate to which the filter should be applied. The order is not important. Entering only the asterisk * will cause that any subject of a remote certificate will match. Document ID: UG206002508-017 Page 54 of 95

12.2.2 VPN Firewall VPN specific firewall rules may be specified when configuring the VPN connection. The VPN Firewall allows restricting the access through the VPN tunnel. You may configure the VPN firewall if required. By default, all incoming and outgoing connections will be passed through. Document ID: UG206002508-017 Page 55 of 95

12.2.3 IKE Options The IKE options need to be specified when configuring the VPN connection. This will be done through the menu IPsec VPN -> Connections, tab IKE Options. ISKMP SA (Key Exchange) Encryption Algorithm Select the Encryption Algorithm that shall be used for phase 1. The selected Encryption Algorithm must be supported by the remote VPN gateway. Hash Algorithm Select the Hash Algorithm that shall be used for phase 1. The selected Hash Algorithm must be supported by the remote VPN gateway. IPsec SA (Data Exchange) Encryption Algorithm Select the Encryption Algorithm that shall be used for phase 2. The selected Encryption Algorithm must be supported by the remote VPN gateway. Hash Algorithm Select the Hash Algorithm that shall be used for phase 2. The selected Hash Algorithm must be supported by the remote VPN gateway. Perfect Forward Secrecy Enable PFS if desired. If you enable PFS on one device you also need to (PFS) enable it on the other site. Lifetimes ISAKMP SA Lifetime Specifies the lifetime of the ISAKMP SA in seconds. When the lifetime expires, a new key will be negotiated between the peers. IPsec SA Lifetime Specifies the lifetime of the IPsec SA in seconds. When the lifetime expires, a new key will be negotiated between the peers. Rekeymargin Minimal time interval before the old key expires during which a new key shall be negotiated. Rekeyfuzz Maximum in percent by which Rekeymargin shall be randomly increased. This is to lower the load during key exchanges on machines with many VPN connections by serializing them. Rekeying tries Number of attempts to negotiate new keys with the remote peer. The special value 0 means unlimited attempts in case the connection is to be initiated by the mguard, otherwise it means 5. Rekey When set to Yes, the mguard will try to renegotiate keys when they expire. Dead Peer Detection Delay The length of time in seconds after which DPD Keep Alive queries will be sent to check the availability of the remote peer. Timeout The length of time in seconds after which the remote peer will be declared dead if the Keep Alive queries are not answered. Document ID: UG206002508-017 Page 56 of 95

12.2.3.1 ISAKMP SA/IPsec SA Lifetime The keys of an IPsec connection will be renegotiated in certain intervals to increase the costs of an attack at the IPsec connection. Those intervals are defined by the parameters ISAKMP SA Lifetime and IPsec SA Lifetime. The default settings are ISAKMP SA Lifetime = 3600 seconds (1 hour) IPsec SA Lifetime = 28800 seconds (8 hours) Rekeymargin specifies a minimal time interval before the old key expires during which a new key shall be negotiated. Rekeyfuzz defines the maximum in percent by which Rekeymargin shall be randomly increased. This is to lower the load during key exchanges on machines with many VPN connections by serializing them. The settings for Rekeymargin and Rekeyfuzz are applied to ISAKMP SA Lifetime and IPsec SA Lifetime. Example: ISAKMP SA Lifetime = 3600 (seconds) Rekeymargin = 540 (seconds) Rekeyfuzz = 50 (%) When the ISAKMP SA has been established, a new key will be negotiated after 3600 seconds. Due to the value of Rekeymargin this could happen after 3600 540 = 3060 seconds. Due to the value of Rekeyfuzz the value of Rekeymargin can be increased randomly by maximal 50 percent: 3600 540 + (540/2) = 3330 seconds. The new key for the ISAKMP SA will be negotiated after 3060 3330 seconds. 12.2.3.2 Dead Peer Detection (DPD) Note: The mechanism of Dead Peer Detection only works if both peers support DPD. Let s take a look at the following example: Delay = 30 (seconds) Timeout = 120 (seconds) The mguard will send a DPD Keep Alive query over the ISAKMP SA to check the availability of the remote VPN gateway every 30 seconds (Delay). If the remote VPN gateway does not answer the Keep Alive queries within 120 seconds (Timeout), the mguard will declare the peer as dead. The action resulting from a peer found dead depends on the selected Connection startup option (tab General): Initiate: The mguard tries to re-establish the connection. Initiate on demand: The mguard will re-establish the connection the next time when data from the internal network needs to be sent to the remote VPN network. Wait: The connection is cleared and needs to be re-established by the remote VPN gateway. Document ID: UG206002508-017 Page 57 of 95

12.3 mguard behind NAT Gateway If the VPN connection is established across one or more gateways that have Network Address Translation (NAT) activated, X.509 certificates must be used for authentication. Only one mguard should initiate the VPN connection, the other one must wait for the connection (menu: IPsec VPN -> Connections, tab General, parameter Connection startup). On the responding mguard Address of the remote site s VPN gateway must be specified as %any, even if the remote NAT Router has a static public IP address. Apart of this the following needs to be considered: 12.3.1 VPN initiating mguard behind NAT Gateway A firewall on the NAT Router must allow outgoing UDP packets to port 500 and 4500. 12.3.2 VPN responding mguard behind NAT Gateway On the NAT Router port forwarding must be configured for UDP port 500 and UDP port 4500 to the external IP of mguard 2. Note: Due to the required port forwarding for UDP 500 and UDP 4500 on the NAT router neither other VPN connections can terminate at the NAT router itself nor further VPN connections can be established to other mguards which are located in Network B. If this is required, mguard 2 should initiate the VPN connection to mguard 1. In this case no port forwarding rules need to be specified on the NAT router. Document ID: UG206002508-017 Page 58 of 95

12.3.3 Both mguards behind NAT Gateways Only the mguard who initiates the VPN tunnel must also initiate the re-keying of the ISAKMP SA and IPsec SA. Deactivate the re-keying on mguard 2 (menu IPsec VPN -> Connections, tab IKE Options, Rekey = No) and set the lifetimes of the ISAKMP SA and the IPsec SA to 86400. A firewall on NAT Router 1 must allow outgoing UDP packets to port 500 and 4500. On NAT Router 2 port forwarding must be configured for UDP port 500 and UDP port 4500 to the external IP of mguard 2. Document ID: UG206002508-017 Page 59 of 95

12.4 VPN Transport Connection between two mguard in Stealth Mode with PSK A VPN transport connection is used for connecting two hosts. You won t have access to the internal network of the remote host. Therefore using a transport connection makes only sense if the mguards are operated in Stealth mode for securing the data transfer between two hosts or for accessing a host through a secured connection for maintenance purposes. Note: A transport connection can not be used if the connection will be established across one or more gateways that have Network Address Translation (NAT) activated. In this example we want to establish a VPN transport connection between two mguards in Stealth mode, using Pre-Shared Key for authentication. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. 12.4.1 Configuration of the Interfaces The interfaces of the mguard are configured through the menu Network -> Interfaces. Both mguards were configured to operate in Stealth autodetect mode. mguard 1 adopts the IP address of Server 1 (10.1.0.54), mguard 2 the IP address of Server 2 (10.1.0.58). Document ID: UG206002508-017 Page 60 of 95

12.4.2 VPN Configuration From the menu, select IPsec VPN -> Connections. Click the down arrow for creating a new line. Enter a descriptive name for the connection and click Edit. 1) General Settings The following screenshot displays the configuration of both devices. The Transport and Tunnel Settings are the same on both devices. Options Address of the remote site s VPN gateway Connection startup On mguard 1, enter the IP address of mguard 2 and vice versa. %any can t be used because we are using PSKs. %any can only be used with certificates. Initiate: Initiate the VPN connection. Initiate on traffic: Initiate the VPN connection only if traffic needs to be send through the tunnel. Wait: Wait for the VPN connect request from the remote peer. Transport and Tunnel Settings Type Select Transport for a VPN transport connection. 2) Authentication We have used Pre-Shared Key (PSK) for authentication. Please refer to chapter Authentication Method for getting further information about the configuration of the tab Authentication. 3) Firewall We have kept the default settings. Please refer to chapter VPN Firewall for getting further information about the configuration of the VPN firewall. 4) IKE Options We have kept the default settings. Please refer to chapter IKE Options for getting further information about the configuration of the IKE Options. Document ID: UG206002508-017 Page 61 of 95

12.5 VPN Tunnel between two mguards in Router/PPPoE Mode with Certificates In this example we want to establish a VPN tunnel between two mguards in Router mode, using X.509 certificates for authentication. The tunnel will be initiated by mguard 1. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Establishing a VPN tunnel between two mguards in PPPoE mode through the Internet is similar to the scenario described above. In this case the External Network is the Internet. The mguards will receive their external IP settings from the ISP. If both sites have a dynamic public IP address, one mguard (responder, mguard 2) must register its external IP address under a fixed name in a DynDNS service and the other mguard (initiator, mguard 1) must refer to this name when establishing the VPN connection. In this case you must activate DynDNS monitoring (menu IPsec VPN -> Global, tab DynDNS Monitoring) on the VPN initiating mguard (mguard 1). Otherwise the mguard won t notice if the IP address of the remote entity has changed and establishing the VPN tunnel fails. Note: A VPN tunnel can only be established between different networks. If two sites have the same internal network you need to use the feature VPN 1:1 NAT for the local network (refer to chapter VPN 1-to-1 NAT for the local Network (Destination NAT, DNAT)). Document ID: UG206002508-017 Page 62 of 95

12.5.1 Configuration of the Interfaces The interfaces of the mguard are configured through the menu Network -> Interfaces. Both mguard were configured to operate in Router mode with the following settings: Network Mode mguard 1 mguard 2 Network Mode Router Router External Networks Obtain external No No configuration via DHCP External IPs 10.1.80.100 10.1.80.101 External Netmask 255.255.0.0 255.255.0.0 IP of default gateway 10.1.0.254 10.1.0.254 Internal Networks Internal IPs 192.168.1.254 192.168.80.254 Internal Netmask 255.255.255.0 255.255.255.0 12.5.2 Required X.509 Certificates The following certificates are required for this setup. The certificates of mguard 1 and mguard 2 don t necessarily need to be signed by the same CA. mguard 1 certificate o PKCS#12 export (mguard 1 machine certificate): This export needs to be imported on mguard 1 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 1 certificate): This certificate needs to be imported on mguard 2 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). mguard 2 certificate o PKCS#12 export (mguard 2 machine certificate): This export needs to be imported on mguard 2 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 2 certificate): This certificate needs to be imported on mguard 1 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). 12.5.3 Import of the Machine Certificates Before you start configuring the VPN connection you need to import the machine certificates on both mguards, in our example the PKCS#12 export of the mguard 1 certificate on mguard 1 and the PKCS#12 export of the mguard 2 certificate on mguard 2. This needs to be done through the menu Authentication -> Certificates, tab Machine Certificates. Please refer to chapter X.509 Certificates for getting further information about how to import the machine certificates. Document ID: UG206002508-017 Page 63 of 95

12.5.4 VPN Configuration From the menu, select IPsec VPN -> Connections. Click the down arrow at the left side to create a new line. Enter a descriptive name for the connection and click Edit. 1) General Settings mguard 1 (Initiator) mguard 2 (Responder) Options mguard 1 (Initiator) mguard 2 (Responder) Address of the remote site s VPN gateway Enter the external IP address of mguard 2, in our example 10.1.80.101. Enter %any. Connection startup mguard 1 should Initiate the VPN connection. mguard 2 Waits for the connection. Transport and Tunnel Settings Type Set Type to Tunnel for a tunnel connection. Local Enter the internal network of the mguard, in our example 192.168.1.0/24. Enter the internal network of the mguard, in our example 192.168.80.0/24. Remote Enter the internal network of the remote mguard, in our example 192.168.80.0/24. Enter the internal network of the remote mguard, in our example 192.168.1.0/24. Document ID: UG206002508-017 Page 64 of 95

2) Authentication Authentication Authentication method Local X.509 Certificate Remote X.509 Certificate Remote Certificate VPN Identifier Not required for this setup. Select X.509 Certificate. Select the mguard s machine certificate Select No CA certificate, but the Remote Certificate below. Click Browse, select the host certificate of the remote entity, in our example on mguard 1 the certificate (PEM export) of mguard 2 and vice versa, and click Upload. 3) Firewall We have kept the default settings. Please refer to chapter VPN Firewall for getting further information about the configuration of the VPN firewall. 4) IKE Options We have kept the default settings. Please refer to chapter IKE Options for getting further information about the configuration of the IKE Options. Document ID: UG206002508-017 Page 65 of 95

12.6 VPN Tunnel between two mguards, Single-Stealth and PPPoE Mode, with Certificates In this example we want to establish a VPN tunnel from an mguard in Single Stealth (autodetect or static) mode to an mguard in PPPoE mode. We need to use X.509 certificates because the connection will be established across a NAT router. The tunnel will be initiated by the Stealth mguard (mguard 1). mguard 2 has the static public IP 77.245.32.78. Of course, it would also be possible to establish the VPN tunnel from mguard 2 to mguard 1 but in this case port forwarding to the IP of the Stealth mguard for UDP 500 and UDP 4500 must be configured on the NAT router. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. 12.6.1 Configuration of the Interfaces The interfaces of the mguard are configured through the menu Network -> Interfaces. Both mguard were configured with the following settings: Network Mode mguard 1 (Stealth) mguard 2 (PPPoE) Network Mode Stealth (autodetect) PPPoE Internal Networks Internal IPs n.a. 192.168.1.254 Internal Netmask n.a. 255.255.255.0 The Stealth mguard adopts the IP address of the client (10.1.0.58). Document ID: UG206002508-017 Page 66 of 95

12.6.2 Required X.509 Certificates The following certificates are required for this setup. The certificates of mguard 1 and mguard 2 don t necessarily need to be signed by the same CA. mguard 1 certificate o PKCS#12 export (mguard 1 machine certificate): This export needs to be imported on mguard 1 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 1 certificate): This certificate needs to be imported on mguard 2 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). mguard 2 certificate o PKCS#12 export (mguard 2 machine certificate): This export needs to be imported on mguard 2 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 2 certificate): This certificate needs to be imported on mguard 1 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). 12.6.3 Import of the Machine Certificates Before you start configuring the VPN connection you need to import the machine certificates on both mguards, in our example the PKCS#12 export of the mguard 1 certificate on mguard 1 and the PKCS#12 export of the mguard 2 certificate on mguard 2. This needs to be done through the menu Authentication -> Certificates, tab Machine Certificates. Please refer to chapter X.509 Certificates for getting further information about how to import the machine certificates. Document ID: UG206002508-017 Page 67 of 95

12.6.4 VPN Configuration From the menu, select IPsec VPN -> Connections. Click the down arrow at the left side to create a new line. Enter a descriptive name for the connection and click Edit. 1) General Settings mguard 1 (Stealth mode) mguard 2 (PPPoE mode) Options mguard 1 (Stealth mode) mguard 2 (PPPoE mode) Address of the remote site s VPN gateway Enter the external IP address of mguard 2, in our example 77.245.32.78. Enter %any. Connection startup mguard 1 should Initiate the VPN connection. mguard 2 Waits for the connection. The following needs to be considered regarding the Transport and Tunnel Settings: If the client, which is connected to the internal interface of the Stealth mguard, has static IP setting and if this IP address does not belong to the remote network of mguard 2, you can enter the client s IP address as Local network and Virtual IP on mguard 1 (Stealth mode) and as Remote network on mguard 2 (PPPoE mode). mguard 1 (Stealth mode) mguard 2 (PPPoE mode) Document ID: UG206002508-017 Page 68 of 95

Otherwise, if the client receives the IP settings from a DHCP server or if the client s IP address belongs to the remote network, you need to use a virtual transfer network as Local network on mguard 1 (Stealth mode). The Virtual IP must belong to the virtual network and is used for accessing the client from the remote VPN network. In this example we have used 172.16.1.1/32 as virtual transfer network and 172.16.1.1 as Virtual IP. The virtual transfer network must be entered on mguard 2 (PPPoE mode) as Remote network. mguard 1 (Stealth mode) mguard 2 (PPPoE mode) Document ID: UG206002508-017 Page 69 of 95

2) Authentication Authentication Authentication method Local X.509 Certificate Remote X.509 Certificate Remote Certificate VPN Identifier Not required for this setup. Select X.509 Certificate. Select the mguard s machine certificate Select No CA certificate, but the Remote Certificate below. Click Browse, select the host certificate of the remote entity, in our example on mguard 1 the certificate (PEM export) of mguard 2 and vice versa, and click Upload. 3) Firewall We have kept the default settings. Please refer to chapter VPN Firewall for getting further information about the configuration of the VPN firewall. 4) IKE Options We have kept the default settings. Please refer to chapter IKE Options for getting further information about the configuration of the IKE Options. Document ID: UG206002508-017 Page 70 of 95

12.7 VPN Tunnel between two mguards, Multi-Stealth and PPPoE Mode, with Certificates Starting with mguard version 6.0.0 VPN is also supported for the Multi Stealth mode. In this example we want to establish a VPN tunnel from an mguard in Multi Stealth mode to an mguard in PPPoE mode. We need to use X.509 certificates because the connection will be established across a NAT router. The tunnel will be initiated by mguard 1. mguard 2 has the static public IP 77.245.32.78. Of course, it would also be possible to establish the VPN tunnel from mguard 2 to mguard 1 but in this case port forwarding to the Management IP of the Stealth mguard for UDP 500 and UDP 4500 must be configured on the NAT router. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. For using the VPN feature in Multi Stealth mode, a Management IP needs to be assigned to the mguard. This IP address must belong to the local network and must not be used by any other entity. In our example we have chosen 10.1.80.10. 12.7.1 Configuration of the Interfaces The interfaces of the mguard are configured through the menu Network -> Interfaces. Both mguard were configured with the following settings: Network Mode mguard 1 (Stealth) mguard 2 (PPPoE) Network Mode Stealth (multiple clients) PPPoE Stealth Management IP Address IP address 10.1.80.10 n.a. Netmask 255.255.0.0 n.a. Default gateway 10.1.0.254 n.a. Internal Networks Internal IPs n.a. 192.168.1.254 Internal Netmask n.a. 255.255.255.0 Document ID: UG206002508-017 Page 71 of 95

12.7.2 Required X.509 Certificates The following certificates are required for this setup. The certificates of mguard 1 and mguard 2 don t necessarily need to be signed by the same CA. mguard 1 certificate o PKCS#12 export (mguard 1 machine certificate): This export needs to be imported on mguard 1 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 1 certificate): This certificate needs to be imported on mguard 2 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). mguard 2 certificate o PKCS#12 export (mguard 2 machine certificate): This export needs to be imported on mguard 2 as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). o PEM export (mguard 2 certificate): This certificate needs to be imported on mguard 1 as remote certificate when configuring the VPN connection (menu IPsec VPN -> Connections, tab Authentication). 12.7.3 Import of the Machine Certificates Before you start configuring the VPN connection you need to import the machine certificates on both mguards, in our example the PKCS#12 export of the mguard 1 certificate on mguard 1 and the PKCS#12 export of the mguard 2 certificate on mguard 2. This needs to be done through the menu Authentication -> Certificates, tab Machine Certificates. Please refer to chapter X.509 Certificates for getting further information about how to import the machine certificates. Document ID: UG206002508-017 Page 72 of 95

12.7.4 VPN Configuration From the menu, select IPsec VPN -> Connections. Click the down arrow at the left side to create a new line. Enter a descriptive name for the connection and click Edit. 1) General Settings mguard 1 (Multi Stealth) mguard 2 (PPPoE) Options mguard 1 (Multi Stealth) mguard 2 (PPPoE) Address of the remote site s VPN gateway Enter the external IP address of mguard 2, in our example 77.245.32.78. Enter %any. Connection startup mguard 1 should Initiate the VPN connection. mguard 2 Waits for the connection. Transport and Tunnel Settings Type Set Type to Tunnel for a tunnel connection. Local Enter the internal network of the mguard, in our example 10.1.0.0/16. Enter the internal network of the mguard, in our example 192.168.1.0/24. Remote Enter the internal network of the remote mguard, in our example 192.168.1.0/24. Enter the internal network of the remote mguard, in our example 10.1.0.0/16. Document ID: UG206002508-017 Page 73 of 95

2) Authentication Authentication Authentication method Local X.509 Certificate Remote X.509 Certificate Remote Certificate VPN Identifier Not required for this setup. Select X.509 Certificate. Select the mguard s machine certificate Select No CA certificate, but the Remote Certificate below. Click Browse, select the host certificate of the remote entity, in our example on mguard 1 the certificate (PEM export) of mguard 2 and vice versa, and click Upload. 3) Firewall We have kept the default settings. Please refer to chapter VPN Firewall for getting further information about the configuration of the VPN firewall. 4) IKE Options We have kept the default settings. Please refer to chapter IKE Options for getting further information about the configuration of the IKE Options. Document ID: UG206002508-017 Page 74 of 95

12.8 VPN 1-to-1 NAT for the local Network Usually a VPN connection can only be established between different networks, e.g. between 192.168.1.0/24 and 192.168.2.0/24, but not if both sites have the same network. This would lead to a routing problem because packets sent to an IP address of the internal network may either be directed to the internal network itself or through the tunnel to the remote network. VPN 1-to-1 NAT for the local network solves this problem. VPN 1-to-1 NAT for the local network can be used either for establishing a VPN connection between two sides which have the same internal network or for connecting to different locations which all have the same internal network. A virtual transfer network is used for establishing the VPN tunnel. The mguard, on which VPN 1-to-1 NAT for the local network is configured, performs a 1-to-1 NAT (DNAT) from the virtual transfer network to its local network by mapping the network part of the IP address and keeping the host part unchanged. 12.8.1 VPN Tunnel between two Sites with the same internal Network In the following example we want to establish a VPN tunnel between two sites which have the same internal network 192.168.1.0/24. Virtual transfer networks need to be used on both sides for establishing the VPN tunnel. VPN 1-to-1 NAT for the local network needs to be configured on both mguards. Network A has the virtual network 192.168.10.0/24 and Network B 192.168.20.0/24. The VPN tunnel needs to be established between the virtual networks 192.168.10.0/24 and 192.168.20.0/24. Hosts of Network B are accessible from Network A through the network 192.168.20.0/24. Hosts of Network A are accessible from Network B through the network 192.168.10.0/24. Document ID: UG206002508-017 Page 75 of 95

The VPN connections need to be configured as described in the previous chapters with the following additional settings. The following screenshots display the settings of mguard 1: Options mguard 1 (Initiator) mguard 2 (Responder) Address of the remote site s VPN gateway Enter the external IP address of mguard 2. Enter %any. Connection startup mguard 1 should Initiate the VPN connection. Transport and Tunnel Settings Type Select Tunnel for a tunnel connection. Local Enter the local virtual network, in our example 192.168.10.0/24. Remote Enter the virtual network of the remote mguard, in our example 192.168.20.0/24. Click More! This action must be performed on both mguards. mguard 2 Waits for the connection. Enter the local virtual network, in our example 192.168.20.0/24. Enter the virtual network of the remote mguard, in our example 192.168.10.0/24. 1-to-1 NAT Enable 1-to-1 NAT of the local network to an internal network Internal network address for local 1- to-1 NAT Enable this option on both mguards. Enter the real internal network on both mguard, in our example 192.168.1.0. Do not specify a subnet mask. The subnet mask is taken from the specified Local network (/24). Document ID: UG206002508-017 Page 76 of 95

12.8.2 VPN Tunnel to different Locations with the same remote Network In the following example VPN tunnels from the headquarters to the branch offices Berlin and Los Angeles should be established, both of them using the same internal network 192.168.1.0/24. Virtual networks are used for the branch offices and the VPN tunnels will be established from the headquarters to the virtual networks. VPN 1-to-1 NAT for the local network takes place on the mguards located at the branch offices. For Berlin we have used the virtual network 192.168.2.0/24 and for Los Angeles 192.168.3.0/24. Data directed to 192.168.2.0/24 will be sent through the VPN tunnel to Berlin, data directed to 192.168.3.0/24 to Los Angeles. The network part of the IP address will be mapped to the local network of the branch office, keeping the host part unchanged, e.g. 192.168.3.47 -> 192.168.1.47. Examples: A ping from the headquarters to the IP address 192.168.2.100 will be sent through the VPN tunnel to Berlin. The mguard at the Berlin office maps the network part of the IP address to the local network of the branch office, keeping the host part unchanged: 192.168.2.100 -> 192.168.1.100. A ping from the headquarters to the IP address 192.168.3.100 will be sent through the VPN tunnel to Los Angeles. The mguard at the Los Angeles office maps the network part of the IP address to the local network of the branch office, keeping the host part unchanged: 192.168.3.100 -> 192.168.1.100. The VPN connections need to be configured as described in the previous chapters with the following additional settings. Headquarters mguard Two VPN tunnels need to be configured on the Headquarters mguard. One tunnel to the Berlin mguard with Local network = 10.1.0.0/16 and Remote network = 192.168.2.0/24 and the other tunnel to Los Angeles with Local network = 10.1.0.0/16 and Remote network = 192.168.3.0/24. The specified Remote networks are the virtual networks. Document ID: UG206002508-017 Page 77 of 95

Berlin mguard and Los Angeles mguard The following screenshots display the settings of the Berlin mguard: Options Berlin mguard Los Angeles mguard Address of the remote site s VPN gateway Connection startup Enter %any because the tunnel will be initiated by the headquarters mguard, using certificates. The mguards should Wait for the connection. Transport and Tunnel Settings Type Select Tunnel for a tunnel connection. Local Enter the virtual network, in our example 192.168.2.0/24. Enter the virtual network, in our example 192.168.3.0/24. Remote Enter the internal network of the headquarters mguard, in our example 10.1.0.0/16. Click More! 1-to-1 NAT Enable 1-to-1 NAT of the local network to an internal network Internal network address for local 1-to-1 NAT Enable this option on both mguards. Enter the real internal network on both mguard, in our example 192.168.1.0. Do not specify a subnet mask. The subnet mask is taken from the specified Local network (/24). Document ID: UG206002508-017 Page 78 of 95

12.9 VPN 1-to-1 NAT for the remote Network VPN 1-to-1 NAT for the remote network is used if the target systems, which should be accessed through a VPN tunnel, either do not have a default gateway defined or for which the mguard is not the default gateway. Applying changes to the IP settings of the target systems is not possible. The remote network (10.1.0.0/16) is unknown to the target system (192.168.1.47/24). In this case, if a target has received a packet through the VPN tunnel from the remote network, it will either send the reply to its default gateway (which is not the VPN gateway) or won t reply if no default gateway is defined. In any case, the sender will not receive a reply. VPN 1-to-1 NAT for the remote network solves this problem and needs to be configured on mguard 2. The specified remote network or IP is mapped to the local network (e.g. 10.1.0.32/32 -> 192.168.1.253). The ARP proxy on the mguard will provide ARP resolution for this network/ip (e.g. 192.168.1.253). This network/ip must not be used by any entity of the local network. The target machine will direct the responses to the mguard. Document ID: UG206002508-017 Page 79 of 95

The VPN connections need to be configured as described in the previous chapters with the following additional settings. The following screenshots display the settings on mguard 2, on which VPN 1- to-1 NAT for the remote network needs to be enabled. Options Address of the remote site s VPN gateway Connection startup Transport and Tunnel Settings Type Local Remote Enter %any because the tunnel will be initiated by the remote mguard, using certificates. The mguard Waits for the connection. Select Tunnel for a tunnel connection. Enter the internal network of the mguard, in our example 192.168.1.0/24. Enter the internal network of the remote mguard, in our example 10.1.0.32/32 (please refer to Considerations at the end of this chapter). Click More. 1-to-1 NAT Enable 1-to-1 NAT of the remote network to a different network Network address for remote 1-to-1 NAT Enable this option. Enter the network or IP address to which the remote network should be mapped, in our example 192.168.1.253. Do not specify a subnet mask. The subnet mask is taken from the specified Remote network (/32). Document ID: UG206002508-017 Page 80 of 95

Considerations You must be careful when choosing the subnet mask of the Remote network and specifying the network to which the remote network should be mapped. Perhaps you have noticed that according to the above mentioned configuration only the client 10.1.0.32 of Network A would have access to the machines of Network B. A subnet mask of /24 for the remote network (e.g. Remote Network = 10.1.0.0/24 and Network address for remote 1-to-1 NAT = 192.168.1.0) won t work because in this case the ARP proxy of the mguard would reply to all ARP request of the internal network (192.168.1.1 192.168.1.254). Increasing the subnet mask of the remote network would also increase the number of clients of Network A from which Network B could be accessed but it would also increases the required number of unused IP addresses of Network B for the source address mapping. The following table shows the relationship between the remote subnet mask, which clients may have access to the target systems and the number of required unused IP addresses of the local network. If you need access to the target systems from several clients, place them behind a NAT router before the packets are sent to the VPN tunnel. This way you need to specify the external IP of the NAT router with a subnet mask of /32 as Remote network and only one unused IP address of the local network is required. Document ID: UG206002508-017 Page 81 of 95

12.10 VPN Tunnel Groups The VPN Tunnel Groups feature is an optional feature, which needs to be purchased separately. Activating this feature will automatically set the maximum number of allowed VPN connections to 250. In releases prior to version 5, you needed to configure a VPN tunnel for each remote entity, which needed to establish a VPN connection to the mguard. Using the VPN Tunnel Groups feature, you only need to configure one VPN connection on the mguard. The certificates of the remote entities are verified against the CA certificate, which was used for signing their certificates. In the following example five remote users establish a VPN connection to the mguard, using a Software VPN Client on their laptop. A virtual IP from the network 172.16.1.0/24 is assigned to each Software VPN Client. Using the VPN Tunnel Groups feature on the mguard, only one VPN tunnel needs to be configured. The VPN Tunnel Groups feature is not limited to remote users, which use a single virtual IP address. Of course, you may also connect several branch offices with internal networks (e.g. 192.168.1.0/24, 192.168.2.0/24, etc.) via VPN to the mguard using this feature. 12.10.1 Import of the required Certificates Before you start configuring the VPN connection you need to import the mguard s machine certificate and the CA certificate which was used for signing the remote certificates as described in chapter X.509 Certificates. Document ID: UG206002508-017 Page 82 of 95

12.10.2 VPN Configuration 1) General Settings Options Address of the remote Enter %any because each remote users will have a different IP address and site s VPN gateway you don t want to restrict the access to one single IP address only. Connection startup The VPN tunnel will be initiated by the remote users. Therefore select Wait. Transport and Tunnel Settings Type Select Tunnel for a tunnel connection. Local Enter the internal network of the mguard, in our example 192.168.1.0/24. Remote The specified remote network must include the virtual IPs off all remote users. In our example we have entered the network 172.16.1.0/24. In case of remote networks (e.g. 192.168.1.0/24, 192.168.2.0/24, etc.) you need to choose a network which includes all remote networks (e.g. 192.168.0.0/16). Document ID: UG206002508-017 Page 83 of 95

2) Authentication Authentication Authentication method Local X.509 Certificate Remote X.509 Certificate VPN Identifier Remote Select X.509 Certificates. Select the mguard s machine certificate. Select the CA certificate which was used for signing the remote certificates. The Remote VPN Identifier can be used as subject filter. Enter only the asterisk * if any remote certificate which was signed by the specified CA certificate should be accepted. Otherwise you can use the asterisk as wildcard, as for example CN=*, O=Innominate, OU=Support. The number of the specified attributes must exactly match those of the certificate to which the filter should be applied. The order is not important. 3) Firewall We have kept the default settings. Please refer to chapter VPN Firewall for getting further information about the configuration of the VPN firewall. 4) IKE Options We have kept the default settings. Please refer to chapter IKE Options for getting further information about the configuration of the IKE Options. Document ID: UG206002508-017 Page 84 of 95

12.11 Hub and Spoke Starting with version 5 the mguard supports Hub and Spoke. This means that an mguard, operating as central VPN gateway, can redirect packets received through one VPN tunnel directly into another VPN tunnel. To activate this feature: Go to the menu IPsec VPN -> Global, tab Options. Enable Allow packet forwarding between VPN connections. Click Apply. The following needs to be considered when configuring the VPN connections: On the central VPN gateway, the specified local VPN network must include the remote VPN networks for allowing the routing between those networks. Example: Headquarters (central VPN gateway): 192.168.1.0/24 Branch Office 1: 192.168.5.0/24 Branch Office 2: 192.168.6.0/24 Branch Office 3: 192.168.9.0/24 The network 192.168.0.0/16 includes all networks. This network needs to be specified on the central VPN gateway as Local VPN network and at the branch offices as Remote VPN network. Tunnel settings for the VPN connection between Branch Office 1 and the Headquarters: Branch Office 1 Headquarters Local network 192.168.5.0/24 192.168.0.0/16 Remote network 192.168.0.0/16 192.168.5.0/24 Tunnel settings for the VPN connection between Branch Office 2 and the Headquarters: Branch Office 2 Headquarters Local network 192.168.6.0/24 192.168.0.0/16 Remote network 192.168.0.0/16 192.168.6.0/24 Tunnel settings for the VPN connection between Branch Office 3 and the Headquarters: Branch Office 3 Headquarters Local network 192.168.9.0/24 192.168.0.0/16 Remote network 192.168.0.0/16 192.168.9.0/24 Document ID: UG206002508-017 Page 85 of 95

12.12 URL for starting, stopping and Status Query of a VPN Connection The following URL can be used to start and stop VPN connections and query the connection status: https://<user>:<password>@<mguard IP>/nph-vpn.cgi?name=<name>&cmd=[up down status] <user>: The following users can be used: admin, root and user. The passwords can be configured through the menu Management -> Authentication -> Local Users. <name>: name of the VPN connection as it is displayed in the menu IPsec VPN -> Connections. The URL can be executed either from a web browser or for example on a client using wget. If a VPN connection should be activated from a client using wget, the VPN connection must be disabled in the VPN configuration (menu IPsec VPN -> Connections). wget example: wget --quiet --no-check-certificate --output-document=vpnstate.txt https://user:user_pw@10.1.0.34/nph-vpn.cgi?name=servicecenter&cmd=up wget --quiet --no-check-certificate --output-document=vpnstate.txt "https://user:user_pw@10.1.0.34/nph-vpn.cgi?name=servicecenter&cmd=down" wget --quiet --no-check-certificate --output-document=vpnstate.txt "https://user:user_pw@10.1.0.34/nph-vpn.cgi?name=servicecenter&cmd=status" Document ID: UG206002508-017 Page 86 of 95

12.13 mguard industrial RS: Activating a VPN Tunnel through an external push Button or on/off Switch The mguard industrial RS supports the feature to activate a specific VPN connection through an external connected on/off switch or push button. A signal LED (20 ma, without series resistor) indicates the status of the VPN connection: If the signal LED is set to OFF, the VPN connection is disabled. Cause: VPN connection not established or failed due to errors. If the signal LED is set to ON, the VPN connection is established. If the signal LED flashes, the VPN connection is being established or disabled. The VPN connection needs to be configured as described in the previous chapters. Apart of this the following needs to be configured: The VPN connection should be established by the external on/off switch or push button. Therefore it must be disabled in the VPN configuration (menu IPsec VPN -> Connections). Specify in the menu IPsec VPN -> Globals (tab Options): o The name of the VPN connection which should be activated. o If an on/off switch or a push button is connected to the CMD contact. Document ID: UG206002508-017 Page 87 of 95

12.14 L2TP/IPSec Connection In this example we want to establish a L2TP/IPSec connection from a Windows client to the mguard which is operated in PPPoE mode. Note: You can not use an L2TP/IPsec connection if the connection will be established across one or more gateways that have Network Address Translation (NAT) activated. The L2TP service on the mguard is supported for the Router modes (Router, PPPoE, PPTP) only. You can use PSK for authentication but this requires that you enter on the mguard as Address of the remote site s VPN gateway the public IP address of the Windows client. This is only suitable if the Windows client has a static IP address. 12.14.1 Required X.509 Certificates The following certificate exports are required for setting up the L2TP/IPsec connection. The mguard certificate and the Windows certificate must be signed by the same CA certificate. CA certificate as PEM export: This certificate needs to be imported on the Windows client with the Microsoft Management Console (MMC) as Trusted Root Certification Authorities. In this example we have named the export CA.crt. Windows certificate as PKCS#12 export: This certificate needs to be imported on the Windows client with the Microsoft Management Console (MMC) as Personal certificate. In this example we have named the export Windows.p12. Windows certificate as PEM export: This certificate needs to be imported on the mguard as connection certificate (menu IPsec VPN -> Connections, tab Authentication). In this example we have named the export Windows.crt. mguard certificate as PKCS#12 export: This certificate needs to be imported on the mguard as machine certificate (menu Authentication -> Certificates, tab Machine Certificates). In this example we have named the export mguard.p12. Document ID: UG206002508-017 Page 88 of 95

12.14.2 Configuration of the mguard 12.14.2.1 Import of the Machine Certificate Executing this step is only required when using certificates for authentication. From the menu, select Authentication -> Certificates, tab Machine Certificates. Enter a name (Shortname) for the certificate. When configuring the L2TP/IPsec connection, the machine certificate will be selectable by its short name. Click Browse and select the machine certificate of the mguard, in our example mguard.p12. Enter the Password which protects the certificate against unauthorized usage. Click Import. The certificate is uploaded to the device. When the upload is finished, the certificate identifying parameters are displayed. Click Apply. Note: The certificate will not be stored on the device if you do not click Apply. Document ID: UG206002508-017 Page 89 of 95

12.14.2.2 VPN Configuration From the menu, select IPsec VPN -> Connections. Click the down arrow for creating a new VPN connection. Enter a descriptive name for the connection and click Edit. 1) General Settings Options Address of the remote site s VPN gateway If you enter %any, you can establish the connection from every Windows client on which the L2TP/IPSec client with the appropriate certificate is configured. Otherwise only the Windows client can establish the connection which has the corresponding IP address. Note: If you use pre-shared key for authentication, you must enter the IP address of the Windows client. Connection startup Has to be set to Wait because the connection will be initiated by the Windows client. Transport and Tunnel Settings Type Select Transport because a L2TP/IPsec connection is a transport connection. Click More. Set Protocol to UDP. Ensure that Local Port and Remote Port are set to %all. Click Back. Document ID: UG206002508-017 Page 90 of 95

2) Authentication If certificates are used for authentication: Set Authentication method to X.509 Certificate. Select as Local X.509 Certificate the mguard s machine certificate which should be used for the connection. Set Remote CA Certificate to No CA certificate, but the Remote Certificate below. Click Browse, select the certificate of the Windows client, in our example Windows.crt, and click Upload. If pre-shared key is used for authentication: Set Authentication method to Pre-Shared Secret (PSK). Enter the secret key. Document ID: UG206002508-017 Page 91 of 95

3) Firewall We have kept the default settings. Of course you may modify the VPN firewall rules for restricting the access through the L2TP/IPsec connection. 4) IKE Options Select either DES or 3DES as Encryption Algorithm. Windows does not support AES. Select MD5 as Hash Algorithm, Windows does not support SHA. Set Perfect Forward Secrecy (PFS) to No. Windows does not support PFS. Click Apply. Document ID: UG206002508-017 Page 92 of 95

12.14.2.3 Starting the L2TP Server From the menu, select IPsec VPN -> L2TP over IPsec. Note: The IP addresses specified in this menu will be assigned to the mguard (Local IP) and to the Windows client (Remote IP) for the Point-to-Point connection between them. The Remote IP only needs to be used for accessing the Windows client from the internal network of the mguard. The specified IP addresses should neither belong to the internal network of the mguard nor to the external network. Enable the option Start L2TP Server for IPSec/L2TP. Local IP for L2TP connections specifies the IP address which will be used by the mguard for the Point-to-Point connection to the Windows client. Remote IPs range start/end: This IP address range is used for assigning IP addresses to the Windows clients for the Point-to-Point connection to the mguard. Click Apply. Document ID: UG206002508-017 Page 93 of 95

12.14.3 Configuring the Windows Client We have used a Windows XP SP2 client for setting up the L2TP/IPsec connection to the mguard. 12.14.3.1 Certificate import through Microsoft Management Console (MMC) The steps described in this chapter are only required when using certificates for authentication. MMC is used for importing the required certificates. 1) Add Snap-In for Certificates Click Start -> Run, enter mmc and click OK. Select File -> Add/Remove Snap-in from the menu, click Add. Select Certificates from the list, click Add. º Select Computer account, click Next. º Select Local computer, click Finish. Close the Add Standalone Snap-in window. The entry Certificates (Local computer) should appear in the list. Click OK. Now you need to save the configuration. From the menu, select File -> Save. Select Desktop from the Save in field. Enter a file name and click Save. Close MMC by selecting File -> Exit from the menu. Now it is possible to start MMC with the certificates snap-in by making a double click the MMC icon on the desktop. 2) Import of the X.509 Certificates Start MMC and reload the previously saved configuration or double click the MMC icon on the desktop. Import of the CA certificate: Expand the tree Console Root -> Certificates (Local computer). Right click Trusted Root Certification Authorities and select All Tasks -> Import. The Certificate Import Wizard appears. º Click Next. º Click Browse. º Select the option X.509-Certificate (*.cer,*.crt) from Files of type, select the CA export, in our example the certificate called CA.crt and click Open. º Click Next. º Select the option Place all certificates in the following store, click Next. º Click Finish. The message should appear that the certificate was imported successfully. Import of the windows certificate (PKCS#12 export): Expand the tree Console Root -> Certificates (Local computer). Right click Personal and select All Tasks -> Import. The Certificate Import Wizard appears. º Click Next. º Click Browse. º Select the option Personal Information Exchange (*.pfx,*.p12) from Files of type, select the PKCS#12 export of the Windows certificate, in our example Windows.p12, and click Open. º Click Next. º Enter the password which protects the certificate against unauthorized usage and click Next. º Select the option Place all certificates in the following store and click Next. º Click Finish. The message should appear that the certificate was imported successfully. You need to save the configuration before closing MMC. Select File -> Save from the menu. Document ID: UG206002508-017 Page 94 of 95

12.14.3.2 Configuration of the L2TP/IPSec Dial-up Connection Select Start -> Control Panel -> Network Connections. Select Create a new connection from the Network Tasks. The Network Connection Wizard appears. º Click Next. º Select Connect to the network at my workplace, click Next. º Select Virtual Private Network connection, click Next. º Enter a descriptive name for the connection, click Next. º Enter the external IP address of the mguard, click Next and then Finish. Now the Connect <Connection name> window appears. º Click Properties. º Switch to the tab Networking. º Select L2TP IPSec VPN as Type of VPN. º Switch to the tab Security. º Activate Advanced (custom settings) and click Settings. º Select Optional encryption as Data encryption. º Activate Unencrypted password (PAP). º Click OK. º If Pre-Shared Key (PSK) should be used for authentication: Click IPSec settings. Enable Use pre-shared key for authentication. Enter the secret key and click OK. º Click OK again to close the connection properties. º Finally click Connect for establishing the L2TP connection. You don t need to enter a password. Now it is possible to establish a L2TP connection from the Windows client to the mguard. Further information about the status of the L2TP connection can be retrieved from the menus IPsec VPN -> L2TP over IPsec and Logging -> Browse local logs, option IPsec VPN. Document ID: UG206002508-017 Page 95 of 95