Innominate mguard Version 7.0 Configuration Examples

Transcription

1 Innominate mguard Version 7.0 Configuration Examples mguard smart mguard centerport mguard blade mguard industrial RS mguard PCI mguard delta Innominate Security Technologies AG Rudower Chaussee Berlin, Germany Phone: +49 (0) Fax: +49 (0) [email protected]

2 Table of Contents 1 Disclaimer 5 2 Introduction 6 3 Factory Default Settings and Access to the Web Interface Windows Vista/Windows 7 and the command arp s 7 4 Purpose of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) Stealth Modes (autodetect, static, multiple clients) Router Mode PPPoE/PPTP Mode Modem Mode 9 5 mguard operating in Stealth Mode Management IP Static Routes DNS Server 12 6 mguard operating in PPPoE Mode Configuring the Interfaces Network Address Translation (NAT) / IP Masquerading DNS Server DynDNS Registration Required IP Settings on the Clients 15 7 mguard operating in Router Mode Configuration of the Clients in the Internal Network Configuration of the mguard Configuring the Interfaces Additional internal/external Routes Network Address Translation (NAT) / IP Masquerading DHCP Configuration DNS Sever Configuration to access the Clients in the internal Network from the external Network Configuring the incoming Firewall Possibility 1: Additional internal Routes on the Gateway Possibility 2: Port Forwarding Possibility 3: 1:1 NAT Configuration to access the Clients in the external Network from the internal Network Possibility 1: Additional internal Routes on the Gateway Possibility 2: Network Address Translation (NAT) / IP Masquerading Possibility 3: 1:1 NAT 27 Document ID: UG Page 2 of 106

3 8 Firewall Incoming/Outgoing Firewall Example of a wrongly configured Firewall Sets of Rules MAC Filtering Basic Rules to set up MAC filtering Examples MAC Filter Configuration Restricted IPv4 Access Allowing access for other Protocols than IPv4 (e.g. Novell IPX) :1 NAT :1 Mapping of IP addresses :1 Mapping of Networks User Firewall Configuring Remote Users RADIUS Servers Access Configuring the User Firewall General Settings Template Users Firewall Rules Activating the User Firewall 40 9 Firewall Redundancy Router Mode Multi-Stealth Mode ICMP Checks Quality of Service (Egress QoS) CIFS Integrity Monitoring Importable Shares CIFS Integrity Checking Integrity Database Certificate Filename Patterns Integrity Check Settings Initialize the Integrity Database CIFS Antivirus (AV) Scan Connector Modem Support Connecting an external Modem to the mguard Dial-in Configuration General Modem Settings Configuring the Dial-in Connection on the mguard Enabling HTTPS Remote Access Required changes on the remote entity Dial-out Configuration General Modem Settings Configuring the Dial-out Connection on the mguard 61 Document ID: UG Page 3 of 106

4 13 IPsec VPN Introduction mguard behind NAT Router VPN initiating mguard behind NAT Router VPN responding mguard behind NAT Router Both mguards behind NAT Router Authentication (PSK or Certificates) Limitations Import of the Machine Certificate VPN Configuration General Settings VPN Transport Connection between two mguards in Stealth Mode VPN Tunnel between two mguards in Router/PPPoE Mode VPN Tunnel between two mguards, Single Stealth and Router/PPPoE Mode VPN Tunnel between two mguards, Multi Stealth and Router/PPPoE Mode VPN 1:1 NAT for the local Network VPN Tunnel between two Sites with the same internal Network VPN Tunnel to different Locations with the same internal Networks VPN Masquerading (VPN NAT) VPN 1:1 NAT for the remote Network Hub & Spoke Example: Branch Offices Example: Remote Maintenance Authentication Pre-Shared Secret Key (PSK) X.509 Certificates VPN Firewall IKE Options ISAKMP SA/IPsec SA Lifetime Dead Peer Detection (DPD) TCP Encapsulation VPN Tunnel Groups Import of the CA Certificate Tunnel Settings Authentication URL to start, stop and retrieve the Status of a VPN Connection mguard industrial RS: Activating a VPN Tunnel through an external push Button or on/of Switch Windows L2TP/IPSec Connection to the mguard Secondary External Interface VPN Fallback through a Phone Line 105 Document ID: UG Page 4 of 106

5 1 Disclaimer Innominate Security Technologies AG March 2010 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 # and # 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: UG Page 5 of 106

6 2 Introduction This guide should help getting familiar with the configuration of the mguard. It explains on a basis of several examples how to configure the mguard for different scenarios. 3 Factory Default Settings and Access to the Web Interface The following table lists the factory default settings of the different products: Product Network mode Internal IP address Access from the internal network through mguard smart Stealth (autodetect) - mguard PCI Stealth (autodetect) - mguard industrial RS Stealth (autodetect) - mguard blade Stealth (autodetect) - mguard blade control unit Router mguard delta Router mguard centerport Router The firewall drops all incoming (except VPN) and allows all outgoing connections by default. SSH/HTTPS access from the internal network is allowed but not from the external network. The default passwords are: User = root Password = root User = admin Password = mguard Note: Before trying to access the device from 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 (autodetect): The web interface of the mguard can be accessed through under the condition that a network is connected to the external interface of the mguard and that the default gateway, defined on the client, is reachable. The easiest way to obtain this is to interconnect the mguard in-between a client and the network. If the default gateway is not reachable because it does not really exist or because the external interface of the mguard is not connected to the network, proceed as follows to obtain access to the web interface (please refer to the next chapter when using Windows Vista or Windows 7): Assign static IP settings to the client if the client is configured to obtain the IP settings from a DHCP server, as for example IP = , Subnet mask = , Default Gateway = Assign a static MAC address to the IP address of the default gateway. To send packets to the IP address the client will send an ARP request for the IP address of the default gateway first because does not belong to the network in which the client is located. This ARP request will never be answered if the default gateway is not reachable and therefore the client will never send packets directed to to the network. If the client already knows the MAC address of the default gateway, even if it is a fictitious one, it will send the packets directly to the network without issuing an ARP request first. The mguard will catch those packets directed to and will send the response back to the client. Follow these steps to assign a static MAC address to the IP address of the default gateway: Open a command prompt. Type the command ipconfig to obtain the IP address of the default gateway. Execute the command: arp s <IP of the default gateway> 00-aa-aa-aa-aa-aa A ping to the IP address should be answered. Now the web interface of the mguard can be accessed from the client through Router mode: The following static IP settings must be assigned to the client: The IP address must belong to the network /24, e.g Subnet mask = Default gateway = Now the web interface of the mguard can be accessed through Document ID: UG Page 6 of 106

7 3.1 Windows Vista/Windows 7 and the command arp s With Windows Vista and Windows 7 it is not possible anymore to assign a static MAC address to the IP address of the default gateway using the arp program. Use netsh from a command shell with administrator rights instead. At first determine the name of the corresponding interface (e.g. Local Area Connection) as it is displayed when executing the command ipconfig /all. Then use the following command to assign a static MAC address to the IP address of the default gateway. The static entry will be valid until the next reboot or until the next restart of the network connection due to the argument store=active. If this argument is not specified, the default value is store=persistent. netsh interface ipv4 set neighbors [interface=]string [address=]ipv4address [neighbor=]<string> [store=]active Example: netsh interface ipv4 set neighbors interface= Local Area Connection address= neighbor=00-aa-aa-aa-aa-aa store=active or in short netsh interface ipv4 set neighbors Local Area Connection aa-aa-aa-aa-aa active The static assignment can be verified either with the command arp a or with the command netsh interface ipv4 show neighbors <interface name>. Use the following command to delete a static assigned MAC address: netsh interface ipv4 delete neighbors [name=]string [address=]ipv4address Example: netsh interface ipv4 delete neighbors name= Local Area Connection address= or in short netsh interface ipv4 delete neighbors Local Area Connection Document ID: UG Page 7 of 106

8 4 Purpose of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) 4.1 Stealth Modes (autodetect, static, multiple clients) In Stealth mode, simply interconnect the mguard in between the client(s) to be protected and the network. Reconfiguring the IP settings of the clients or applying other IP changes to the network 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 are 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. In autodetect Stealth mode, the mguard detects the client s IP address automatically by analyzing the outgoing traffic and adopts the IP and MAC address of the client. Some entities do not generate traffic by themselves (e.g. server, webcam). In this case the mguard will never get its IP settings and the static Stealth mode must be used. In this mode at least the clients IP address must be specified on the mguard. These modes are also called Single Stealth mode because only one single entity can be protected. Stealth - multiple clients Use this mode to protect multiple clients or if the NIC of the system has more than one IP address. This mode is also called Multi Stealth mode. Document ID: UG Page 8 of 106

9 4.2 Router Mode In Router mode the mguard acts as router between two different networks. The external network could also be the Internet, if the Internet Service Provider supplies an Ethernet line. The internal and external interfaces must be configured. The external interface may use static IP settings or receive them from a DHCP server. 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. The mguard may act as DHCP server for the internal network. PPTP is an equivalent to PPPoE, used to get access to the Internet in certain countries as for example in Austria. 4.4 Modem Mode The Modem mode can be used to access 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 analog 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 through the external serial port (external modem) or through the built-in analog modem or ISDN terminal adaptor (mguard industrial RS, when equipped). Document ID: UG Page 9 of 106

10 5 mguard operating in Stealth Mode The major advantage of using the Stealth mode is that it is not required to reconfigure the IP settings of the clients or to apply other IP changes to the network. 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). Simply interconnect the mguard in between the network and the entities which should be protected, but 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 the Stealth static mode must be used by specifying at least the clients IP 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. Single Stealth Mode Multi Stealth Mode The web interface of the mguard can be accessed from the internal client(s) through HTTPS remote access must be enabled on the mguard to access it from the external network. In Single Stealth mode the mguard can be accessed through the IP address of the client. In Multi Stealth mode a Management IP must be assigned to the mguard. Document ID: UG Page 10 of 106

11 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, accessing the mguard is only possible through IP> and no longer through (except in Stealth autodetect mode). A Management IP must be assigned 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. Select Network >> Interfaces, tab General. The Management IP must belong to the network in which the mguard is located and must not be used by any other entity. Also the network subnet mask and its default gateway must be specified. 5.2 Static Routes Static routes can be used to send data through another gateway than the default gateway of the network. Static routes are only used for actions initiated by the mguard, as for example establishing VPN connections or executing an online firmware update. Document ID: UG Page 11 of 106

12 5.3 DNS Server The mguard uses a predefined list of publicly available DNS servers (Servers to query = DNS Root Servers) by default. 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 or establishing a VPN connection to a remote VPN gateway, specified by a DynDNS name. These actions may also be delayed if the responses of the publicly available DNS servers take too long. If the mguard is located within a private network it is recommend to set Servers to query = User defined and to enter the IP address of the DNS server. Select Network >> DNS, tab DNS Server. Network >> DNS, tab DNS server DNS Servers to query Select User defined. User defined name servers Enter the IP address of the DNS server. Document ID: UG Page 12 of 106

13 6 mguard operating in PPPoE Mode In this example, the mguard is operated in PPPoE mode and should act as gateway to the Internet. The following diagram illustrates the machines and addresses involved in the connection. The clients in the internal network must use the internal IP address of the mguard ( ) as Default Gateway to get access to the Internet. The external interface of the mguard is connected to a DSL modem. 6.1 Configuring the Interfaces Select Network >> Interfaces, tab General. Document ID: UG Page 13 of 106

14 Network >> Interfaces, tab General Network Mode PPPoE Internal Networks Secondary External Interface Network Mode Router Mode PPPoE Login PPPoE Password Request PPPoE Service Name / PPPoE Service Name Automatic Re-connect? / Re-connect daily at IP Netmask Not required for this setup. Select Router. Select PPPoE. Enter the user name provided by the Internet Service Provider (ISP). Enter the password provided by the Internet Service Provider (ISP). Enable this option if the DSL modem is used to connect to more than one Internet Service Provider. In this case enter the corresponding PPPoE Service Name to connect to the desired Internet Service Provider. If enabled, the mguard will reconnect to the ISP every day at the specified time. This feature allows moving the 24 hour interruption of the DSL line outside the office hours. Using this feature requires that the system time was either entered manually or synchronized with an NTP server. Enter the internal IP address of the mguard, in this example Enter the corresponding subnet mask, in this example After applying the changes, the mguard can be accessed through IP of the mguard>, in this example through Network Address Translation (NAT) / IP Masquerading Network Address Translation (NAT) must be activated to gain access to the Internet. Select Network >> NAT, tab Masquerading. Network >> NAT, tab Masquerading Network Address Translation Outgoing on Interface From IP Select External. Enter the network and the appropriate subnet mask in CIDR-notation (e.g = 16, = 24, = 32). A value of /0 means that all internal IP addresses will have access to the Internet (assuming an outgoing firewall rule allows the access). If only a special subnet should have access to the Internet, enter this subnet and the appropriate subnet mask (e.g /24). If only one client should have access to the Internet, enter its IP address and the value 32 as subnet mask (e.g /32). 1:1 NAT Not required for this setup. Document ID: UG Page 14 of 106

