Innominate mguard Version 6 Configuration Examples mguard smart mguard PCI mguard blade mguard industrial RS EAGLE mguard mguard delta Innominate Security Technologies AG Albert-Einstein-Str. 14 12489 Berlin, Germany Phone: +49 (0)30-6392 3300 Fax: +49 (0)30-6392 3307 contact@innominate.com http://www.innominate.com
Table of Contents 1 Disclaimer 5 2 Introduction 6 3 Factory Default Settings and Access to the GUI 6 4 Purposes of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) 7 4.1 Stealth Modes (autodetect, static, multiple clients) 7 4.2 Router Mode 8 4.3 PPPoE/PPTP Mode 8 4.4 Modem Mode 8 5 mguard operating in Stealth Mode 9 5.1 Management IP 10 5.2 Static Routes 10 5.3 DNS Server 11 6 mguard operating as DSL Router (PPPoE Mode) 12 6.1 Replacing an existing DSL Router with the mguard 12 6.2 Configuring the Interfaces 13 6.3 Network Address Translation (NAT) 14 6.4 DNS Server 14 6.5 Required IP Settings on the Clients 14 6.6 DynDNS Registration 15 7 mguard operating as Router (Router Mode) 16 7.1 Configuration of the Clients 16 7.2 Configuration of the mguard 17 7.2.1 Configuring the Interfaces 17 7.2.1.1 Additional internal/external Routes 18 7.2.2 Network Address Translation (NAT) 18 7.2.3 Internal DHCP Configuration 19 7.2.3.1 DHCP Server for the internal Network 19 7.2.3.2 DHCP Relay 20 7.2.4 External DHCP Configuration 21 7.2.5 DNS Sever 21 Document ID: UG206002508-017 Page 2 of 95
8 Firewall 22 8.1 Incoming/Outgoing Firewall 22 8.1.1 Basic Guidelines for setting up the Firewall 22 8.1.2 Example of a wrongly configured Firewall 22 8.2 Sets of Rules 23 8.3 MAC Filtering 25 8.3.1 Basic Rules for setting up MAC filtering 25 8.3.2 Examples MAC Filter Configuration 26 8.3.2.1 Novell IPX 26 8.3.2.2 Restricted IPv4 Access 27 8.4 1:1 NAT 28 8.5 User Firewall 30 8.5.1 Configuring Remote Users 30 8.5.2 RADIUS Servers 31 8.5.3 Configuring the User Firewall 31 8.5.3.1 General Settings 31 8.5.3.2 Template Users 32 8.5.3.3 Firewall Rules 32 8.5.4 Activating the User Firewall 33 9 Redundancy 34 9.1 Router Redundancy (Router Mode) 34 9.1.1 Configuration of the Interfaces 35 9.1.2 Redundancy Configuration 36 9.2 Firewall Redundancy (Multi Stealth Mode) 37 9.2.1 Configuration of the Interfaces 38 9.2.2 Redundancy Configuration 39 9.3 ICMP Checks 40 10 Quality of Service (Egress QoS) 41 11 Modem Support 44 11.1 Connecting an external Modem to the mguard 44 11.2 Dial-in Configuration 44 11.2.1 General Modem Settings 45 11.2.2 Configuring the Dial-in Connection on the mguard 46 11.2.3 Enabling HTTPS Remote Access 46 11.2.4 Required changes on the remote entity 47 11.3 Dial-out Configuration 48 11.3.1 General Modem Settings 48 11.3.2 Configuring the Dial-out Connection on the mguard 49 Document ID: UG206002508-017 Page 3 of 95
12 IPsec VPN 50 12.1 Limitations 50 12.2 VPN Configuration 51 12.2.1 Authentication Method 51 12.2.1.1 Pre-Shared Secret Key (PSK) 51 12.2.1.2 X.509 Certificates 52 12.2.2 VPN Firewall 55 12.2.3 IKE Options 56 12.2.3.1 ISAKMP SA/IPsec SA Lifetime 57 12.2.3.2 Dead Peer Detection (DPD) 57 12.3 mguard behind NAT Gateway 58 12.3.1 VPN initiating mguard behind NAT Gateway 58 12.3.2 VPN responding mguard behind NAT Gateway 58 12.3.3 Both mguards behind NAT Gateways 59 12.4 VPN Transport Connection between two mguard in Stealth Mode with PSK 60 12.4.1 Configuration of the Interfaces 60 12.4.2 VPN Configuration 61 12.5 VPN Tunnel between two mguards in Router/PPPoE Mode with Certificates 62 12.5.1 Configuration of the Interfaces 63 12.5.2 Required X.509 Certificates 63 12.5.3 Import of the Machine Certificates 63 12.5.4 VPN Configuration 64 12.6 VPN Tunnel between two mguards, Single-Stealth and PPPoE Mode, with Certificates 66 12.6.1 Configuration of the Interfaces 66 12.6.2 Required X.509 Certificates 67 12.6.3 Import of the Machine Certificates 67 12.6.4 VPN Configuration 68 12.7 VPN Tunnel between two mguards, Multi-Stealth and PPPoE Mode, with Certificates 71 12.7.1 Configuration of the Interfaces 71 12.7.2 Required X.509 Certificates 72 12.7.3 Import of the Machine Certificates 72 12.7.4 VPN Configuration 73 12.8 VPN 1-to-1 NAT for the local Network 75 12.8.1 VPN Tunnel between two Sites with the same internal Network 75 12.8.2 VPN Tunnel to different Locations with the same remote Network 77 12.9 VPN 1-to-1 NAT for the remote Network 79 12.10 VPN Tunnel Groups 82 12.10.1 Import of the required Certificates 82 12.10.2 VPN Configuration 83 12.11 Hub and Spoke 85 12.12 URL for starting, stopping and Status Query of a VPN Connection 86 12.13 mguard industrial RS: Activating a VPN Tunnel through an external push Button or on/off Switch _ 87 12.14 L2TP/IPSec Connection 88 12.14.1 Required X.509 Certificates 88 12.14.2 Configuration of the mguard 89 12.14.2.1 Import of the Machine Certificate 89 12.14.2.2 VPN Configuration 90 12.14.2.3 Starting the L2TP Server 93 12.14.3 Configuring the Windows Client 94 12.14.3.1 Certificate import through Microsoft Management Console (MMC) 94 12.14.3.2 Configuration of the L2TP/IPSec Dial-up Connection 95 Document ID: UG206002508-017 Page 4 of 95
1 Disclaimer Innominate Security Technologies AG June 2008 Innominate and mguard are registered trademarks of the Innominate Security Technologies AG. All other brand names or product names are trade names, service marks, trademarks, or registered trade marks of their respective owners. mguard technology is protected by the German patents #10138865 and #10305413. Further national and international patent applications are pending. No part of this documentation may be reproduced or transmitted in any form, by any means without prior written permission of the publisher. All information contained in this documentation is subject to change without previous notice. Innominate offers no warranty for these documents. This also applies without limitation for the implicit assurance of scalability and suitability for specific purposes. In addition, Innominate is neither liable for errors in this documentation nor for damage, accidental or otherwise, caused in connection with delivery, output or use of these documents. This documentation may not be photocopied, duplicated or translated into another language, either in part or in whole, without the previous written permission of Innominate Security Technologies AG. Document ID: UG206002508-017 Page 5 of 95
2 Introduction This guide should help you getting familiar with the configuration of the mguard. It explains on a basis of several examples how to configure the different operating modes on the mguard and the required steps. 3 Factory Default Settings and Access to the GUI The following table lists the factory default settings of the different models: Model Network mode Internal IP address Access from the internal network through mguard smart Stealth (autodetect) - https://1.1.1.1 mguard PCI Stealth (autodetect) - https://1.1.1.1 mguard industrial RS Stealth (autodetect) - https://1.1.1.1 EAGLE mguard Stealth (autodetect) - https://1.1.1.1 mguard blade Stealth (autodetect) - https://1.1.1.1 mguard blade Router 192.168.1.1 https://192.168.1.1 Control Unit mguard delta Router 192.168.1.1 https://192.168.1.1 By default, the firewall drops all incoming (except VPN) and allows all outgoing connections. The default passwords are: User = root Password = root User = admin Password = mguard Note: Before trying to access the device through the web browser, ensure that the web browser does not use a proxy and that a default gateway is defined on the client. Stealth mode: Obtaining access to the web interface depends on whether the external interface of the mguard is connected to the network or not. If the external interface is connected to the network, which means that the default gateway is reachable, you can access the web interface directly from the client through https://1.1.1.1. If the external interface of the mguard is NOT connected to the network, ensure first that the client does not receive its IP settings via DHCP. If this is the case, assign static IP settings to the client (e.g. IP Address=192.168.1.2, Subnet Mask=255.255.255.0, Default Gateway=192.168.1.1). Then assign a static MAC address to the IP address of the default gateway with the ARP command. To do this: Open a DOS prompt. Type the command ipconfig for obtaining the IP address of the default gateway. Execute the command: arp s <IP of the default gateway> 00-aa-aa-aa-aa-aa Now you can access the GUI from the client through https://1.1.1.1. Router mode: You need to assign the following IP settings to the client: The IP address must belong to the network 192.168.1.0/24, e.g. 192.168.1.100 Subnet mask = 255.255.255.0 Default gateway = 192.168.1.1 Now you can access the web interface from the client through https://192.168.1.1. Document ID: UG206002508-017 Page 6 of 95
4 Purposes of the different Network Modes (Stealth, Router, PPPoE/PPTP, Modem) 4.1 Stealth Modes (autodetect, static, multiple clients) In Stealth mode, you simply need to interconnect the mguard between the clients which should be protected and the network. Reconfiguring the IP settings of the clients is not required. All processes which are listening on ports are hidden to the network and will not be detected by a port scanner. The mguard works completely transparent. Stealth - autodetect and static The Stealth modes autodetect or static can by used if the mguard should protect one single system (e.g. server) and if the NIC of the system has only one IP address. Otherwise multiple clients Stealth mode must be used. When using autodetect Stealth mode, the mguard detects the client s IP address automatically by analyzing the traffic which comes from the internal network and adopts the IP and MAC address of the client. Some entities do not generate traffic by itself (e.g. server, webcam). In this case the mguard will never get its IP settings. You need to use static Stealth mode and specify the clients IP and MAC address on the mguard. Stealth - multiple clients This mode is also called Multi Stealth mode. Use this mode to protect multiple clients or if the NIC of the system has more than one IP address. Note: Starting with version 6 VPN is also supported in Multi Stealth mode. Document ID: UG206002508-017 Page 7 of 95
4.2 Router Mode In Router mode the mguard works as router between two different networks. You need to configure the internal and external interfaces. The external interface may use static IP settings or receive them from a DHCP server. In Router mode the mguard may act as DHCP server for the internal and/or external network. 4.3 PPPoE/PPTP Mode In PPPoE mode the mguard works as DSL router between the internal network and the Internet. The external interface of the mguard needs to be connected to a DSL modem. The mguard will receive its external IP settings from the Internet Service Provider (ISP). The internal interface needs to be configured. In PPPoE mode the mguard may act as DHCP server for the internal network. PPTP is the equivalent to PPPoE and is used in certain countries, as for example in Austria. 4.4 Modem Mode The Modem mode can be used for accessing machines of the internal network or for sending data from the internal network through a phone line. This mode requires either an external modem connected to the serial port of the mguard or an mguard industrial RS with built-in modem or ISDN terminal adapter. All traffic directed to the WAN port is redirected to the internal serial port of the mguard and from there either over the external serial port where an external modem must be connected or over the built-in modem or ISDN terminal adaptor (mguard industrial RS, when equipped). Document ID: UG206002508-017 Page 8 of 95
5 mguard operating in Stealth Mode Using the mguard in Stealth mode is like Plug-and-Play. By default, a brand new mguard is in Stealth autodetect mode (except mguard delta and mguard blade control unit). You simple need to interconnect the mguard between the network and the entities which should be protected, but you should keep the following in mind. The network modes Stealth autodetect and Stealth static can only be used to protect one single entity with one (and only one) IP address. In Stealth autodetect mode the mguard analyzes the outgoing traffic and adapts the IP and MAC address of the client. If the client does not generate traffic by its own you need to use the Stealth static mode by specifying the clients IP and MAC address on the mguard. If more than one client should be protected by the mguard or if one single client has more than one IP address, the Stealth multiple clients mode must be used. From the internal client(s) you have access to the web interface of the mguard through https://1.1.1.1. From the external network you may access the mguard in autodetect and static Stealth mode by using the IP address of the client which is connected to the internal interface of the mguard, assuming that HTTPS remote access is enabled. For accessing the mguard from the external network in Stealth multiple clients mode, you need to assign a Management IP to the mguard. Document ID: UG206002508-017 Page 9 of 95
5.1 Management IP Note: Using a Management IP is supported for all Stealth modes (autodetect, static and multiple clients). After assigning a Management IP to the mguard you only can access the mguard through https://<management IP> and not through https://1.1.1.1 anymore (except in Stealth autodetect mode). You need to assign a Management IP to the device if the mguard is operated in Multi Stealth mode and if the device should be accessible from the external network through HTTPS/SSH or if the mguard should establish a VPN connection to a remote VPN gateway. From the menu, select Network -> Interfaces, tab General. The Management IP must belong to the network and must not be used by any other entity. Apart of this IP address you need to enter the subnet mask and the default gateway of the network. 5.2 Static Routes Static routes can be used for sending data through another gateway than the default gateway of the network by specifying the Network and the Gateway. Static routes do only have an effect on actions initiated by the mguard, as for example establishing VPN connections or online firmware updates. Document ID: UG206002508-017 Page 10 of 95
5.3 DNS Server By default, the mguard uses a predefined list of public available DNS servers (Servers to query = DNS Root Servers). If the mguard is located within a private network, accessing those servers may fail if the firewall of the gateway to the Internet does not allow DNS queries or if the Internet is not accessible. This would have an impact on actions initiated by the mguard where a DNS name must be resolved, as for example an online firmware update, establishing a VPN connection against a DynDNS name or the download of the anti virus database. These actions may also be delayed if the responses of the public available DNS servers take too long. If the mguard is located within a private network we recommend to set Servers to query = User defined and to enter the IP address of the DNS server. From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select User defined. Enter the IP address of the DNS server of the network. Document ID: UG206002508-017 Page 11 of 95
6 mguard operating as DSL Router (PPPoE Mode) In this example, we will use the mguard as DSL Router (PPPoE mode) for connecting the company s network to the Internet through a DSL modem. The following diagram illustrates the machines and addresses involved in the connection. 6.1 Replacing an existing DSL Router with the mguard Follow these steps if you want to replace an existing DSL router with the mguard in an already configured environment: Write down the internal IP address of the DSL router. You will need it later. In our example, the IP address is 192.168.1.254. Replace the DSL router with the mguard. Connect one single client to the internal interface of the mguard. The mguard (except mguard delta and mguard blade control unit) is in Stealth mode if you did not preconfigure it before installation. In this case you can access the mguard from the web browser through https://1.1.1.1. The default gateway can t be reached anymore due to the replacement of the DSL router. Therefore you need to perform the following steps on the client you use for configuring the mguard: º Open a DOS prompt. º Execute the command: arp a. This command lists all existing arp entries. If the IP address of the router appears in this list (in our example: 192.168.1.254) you need to delete this entry by using the command: arp d <IP address> (in our example: arp -d 192.168.1.254). º Now you need to assign a static MAC address to the IP address of the default gateway with the command: arp s <IP adresse> 00-aa-aa-aa-aa-aa (in our example: arp -s 192.168.1.254 00-aa-aa-aa-aa-aa). After doing this, you can access the mguard from the web browser through https://1.1.1.1 and configure it. Restart the switch for deleting possibly cached arp entries after configuring the mguard and reconnecting the internal network to the mguard. Document ID: UG206002508-017 Page 12 of 95
6.2 Configuring the Interfaces From the menu, select Network -> Interfaces, tab General. Network Mode Network Mode PPPoE PPPoE Login PPPoE Password Automatic Re-connect? Re-connect daily at Internal Networks Internal IPs Secondary External Interface Not required for this setup. Select PPPoE. Enter the user name you have received from your Internet Service Provider (ISP) for accessing the Internet. Enter the password you have received from your Internet Service Provider (ISP) for accessing the Internet. If this option is enabled, the mguard will reconnect to the ISP every day at the specified time. This feature allows moving the 24 hour reconnect of the DSL line outside the office hours. Using this feature requires that the system time was either entered manually on the mguard or synchronized with an NTP server. Enter the internal IP of the mguard into the field IP and the appropriate Netmask. The IP address must belong to the internal network. If you have replaced an existing DSL router, enter the IP setting used previously by the DSL router, in our example 192.168.1.254/255.255.255.0. Usually this IP address needs to be entered as default gateway on the clients. The mguard will reboot automatically after applying the changes due to the change of the network mode from Stealth to PPPoE. After the reboot you have access to the mguard through https://<internal IP of the mguard>, in our example: https://192.168.1.254. Document ID: UG206002508-017 Page 13 of 95
6.3 Network Address Translation (NAT) You must activate Network Address Translation (NAT) for gaining access to the Internet. From the menu, select Network Security -> NAT, tab Masquerading. Network Address Translation/IP Masquerading Outgoing on Interface Select External. From IP Enter the network and the appropriate subnet mask in CIDR-notation (e.g. 255.255.0.0 = 16, 255.255.255.0 = 24, 255.255.255.255 = 32) into the field From IP. A value of 0.0.0.0/0 means that all internal IP addresses will have access to the Internet (assuming an outgoing firewall rules allows this access). If only a special subnet should have access to the Internet, enter this subnet and the appropriate subnet mask (e.g. 192.168.1.0/24). If only one client should have access to the Internet, enter its IP address and the value 32 as subnet mask (e.g. 192.168.1.100/32). 1:1 NAT Not required for this setup. 6.4 DNS Server From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select Provider defined. Not required for this setup. 6.5 Required IP Settings on the Clients If the clients use static IP settings, you need to specify the internal IP of the mguard as default gateway and as DNS name server, in our example 192.168.1.254. Document ID: UG206002508-017 Page 14 of 95
6.6 DynDNS Registration If the mguard has a dynamic public IP address, it could be necessary that the mguard registers its public IP address under a fixed name in a DynDNS service. This could be the case for example: If you need remote HTTPS access to the device. If a VPN connection should be established to the device. If Pre-Shared Key (PSK) should be used for authentication in the VPN configuration. In the following screenshot, the mguard should register its public IP address under the name mguard in the DynDNS service dyndns.org. From the menu, select Network -> DNS, tab DynDNS. Document ID: UG206002508-017 Page 15 of 95
7 mguard operating as Router (Router Mode) The mguard shall be used as router between two different networks. The following diagram illustrates the machines and addresses involved in this configuration. The examples used in this chapter are taken from this setup. 7.1 Configuration of the Clients Internal network The clients of the internal network may either use static IP settings or receive them from the mguard (internal DHCP server) or from a DHCP server of the external network (DHCP relay) or from a DHCP server of the internal network. The clients of the internal network should use the internal IP address of the mguard as default gateway. External network The clients of the external network may either use static IP settings or receive them from the mguard (external DHCP server) or from a DHCP server of the internal network (DHCP relay) or from a DHCP server of the external network. Document ID: UG206002508-017 Page 16 of 95
7.2 Configuration of the mguard 7.2.1 Configuring the Interfaces From the menu, select Network -> Interfaces, tab General. Network Mode Network Mode External Networks Obtain external configuration via DHCP External IPs Additional External Routes IP of default gateway Internal Networks Internal IPs Additional Internal Routes Secondary External Interface Not required for this setup. Select Router. Enable this option, if the mguard should receive its external IP settings from a DHCP server. Otherwise you need to configure the external IP settings manually. Enter the external IP address of the mguard and the appropriate Netmask, in our example 10.1.0.64/255.255.0.0. Will be explained in the next chapter. Enter the IP address of the default gateway of the external network. Enter the internal IP of the mguard into the field IP and the appropriate Netmask. The IP address must belong to the internal network. This IP address should be specified as default gateway on every client of the internal network. Will be explained in the next chapter. Document ID: UG206002508-017 Page 17 of 95
7.2.1.1 Additional internal/external Routes If the internal network of the mguard contains another subnet, the mguard must know to which gateway packets addressed to the subnet need to be directed. This is achieved with the option Additional Internal Routes. In the following example an additional internal route needs to be defined for the network 192.168.2.0/24 with the gateway 192.168.1.1. Note: Do never specify an additional internal route with a gateway located in the external network or vice versa. This could cause a routing problem on the mguard. 7.2.2 Network Address Translation (NAT) Activate NAT if required. You need to activate NAT for example if the route to the internal network of the mguard is unknown to the external network. From the menu, select Network Security -> NAT, tab Masquerading. Network Address Translation/IP Masquerading Outgoing on Interface Select External. From IP Enter the network and the appropriate subnet mask in CIDR-notation (e.g. 255.255.0.0 = 16, 255.255.255.0 = 24, 255.255.255.255 = 32) into the field From IP. A value of 0.0.0.0/0 means that all internal IP addresses will have access to the Internet (assuming an outgoing firewall rule allows this access). If only a special subnet should have access to the Internet, enter this subnet and the appropriate subnet mask (e.g. 192.168.1.0/24). If only one client should have access to the Internet, enter its IP address and the value 32 as subnet mask (e.g. 192.168.1.100/32). 1:1 NAT Not required for this setup. Document ID: UG206002508-017 Page 18 of 95
7.2.3 Internal DHCP Configuration You need to configure the internal DHCP service if the clients of the internal network should receive their IP settings from the mguard or from a DHCP server which is located in the external network (DHCP relay). From the menu, select Network -> DHCP, tab Internal DHCP. 7.2.3.1 DHCP Server for the internal Network Mode DHCP Mode DHCP Server Options Enable dynamic IP address pool DHCP lease time DHCP range start DHCP range end Local netmask Broadcast address Default gateway DNS server WINS server Static Mapping Select Server. Enable this option if the clients should receive their IP address from the pool DHCP range start to DHCP range end. Disable this option if the assignment should be done statically based on the MAC address (refer to Static Mapping). Validity of the assigned IP settings in seconds. Start and end of the IP address range from which IP addresses will be assigned dynamically to the clients. Netmask to be used by the clients. Broadcast address to be used by the clients. IP address of the default gateway used by the clients. Usually this is the internal IP address of the mguard. IP address of the Domain Name Service (DNS) server which shall be used by the clients for resolving hostnames into IP addresses and vice versa. Enter the internal IP address of the mguard if the DNS service of the mguard shall be used. IP address of the WINS server which shall be used by the clients for resolving hostnames into IP addresses and vice versa, using the Windows Internet Naming Service (WINS). Use Static Mapping to assign fixed IP addresses to clients depending on their MAC address. When doing this, consider the following: º Statically assigned IP addresses have a higher priority than the dynamic IP address pool. º Static IP addresses and pool addresses must not overlap. Do not assign the same IP address to several MAC addresses. Otherwise the same IP address will be assigned to several clients. Document ID: UG206002508-017 Page 19 of 95
7.2.3.2 DHCP Relay Use DHCP relay if the clients of the internal network should receive their IP addresses from a DHCP server which is located in the external network. Mode DHCP mode DHCP Relay Options DHCP Servers to relay to Append Relay Agent Information (Option 82) Select Relay. Enter the IP address of the DHCP server of the external network. Enable this option if additional information for the DHCP server according to RFC 3046 should be appended. Note: The mguard must have a static external IP address when using DHCP relay and an according route to the internal network must be defined on the DHCP server. Document ID: UG206002508-017 Page 20 of 95
7.2.4 External DHCP Configuration You need to configure the external DHCP service if the clients of the external network should receive their IP settings from the mguard or from a DHCP server which is located in the internal network (DHCP relay). The required settings are according to the previous chapter and need to be configured through the menu Network -> DHCP, tab External DHCP. 7.2.5 DNS Sever You need to specify a DNS server if: The mguard itself needs to resolve hostnames, as it is the case for: o Anti Virus pattern downloads. o Applying online updates. o Requesting licenses from the device online. o Online license reload. o Resolving DynDNS names for establishing VPN connections. The clients of the internal network have the internal IP address of the mguard specified as DNS server. From the menu, select Network -> DNS, tab DNS Server. DNS Servers to query User defined name servers Select User defined. Enter the IP address of the DNS server of the external network. Document ID: UG206002508-017 Page 21 of 95
8 Firewall 8.1 Incoming/Outgoing Firewall The incoming and outgoing firewall is configured through the menu Network Security -> Packet Filter, tabs Incoming Rules and Outgoing Rules. Outgoing rules are applied to packets from the internal (trusted) network directed to the external (untrusted) network, incoming rules to packets from the external (untrusted) to the internal (trusted) network. 8.1.1 Basic Guidelines for setting up the Firewall Keep the following guidelines in mind when setting up the firewall: The specified firewall rules will be checked one by one, starting with the first rule. If one rule matches the criteria, no matter whether the action is Reject, Accept or Drop, the subsequent rules will not be considered. Specified ports ( From Port and To Port ) are only considered if protocol is set to TCP or UDP. 8.1.2 Example of a wrongly configured Firewall In this example, access to HTTP servers should not be granted to the employees. The settings above contain a couple of errors: Line #1: The specified firewall rules will be checked one by one, starting with the first rule. If one rule matches the criteria, no matter whether the action is Reject, Accept or Drop, the subsequent rules will not be considered. The first rule will match in any case. Therefore the second rule will never be checked removing it would have the same effect. The order of the two rules needs to be changed. Line #2 From Port =80: HTTP requests issued by a web browser usually use a port number above 1024 and send their requests to port number 80. This rule will not have any effect due to From Port=80. In this case you need to specify From Port=any and To Port=80. The correct configuration would be: Document ID: UG206002508-017 Page 22 of 95
8.2 Sets of Rules Starting with version 5 summarizing firewall rules to a Set of Rules is supported. A Set of Rules can be specified as Action when configuring the incoming and/or outgoing firewall. Let s take a look at the following example: The incoming firewall should allow ftp, telnet and https access only to the servers 192.168.1.1, 192.168.1.23 and 192.168.1.145. In previous releases you needed to configure nine incoming firewall rules for allowing the access. Using a Set of Rules, which summarizes either the allowed protocols or the IP addresses of the target machines, will result in six firewall rules. Example 1: Set of Rules summarizes the IP addresses of the target machines The set is called Servers and allows the access to the target machines. The incoming firewall rules allow the access for the specified services (ftp, telnet and https) and refer to the Set of Rules with the name Servers (Action = Servers) which grants the access to the target machines. Document ID: UG206002508-017 Page 23 of 95
Example 2: Set of Rules summarizes the allowed services The set is called Allowed Access and allows the access for the specified services. The incoming firewall rules allow the access to the target machines and refer to the Set of Rules with the name Allowed Access (Action = Allowed Access) which grants the access for the specified services. Document ID: UG206002508-017 Page 24 of 95
8.3 MAC Filtering MAC filtering is configured through the menu Network Security -> Packet Filter, tab MAC Filtering. 8.3.1 Basic Rules for setting up MAC filtering The MAC filter is stateless in contrast to the IPv4 stateful inspection firewall. This means that rules must be defined for both directions, incoming and outgoing. If no MAC filter rules are applied, IPv4 and ARP frames are allowed to pass in both directions. All other Ethernet frames are dropped. IPv4 frames are always filtered additionally according to the IPv4 stateful inspection firewall rules defined for incoming and outgoing traffic. If the MAC filter allows other Ethernet frames than IPv4 and ARP, no filtering except for the MAC address will take place. All ARP and IPv4 frames will pass the MAC filter by default. If the MAC filter should restrict the access for specific MAC addresses then you need to define a final rule for IPv4, which rejects everything else. If not using statically configured ARP tables on your devices, all IP traffic will require ARP address resolution first, this may as well include the administrative access to the mguard. Therefore, restrictions to ARP traffic should be used with special care. xx is used as wildcard: º xx:xx:xx:xx:xx:xx means all MAC addresses. º 00:0c:be:xx:xx:xx means all MAC addresses which start with 00:0c:be. Note: MAC filtering is only supported for the Stealth mode. Document ID: UG206002508-017 Page 25 of 95
8.3.2 Examples MAC Filter Configuration 8.3.2.1 Novell IPX In the following example Novell IPX protocol should pass the mguard. The MAC filter is stateless in contrast to the IP firewall. Therefore, incoming and outgoing rules need to be defined for allowing the traffic in both directions. Source MAC = Destination MAC = xx:xx:xx:xx:xx:xx: No restriction on the MAC address should be applied. The hexadecimal value of the Novell IPX protocol is 8137, which needs to be entered as Ethernet Protocol. Document ID: UG206002508-017 Page 26 of 95
8.3.2.2 Restricted IPv4 Access In the following example the access through the IPv4 protocol should be allowed only for the machines of the external network which MAC addresses start with 00:0c:be. The MAC filter is stateless in contrast to the IP firewall. Therefore, incoming and outgoing rules need to be defined. Only MAC addresses from the external network which start with 00:0c:be should be granted access to the internal network. We need to specify 00:0c:be:xx:xx:xx as Source MAC for the incoming rule and as Destination MAC for the outgoing rule. The restriction should be applied for the IPv4 protocol. IPv4 needs to be entered as Ethernet Protocol. All ARP and IPv4 frames will pass the MAC filter by default. That s why we need to specify a second incoming and outgoing rule, which drops IPv4 packets from all other MAC addresses than specified in the first rules. If a packet was sent from a MAC address starting with 00:0c:be, the first rule will match and the access to the internal network is granted (assuming, that there is also an incoming firewall rule defined which does not block the packet). If the packet was sent by any other MAC address, the second rule will match and drop the packet. Document ID: UG206002508-017 Page 27 of 95
8.4 1:1 NAT Note: 1:1 NAT is not supported for the Stealth mode. 1:1 NAT can be used for connecting several subnets with the same network to the main network. In the following example two production sites, which use the same network 192.168.1.0/24, shall be connected to the corporate network with the network 10.1.0.0/16. The major advantage of using 1:1 NAT is that no additional routes need to be defined in the corporate network. An ARP daemon on the mguard ensures that routers of the external network know where to send packets directed to the internal network. The systems of the production sites can be reached directly from the corporate network through their mapped IP addresses. Both mguards have external IP addresses which belong to the corporate network (10.1.0.100 and 10.1.0.101). It is not a typo that the corporate network has a netmask of 16 and that a netmask of 24 is specified in the 1:1 NAT rule. Due to the flat netmask of the corporate network it is possible to use the virtual network 10.1.1.0/24 for accessing the systems of production site 1 and 10.1.2.0/24 for accessing the systems of production site 2. An ARP daemon on the mguard ensures that routers of the corporate network know where to send packets addressed to the networks 10.1.1.0/24 and 10.1.2.0/24. The client 192.168.1.10 of production site 1 can be reached from the corporate network by using the IP address 10.1.1.10, client 192.168.1.11 with the IP address 10.1.1.11, etc. The client 192.168.1.10 of production site 2 can be reached from the corporate network by using the IP address 10.1.2.10, client 192.168.1.11 with the IP address 10.1.2.11, etc. Of course, clients of production site 2 may also be reached from production site 1 through their mapped IP address and vice versa. Document ID: UG206002508-017 Page 28 of 95
1:1 NAT is configured through the menu Network Security -> NAT and mirrors addresses from the internal network to the external network. Depending on the specified netmask, the network address is masqueraded and the host address will be kept unchanged. In the following example, the mguard works as router between the networks 192.168.1.0/24 (internal) and 10.1.0.0/16 (external) and has the following 1:1 NAT rule defined. The virtual network 10.1.1.0/24 is used for accessing the internal network. The 1:1 NAT rule will cause the following masquerading: Internal External 192.168.1.1 <-> 10.1.1.1 192.168.1.2 <-> 10.1.1.2 192.168.1.3 <-> 10.1.1.3 192.168.1.254 <-> 10.1.1.254 For example, the client of the internal network with the IP address 192.168.1.27 can be reached from the external network using the IP address 10.1.1.27. Document ID: UG206002508-017 Page 29 of 95
8.5 User Firewall The User Firewall allows defining user specific firewall rules. The firewall rules are defined within User Firewall Templates and the users to which the firewall template should be applied must be assigned to the template. The user needs to log onto the device through HTTPS for activating the firewall rules. This can be done either from the internal or from the external network. Log onto the device from the external network requires that HTTPS remote access is enabled (menu Management -> Web Settings, tab Access). The mguard detects automatically through which interface the login happened and applies the firewall template to the incoming (login from the external network) or outgoing (login from the internal network) firewall. The login can only happen through one of the interfaces specified in the tab Access. The authentication of the user can be done either on the mguard locally (the passwords are stored on the mguard) or through a RADIUS server. In this example we want to setup a User Firewall which allows HTTP and FTP access for the users user1, user2, user3 and user4. 8.5.1 Configuring Remote Users From the menu, select Authentication -> Firewall Users, tab Firewall Users. Users Enable user firewall Enable group authentication Username Authentication Method User Password Enable this option for activating the user firewall. Group authentication makes the administration of the firewall users easier because not every single user needs to be specified on the mguard. If a user logs onto the device without being defined as firewall user, the mguard will send a request to the RADIUS server for the verification of the user. If the RADIUS server grants the access with an Access Accept packet and if this packet contains the attribute Filter-ID = <group name>, all firewall users will be accepted which belong to the group <group name>. Note: When configuring the User Firewall you need to enter the name of the group as Template User. Enter the name of the user. Select either RADIUS, if the authentication of the user should be done through a RADIUS server, or Local DB (the passwords will be stored on the mguard locally). If you have chosen RADIUS, you need to configure the RADIUS server in the tab RADIUS Servers. Otherwise the user s password needs to be entered in the column User Password. Enter the user s password if Local DB is selected as Authentication Method. Document ID: UG206002508-017 Page 30 of 95
8.5.2 RADIUS Servers If the remote user should be authenticated by a RADIUS server, configure the RADIUS server. Switch to the tab RADIUS Servers. RADIUS Servers RADIUS timeout RADIUS retries Server Port Secret Determines the time (in seconds) the mguard will wait for a response from the RADIUS server. Determines how often the mguard will send the request to the RADIUS server if the timeout was exceeded. IP address of the RADIUS server. Port number used by the RADIUS server. RADIUS server password. 8.5.3 Configuring the User Firewall From the menu, select Network Security -> User Firewall. Click New, enter a descriptive name for the firewall template and click Edit. 8.5.3.1 General Settings Options Enabled Comment Timeout Timeout type Select Yes for enabling the firewall template. You can enter an explanatory text which describes the template. Indicates the time in seconds at which point the firewall rules will be deactivated. If the user session lasts longer than the timeout defined here, the user will have to repeat the login process. Select whether the specified Timeout should be applied statically or dynamically. Note: After the log out the user can t establish new connections but he still can use already existing connections as long as they exist in the connection tracking table. Document ID: UG206002508-017 Page 31 of 95
8.5.3.2 Template Users Enter the names of users to which the firewall template should be applied. The names must correspond to those defined in the menu User Authentication -> Remote Users. If you have enabled Group Authentication, you need to enter the name of the group. 8.5.3.3 Firewall Rules The mguard determines automatically if the firewall template needs to be applied to the incoming or outgoing firewall, depending on whether the remote user logs in from the external or internal network. Firewall rules Source IP Protocol From Port To IP To Port Comment Log If %authorized_ip is specified, the firewall rules will be applied to data packets which were sent from the same machine (source IP address) from which the remote user has logged in. Data packets from other IP addresses will be dropped. If an IP address is specified, the firewall rules will be applied to data packets which were sent from this (source) IP address. Data packets from other IP addresses will be dropped. This option should be used for example if an administrator logs onto the device for enabling the user firewall for a technician who works on a different machine. Select All, TCP, UDP or ICMP. Specify the source port of the requests. This can be either any which means every port or a special port number or a range of ports (startport:endport). Port entries are only evaluated if Protocol is set to TCP or UDP. Use this field for restricting the access to a special subnet (e.g. 192.168.1.0/24) or to a single machine (e.g. 192.168.1.100/32). Specify the destination port of the requests. This can be either any which means every port or a special port number or a range of ports (startport:endport). Port entries are only evaluated if Protocol is set to TCP or UDP. Enter here an explanatory text. Select if data packets which match the rule shall be logged. Document ID: UG206002508-017 Page 32 of 95
8.5.4 Activating the User Firewall The remote user needs to log onto the mguard through https for activating the User Firewall. He needs to provide his username and password for the log in and set Access Type to User Firewall. A message in the log in screen informs the user if the log in succeeded. Document ID: UG206002508-017 Page 33 of 95
9 Redundancy 9.1 Router Redundancy (Router Mode) The redundancy feature allows two mguards to operate as one virtual router. A virtual IP address is shared among the mguards, with one designated as the master router and the other as backup. In case the master fails, the virtual IP address is mapped to the backup mguard s IP address. This backup becomes the master router. The state of the stateful firewall is synchronized between both mguards, so that in case of a fail over already existing connections will not be interrupted. The master sends messages using the Virtual Router Redundancy Protocol (VRRP) to the backup through the internal and external interface. The backup becomes the master if such messages are not received through the internal or external interface. Two mguards shall be configured to work as a redundant router. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Both mguards were configured in Router mode with static internal and external IP settings. We have used as virtual internal IP 192.168.1.254/24 and as virtual external IP 10.1.80.1/16. Devices connected to the internal network of the virtual router configuration must use the internal virtual IP as default gateway, in our example 192.168.1.254. Note: A VPN connection can not be established to the virtual external IP. Document ID: UG206002508-017 Page 34 of 95
9.1.1 Configuration of the Interfaces The following screenshot shows the configuration of the interfaces of both mguards (menu Network -> Interfaces). Both mguard were configured to use static external and internal IP settings. The options Use VLAN and VLAN ID were disabled and are not displayed in the screenshot. Document ID: UG206002508-017 Page 35 of 95
9.1.2 Redundancy Configuration Redundancy is configured through the menu Redundancy -> Firewall Redundancy. The following screenshot displays the redundancy configuration of both mguards. General Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase Virtual Router ID External IP of the 2 nd device Router Mode Internal Virtual Router ID Internal IP of the 2 nd device External virtual IP Internal Virtual IP Redundancy State displays which mguard currently acts as Master and which one as Backup. In the above example mguard 1 is the Master, mguard 2 the Backup. If mguard 1 would fail for some reasons then mguard 2 will become the Master. Must be enabled on both mguards. You should activate redundancy as last step after configuring the redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when the redundancy feature is activated. Priority defines which mguard will operate as Master. If the priorities are different, the mguard with the higher priority will operate as Master as long as there is no failure. If both mguards have the same priority and the Backup becomes the Master, it will continue working as Master, even if the other mguard becomes available again. The Authentication passphrase protects against misconfiguration among different virtual router configurations. The password must be the same on both mguards which form a virtual router. It will be transmitted in clear text and shouldn t be identical with other security relevant passwords. The Virtual Router ID identifies the virtual router and must be the same on both mguards. If there are several virtual router configurations in your network then each pair of mguards which build a virtual router must use the same Virtual Router ID but it must be different to other virtual router configurations. Enter the external IP of the other mguard, on mguard 1 the external IP of mguard 2 and vice versa. The Internal Virtual Router ID identifies the virtual router on the internal interface and must be the same on both mguards. Enter the internal IP of the other mguard, on mguard 1 the internal IP of mguard 2 and vice versa. External virtual IP specifies the external virtual IP of the virtual router configuration, in our example 10.1.80.1. Internal virtual IP specifies the internal virtual IP of the virtual router configuration, in our example 192.168.1.254. Devices connected to the internal network of the virtual router configuration should specify this IP address as default gateway. Document ID: UG206002508-017 Page 36 of 95
9.2 Firewall Redundancy (Multi Stealth Mode) Two mguards shall be configured to work as a redundant firewall. The following diagram illustrates the machines and addresses involved in the configuration. The examples used in this chapter are taken from this setup. Both mguards were configured to operate in Multi Stealth mode with a configured Management IP. In our example mguard 1 uses the Management IP 10.1.80.100 and mguard 2 10.1.80.101. Defined firewall rules must be the same on both devices. Note: It is not possible to gain access to the mguard through https://1.1.1.1 if a Management IP was specified. In this case you need to specify the Management IP for gaining access to the mguard. Document ID: UG206002508-017 Page 37 of 95
9.2.1 Configuration of the Interfaces The following screenshot shows the configuration of the interfaces of both mguards (menu Network -> Interfaces). Both mguards were configured to operate in Multi Stealth mode with an assigned Management IP. mguard 1 uses the Management IP 10.1.80.100, mguard 2 10.1.80.101. Document ID: UG206002508-017 Page 38 of 95
9.2.2 Redundancy Configuration Redundancy is configured through the menu Redundancy -> Firewall Redundancy. The following screenshot shows the redundancy configuration of both mguards. General Redundancy State Enable Redundancy Redundancy State Start Priority Authentication passphrase Virtual Router ID Management IP of the 2 nd device Router Mode Not required for this setup (ignored in Stealth mode). Redundancy State displays which mguard currently acts as Master and which one as Backup. In the above example mguard 1 is the Master, mguard 2 the Backup. If mguard 1 would fail for some reason then mguard 2 will become the Master. Must be enabled on both mguards. You should activate redundancy as last step after configuring the redundancy on both devices. This option specifies which mguard should act as Master and which one as Backup when the redundancy feature is activated. Priority defines which mguard will operate as Master. If the priorities are different, the mguard with the higher priority will operate as Master as long as there is no failure. If both mguards have the same priority and the Backup becomes the Master, it will continue working as Master, even if the other mguard becomes available again. The Authentication passphrase protects against misconfiguration among different redundant firewall configurations. The password must be the same on both mguards which form a redundant firewall. It will be transmitted in clear text and shouldn t be identical with other security relevant passwords. The Virtual Router ID identifies the redundant firewall configuration and must be the same on both mguards. If there are several redundant firewall configurations in your network then each pair of mguards which build a redundant firewall must use the same Virtual Router ID but it must be different to other redundant firewall configurations. Enter the Management IP of the other mguard, on mguard 1 the Management IP of mguard 2 and vice versa. Document ID: UG206002508-017 Page 39 of 95