15 6.3 DNS Server Select Network >> DNS, tab DNS Server. Network >> DNS, tab DNS server DNS Local Resolving of Hostnames Servers to query User defined name servers Not required for this setup. Select Provider defined. In PPPoE mode the mguard receives the IP address of a DNS server from the Internet Service Provider. Not required for this setup. 6.4 DynDNS Registration If the mguard has a dynamic public IP address, it could be necessary that the mguard registers its current public IP address with a fixed name at a DynDNS service. This could be required: To gain remote HTTPS/SSH access to the mguard. If a VPN connection should be established to the mguard. If Pre-Shared Key (PSK) should be used for authentication in the VPN configuration. In the following screenshot, the mguard registers its public IP address under the name mguard at the DynDNS service dyndns.org. Select Network >> DNS, tab DynDNS. 6.5 Required IP Settings on the Clients If the clients use static IP settings, the internal IP of the mguard must be specified as default gateway, in this example Otherwise the DHCP server must provide this value. Document ID: UG Page 15 of 106

16 7 mguard operating in 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 in the Internal Network The clients in the internal network may either use static IP settings or receive them from the DHCP server of the mguard. The clients must use the internal IP address of the mguard as default gateway (in this example ) to gain access to the external network. Document ID: UG Page 16 of 106

17 7.2 Configuration of the mguard Configuring the Interfaces Select Network >> Interfaces, tab General. Network >> Interfaces, tab General Network Mode External Networks Internal Networks Secondary External Interface Network Mode Router Mode Select Router. If the mguard receives its external IP settings from a DHCP server, select DHCP. Otherwise select static. This section is only displayed when using static external IP settings (Router Mode = static). External IPs Additional External Routes IP of default gateway Internal IPs Additional Internal Routes Not required for this setup. Enter the external IP address of the mguard and the Netmask, in this example / 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 and the Netmask, in this example / This IP address should be specified as default gateway on every client in the internal network. Will be explained in the next chapter. Document ID: UG Page 17 of 106

18 Additional internal/external Routes If another network is reachable through a router in the internal network of the mguard, the mguard must know to which gateway packets directed to this network need to be forwarded. This is achieved with the option Additional Internal Routes. In this example an additional internal route needs to be defined for the network /24 with the gateway Note: Do never specify an additional internal route with a gateway located in the external network or vice versa. This could cause routing problems on the mguard Network Address Translation (NAT) / IP Masquerading Activate NAT if required. NAT needs to be activated for example if the route to the internal network of the mguard is unknown to the external network. Select Network >> NAT, tab Masquerading. Network >> NAT, tab Masquerading Network Address Translation Outgoing on Interface From IP 1:1 NAT Not required for this setup. Select External. Enter the network and the appropriate subnet mask in CIDRnotation (e.g = 16, = 24, = 32). A value of /0 means that all internal IP addresses will be masqueraded when sending data to the external network. If only a special subnet should be masqueraded, enter this subnet and the appropriate subnet mask (e.g /24). If only the IP address of one client should be masqueraded, enter its IP address and the value 32 as subnet mask (e.g /32). Document ID: UG Page 18 of 106

19 7.2.3 DHCP Configuration The internal DHCP service (menu Network >> DHCP, tab Internal DHCP) needs to be configured if the clients in the internal network should receive their IP settings from the mguard. Network >> DHCP, tab Internal DHCP Mode DHCP mode Select Server. DHCP Server Options Enable dynamic IP address pool Enable this option if the clients should receive their IP address from the IP address pool DHCP range start to DHCP range end. Disable this option if the assignment should be done statically only, based on the MAC address (refer to Static Mapping). DHCP lease time DHCP range start / DHCP range end Local netmask Broadcast address Default gateway DNS server WINS server Static Mapping Validity of the assigned IP settings in seconds. Start and end of the IP address range from which IP addresses are assigned to the clients dynamically. Subnet mask to be used by the clients. Broadcast address of the network. 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 to resolve 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 to resolve 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. Note: The mguard may act as DHCP server for the external network. In this case configure the tab External DHCP accordingly. If the DHCP server for the internal network is located in the external network of the mguard, use the option DHCP Relay in the tab Internal DHCP and specify the IP address of the DHCP server. If the DHCP server for the external network is located in the internal network of the mguard, use the option DHCP Relay in the tab External DHCP and specify the IP address of the DHCP server. Document ID: UG Page 19 of 106

20 7.2.4 DNS Sever A DNS server needs to be specified if: The mguard itself needs to resolve hostnames, as it is the case for: o Applying online updates. o Requesting licenses from the device online. o Online license reload. o Resolving DynDNS names to establish VPN connections. o Resolving a DNS name of an NTP server for time synchronization. The clients in the internal network have the internal IP address of the mguard specified as DNS server. Select Network >> DNS, tab DNS Server. Network >> DNS, tab DNS server DNS Local Resolving of Hostnames Servers to query User defined name server Not required for this setup. Select User defined. Enter the IP address of the DNS server of the external network. Document ID: UG Page 20 of 106

21 7.3 Configuration to access the Clients in the internal Network from the external Network The mguard acts as router between the external network /16 and the internal network /24. The external IP of the mguard is /16, the internal IP /24. The mguard should be configured to allow access to the web interface (HTTP protocol) of the machine from the external network. Apart of this it should also be possible to ping this machine. There exist three different possibilities to configure the mguard to achieve this: 1) Additional internal routes on the gateway 2) Port forwarding 3) 1:1 NAT Before starting with the configuration ensure that the target machine uses the internal IP address of the mguard ( ) as default gateway Configuring the incoming Firewall According incoming firewall rules must be specified on the mguard (menu Network Security >> Packet Filter, tab Incoming Rules) when using the possibilities 1:1 NAT or additional internal routes on the gateway to allow the incoming traffic. This is not required when using port forwarding because the mguard will forward data packets directly to the destination IP without sending them through the firewall. The following firewall rules (menu Network Security >> Packet Filter, tab Incoming Rules) allow incoming TCP packets directed to the http port and incoming ICMP packets. All other packets will be dropped by the firewall. The fields From IP and To IP can be used to restrict the access for special networks/machines only. Document ID: UG Page 21 of 106

22 7.3.2 Possibility 1: Additional internal Routes on the Gateway The target machine ( ) does not belong to the network in which the sending entity is located ( /16). Therefore the sending entity will send packets directed to the to its default gateway ( ). The gateway must know where to forward those packets. Therefore a route must be configured on the gateway ( ), specifying the external IP of the mguard ( ) as gateway and the target network ( /24). For testing purposes this route can be added locally on the machine ( ). If this is a Windows system, open a command prompt and enter the command router add mask Now the computer will send packets directed to the network /24 directly to the mguard. Now it is possible to access the target directly through its IP address: ping Advantages: The machine can be accessed directly by its IP address. Disadvantages: Additional routes must be specified on the gateway. This is not applicable if several mguards are connected to the external network, some or all of them using the same internal network ( /24). Document ID: UG Page 22 of 106

23 7.3.3 Possibility 2: Port Forwarding When using port forwarding (menu Network >> NAT, tab Port Forwarding), the mguard will forward received data packets directly to the specified IP address and port. Note: Port forwarding can only be used for port based protocols (UDP/TCP). ICMP is not a port based protocol. Therefore it is not possible to ping the target machine from the external network. Network >> NAT, tab Port Forwarding Port Forwarding Protocol From IP From Port Incoming on IP Incoming on Port Redirect to IP Redirect to Port Comment Log Select the corresponding protocol, either TCP or UDP /0 means from all IP addresses. The rule may be restricted to the sender s network ( /16) or IP address ( /32). The rule may be restricted to the sender s port. This is not applicable for http access because web browser uses a varying port greater or equal %extern will automatically take the current external IP address of the mguard. Alternatively the external IP address of the mguard may be entered. Enter the original destination port number or the corresponding service name (e.g. http for TCP port 80). Specify the IP address where to the data packets should be forwarded. Specify the port number or service name where to the data packets should be forwarded. Usually this value corresponds to the value of Incoming on Port but there exists also the possibility to redirect the packets to another port. This feature must be used if the web interface of several machines located in the internal network should be assessable from the external network: Incoming on Port Redirect to IP Redirect to Port http http http http Enter a comment if desired. Enable logging if desired. Now it is possible to access the target through but a ping will not work. Advantages: Easy to configure for a small number of targets. Document ID: UG Page 23 of 106

24 Disadvantages: Only port based protocols (UDP/TCP) can be forwarded. The target machine is accessible through the external IP of the mguard. If the same port of several machines in the internal network must be accessible, a kind of mapping table must be maintained to know which port must be used to access a specific machine (e.g. for , for ). This may get confusing, especially if several mguards connect different machine networks to the external network and web access is required to all machines Possibility 3: 1:1 NAT 1:1 NAT (menu Network >> NAT, tab Masquerading) maps IP addresses of the internal network to IP addresses of the external network. Depending on the specified subnet mask in the 1:1 NAT configuration, also subnets of the internal network or the complete network can be mapped to the external site. When using 1:1 NAT, no changes need to be applied to the external network. The ARP demon of the mguard will reply to ARP requests of the external network for the mapped IP addresses. The mapped IP addresses must not be used by any other entity of the external network. When performing 1:1 NAT, the network part of the IP address is mapped and the host part is kept unchanged. The network part of the IP address is defined by the specified subnet mask. Examples of 1:1 NAT rules and the resulting IP mapping: Local External Netmask Mapped IP addresses internal <-> external <-> <-> <-> <-> <-> <-> <-> <-> <-> Note: It is not possible to use the same subnet mask as it is used by the external network to map the internal network to the external site. In this case the mguard would reply to all ARP requests of the external network which will make this network inoperable. In this example, the IP address of the target ( ) should be mapped to the external IP address which is not used by any other entity. The 1:1 NAT configuration for this setup looks as follows: Now it is possible to access the target through its mapped IP address: ping Document ID: UG Page 24 of 106

25 Advantages: No changes need to be applied to the external network. Each target is accessible through an IP address of the external network. The target can be accessed using protocols and ports according to the specified incoming firewall rules. Connecting several mguards to the external network, some or all of them having the same internal network (e.g /24), is not a problem anymore. If for example the external network has a subnet mask of 16 and the systems in this network only use IP addresses from the range , the networks /24, /24, /24, etc. can be used to map the internal networks to IP addresses of the external network. Disadvantages: A reasonable amount of unused IP addresses of the external network is required to perform the mapping. Refer to chapter 1:1 NAT to get further information about 1:1 NAT. Document ID: UG Page 25 of 106

26 7.4 Configuration to access the Clients in the external Network from the internal Network The mguard acts as router between the internal network /24 and the external network /16. The internal IP address of the mguard ( ) must be specified as default gateway on the clients in the internal network. Otherwise accessing the external network will not be possible. Let us take a look at what happens if a client in the internal network ( ) wants to access a target located in the external network ( ). When data packets are sent from the client ( ) to a target located in the external network ( ), the client will send the packets to its default gateway ( ) because the IP address of the target is located in a different network. The mguard takes care of forwarding the packets to the destination. When the packets arrive at the target ( ), the sender s IP address ( ) belongs to a different network. Therefore the target will send its response to its default gateway ( ) and there the transfer stops because the gateway does not know where to send packets directed to the network /24. There exist the following three possibilities to get the response of the target back to the sender: 1) Additional internal routes on the gateway 2) NAT 3) 1:1 NAT (refer to the previous chapter) Possibility 1: Additional internal Routes on the Gateway Add an additional route on the gateway of the external network ( ), specifying as network /24 and as gateway the external IP address of the mguard ( ). This way the gateway knows where to send packets directed to the network /24. This required change on the gateway could sometimes not be applicable. The most common way is to activate Network Address Translation (NAT) on the mguard, described in the next chapter Possibility 2: Network Address Translation (NAT) / IP Masquerading When activating NAT on the mguard, the mguard will masquerade the senders IP address by its own external IP address. In other words, the mguard will replace in the data packets the sender s IP address ( ) by its own external IP address ( ). When the packets arrive at the target, the sender s IP address ( ) is located in the same network and the target will send the response directly back to the mguard. The mguard will undo the NAT changes and forward the response back to the original sender. Especially if the external network is the Internet, NAT must be activated. Otherwise accessing any site will not be possible. Document ID: UG Page 26 of 106

27 Select Network >> NAT, tab Masquerading. Network >> NAT, tab Masquerading Network Address Translation Outgoing on Interface From IP 1:1 NAT Not required for this setup. Select External. Enter the network and the appropriate subnet mask in CIDRnotation (e.g = 16, = 24, = 32). A value of /0 means that all internal IP addresses will be masqueraded when sending data to the external network. If only a special subnet should be masqueraded, enter this subnet and the appropriate subnet mask (e.g /24). If only one client should be masqueraded, enter its IP address and the value 32 as subnet mask (e.g /32) Possibility 3: 1:1 NAT Refer to chapter Possibility 3: 1:1 NAT. Document ID: UG Page 27 of 106

28 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. The mguard s firewall is a stateful packet inspection firewall. If the outgoing firewall allows TCP packets directed to port 80, the response from the target will also pass the incoming firewall even if the incoming firewall is configured to block all packets. Configuring the incoming firewall is not required to allow the responses to come through. 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. Network Security >> Packet Filter, tab Outgoing Rules Outgoing Protocol From IP From Port To IP To Port Action Comment Log Select the protocol to which the rule should be applied (TCP, UDP, ICMP or All). The sender s IP address /0 means all IP addresses. The rule may be restricted to a subnet (e.g /24) or to an IP address (e.g /32). If no subnet mask was specified, the mguard treats the entered value as IP address. Only applicable if Protocol=TCP or UDP. The port from which the packets are sent. Either the port number or the corresponding service name (e.g. http for TCP port 80) can be entered. Entering a port range (e.g. <start port>:<end port>) is also supported. If the port varies from which the packets are sent, as it is the case when accessing the Internet from a web browser, enter any. The target IP address (refer to From IP). Only applicable if Protocol=TCP or UDP. The destination port to which the packets are sent (refer to From Port). Action applied to a packet which matches the rule. This could be Accept, Drop, Reject or the name of a Set Of Rules (refer to Sets of Rules). Enter a comment if required. Enables the logging for the rule. Document ID: UG Page 28 of 106

29 8.1.1 Example of a wrongly configured Firewall In this example, only access to HTTP servers should not be granted from the internal network. The rules above contain a couple of errors: Rule 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 for every packet. 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. Rule 2: HTTP requests issued by a web browser use a varying sending port greater or equal 1024 and send their requests to port number 80. This rule will never match due to From Port=80. In this case From Port=any and To Port=80 must be specified. The correct configuration would be: Document ID: UG Page 29 of 106

30 8.2 Sets of Rules Sets of rules, which summarize firewall rules, are configured through the menu Network Security >> Packet Filter, tab Sets of Rules. A Set of Rules can be specified as Action when configuring the incoming and/or outgoing firewall. Let us take a look at the following example: The incoming firewall should allow ftp, telnet and https access only to the servers , and Without using Set of Rules nine incoming firewall rules (one per service and target machine) need to be configured. Using a Set of Rules, which summarizes either the allowed protocols or the IP addresses of the target machines, will result in three firewall rules. Example 1: Set of Rules summarizing the IP addresses of the target machines The set is called Servers and allows the access to the target machines only (column To IP). The incoming firewall rules define the access for the specified services (column To Port) and refer to the Set of Rules with the name Servers (Action = Servers) which grants the access to the target machines. Document ID: UG Page 30 of 106

31 Example 2: Set of Rules summarizing the allowed services The set is called Services and allows the access for the specified services (column To Port). The incoming firewall rules define the access to the target machines (column To IP) and refer to the Set of Rules with the name Services (Action = Services) which grants the access for the specified services. Document ID: UG Page 31 of 106

32 8.3 MAC Filtering Note: MAC filtering is only supported for the Stealth mode. MAC filtering is configured through the menu Network Security >> Packet Filter, tab MAC Filtering Basic Rules to set 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, a final rule for IPv4 needs to be specified which rejects everything else. If not using statically configured ARP tables on 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. Document ID: UG Page 32 of 106

33 8.3.2 Examples MAC Filter Configuration Restricted IPv4 Access In the following example the access through the IPv4 protocol should be allowed only for 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. 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 a second incoming and outgoing rule must be specified, which drops IPv4 packets from all other MAC addresses. 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 Allowing access for other Protocols than IPv4 (e.g. 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 to allow 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: UG Page 33 of 106

34 8.4 1:1 NAT Note: 1:1 NAT is not supported for the Stealth mode. 1:1 NAT (menu Network >> NAT, tab Masquerading) is used to connect several internal networks with the same network IPs (e.g /24) to the external network. 1:1 NAT maps IP addresses of the internal network to IP addresses of the external network. Systems in the internal network can be reached directly through their mapped IP addresses from the external network. Depending on the specified subnet mask in the 1:1 NAT configuration, also subnets of the internal network or the complete network itself can be mapped to the external site. The ARP demon on the mguard will respond to ARP requests for the mapped IP addresses issued by the external network. Therefore no IP changes must be applied to the external network. The mapped IP addresses must not be used by any other entity in the external network. When performing 1:1 NAT, the network part of the IP address is mapped and the host part is kept unchanged. The network part of the IP address is given by the specified subnet mask. Examples of 1:1 NAT rules and the resulting IP mapping: Local External Netmask Mapped IP addresses internal <-> external <-> <-> <-> <-> <-> <-> <-> <-> <-> Note: The same subnet mask as it is used by the external network can not be used to map the internal network to the external site. In this case the mguard would reply to all ARP requests of the external network which will make this network inoperable. The specified subnet mask must be less than the one used by the external network and the mapped IP addresses must not be used by any other entity in the external network. Apart of the 1:1 NAT configuration the incoming/outgoing firewall (menu Network Security >> Packet Filter, tabs Incoming Rules and Outgoing Rules) must be configured according to the allowed traffic. Document ID: UG Page 34 of 106

35 :1 Mapping of IP addresses In the following example it is only required to access one machine of each production site. In this case a direct 1:1 mapping of IP addresses can be used. Due to this configuration, of Production Site 1 is accessible from the external network through , of Production Site 2 through The mapped IP addresses and must not be used by any other entity in the external network. 1:1 NAT on mguard 1 needs to be configured as follows: The client can be accessed from the external network through :1 NAT on mguard 2 needs to be configured as follows: The client can be accessed from the external network through Document ID: UG Page 35 of 106

36 :1 Mapping of Networks In this example, two production sites with the same network /24 shall be connected to the external network /16. Both mguards have external IP addresses which belong to the external network ( and ). It is not a typo that the corporate network has a subnet mask of 16 and that a subnet mask of 24 is specified in the 1:1 NAT rule. Due to the flat subnet mask of the external network it is possible to use the virtual network /24 to access the systems of Production Site 1 and /24 to access the systems of Production Site 2, assuming that no client in the external network uses an IP address from these networks. The ARP daemon on the mguard ensures that routers in the external network know where to send packets addressed to the networks /24 and /24. The client of Production Site 1 can be accessed from the external network through the IP address , client with the IP address , etc. The client of Production Site 2 can be accessed from the external network through the IP address , client with the IP address , etc. Clients of Production Site 2 may also be reached from Production Site 1 through their mapped IP addresses ( /24) and vice versa. 1:1 NAT on mguard 1 needs to be defined as follows: 1:1 NAT on mguard 2 with the following settings: Local network = , External network = , Netmask = 24. Document ID: UG Page 36 of 106

37 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 to activate 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 a User Firewall should be configured to allow HTTP and FTP access for the users user1, user2, user3 and user Configuring Remote Users Select Authentication >> Firewall Users, tab Firewall Users. Authentication >> Firewall Users, tab Firewall Users Users Enable user firewall Enable group authentication Username Authentication Method User Password Enable this option to activate 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: The name of the group must be entered as Template User when configuring the User Firewall. 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). Selecting RADIUS requires configuring 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: UG Page 37 of 106

38 8.5.2 RADIUS Servers Configure this tab if the remote user should be authenticated by a RADIUS server. Select the RADIUS Servers tab. Authentication >> Firewall Users, tab RADIUS Servers RADIUS Servers RADIUS timeout RADIUS retries Sever 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 to access the RADIUS server. RADIUS server access password Access Select the Access tab. Specify the interface(s) through which HTTPS authentication of the users should be allowed. Document ID: UG Page 38 of 106

39 8.5.4 Configuring the User Firewall Select Network Security >> User Firewall. Click New, enter a descriptive name for the firewall template and click Edit General Settings Network Security >> User Firewall, tab General Options Enabled Comment Timeout Timeout type Select Yes to enable the firewall template. Enter an explanatory text which describes the template, if desired. 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 not establish new connections but he still can use already existing connections as long as they exist in the connection tracking table 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 Authentication >> Firewall Users. Enter the name of the group when using Group Authentication. Document ID: UG Page 39 of 106

40 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. Network Security >> User Firewall, tab Firewall rules Firewall rules Source IP 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 to enable the user firewall for a technician who works on a different machine. Protocol From Port To IP To Port Comment Log 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 to restrict the access to a special subnet (e.g /24) or to a single machine (e.g /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, if desired. Select if data packets which match the rule shall be logged Activating the User Firewall The remote user needs to log onto the mguard through HTTPS to activate 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: UG Page 40 of 106

41 9 Firewall Redundancy Note: This feature is not available with mguard version 7.0. Customers using this feature should not update to this version. It will be available again with a later version 7 release. Please consult the release notes of newer releases to get the information if this feature is supported again. This feature provides a redundant firewall between the internal and external network for the case of a device or link failure. It does neither provide VPN Redundancy, nor Path Redundancy to route data through different external paths depending on which mguard acts currently as master. Two mguards of a redundant firewall setup will share a virtual external IP address. Establishing a VPN connection to this virtual IP is not supported. This feature is not available by default. It must be licensed separately. When using Firewall Redundancy, two parallel operating mguards are configured that way that one mguard can take over the firewall functionality just in case of a device or link failure of the other mguard. 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 mguards can be operated either in Router or Multi-Stealth mode. In the following examples mguard version was used on both devices. 9.1 Router Mode In router mode two mguards operate as one virtual router. A virtual IP and MAC address is shared among the mguards, with one designated as the master router and the other as backup. The master sends Virtual Router Redundancy Protocol (VRRP) messages every second to the backup through the internal and external network. The master will switch into Fault status and will stop sending VRRP messages if a link failure is detected, either at the internal or at the external interface. The backup becomes the master if no VRRP messages are received anymore from the master, either through the internal or through the external network. In this case the virtual IP and MAC address is mapped to the backup mguard. The fail over will take at most three seconds. Two mguards shall be configured to work as a redundant firewall in router mode. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Document ID: UG Page 41 of 106

42 Both mguards were configured in Router mode with static internal and external IP settings /24 was used as virtual internal IP address, /16 as virtual external IP. Devices in the internal network must use the internal virtual IP as default gateway, in this example The Firewall Redundancy is configured through the menu Redundancy >> Firewall Redundancy. The following screenshot displays the redundancy configuration of both mguards. Redundancy >> Firewall Redundancy tab Redundancy General Router Mode Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase External Virtual Router ID External IP of the 2 nd device Internal Virtual Router ID Internal IP of the 2 nd device External virtual IP Internal virtual IP Displays which mguard currently acts as Master and which one as Backup. Must be enabled on both mguards. This should be done as last step after configuring redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when activating redundancy. 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. Protects against faulty configuration 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 should not be identical with other security relevant passwords. Identifies the virtual router and must be the same value on both mguards. If there are several virtual router configurations in the network, 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. Identifies the virtual router on the internal interface and must be the same value on both mguards. Enter the internal IP of the other mguard, on mguard 1 the internal IP of mguard 2 and vice versa. Specifies the virtual external IP of the virtual router configuration. This entry must be the same on both devices. Specifies the virtual internal IP of the virtual router configuration. This entry must be the same on both devices. Devices of the internal network should use this IP address as default gateway. Document ID: UG Page 42 of 106

43 9.2 Multi-Stealth Mode Two mguards shall be configured to work as a redundant firewall in Multi-Stealth mode. 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 this example mguard 1 uses the Management IP and mguard The same firewall rules must be defined on both devices. Redundancy is configured through the menu Redundancy >> Firewall Redundancy. The following screenshot shows the redundancy configuration of both mguards. Document ID: UG Page 43 of 106

44 Redundancy >> Firewall Redundancy tab Redundancy General Router Mode Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase Virtual Router ID Management IP of the 2 nd device Not required for this setup (ignored in Stealth mode). Displays which mguard currently acts as Master and which one as Backup. Must be enabled on both mguards. This should be done as last step after configuring redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when activating redundancy. 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. 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. Identifies the virtual router and must be the same on both mguards. If there are several virtual router configurations in the network, 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 Management IP of the other mguard, on mguard 1 the Management IP of mguard 2 and vice versa. Document ID: UG Page 44 of 106

45 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 master detects a link failure, it switches into Fault state and the backup becomes the master due to the outstanding VRRP message. 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. To avoid this situation for this kind of topology ICMP Checks should be configured (menu Redundancy >> Firewall Redundancy, tab ICMP Checks). Adequate hosts must be chosen when configuring the ICMP checks. In this example, mguard 1 and mguard 2 must verify with the checks the availability of the connection until Switch 3. Consequently and are adequate hosts for this scenario. Both mguards should be configured to use the same hosts for the ICMP checks. When enabling ICMP Checks, the mguards check automatically if they can reach each other. The master will switch into Fault state, if none of the specified hosts reply to the ICMP echo request. All checks must fail to avoid the situation that there is no connection failure but for example the NIC of one specified host is defective. The Fault state is cancelled when at least one of the specified hosts replies. Document ID: UG Page 45 of 106

46 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 to limit 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/High). 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 in 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 to access the control of the machine. The application requires a bandwidth of 64kbit/s to allow a comfortable access. In parallel, the technician talks with the user in front 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 VPN interface (VPN via External). This will not have any impact on the communication of the machine within the production site because in this example the bandwidth management is restricted to the VPN interface only. Document ID: UG Page 46 of 106

47 First, Egress Queues for VoIP data and for the desktop sharing application need to be defined. 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 this 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 to restrict 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 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 to assign 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 = /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 The selection criteria was configured with the parameters Protocol = TCP, From IP = /32 and From Port = This rule was assigned to the desktop sharing application queue (Queue Name = SC RDA). In case of network congestion, packets directed to the VPN interface with the source IP 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 VPN interface will be processed by the queue SC RDA with medium priority. All other packets directed to the VPN interface will be processed by the Default queue with low priority. Document ID: UG Page 47 of 106

48 11 CIFS Integrity Monitoring Note: This feature needs to be licenses separately. CIFS stands for Common Internet File System which is better known as Windows File Sharing. The most vulnerable part of Windows based automation components are the file shares. CIFS Integrity Monitoring monitors those shares against malware infections and provides the following two options to check them for malware infections: 1) CIFS Integrity Checking This option allows to monitor file shares of protected systems for unexpected modifications of executable code (e.g. *.exe, *.dll). It works without any malware signatures or virus pattern updates. The results of the integrity check are stored in a database (checksum files) which contains the hash value of each checked file. This database is used as reference for subsequent integrity checks. The database is signed by a specified certificate (needs to be imported as machine certificate) to protect it against unauthorized modifications. If configured, the mguard issues a notification via and/or SNMP trap after every check or in case of a failure or modified files. 2) CIFS Antivirus Scan Connector This option allows external antivirus scanners to access file shares of protected systems and works with any external scanner. The mguard mirrors the specified shares to the external network so that they can be mounted on a machine on which the antivirus scanner is running. In the following example the mguard acts as router between the external network /16 and the internal network /24. The internal network contains two machines, MACHINE_1 ( ) with the file shares Shares_1 and Shares_2 and MACHINE_2 ( ) with the file share Shares_3. For those shares CIFS Integrity Checking should be configured and they should be mirrored to the external network to mount them on the server running the anti virus scanner. Document ID: UG Page 48 of 106

49 11.1 Importable Shares At first specify the importable shares of the machines through the menu CIFS Integrity Monitoring >> Importable Shares. This needs to be done when using the option CIFS Integrity Monitoring and CIFS Antivirus Scan Connector as well. CIFS Integrity Monitoring >> Importable Shares Importable CIFS Shares Name Server Share Enter a descriptive name for the share. Enter the IP address of the machine. Enter the directory name of the file share. <Edit> Click <Edit>. Enter the account parameters to access the shares on the machine. This account must have administrator rights on the machine. Click <Save>. Document ID: UG Page 49 of 106

50 11.2 CIFS Integrity Checking Integrity Database Certificate The results of the integrity check are stored in a database which contains the hash value of each checked file. This database is used as reference for subsequent integrity checks and it is signed by a specified certificate to protect it against unauthorized modifications. To upload the certificate (PKCS#12 format): Select Authentication >> Certificates, tab Machine Certificates. Click <Browse> and open the certificate file. 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> Filename Patterns A filename pattern allows grouping the files together which should be included in the integrity check or to specify filenames or file types which should be excluded from the check. Select CIFS Integrity Monitoring >> CIFS Integrity Checking, tab Filename Patterns. CIFS Integrity Monitoring >> CIFS Integrity Checking, Set of Filename Patterns Rules for files to check Filename Pattern Include in check Specify the filename or file type which should be included or excluded. Only one wildcard is allowed per filename or directory. ** means the root directory and all subdirectories. Examples: **\*.exe: Scans all files with the extension exe in the root directory of the share and all subdirectories. Name\**\*.exe: Scans all files with the extension exe of the subdirectory Name and all its subdirectories. Win*\*.exe: Scans all files with the extension exe of all subdirectories which start with Win. Select either Include or Exclude, depending on whether the specified filename of file type should be checked or not. Document ID: UG Page 50 of 106

51 File Pattern to check the complete C drive: If the integrity check should run through the complete C drive, the following adjustments are required. The settings were verified on Windows XP Professional (Service Pack 3) and may be different for other Windows versions. At first disable Simple File Sharing which is enabled by default on Windows XP. To do this: Start the Windows Explorer. Select Tools >> Folder Options from the menu. Select the View tab. Scroll to the bottom of the list of advanced settings and uncheck Use Simple File Sharing (Recommended). Click <OK>. When specifying the file pattern, exclude the following directories from the integrity check because Windows creates files in those directories which can not be opened even with administrator rights: Documents and Settings\**\* RECYCLER\**\* System Volume Information\**\* pagefile.sys pagefile.sys\**\* The resulting file pattern looks as follows: If the integrity database is stored on the share on which an integrity check will be performed and if the check includes files with the extension *.dat and/or *.txt, exclude the integrity database (in this example integrity-check*.dat and integrity-check*.txt) from being checked. Otherwise the mguard will detect a change of the integrity after every run. Document ID: UG Page 51 of 106

52 Integrity Check Settings Select CIFS Integrity Monitoring >> CIFS Integrity Checking, tab Settings. CIFS Integrity Monitoring >> CIFS Integrity Checking, tab Settings General Checking of Shares Integrity certificate Send notifications via Target address for e- mail notifications Sender address of e- mail notifications Subject prefix for e- mail notifications Address of the server Enabled Checked CIFS Share Checksum memory Select the certificate which protects the integrity database against unauthorized modifications by its name (refer to Integrity Database Certificate). Specify if a notification should be sent after every check or in case of a failure or difference via . Recipients address. Senders address. Subject prefix of the s which will be issued by the mguard to the specified recipient. IP address or hostname of the server. Enable, disable or suspend the check for the specified share. Select the share by its name (refer to Importable Shares). Specify the location where the integrity database should be stored. <Edit> Click <Edit>. Select the Patterns for filenames which should be used for the integrity check and specify the Time schedule. Specify the Checksum Algorithm which should be used for the integrity check of the files. Modify the Basename of the checksum files (integrity database) if required. Click <Apply>. Document ID: UG Page 52 of 106

53 Initialize the Integrity Database After configuring CIFS Integrity Monitoring, the integrity database can be initialized as follows: Select CIFS Integrity Monitoring >> CIFS Integrity Status. Click <Show>. Select the Actions tab. Click <Initialize>. The results of the integrity check are stored in the integrity database which consists of the following files. The files are stored in the specified Checksum Memory, using the specified Basename of the checksum files as filename prefix (refer to the previous chapter). Filename <Basename>-idx.dat <Basename>-log.txt <Basename>-lsi.dat <Basename>-tbl.dat <Basename>-sig.dat Purpose Currently not used. Log entries of the last integrity check. Hash value of the log file, signed by the integrity certificate. File containing the list of checked filenames and their hash value. Hash value of the hash table file, signed by the integrity certificate. Document ID: UG Page 53 of 106

54 11.3 CIFS Antivirus (AV) Scan Connector Select CIFS Integrity Monitoring >> CIFS AV Scan Connector. CIFS Integrity Monitoring >> CIFS AV Scan Connector CIFS Server Allowed Networks Consolidated imported shares Enable the server Server's workgroup Login/Password Exported share's name Enable this option to activate the CIFS server on the mguard. Specify the workgroup of the CIFS server if required. Specify an arbitrary account (login/password) to access the CIFS server. This account must be specified on the server on which the antivirus scan engine is running for accessing the CIFS server. Define a name for the summarized exported shares. This name must be specified when mounting the CIFS server as drive on the server on which the antivirus scan engine is running, e.g. \\ \production-cell-1. The single shares of the machines will be displayed as subdirectories of this drive, using as directory name the name of the field Exported in Subdirectory. Specify a rule (From IP, Interface, Action) to allow the server to access the CIFS server of the mguard. Exported in Subdirectory CIFS Share Define a name for the exported share of the machine. This name will be displayed as subdirectory name when mounting the CIFS server on the server on which the antivirus scan engine is running (refer to Exported share's name). Select the corresponding share by its name (refer to Importable Shares). Document ID: UG Page 54 of 106

55 Mounting the exported shares on the server: Follow these steps to mount the exported shares on the server on which the antivirus scan engine is running: Start the Windows Explorer on the server. Select Tools >> Map Network Drive from the menu. Select the desired Drive letter. Enter as Folder the external IP address of the mguard with the Exported share s name specified in the menu CIFS AV Scan Connector, in this example: \\ \ production-cell-1. Click Connect using a different user name. Enter the User name and Password specified in the menu CIFS AV Scan Connector to access the CIFS server on the mguard, in this example av-scan-server and the corresponding password. Click <OK> to close this dialog. Click <Finish> to close the Map Network Drive dialog. Document ID: UG Page 55 of 106

56 12 Modem Support To connect the mguard to a phone line, either an external modem connected to the serial port of the mguard (if the serial port is accessible) can be used or 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: To get administrative access to the mguard or to access the clients in 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: To get access to the Internet or to establish 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 to establish VPN connections through a phone line temporarily if the access to the Internet fails for some reasons (refer to VPN Fallback through a Phone Line). As permanent secondary external interface Connecting an external Modem to the mguard The following wiring is required to connect the serial port of the mguard to a modem: Signal RJ12 mguard blade mguard industrial RS SUB-D9: Female mguard delta SUB-D9: Male Modem GND RXD RTS TXD CTS 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 Dial-in Configuration A dial-in connection can be used to get administrative access to the mguard or to access the clients in 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 /24 and /16. The dial-in connection is used to gain administrative access to the mguard and to access the clients in the internal network. Document ID: UG Page 56 of 106

57 IP addresses must be assigned to the mguard and to the remote entity for the Point-To-Point connection (in this example and ). Those IP addresses must not belong to an existing network General Modem Settings Select Network >> Interfaces, tab Modem / Console. When using the built-in modem of the mguard industrial RS, select the general modem settings in the section Built-in Modem (analog). When using an external modem, specify the following settings in the section External Modem: Network >> Interfaces, tab Modem / Console 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 the default value (57600) can be used. 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 Document ID: UG Page 57 of 106

58 Configuring the Dial-in Connection on the mguard Select Network >> Interfaces, tab Dial-in. Network >> Interfaces, tab Dial-in External Modem Incoming Rules (PPP) / Outgoing Rules (PPP) 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. Specifying incoming and/or outgoing rules is only required if the clients in the internal network should be reachable through the dial-in connection. No rules need to be specified if only administrative access to the mguard is required Enabling HTTPS Remote Access If the mguard should be administered through the dial-in connection HTTPS remote access (menu Management >> Web Settings, tab Access) needs to be enabled. A rule for the Allowed Networks must not be specified. HTTPS remote access for the dial-in connection is allowed by default if HTTPS remote access is enabled. Document ID: UG Page 58 of 106

59 Required changes on the remote entity To access the internal clients of the mguard through the dial-in connection it could be required to add a route to this network, using the Local IP of the mguard as gateway (in this example: network = /24, gateway = ). At first determine which interface is used for the PPP connection. On Windows, open a command prompt and enter route print: C:\>route print =========================================================================== Interface List 0x1... MS TCP Loopback interface 0x ca Intel(R) PRO/100 VE Network Connection 0xe WAN (PPP/SLIP) Interface =========================================================================== Then use the command route add to add the route to the internal network of the mguard, in this example: route add mask IF 0xe0006 Document ID: UG Page 59 of 106

60 12.3 Dial-out Configuration The purpose to use the dial-out feature depends on the used network mode: Modem / Built-in Modem: To get access to the Internet or to establish 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 to establish VPN connections through a phone line temporarily if the access to the Internet fails for some reasons (refer to VPN Fallback through a Phone Line). o Using the phone line as secondary external interface permanently General Modem Settings Select Network >> Interfaces, tab Modem / Console. When using the built-in modem of the mguard industrial RS, select the general modem settings in the section Built-in Modem (analog). When using an external modem, specify the following settings in the section External Modem: Network >> Interfaces, tab Modem / Console 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 the default value (57600) can be used. 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. Document ID: UG Page 60 of 106

61 Configuring the Dial-out Connection on the mguard The selected network mode and the configuration of the Secondary External Interface (tab General) determine through which interface the dial-out will happen: 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 Select Network >> Interfaces, tab Dial-out. 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 Phone number to be dialled. 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 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 to enter 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 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. Use the predefined value Netmask which belongs to the Local IP and Remote IP. If fixed settings for the IP addresses are used, enter the corresponding netmask. Otherwise use Document ID: UG Page 61 of 106

62 13 IPsec VPN 13.1 Introduction Data packets are commonly sent over the Internet unprotected and therefore do not ensure privacy (encryption), proof of the identity of the sender (authentication) and that data packets were not modified (integrity) or replayed. A Virtual Private Network (VPN) is a communication channel that uses encryption and authentication to protect the packet contents while transmitted over a public medium like the Internet. Today the most commonly implemented VPN protocol is Internet Protocol Security (IPsec). Most VPN devices and clients are IPsec compliant. IPsec is scalable from very small applications to very large networks. IPsec supports a transport connection, which connects two hosts only, and a tunnel connection, which connects two networks. A VPN connection is established in two phases: Phase I (ISAKMP SA) and phase II (IPsec SA). SA stands for Security Association. 1) Phase I (ISAKMP SA): both VPN peers negotiate the encryption and hash algorithm that should be used for this phase, authenticate each other, either using Pre Shared Keys (PSK) or X.509 certificates, and securely negotiate an encryption key to protect the data exchange of phase II. The ISAKMP SA is a security association between both VPN peers and is used for the key exchange. 2) Phase II (IPsec SA): both peers negotiate the encryption and hash algorithm that should be used for this phase and exchange the information about the networks that should be connected. The IPsec SA is a security association connecting the internal networks of the VPN peers and is used for the data exchange. The following questions, discussed in the next chapters, should be answered before starting with the VPN configuration: Are the mguards located behind NAT router? Which authentication method should/can be used (PSK or X.509 certificates)? Document ID: UG Page 62 of 106

63 mguard behind NAT Router 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. Pre Shared Keys (PSK) can not be used because this would require the Aggressive Mode which is currently not supported by the mguard. 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. VPN connections are established through UDP port 500 and, if the connection is NATed, also through UDP port This has consequences for the NAT routers. Apart of this the following needs to be considered: VPN initiating mguard behind NAT Router mguard 1 initiates the VPN connection to mguard 2. A firewall on the NAT Router must allow outgoing UDP packets to the ports 500 and If those ports can t be opened for some reasons, TCP Encapsulation (refer to TCP Encapsulation) can be used to establish the VPN connection VPN responding mguard behind NAT Router mguard 1 initiates the VPN connection to mguard 2. On the NAT Router port forwarding must be configured for the UDP ports 500 and 4500 to the external IP address of mguard 2. TCP Encapsulation can not be used in this scenario because the responding mguard (mguard 2) may not be located behind a NAT router. Note: Due to the required port forwarding on the NAT router for the UDP ports 500 and 4500 neither other VPN connections can terminate at the NAT router itself nor further VPN connections can be established to other mguards 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 must be specified on the NAT router. Document ID: UG Page 63 of 106

64 Both mguards behind NAT Router mguard 1 initiates the VPN connection to mguard 2. A firewall on NAT Router 1 must allow outgoing packets to the UDP ports 500 and On NAT Router 2 port forwarding must be configured for the UDP ports 500 and 4500 to the external IP address of mguard 2. TCP Encapsulation can not be used in this scenario because the responding mguard (mguard 2) may not be located behind a NAT router. Document ID: UG Page 64 of 106

65 Authentication (PSK or Certificates) A Pre Shared Key (PSK) is a sequence of alphanumerical characters, as for example complicated_like_5dy0qod_and_long. When using PSK for authentication, the same PSK must be entered on both sites. Note: Configuring a VPN connection using certificates is considered more secure than using PSK. PSK can not be used if the VPN connection will be established across one or more gateways that have Network Address Translation (NAT) activated. In other words, PSK can only be used if both mguards are connected to the same external network or to the Internet directly. Otherwise this would require the Aggressive Mode which is currently not supported by the mguard. In this case using X.509 certificates is required. When using PSK, the external (or public) IP address of the remote VPN gateway must be entered in the VPN configuration on each site as Address of the remote site s VPN gateway. %any can not be used on the responding site. This would require the Aggressive Mode which is currently not supported by the mguard. If one site has a dynamic public IP address, it must register the current IP address under a fixed name at a DynDNS service and the other site must refer to this name. X.509 Certificates may be obtained either from commercial Certification Authority (e.g. VeriSign) or from a Microsoft CA Server or using freeware tools as for example OpenSSL or XCA. Please refer to the application note How to obtain X.509 Certificates which can be downloaded from our homepage ( >> Downloads >> Application Notes). This document describes in detail how to request certificates from a Microsoft CA Server, how to setup your own CA infrastructure with OpenSSL and how to create certificates with XCA ( easily. A certificate is like a personal ID. It must be unique for each entity. Using the same certificate on different entities is not advisable and will cause problems. When creating a certificate, at first the certificate identifying parameters (Common Name, Organization, Organization Unit, etc.) must be entered which identify to whom the certificate belongs. Those parameters are also called the Subject of the certificate. The subject must be unique for each certificate. Then a key pair is generated: a private key and a corresponding public key. As the names imply, the private key should be protected carefully whereas the public key can be published. A VPN connection can only be established between two entities if the private key on one site matches to the published public key imported on the other site and vice versa. Finally two exports of the certificate are required: 1) PEM Format: this export is the X.509 certificate of the entity, containing the public key but not the private key. This certificate needs to be imported on any remote entity which should establish a VPN connection to the entity to which the certificate belongs. 2) PKCS#12 Format: this export contains the certificate and the private key. This export needs to be imported on the entity itself as machine certificate. Document ID: UG Page 65 of 106

66 The following certificates, exports and imports on the devices are required to establish a VPN connection between two mguards: A certificate (not considering self signed certificates) must be signed by a CA (Certification Authority) certificate to become a valid certificate. Therefore at first a CA certificate must be created. Then create a certificate for each mguard. Both certificates are signed by the CA certificate. A PKCS#12 export of each certificate must be imported as machine certificate on the corresponding mguard (menu Authentication >> Certificates, tab Machine Certificates). A PEM export of each certificate must be imported as connection certificate on the remote mguard (menu IPsec VPN >> Connections, tab Authentication), the PEM export of the mguard 1 certificate on mguard 2 and vice versa. Note: The mguard also supports CA authentication. With this feature the remote entity is authenticated by the CA certificate which was used to sign the remote certificate and not by the remote certificate itself. This feature is mainly used together with the feature VPN Tunnel Groups. CA authentication will be treated in chapter VPN Tunnel Groups (refer to VPN Tunnel Groups). Document ID: UG Page 66 of 106

67 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 at 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 PSK with NAT/NAT-T can not be used because the mguard does not support the 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 an 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 in the same network. Document ID: UG Page 67 of 106

68 13.2 Import of the Machine Certificate This step is only required when using certificates for authentication. The machine certificate (refer to Authentication (PSK or Certificates)) is imported through the menu Authentication >> Certificates, tab Machine Certificates. This should be done before starting configuring the VPN connection. Switch to the menu Authentication >> Certificates, tab Machine Certificates. Click the down arrow to create a new line. Click Browse and select the machine certificate (PKCS#12 export) 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. Modify the Shortname for the certificate if desired. When configuring the VPN connection, the machine certificate is selectable by this name. Click Apply. Document ID: UG Page 68 of 106

69 13.3 VPN Configuration VPN connections are configured through the menu IPsec VPN >> Connections. The configuration of the tabs Authentication, Firewall and IKE Options do not depend on the network topology in which the mguard is located, the network mode of the mguard (e.g. Stealth, Router, PPPoE) or the VPN feature that should be used (e.g. 1:1 NAT for the local network, Hub & Spoke). Those circumstances have only an impact on the tunnel settings in the tab General. Thus a couple of configuration examples for different topologies will be given when explaining the tab General in the next chapter General Settings IPsec VPN >> Connections, tab General Options Transport and Tunnel Settings Descriptive name Enabled Address of the remote VPN gateway Connection startup Encapsulate the VPN traffic in TCP Enter a descriptive name for the connection. Enable the connection. If Pre Shared Keys are used for authentication, enter the IP address or the DNS name of the remote VPN gateway, even if the mguard is waiting for the connection (Connection startup = Wait). Otherwise, when using certificates, enter %any if the mguard waits for the VPN connection. Specify if the mguard initiates the connection, waits for it or if the connection should be established on demand when packets are sent to the remote VPN network. Only required if the VPN traffic should be encapsulated in TCP packets (refer to chapter TCP Encapsulation). The tunnel and transport settings depend on the network mode of the mguard, on the network topology in which the mguard is located and on the VPN feature that should be used. The next chapters contain a couple of configuration examples for different scenarios. Document ID: UG Page 69 of 106

70 VPN Transport Connection between two mguards in Stealth Mode A VPN transport connection is used to connect two hosts in contrast to a VPN tunnel connection which connects two networks. When using a VPN transport connection between two mguards in Router mode, accessing the clients in the internal network through the VPN connection will not be possible. Therefore using a transport connection makes only sense if the mguards are operated in Stealth mode to secure the data transfer between two hosts or to access 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 a VPN transport connection should be established between two mguards in Stealth autodetect mode (refer to mguard operating in Stealth Mode). PSK can be used for authentication because the connection is not NATed. 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 Stealth autodetect mode. Thus they adopt the IP and MAC address of the internal client (mguard 1: , mguard 2: ). The following screenshot displays the configuration of both devices. The Transport and Tunnel Settings are the same on both devices. IPsec VPN >> Connections, tab General Options Transport and Tunnel Settings Refer to General Settings. Select Type=Transport for a transport connection on both mguards. A transport connection connects two hosts and not two networks. Thus the fields to enter the local and remote network are disabled. Document ID: UG Page 70 of 106

71 VPN Tunnel between two mguards in Router/PPPoE Mode In this example a VPN tunnel should be established between two mguards in Router mode (refer to mguard operating in Router Mode). The VPN connection will be initiated by mguard 1 and connects the internal network of mguard 1 ( /24) with the internal network of mguard 2 ( /24). 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 (refer to mguard operating in PPPoE Mode) through the Internet is similar to the scenario described in this chapter. In this case the External Network is the Internet. The mguards will receive their external IP settings from the Internet Service Provider (ISP). If the VPN responding mguard (mguard 2) has a dynamic public IP address, this mguard must register its external IP address under a fixed name at a DynDNS service and the other mguard (initiator, mguard 1) must refer to this name to establish the VPN connection. DynDNS monitoring (menu IPsec VPN >> Global, tab DynDNS Monitoring) must be enabled on the VPN initiating mguard (mguard 1). Otherwise the mguard will not notice if the IP address of the remote entity has changed and establishing the VPN connection will fails. Note: A VPN tunnel can only be established between different networks. If two sites have the same internal network, the feature VPN 1:1 NAT for the local network (refer to VPN 1:1 NAT for the local Network) must to be used. PSK can be used for authentication if both mguard are connected with their external interface to the same network, which could also be the Internet. Otherwise use certificates. The interfaces of the mguards were configured through the menu Network >> Interfaces. Both mguards were configured to operate in Router mode with the following static IP settings: Parameter mguard 1 mguard 2 External IP address Subnet mask Default gateway Internal IP address Subnet mask The clients in the internal networks should use the internal IP of the corresponding mguard as default gateway to be able to reach other networks. Document ID: UG Page 71 of 106

72 For this scenario, the configuration of the tab General and the tunnel settings look as follows when using certificates for authentication: mguard 1 (Initiator): mguard 2 (Responder): Section Parameter mguard 1 mguard 2 Options Transport and Tunnel Settings Refer to General Settings. Type Local Remote On both mguards, select Type=Tunnel for a tunnel connection. Enter the internal network of the mguard, in this example /24. Enter the internal network of the remote mguard, in this example /24. Enter the internal network of the mguard, in this example /24. Enter the internal network of the remote mguard, in this example /24. Document ID: UG Page 72 of 106

73 VPN Tunnel between two mguards, Single Stealth and Router/PPPoE Mode In this example a VPN tunnel from an mguard in Single Stealth (autodetect or static, refer to mguard operating in Stealth Mode) mode to an mguard in PPPoE (refer to mguard operating in PPPoE Mode) or Router mode (refer to mguard operating in Router Mode) should be established. If the responding mguard is operated in PPPoE mode and receives a dynamic public IP address from the ISP, this mguard must register its current IP address under a fixed name at a DynDNS service and the Stealth mguard must refer to this name to establish the VPN connection. Apart of this DynDNS Monitoring (menu IPsec VPN >> Global, tab DynDNS Monitoring) must be enabled on the Stealth mguard. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Certificates must be used for authentication because the connection will be established across a NAT router. Using PSK is not possible. The tunnel will be initiated by the Stealth mguard (mguard 1). This mguard adopts the IP and MAC address of the client ( , autodetect Stealth mode) or has them defined as static entries (static Stealth mode). mguard 2 is operated in Router mode with the static public IP and the internal IP /24. The clients in the internal networks must use this IP address as default gateway to be able to access other networks. Regarding the Stealth mguard two cases need to be distinguished: Case 1) If the client has a static IP address, this IP address is used to set up the VPN tunnel (Local = /32, Virtual IP = , Remote = /24). Case 2) If the client receives its IP settings from a DHCP server with a slight chance that the IP address could change, a virtual IP address is used to set up the VPN tunnel (Local = /32, Virtual IP = , Remote = /24). The virtual IP is used to access the client ( ) from Network B. The mguard will perform a 1:1 NAT from the virtual IP to the real IP address of the client automatically. Document ID: UG Page 73 of 106

74 For this scenario, the configuration of the tab General and the tunnel settings look as follows: mguard 1 (Initiator, Single Stealth): mguard 2 (Responder, Router/PPPoE Mode): Document ID: UG Page 74 of 106

75 Section Parameter mguard 1 (Single Stealth) mguard 2 (Router/PPPoE) Options Transport and Tunnel Settings Refer to General Settings. Type Local On both mguards, select Type=Tunnel for a tunnel connection. Case 1: Enter the real IP of the client with a subnet mask of 32, in this example /32. Case 2: Enter the virtual IP of the client with a subnet mask of 32, in this example /32. Enter the internal network of the mguard, in this example /24. Remote Virtual IP Enter the internal network of the remote mguard, in this example /24. Case 1: Enter the real IP of the client without a subnet mask, in this example Case 2: Enter the virtual IP of the client without a subnet mask, in this example Case 1: Enter the real IP of the client with a subnet mask of 32, in this example /32. Case 2: Enter the virtual IP of the client with a subnet mask of 32, in this example /32. n.a. Document ID: UG Page 75 of 106

76 VPN Tunnel between two mguards, Multi Stealth and Router/PPPoE Mode In this example a VPN tunnel from an mguard in Multi Stealth (refer to mguard operating in Stealth Mode) mode to an mguard in PPPoE (refer to mguard operating in PPPoE Mode) or Router mode (refer to mguard operating in Router Mode) should be established. Certificates must be used for authentication because the connection will be established across a NAT router. The VPN connection is initiated by mguard 1. To use the VPN feature in Multi Stealth mode, a Management IP must be assigned to the mguard. This IP must belong to the network in which the mguard is located and must not be used by any other entity in the network. mguard 2 has the static public IP It would also be possible to establish the VPN tunnel from mguard 2 to mguard 1 but in this case port forwarding for the UDP ports 500 and 4500 to the Management IP of mguard 1 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. The interfaces of the mguard were configured through the menu Network >> Interfaces with the following settings: Parameter mguard 1 (Multi Stealth) mguard 2 (Router) Network Mode Stealth (multiple clients) Router Stealth Management IP n.a. Stealth Management Netmask n.a. Stealth Management Gateway n.a. Internal IP n.a Internal Netmask n.a Document ID: UG Page 76 of 106

77 mguard 1 (Initiator, Multi Stealth): mguard 2 (Responder, Router/PPPoE Mode): Section Parameter mguard 1 (Multi Stealth) mguard 2 (Router/PPPoE) Options Transport and Tunnel Settings Refer to General Settings. Type Local Remote On both mguards, select Type=Tunnel for a tunnel connection. Enter the internal network in which the mguard is located, in this example /16. Enter the internal network of the remote mguard, in this example /24. Enter the internal network of the mguard, in this example /24. Enter the internal network in which the remote mguard is located, in this example /16. Document ID: UG Page 77 of 106

78 VPN 1:1 NAT for the local Network Usually a VPN connection can only be established between different networks, e.g. between the local network /24 and the remote network /24, but not if both sites have the same internal network /24. This would lead to a routing problem because packets sent to an IP address of this network may either be located in the local or in the remote network. VPN 1:1 NAT for the local network solves this problem. This feature must also be used if a couple of mguards establish VPN connections to a central VPN gateway, some or all of them using the same internal network. 1:1 NAT means mapping the network part of the IP address to another network and keeping the host part unchanged (e.g /24 <-> /24). The part of the IP address which represents the network is defined by the subnet mask. VPN 1:1 NAT for the local network can be used either to establish a VPN connection between two sites which have the same internal network or to connect two different locations which all have the same internal network. A virtual transfer network is used to establish the VPN tunnel. The mguard, on which VPN 1:1 NAT for the local network is configured, performs a 1:1 NAT from the virtual transfer network to its local network by mapping the network part of the IP address and keeping the host part unchanged VPN Tunnel between two Sites with the same internal Network In this example a VPN tunnel between two sites with the same internal network /24 should be established. Virtual transfer networks need to be used on both sides to establish the VPN tunnel. VPN 1:1 NAT for the local network must be configured on both mguards. Network A uses as virtual network /24 and Network B /24. The VPN tunnel needs to be established between those virtual networks /24 and /24. Hosts of Network B are accessible from Network A through the network /24. Hosts of Network A are accessible from Network B through the network /24. Document ID: UG Page 78 of 106

79 The following screenshots display the settings on mguard 1: Section Parameter mguard 1 mguard 2 Options Refer to General Settings. Transport and Tunnel Settings Type Local On both mguards, select Tunnel for a tunnel connection. Enter the local virtual network, in this example /24. Enter the local virtual network, in this example /24. Remote Enter the virtual network of the remote mguard, in this example /24. Enter the virtual network of the remote mguard, in this example /24. <More> Click <More>. This action must be performed on both mguards. In the section NAT, select 1:1 NAT for the IPsec tunnel connection. Enable 1-to-1 NAT for the local network. Enter as Intermal network address for local 1-to-1 NAT the real internal network of the mguard, in this example Do not specify a subnet mask. The subnet mask is taken from the specified Local network (/24) automatically. Document ID: UG Page 79 of 106

80 VPN Tunnel to different Locations with the same internal Networks In this example, two mguards should establish a VPN tunnel to the central office. Both mguards are located at different production sites and have the same internal network /24. On those mguards 1:1 NAT of the local network to a virtual network must be performed, choosing as virtual networks /24 for Production Site 1 and /24 for Production Site 2. Data packets directed from the central office to /24 will be sent through the VPN tunnel to Production Site 1, data packets directed to /24 through the tunnel to Production Site 2. The mguard at the production site makes a 1:1 NAT from the virtual to the local network by mapping the network part of the IP address and keeping the host part unchanged, e.g /24 -> /24. Examples: A ping from the central office to the IP address will be sent through the VPN tunnel to Production Site 1. The mguard at Production Site 1 maps the network part of the IP address to the local network ( x -> x), keeping the host part (47) unchanged. A ping from the central office to the IP address will be sent through the VPN tunnel to Production Site 2. The mguard at Production Site 2 maps the network part of the IP address to the local network ( x -> x), keeping the host part (47) unchanged. Document ID: UG Page 80 of 106

81 Central Office mguard Two VPN connections must be configured on the Central Office mguard, specifying the virtual networks as Remote network: 1) Production Site 1: Local network= /16, Remote network= /24 2) Production Site 2: Local network= /16, Remote network= /24 mguards at the production sites The following screenshots display the settings of the mguard at Production Site 1: Section Parameter mguard 1 Production Site 1 Options Refer to General Settings. mguard 2 Production Site 2 Transport and Tunnel Settings Type Local On both mguards, select Tunnel for a tunnel connection. Enter the local virtual network, in this example /24. Enter the local virtual network, in this example /24. Remote Enter the internal network of the Central Office mguard, in this example /16. Enter the internal network of the Central Office mguard, in this example /16. <More> Click <More>. This action must be performed on both mguards. In the section NAT, select 1:1 NAT for the IPsec tunnel connection. Enable 1-to-1 NAT for the local network. Enter as Intermal network address for local 1-to-1 NAT the real internal network of the mguard, in this example Do not specify a subnet mask. The subnet mask is taken from the specified Local network (/24) automatically. Document ID: UG Page 81 of 106

82 VPN Masquerading (VPN NAT) IP Masquerading is a synonym for Network Address Translation (NAT). NAT must be activated on gateways connecting private networks to the Internet to be able to access web sites in the Internet. When accessing a web site in the Internet (e.g. from a private network, the gateway (NAT router) replaces the sender s IP address (e.g ) by its own public IP (e.g ) so that the target web server knows where to send the respond back. When receiving the response from the web server, the gateway reverts the masquerading and forwards the response to the client in the private network. NAT is only applied in one direction, from the internal to the external network. A client in the internal network (e.g ) may access web sites in the Internet but the client can not be accessed from the Internet through its private IP address. VPN Masquerading provides the same functionality, but within a VPN connection. When data packets are sent through the VPN tunnel, the mguard replaces the sender s IP address by a specified, single IP address and reverts the masquerading when receiving the response from the remote network. A VPN connection using VPN Masquerading can only be used in one direction. The clients in the remote VPN network can be accessed through the VPN connection but from the remote network it is not possible to access clients in the local network. If a VPN connection needs to be used in one direction only, VPN Masquerading can be used. The major advantage is that the complete local network is masqueraded by one single IP address. If a lot of VPN connections terminate at a central VPN gateway, this feature reduces the required address space for the VPN connections and also makes the VPN configuration clearer. Let us take a look at the following example to explain this in more detail: A lot of remote sites establish VPN connections to a central office. The VPN connections are used in one direction only to transfer system messages from the machines through the VPN connection to the central office. The VPN connections, especially the tunnel settings, must be configured as follows when not using VPN Masquerading: Connection to Site 1: Both sites have different internal networks so the VPN tunnel can be established between the networks /16 and /24. Connection to Site 2: The internal network of Site 2 ( /24) is already used for the VPN connection to Site1. Therefore a virtual network with 1:1 NAT to the local network needs to be used to access this site. The VPN tunnel is established between the networks /16 and /24. Connection to Site 3: Both sites have the same internal network /16. Therefore virtual networks with 1:1 NAT to the local network must be used on both sites. Apart of this be careful not to use virtual networks which are already used for other VPN connections. The VPN tunnel is established between the networks /16 and /16. Connection to Site 4 and Site 5: Both sites have internal networks which are not used by any other VPN connection so those networks can simple be used to set up the tunnel. Document ID: UG Page 82 of 106

83 Advantages: The VPN connections can be used in both directions. The sites can be accessed from the central office through the VPN connections and vice versa. Disadvantages: Each VPN connection must be treated individually, depending on the local and remote network. Confusing configuration of the VPN connections with increasing number of remote sites. Now let us take a look how this configuration looks like when using VPN Masquerading: When configuring the VPN connections, only the IP address used for masquerading needs to be incremented for each site. This IP address does not necessarily need to belong to the internal network. Advantages: Clear VPN configuration. Reduced address space for the sites. Disadvantages: The VPN connections can only be used in one direction. In the example above only the sites can access the central office. The following screenshots display the settings of the mguard at Site 1: Document ID: UG Page 83 of 106

84 IPsec VPN >> Connections, tab General Options Refer to General Settings. Transport and Tunnel Settings Type Local Remote <More> On both mguards, select Tunnel for a tunnel connection. Enter the IP address which should be used for masquerading, in this example /32. This IP must not necessarily belong to the internal network. Enter the internal network of the remote mguard, in this example /16. Click <More>. In the section NAT, select Local masquerading. Enter as Internal network address for local masquerading the real internal network with its subnet mask. Document ID: UG Page 84 of 106

85 VPN 1:1 NAT for the remote Network VPN 1: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. Network A ( /16) is unknown to the target system ( /24). In this case, if the target ( ) has received a packet through the VPN tunnel from Network A, it will either send the reply to its default gateway (which is not mguard 2) or will not reply if no default gateway is defined. In any case, the sender will not receive a reply. VPN 1: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 /32 -> ). The ARP proxy on the mguard will provide ARP resolution for this network or IP address. This network or IP address must not be used by any entity in the local network. The target machine will direct the responses to the mguard. Document ID: UG Page 85 of 106

86 The following screenshots display the settings on mguard 2, on which VPN 1:1 NAT for the remote network needs to be enabled. IPsec VPN >> Connections, tab General Options Refer to General Settings. Transport and Tunnel Settings Type Local Remote <More> Select Tunnel for a tunnel connection. Enter the internal network of the mguard, in this example /24. Enter the internal network of the remote mguard, in this example /32 (please refer to Considerations at the end of this chapter). Click <More>. In the section NAT, select 1:1 NAT. Enable 1-to-1 NAT of the remote network to a different network. Enter the network or IP address to which the remote network (or IP address) should be mapped, in this example Do not specify a subnet mask. The subnet mask is taken from the specified Remote network automatically (/32 in this example). Document ID: UG Page 86 of 106

87 Considerations Be careful when choosing the subnet mask for the Remote network and specifying the network to which the remote network should be mapped. According to the above mentioned configuration only the client in Network A has access to the target in Network B. A subnet mask of /24 for the remote network (e.g. Remote Network = /24 and Network address for remote 1:1 NAT = ) won t work because in this case the ARP proxy of the mguard would reply to all ARP request of the internal network ( ). Increasing the subnet mask of the remote network would also increase the number of clients in Network A from which Network B could be accessed but it would also increases the required number of unused IP addresses in Network B for the mapping of the source IP address. The following table explains the relationship between the remote subnet mask, which clients may have access to the target systems and the number of required unused IP addresses in the local network. Example 1 Example 2 Example 3 Example 4 Specified remote network / / / /32 Remote IP addresses which may access the remote targets Local network / / / /24 Network address for remote 1-to-1 NAT (/26) (/26) (/28) (/32) Hosts to which the mguard would reply to ARP requests, must not be used in the local network hosts hosts hosts host If it is required to access the target systems from several clients, place the clients behind a NAT router before the packets are sent to the VPN tunnel. This way the external IP of the NAT router must be specified with a subnet mask of /32 as Remote network and only one unused IP address is required. There exists another, easier solution if the VPN connection is only used in one direction, from Network A to Network B, as it would be the case for Remote Maintenance: use VPN Masquerading on mguard 1 (refer to VPN Masquerading (VPN NAT)). This way the data packets arriving at mguard 2 will always come from the same source IP address (/32). Document ID: UG Page 87 of 106

88 Hub & Spoke Hub & Spoke allows redirecting packets received through one VPN tunnel directly into another VPN tunnel. In the diagram above Hub & Spoke must be enabled on the mguard at the Central Office. Without Hub & Spoke the required routing must be configured on an additional router located in the internal network of the central office. Note: If a lot of remote locations are connected to the central office, sending a huge amount of data, the Internet connection at the central office may become the bottleneck. In such a case a fully mashed VPN network should rather be used instead of Hub & Spoke. To enable Hub & Spoke: Go to the menu IPsec VPN >> Global, tab Options. Enable the option Allow packet forwarding between VPN connections. Apart of enabling Hub & Spoke the specified networks for the VPN connections must be chosen accordingly to allow the direct routing between the VPN tunnels. This will be explained based on two examples in the next chapters. Document ID: UG Page 88 of 106

89 Example: Branch Offices Each office should communicate with each other office through the VPN connections. Hub & Spoke must be enabled on mguard 3. To allow the routing from one tunnel into the other, the specified local VPN network on mguard 3 must include all remote VPN networks, in this example /16. Considering this, the tunnel settings for the VPN connections look as follows: VPN Connection Tunnel Settings Local Network <==> Remote Network mguard 1 mguard 3 mguard 1: /24 <==> /16 mguard 3: /16 <==> /24 mguard 2 mguard 3 mguard 2: /24 <==> /16 mguard 3: /16 <==> /24 But what happens if the network of the central office is not located in the network /16, using for example /16? In this case the two branch offices can communicate to each other through the VPN connections but neither Branch Office 1 nor Branch Office 2 will have access to the network of the central office or vice versa. In this case a second tunnel must be specified in each configured VPN connection. This will lead to the following tunnel settings: VPN Connection Tunnel Settings Local Network <==> Remote Network mguard 1 mguard 3 mguard 1: /24 <==> / /24 <==> /16 mguard 3: /16 <==> / /16 <==> /24 mguard 2 mguard 3 mguard 2: /24 <==> / /24 <==> /16 mguard 3: /16 <==> / /16 <==> /24 The following screenshot displays the tunnel settings of mguard 1 for the VPN connection to mguard 3: Document ID: UG Page 89 of 106

90 Example: Remote Maintenance Two technicians should have access to machines located at production sites from their laptops through a VPN connection. The technicians can use either a software VPN client or an mguard to establish the VPN connection to the central mguard. A virtual IP address is used at the technician site for not depending on the real IP address currently assigned to the laptop. In this example the virtual IP /32 was used for Technician 1 and /32 for Technician 2. The technicians want to get access to the machines of all production sites. Therefore the remote VPN network they need to specify must include the networks of all machines, in this example /16. At the production site, an mguard is used as router to connect the machine network to the production site and to establish the VPN connection to the central mguard. The three mguards have the internal networks /24, /24 and /24. When data packets arrive at the mguards through the VPN connection, the senders IP address is either /32 or /32. For not being restricted to two technicians only and to have the possibility to add more technicians to this topology, on these mguards a remote VPN network must be specified which includes all technicians, in this example /24. Hub & Spoke needs to be enabled on the central mguard. Considering the above mentioned points, the tunnel settings for the VPN connections look as follows: VPN Connection Tunnel Settings Local Network <==> Remote Network Technician 1 mguard 4 Technician 1: /32 <==> /16 mguard 4: /16 <==> /32 Technician 2 mguard 4 Technician 2: /32 <==> /16 mguard 4: /16 <==> /32 mguard 1 mguard 4 mguard 1: /24 <==> /24 mguard 4: /24 <==> /24 mguard 2 mguard 4 mguard 2: /24 <==> /24 mguard 4: /24 <==> /24 mguard 3 mguard 4 mguard 3: /24 <==> /24 mguard 4: /24 <==> /24 Document ID: UG Page 90 of 106

91 But what happens if the mguards at the production sites all have the same internal network, e.g /24? In this case use VPN 1:1 NAT for the local network (refer to VPN 1:1 NAT for the local Network) on the mguards at the production sites. A virtual network is used to get access to the single production sites and the mguard will perform a local 1:1 NAT from the virtual network to the real internal network ( /24). In this example the virtual network /24 was used for Production Site 1, /24 for Production Site 2 and /24 for Production Site 3. The technicians need to use those virtual networks to get access to the corresponding machine. Consequently the technicians need to specify /16 as remote VPN network. The tunnel settings for this setup look as follows: VPN Connection Tunnel Settings Local Network <==> Remote Network Technician 1 mguard 4 Technician 1: /32 <==> /16 mguard 4: /16 <==> /32 Technician 2 mguard 4 Technician 2: /32 <==> /16 mguard 4: /16 <==> /32 mguard 1 mguard 4 mguard 1: /24 <==> /24 1-to-1 NAT of the local network to /24 mguard 4: /24 <==> /24 mguard 2 mguard 4 mguard 2: /24 <==> /24 1-to-1 NAT of the local network to /24 mguard 4: /24 <==> /24 mguard 3 mguard 4 mguard 3: /24 <==> /24 1-to-1 NAT of the local network to /24 mguard 4: /24 <==> /24 Document ID: UG Page 91 of 106

92 Authentication If not already done yet, please read the chapter Authentication (PSK or Certificates) carefully before configuring the authentication method. The authentication method is configured through the menu IPsec VPN >> Connections, tab Authentication Pre-Shared Secret Key (PSK) IPsec VPN >> Connections, tab Authentication Authentication VPN Identifier Authentication method Select Pre-Shared Secret (PSK). Pre-Shared Secret Key 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. In this case leave the fields Local and Remote empty. If another VPN identifier shall be used (e.g. hostname or address), enter it into the field Remote or Local VPN Identifier respectively. If a hostname should be used as VPN identifier, the hostname must be preceded by the Document ID: UG Page 92 of 106

93 X.509 Certificates At first ensure that the mguard s machine certificate was already uploaded to the device (refer to Authentication (PSK or Certificates) and Import of the Machine Certificate). IPsec VPN >> Connections, tab Authentication Authentication VPN Identifier Authentication method Local X.509 Certificate Select X.509 Certificates. Select the mguard s machine certificate by its short name. Remote CA certificate Leave the default value (No CA certificate, but the Remote Certificate below). Remote Certificate Click Browse, select the remote certificate and click Upload. When the upload is finished, the certificate identifying parameters are displayed. The mguard uses as default the subject of the certificate (e.g. CN=mGuard, O=Innominate, OU=Support) as VPN identifier. If another VPN Identifier (e.g. hostname, address or IP address) is required enter it into the fields Remote or Local respectively. Otherwise leave the fields Local and Remote empty. Using another VPN identifier than the certificate s subject name requires that the identifier is present in the certificate itself as subject alternative name. If a hostname should be used as VPN identifier, the entered hostname must be preceded by the Document ID: UG Page 93 of 106

94 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. The VPN firewall may be configured if required. By default, all incoming and outgoing connections will be passed through. IPsec VPN >> Connections, tab Firewall Incoming Outgoing Protocol From IP From Port To IP To Port Action Comment Log Select to protocol to which the rule should be applied (TCP, UDP, ICMP or All). The sender s IP address /0 means all IP addresses. The rule may be restricted to a subnet (e.g /24) or to an IP address (e.g /32). If no subnet mask was specified, the mguard treats the entered value as IP address. Only applicable if Protocol=TCP or UDP. The port from which the packets are sent. Enter either the port number or the corresponding service name (e.g. http for TCP port 80). Specifying a port range (e.g. <start port>:<end port>) is also supported. If the port varies from which the packets are sent, as it is the case when accessing the Internet from a web browser, enter any. The target IP address (refer to From IP). Only applicable if Protocol=TCP or UDP. The destination port to which the packets are sent (refer to From Port). Action applied to a packet which matches the rule. This could be Accept, Drop or Reject. Enter a comment if required. Enables the logging for the rule. Document ID: UG Page 94 of 106

95 IKE Options The IKE options specify the encryption and hash algorithms that should be used for the ISAKMP SA and IPsec SA, the lifetimes of the SAs and the parameters for the Dead Peer Detection (DPD). Basically the default settings can be used if not stronger encryption and/or hash algorithms are required. IPsec VPN >> Connections, tab IKE Options ISAKMP SA (Key Exchange) IPsec SA (Data Exchange) Lifetimes Dead Peer Detection Encryption Algorithm Hash Algorithm Encryption Algorithm Hash Algorithm Perfect Forward Secrecy (PFS) ISAKMP SA Lifetime IPsec SA Lifetime Rekeymargin Rekeyfuzz Rekeying tries Rekey Delay Timeout Select the Encryption Algorithm that shall be used for phase I. The selected Encryption Algorithm must be supported by the remote VPN gateway. Select the Hash Algorithm that shall be used for phase I. The selected Hash Algorithm must be supported by the remote VPN gateway. Select the Encryption Algorithm that shall be used for phase II. The selected Encryption Algorithm must be supported by the remote VPN gateway. Select the Hash Algorithm that shall be used for phase II. The selected Hash Algorithm must be supported by the remote VPN gateway. By default, PFS is enabled. This option only needs to be disabled if it is not supported or disabled on the remote VPN gateway. Specifies the lifetime of the ISAKMP SA in seconds. When the lifetime is about to expire, a new key will be negotiated between the peers. Specifies the lifetime of the IPsec SA in seconds. When the lifetime is about to expire, a new key will be negotiated between the peers. Minimal time interval before the old key expires during which a new key shall be negotiated. 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. 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. When set to Yes, the mguard will try to renegotiate keys when they expire. The length of time in seconds after which DPD Keep Alive queries will be sent to check the availability of the remote peer. 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: UG Page 95 of 106

96 ISAKMP SA/IPsec SA Lifetime The keys of an IPsec connection will be renegotiated in certain intervals to increase the costs of an attack on 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 = 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 = 3060 seconds. Due to the value of Rekeyfuzz the value of Rekeymargin can be increased randomly by a maximum of 50 percent: (540/2) = 3330 seconds. The new key for the ISAKMP SA will be negotiated after seconds randomly Dead Peer Detection (DPD) Note: The mechanism of Dead Peer Detection only works if both peers support DPD. The default settings are: 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 respond to the Keep Alive query 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: UG Page 96 of 106

97 mguard Version 7 Configuration Examples 13.4 TCP Encapsulation In this example mguard 1 initiates the VPN connection to mguard 2. In case of a NATed connection, a VPN connection is established through the UDP ports 500 and Also the encrypted ESP packets are enveloped in UDP packets due to NAT-T. Therefore a firewall at the customer site must allow outgoing UDP packets directed to the ports 500 and Usually the customer should ensure that those ports are opened. But in some cases it is not possible to open those ports on the customers firewall. TCP Encapsulation solves this problem. The UDP packets are enveloped in TCP packets and are sent to a specified TCP port. It is only required to know which TCP port is allowed for outgoing TCP packets on the customers firewall. TCP Encapsulation can also be used to establish the VPN connection if accessing the Internet is only granted through a proxy server at the customer s site. In this case the parameters to access the proxy server (menu Network >> Proxy Settings) must be configured. In this example TCP port 80 is used to establish the VPN connection. The VPN connection must be configured as described in the previous chapters. Certificates must be used for authentication because the VPN connection will be established across a NAT router. Apart of this the following additional settings are required to use TCP Encapsulation: mguard 2 (Responder): Select IPsec VPN >> Global, tab Options. In the section TCP Encapsulation, enable TCP Encapsulation. This starts the IPsec-TCP-Server on the mguard. Specify the TCP port to listing on for incoming TCP encapsulated VPN connections, in this example 80. Note: It is not possible to use TCP port 443 if remote HTTPS access through this port (default value) is enabled on the mguard. Either specify another TCP port for remote access (menu Management >> Web Settings, tab Access), e.g or chose another TCP port for TCP Encapsulation. Document ID: UG Page 97 of 106

98 mguard Version 7 Configuration Examples mguard 1 (Initiator): Select IPsec VPN >> Connections, tab General. Enable TCP Encapsulation. Specify the TCP port on which the server (mguard 2) is listening for TCP encapsulated VPN connections, in this example 80. Document ID: UG Page 98 of 106

99 mguard Version 7 Configuration Examples 13.5 VPN Tunnel Groups The VPN Tunnel Groups feature is an optional feature, which needs to be licensed separately. Activating this feature will automatically set the maximum number of allowed VPN connections to 250. When not using this feature, a VPN connection for each remote entity must be configured on the central VPN gateway. Using the VPN Tunnel Groups feature, only one VPN connection needs to be configured. The remote entities are authenticated by the CA certificate which was used to sign their certificates. In this example five remote users establish a VPN connection to the mguard at the central office, using a Software VPN Client on their laptops or an mguard. A virtual IP address is used by the entity for not depending on the real IP address currently assigned to the laptop. In this example virtual IPs from the network /24 were used. Only one VPN connection must be configured on the mguard at the central office due to the usage of the VPN Tunnel Groups feature. The feature VPN Tunnel Groups is not limited to remote users which use a single virtual IP address. Also several branch offices with internal networks (e.g /24, /24, etc.) can be connected to the central office using this feature. Document ID: UG Page 99 of 106

100 mguard Version 7 Configuration Examples Import of the CA Certificate Apart of importing the mguard s machine certificate (refer to Import of the Machine Certificate) the CA certificate which was used to sign the certificates of the remote entities needs to be imported through the menu Authentication >> Certificates, tab CA Certificates. Select Authentication >> Certificates, tab CA Certificates. Click the down arrow to create a new line. Click Browse and select the CA certificate (PEM export) which was used to sign the certificates of the remote entities. Click Import. The certificate is uploaded to the device. When the upload is finished, the certificate identifying parameters are displayed. Modify the Shortname for the certificate if desired. Click Apply Tunnel Settings IPsec VPN >> Connections, tab General Options Transport and Tunnel Settings Refer to General Settings. Type Local Remote Select Tunnel for a tunnel connection. Enter the internal network of the mguard, in this example /24. The specified remote network must include the virtual IPs of all remote users, in this example /24. In case of remote networks (e.g /24, /24, etc.) a network which includes all remote networks must be chosen (e.g /16). Document ID: UG Page 100 of 106

101 mguard Version 7 Configuration Examples Authentication IPsec VPN >> Connections, tab Authentication Authentication VPN Identifier Authentication method Local X.509 Certificate Remote CA Certificate Remote Certificate Local Remote Select X.509 Certificates. Select the mguard s machine certificate by its short name. Select the CA certificate which was used to sign the remote certificates by its short name. Not required for this setup. Not required for this setup. 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 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. Document ID: UG Page 101 of 106

102 mguard Version 7 Configuration Examples 13.6 URL to start, stop and retrieve the Status of a VPN Connection The following URL can be used to start and stop VPN connections and query the connection status. The VPN connection itself must be disabled in the VPN configuration (menu IPsec VPN >> Connections) to activate and deactivate it through this script. 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 directly from a web browser or on a client using for example wget. wget example: wget --quiet --no-check-certificate --output-document=vpnstate.txt wget --quiet --no-check-certificate --output-document=vpnstate.txt " wget --quiet --no-check-certificate --output-document=vpnstate.txt " Document ID: UG Page 102 of 106

103 mguard Version 7 Configuration Examples 13.7 mguard industrial RS: Activating a VPN Tunnel through an external push Button or on/of 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 released. Configure the VPN connection as described in the previous chapters. Apart of this the following settings are required: mguard version 5.x.y and 7.0.x only: 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). In the menu IPsec VPN >> Globals (tab Options) specify: o The name of the VPN connection which should be triggered by the CMD contact. o Whether an on/off switch or a push button is connected to the CMD contact. Document ID: UG Page 103 of 106

104 mguard Version 7 Configuration Examples 13.8 Windows L2TP/IPSec Connection to the mguard An L2TP/IPsec connection from a Windows client to the mguard can only be used if the connection is not established across one or more gateways that have Network Address Translation (NAT) activated. In other words, this kind of connection can only be used if the Windows client and the mguard are connected to the same external network or to the Internet directly. But in most cases the connection is NATed which requires using a software VPN client on the Windows system to set up a VPN connection to the mguard. Basically any software VPN client can be used which is compliant to the IPsec standard. If the conditions allow using an L2TP/IPsec connection, please refer to the mguard Configuration Examples v6 to obtain the information how to configure the Windows client and the mguard for such a connection. Document ID: UG Page 104 of 106

105 mguard Version 7 Configuration Examples 14 Secondary External Interface The first external interface is the external Ethernet interface (WAN port) of the mguard which connects the mguard to an external network or the Internet. The Secondary External Interface is an additional connection to the outer world through a phone line. To establish this connection, either the built-in modem or ISDN terminal adapter of the mguard industrial RS or an external modem connected to the serial port of the mguard (refer to Modem Support) can be used. The Secondary External Interface can be configured as permanent or temporary connection. Routes for this interface must be specified to distinguish which packets should be sent through the WAN port and which ones through the Secondary External Interface. The Secondary External Interface is especially used as VPN fallback through a phone line if accessing the remote VPN gateway through the Internet is temporarily not possible for some reasons. The next chapter explains how to setup such a scenario VPN Fallback through a Phone Line In this example the Secondary External Interface should be configured as fallback to establish the VPN connection. mguard 1 initiates the VPN connection through the Internet to mguard 2. If this path is not available, mguard 1 should dial out and establish the VPN connection through the phone line. This connection should be terminated and the VPN connection should be re-established through the Internet once this path is available again. mguard 1 is configured to operate as router (refer to mguard operating in Router Mode) between the internal network /24 and external network /16. mguard 1 initiates the VPN connection to mguard 2. The VPN connection was configured as described in the previous chapters. The Secondary External Interface is provided by the built-in modem of the mguard industrial RS. The dial out was configured according to chapter Dial-out Configuration with the following important settings: Dial on demand = Yes, Idle timeout = Yes, Idle time (seconds) = 300. Document ID: UG Page 105 of 106

106 mguard Version 7 Configuration Examples For this scenario, the Secondary External Interface (menu Network >> Interfaces, tab General) needs to be configured as follows: Network >> Interfaces, tab General Secondary External Interface Network Mode Operation Mode Secondary External Routes Probes for Activation Specify whether the Secondary External Interface is provided by an external modem connected to the serial port (Modem) or by the internal built-in modem of the mguard industrial RS (Built-in Modem). Specify if this is a permanent or a temporary connection. In this section define which traffic should be routed through the Secondary External Interface. Network: Specify the target network of the packets. In this example the IP address of the remote VPN gateway ( /32) must be entered and not the remote VPN network ( /24) because the mguard sends the encrypted packets to the IP address of the remote VPN gateway. Gateway: Leave %gateway if the gateway is assigned by the ISP for the dial-out connection. Otherwise enter the IP address. In this section define the conditions under which the Secondary External Interface is activated. This is only the case if all specified probes fail. In this example the following probes are defined: Availability of the gateway ( ) of the external network via ICMP Ping. Availability of a web site located in the Internet ( ) via ICMP Ping. Availability of the remote VPN gateway ( ) via IKE Ping. Probe Interval (seconds) Number of times all probes need to fail An IKE Ping sends a UDP packet to port 500 to the specified IP address. This packet should be replied by the remote VPN gateway if it is reachable. An IKE Ping instead of an ICMP Ping was used because the remote VPN gateway may be configured not to reply to ICMP echo requests or it may be located behind a NAT router with a corresponding port forwarding configuration for the UDP port 500 and This interval specifies how long the mguard waits before performing the next probe cycle. Specifies the number of probe cycles in which all specified probes failed before the Secondary External Interface is activated. Document ID: UG Page 106 of 106