Berlin, – mGuard & IDM Training

- 2 - Day 1 Industrial Grade IT Security And Secure Remote Service Day 2 mGuard Basics & Firewall Setup Day 3 mGuard VPN Configuration Day 4 mGuard Device Manager mGuard Licenses and Updates Day 5 CIFS Integrity Monitoring Q&A / Further Topics Agenda

IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

- 4 - IP Address & Subnet Mask

- 5 - An IP address is a 32 bit value which identifies uniquely a system which is connected to a TCP/IP network Usually an IP address is written in the form of four decimal values, separated by dots (Dotted Decimal Notation). Each decimal value represents an 8 bit part of the 32 bit address A B C D = A.B.C.D IP Address & Subnet Mask

- 6 - An IP address consists of a network part and a host part. The subnet mask specifies what portion of the IP address is used to represent the network and what portion is used to represent hosts (other computers) on the network. The subnet mask is also a 32 bit value written in Dotted Decimal Notation (as the IP address). A 1 in the subnet mask means that the corresponding bit of the IP address belongs to the network, a 0 means that it belongs to the host. Subnet mask = = IP address = = Network Host IP Address & Subnet Mask

- 7 - Instead of writing the IP address and the subnet mask in Dotted Decimal Notation ( / ), the subnet mask is often written in Classless Inter Domain Routing (CIDR) notation ( /24). "/n" is called the IP prefix or network prefix. The IP prefix identifies the number of significant bits (leading bits with the value 1) used to identify a network. IP Address & Subnet Mask Subnet mask (dot notation) Binary value CIDR / / / / / / / / / / / /21 … … …

- 8 - Does the IP address /12 belong to the network /12? Subnet mask = /12 = The answer is YES: The network parts of the network /12 and of the IP address /12 are the same. Therefore the IP address /12 belongs to the network /12. IP Address & Subnet Mask Network Host Network = = IP Addr. = =

- 9 - The subnet mask also determines how many hosts can be located in the network. The first IP address in a network (all host bits = 0) is the network address and the last IP address (all host bits = 1) is always the broadcast address. Both addresses should not be assigned to hosts. The broadcast address is used if a request needs to be send to all hosts of the network. IP Address Binary value Used for / Network Address / Hosts / / … … / / / / Broadcast Address IP Address & Subnet Mask

What are private IP addresses? The private IP address space is defined by RFC1918. In this RFC, it says that no public device will use or recognize the following IP addresses: /8: to /12: to /16: to These ranges of IP addresses are available for anyone to use on their own internal (private) network. When making a request to the Internet, that private IP address must be converted into a public IP address. Network Address Translation (NAT) is what performs this public-to-private translation. IP Address & Subnet Mask

If you want to access devices outside of your local network (such as devices on the Internet or another private network), a default gateway is required. A default gateway is where a computer sends requests to IP addresses that are not on its local network. How does the computer know what is and what is not on its local network? As discussed above, the subnet mask is what the computer uses to know what is and what is not on its local network. The default gateway must always be located in the same local network as the client. Default Gateway

Example: Client IP = / (/24) The network is /24. Anything that is through is on the local network. Packets directed to any other IP address do not belong to the local network and would be sent to the default gateway. Default Gateway Internet Web Server Private Network / Gateway:

Internet Web Server mGuard NAT Private Network / SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: Masq The NAT device replaces the senders private IP address by its public (external) IP address. When receiving the response, the public IP address of the NAT device is replaced by the private IP address of the sender. Network Address Translation (Masquerading)

:1 NAT What is 1:1 NAT? 1:1 NAT means mapping the network part of an IP address to another network and keeping the host part unchanged. Subnet mask: (/24) (/24) IP address: Of course 1:1 NAT can only be applied to networks with the same subnet mask / / 24OK / x / 25Wont work 1:1 NAT

IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

Product Overview Security Firewall VPN Integrity Monitoring Event Management Remote Logging SNMP Core Hardened Linux Web Interface mGuard bladePack mGuard rs2000 mGuard rs4000 mGuard smart mGuard smart ² Device Management Firmware Hardware Appliances mGuard industrial RS mGuard PCI Innominate Device Manager (IDM) Template-based Configuration Device-oriented Structure Integrated Certificate Authority (CA) Efficient, automated Roll-out Config Push & Pull Status Control mGuard centerport

Installation - mGuard smart / mGuard smart² The mGuard smart² is supported starting with firmware version Configurable serial console through USB port (mGuard smart² only). LAN WAN USB plug Rescue Button

Installation - mGuard PCI, Power-over-PCI Mode An additional software driver is not required. The PCI interface is only used as power supply. Another network interface card (same or another computer) is required. The LAN jack of the mGuard must be connected to another NIC using an Ethernet cable. LAN WAN NIC mGuard PCI External Network Rescue Button

Installation - mGuard Industrial RS External Network WAN LAN Power Rescue Button Lower Terminal Block

Installation - mGuard Industrial RS External Network Lower Terminal Block

Installation - mGuard rs2000/4000 External Network The mGuard rs2000/4000 is supported starting with firmware version Usage of the SD card: Save/restore a configuration Flash the mGuard with the firmware LAN Power Rescue Button WAN SD Card Service 2 Contact Service 1

Configuration Access - Factory Defaults Possibility 1: (classic way) Possibility 2: (Management IP) Possibility 3:Assign IP address using BOOTP ProductNetwork modeInternal IP addressAccess from the internal network mGuard smart mGuard PCI mGuard industrial RS mGuard blade mGuard rs2000 mGuard rs4000 Stealth (multi-clients) or BOOTP assigned IP or or Through BOOTP assigned IP

Configuration Access - Factory Defaults User: admin, password: mGuard User: root, password: root Configuration access: Through the console via the serial port (e.g. HyperTerminal) Bits per Second: Data Bits: 8 Parity: None Stop bits: 1 Flow control: None Through the WebUI or through the console via SSH Router mode: Stealth mode: (or using EIS) From the internal network, SSH and HTTPS access are always granted if they werent explicitly rejected by HTTPS/SSH access rules

IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

mGuard configuration options Network Management System Web interface Terminal / Script Web server mGuard Device Manager https ssh snmp

mGuard Menu Overview Remote access, time & date, language selection, updates, licenses, SNMP Network mode, interface configuration, NAT Passwords, certificates, RADIUS authentication Firewall VPN Quality of Service Firewall Redundancy Logging Support tools

mGuard Menu Overview Hostname, time & date, remote SSH access Language selection, remote HTTPS access Overview about installed licenses, license installation Firmware updates Save/restore/download/upload/activate mGuard configurations SNMP management access and SNMP traps Central management of remote mGuards (http(s) pull) Reboot of the device Network mode and interface configuration Network address translation (NAT), port forwarding DNS-Configuration DHCP-Server Settings Proxy-Configuration of the mGuard

mGuard Menu Overview Local used passwords (root/admin/user), RADIUS filters User Firewall Users RADIUS server configuration Certificate management Incoming/outgoing firewall Denial of service protection User Firewall configuration Global VPN settings Configuring VPN connections Layer2-Tunnel-Protocol Status of configured VPN connections

mGuard Menu Overview Redundancy configuration Redundancy status information Remote logging Display log entries (system, VPN, firewall, etc) Support tools (ping, traceroute, etc) Hardware information, snapshot download

General Settings Menu Management >> Web Settings, tab General Supported languages are: [Automatic, one of the following named languages], English, German and Japanese. Scope of the Apply button = per Page: The Apply button needs to be pressed before switching to another menu for storing the changes. Scope of the Apply button = per Session: Using this option is only advisable for someone who is really familiar with the mGuard and its configuration. This option allows to switch to other menus for making a complete configuration of the mGuard and to apply the changes as really last step.

IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

The mGuard supports the following network modes, which are explained in the next slides: Stealth Mode Autodetect (also called Single Stealth mode) Static (also called Single Stealth mode) Multiple Clients (also called Multi Stealth mode) Router Modes Router PPPoE / PPTP Modem / Built-In Modem Network Modes - Overview

Network Modes The network mode is configured through the menu Network -> Interfaces, tab General. This menu also displays information about the current network status. 33

34 Single Stealth (autodetect/static) mode: Protect one single entity without the need to apply changes to the IP settings of the network. Multi Stealth mode: Protect several entities without the need to apply changes to the IP settings of the clients. The mGuard supports the following network modes (cont.) Network: / Network: / Network Modes – Stealth Mode

35 Network Modes – Stealth Mode How does the Stealth Mode (autodetect) work? Prerequisites: A default gateway must be specified on the client and the gateway must be reachable. The mGuard obtains its configuration (IP address and MAC address of the client) the first time when the client generates traffic through the mGuard. Use Static Stealth if the client does not generate any traffic by itself (e.g. server, web-cam). In this case you cant use autodetect because the mGuard will never get its configuration. The mGuard checks continuously if the IP of the client has changed by analyzing the outgoing data packets. If an IP address change was detected, the mGuard adopts the new IP address and restarts the depending services.

36 Network Modes – Stealth Mode Client IP: Netmask: Def. GW: Network: / Gateway IP: Netmask: mGuard Stealth Mode (autodetect) ARP-Request to ARP-Response from Packet to Packet from Message flow when accessing the mGuard through the IP

ARP resolution in Stealth mode 37 Network Modes – Stealth Mode mGuard Stealth Mode ICMP echo request from IP ICMP echo reply to IP Retrieve MAC of the gateway Send http request Internet Gateway

38 Network Modes – Multi Stealth Mode Multi Stealth (multiple clients) mode is used to protect multiple clients without loosing the advantage of the Stealth feature. You also need to use this mode if only one client is connected to the mGuard but if its NIC has more than one IP address /16

39 Network Modes – Multi Stealth Mode The mGuard adopts the IP address of the client if it is operated in autodetect or static Stealth mode. Therefore the mGuard can be accessed from the external network through the IP address of the client, assuming that HTTPS/SSH remote access is enabled. This wont work for the Multi Stealth Mode because more than one client is connected to the internal interface. A Management IP needs to be specified for accessing the mGuard from the external network. The Management IP must belong to the network and must not be used by another entity.

The mGuard supports the following network modes (cont.) Router mode: To act as router between two different networks. This mode is also used for connecting to the Internet through an Ethernet line. 40 Corporate Network: /16 Internet Ethernet Line Subnet: /24 Network Modes – Router Mode (Router)

The mGuard supports the following network modes PPPoE mode: Router between the internal network and the Internet, using the PPPoE protocol for connecting through a DSL modem to the Internet. PPTP mode: Router between the internal network and the Internet, using the PPTP protocol for connecting to the Internet (used for example in Austria). 41 Corporate Network DSL Modem Internet Network Modes – Router Mode (PPPoE/PPTP)

The mGuard supports the following network modes (cont.) Modem / Built-In Modem: 42 Corporate Network: /16 Internet Subnet: /24 Phone Line X Network Modes – Router Mode (Modem)

43 Network Modes – Router Mode – Masquerading External network: /16Internal network: / Source:

44 Network Modes – Router Mode – Port Forwarding External network: /16Internal network: / Dest: Port: 80Dest: Port: 80

45 Network Modes – Router Mode – 1:1-NAT (1/2) Corporate Network /16 Production Site /24 Production Site /24 Production Site /24 Production Site /24 mGuard 1mGuard 2mGuard 3mGuard 4

46 Network Modes – Router Mode – 1:1-NAT (2/2) Corporate Network /16 Production Site /24 Production Site /24 Production Site /24 Production Site /24 mGuard 1mGuard 2mGuard 3mGuard / / / /24

1.IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

Menu: Management -> Web Settings, tab Access By default, getting HTTPS access to the mGuard from the internal network is granted. Remote access means getting access to the mGuard from the external network, through a dial-in or VPN connection. 48 Remote Access - https

49 Remote Access - https Menu: Management -> Web Settings, tab Access 1)For gaining remote access to the mGuard, HTTPS remote access must be enabled. 2)The default HTTPS port is 443. This port can be changed if e.g. TCP traffic directed to 443 needs to be forwarded to an internal client. 12

50 Remote Access - ssh Menu: Management -> System Settings, tab Shell Access Enabling remote SSH access follows the same rules as described in the previous chapter. 1)Enable SSH remote access 2)The default SSH port is 22. This port can be changed if e.g. TCP traffic directed to port 22 needs to be forwarded to an internal client. 1 2

51 Remote Access - ssh Menu: Management -> System Settings, tab Shell Access 3)Allowed Networks rules must be specified only to get access to the mGuard from the external network. Enabling SSH remote access is sufficient to get remote SSH access to the mGuard through VPN. 4)Specify the way the user should be authenticated. 34

1.IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

Configuration Profiles Menu Management -> Configuration Profiles This menu option allows to save a current configuration under a specified name. restore an existing configuration. download a configuration (Backup!). upload a configuration. Passwords and additional licenses (e.g. Redundancy license) are not stored in the configuration file. The downloaded configuration file is an ASCII file which can be edited with a text editor.

Configuration Profiles To upload a configuration profile: Specify the filename Enter a name for the profile Click

1.IP Networking Fundamentals 2.Initial Access 3.The Web Interface 4.Operating Modes 5.Remote Access 6.Configuration Profiles 7.Central Management Agenda – mGuard Basics

Central Management Menu Management -> Central Management The mGuard can download new configurations from an HTTPS server, either in defined time intervals or time scheduled (daily or weekly). Prerequisite time scheduled upload: The system time of the mGuard must be synchronized, either by the presence of a system clock (mGuard delta) or by entering the system time manually or by synchronizing it with an NTP server.

Central Management

Firewall basics 2.Firewall configuration 3.Rulesets 4.User Firewall Agenda – mGuard Firewall

59 Firewall Basics WAN LAN Outgoing Incoming

Firewall Basics: Stateful Packet Inspection (SPI) ICMP Echo Request ICMP Echo Reply Allow ICMP (Outgoing) Connection Tracking Table TRUSTEDUNTRUSTED The SPI firewall keeps track of the state of network connections (TCP streams, UDP communication, etc.) travelling across it. The state of a connection is stored in the Connection Tracking Table (CTT) on the mGuard. If a packet is allowed in one direction, the response packet is also allowed, if there exists an according entry in the CTT, even if the firewall is configured to drop every incoming packet.

Firewall Basics: Default Settings The firewall does not only check the source and destination IP addresses and ports of the packets. For TCP connections it checks for example also the sequence number and the specified TCP flags of the packet. Factory Default Settings All incoming packets will be dropped (except VPN). All outgoing packets are allowed. VPN connections are not subject to the firewall rules. Firewall rules for each VPN connection can be defined individually when configuring the VPN connection. If no rule is defined, the firewall drops every packet.

Firewall basics 2.Firewall configuration 3.Rulesets 4.User Firewall 5.Advanced Settings Agenda – mGuard Firewall

Firewall – Incoming/Outgoing Menu Network Security > Packet Filter, tabs Incoming/Outgoing Rules If multiple firewall rules are defined, they will be searched in the order in which they are listed (from top to bottom) until a suitable rule is found. This rule will then be applied. If further down in the list there are other rules, which would also fit, they will be ignored. Port settings (From Port, To Port) are only valid for the protocols TCP and UDP.

Firewall – Incoming/Outgoing You can enter either the port number or the corresponding service name (e.g. ftp, telnet, http, etc.). A list about the supported ports and their names can be obtained on the device with the command cat /etc/services. Note: When entering IP addresses or networks, the specified subnet mask is essential /16 is the network / /24 is the network / /32 is the IP address

Firewall basics 2.Firewall configuration 3.Rulesets 4.User Firewall 5.Advanced Settings Agenda – mGuard Firewall

Menu Network Security -> Packet Filter, tab Rule Records Records of firewall rules can be defined and included to the incoming or outgoing firewall. Advanced - Firewall Rule Records

The firewall record is selected in the column Action A Rule Record may also be called by another Rule Record. Direct and indirect cycles are not accepted by the mGuard Direct cycle: Record A calls Record A. Indirect cycle: Record A calls Record B and B calls A. Advanced - Firewall Rule Records

Firewall basics 2.Firewall configuration 3.Rulesets 4.User Firewall 5.Advanced Settings Agenda – mGuard Firewall

The User Firewall allows defining user specific firewall rules. The firewall rules are defined within User Firewall Templates. 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 The mGuard detects automatically through which interface the login occurred and applies the firewall template to the incoming (login from the external network) or outgoing (login from the internal network) firewall. 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. Advanced – User Firewall

Advanced – User Firewall Configuring the User Firewall consists of the following steps: 1)Define the users to whom it should be allowed to activate the User Firewall. 2)Configure the RADIUS server if authentication should be done against a RADIUS server. 3)Specify the firewall rules.

At first the users need to be configured on the mGuard. Menu User Authentication -> Firewall Users, tab Firewall Users Authentication can be done either against a RADIUS server or on the mGuard locally. Advanced – User Firewall users

Specify through which interfaces a remote user may log onto the device for activating the user firewall. The tab Status displays information about firewall users who are currently logged in. Advanced – User Firewall users

Advanced – User Firewall templates Menu Network Security -> User Firewall, tab General Timeout type = static: The user will be logged out automatically after the time specified in Timeout expired. Timeout type = dynamic: The user will be logged out automatically after a duration of inactivity, specified by the value of Timeout.

Advanced – User Firewall templates

Advanced – User Firewall login The user needs to log onto the mGuard through https by providing his username and password for activating the User Firewall.

Firewall basics 2.Firewall configuration 3.Rulesets 4.User Firewall 5.Advanced Settings Agenda – mGuard Firewall

Menu Network Security -> Packet Filter, tab Advanced The settings affect the fundamental behavior of the firewall. Advanced Settings

Menu Network Security -> DoS Protection Advanced Settings – DoS-Protection

Menu Network Security -> Packet Filer->Advanced Advanced Settings – Connection Tracking Table

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

VPN Basics Data packets are commonly sent over the Internet unprotected and therefore do not ensure privacy (encryption) proof of identity of the sender (authentication) that data wasn't modified (integrity) that data wasn't replayed A Virtual Private Network (VPN) is a communications channel that uses encryption and authentication to protect the packet contents while transmitted over a public medium like the Internet. A VPN may also be formed within a corporations private network.

VPN Basics A packet to be sent to a remote location is first encrypted at one VPN peer. The receiving VPN peer at the remote location is responsible for decrypting the packet. Private Network Internet Private network IPsec VPN mGuard EncryptionDecryption Encrypted Data

VPN Basics Today the most commonly implemented VPN protocol is IPsec. IPsec = Internet Protocol Security Most VPN devices and clients are IPsec compliant. IPsec enables encrypted communication between peers. It can be implemented transparently into network infrastructure. IPsec is scalable from very small applications to very large networks.

VPN Basics Internet I: ISAKMP SA (key exchange) II: IPsec SA (data exchange) VPN connections are established in two phases Phase I (ISAKMP SA or IKE SA: key exchange) -VPN gateways authenticate each other -They securely negotiate an encryption key to protect Phase II Phase II (IPsec SA: data exchange) -Using key from Phase I, negotiate IPsec connection parameters

VPN Basics IKE provides three modes for the exchange of keying information and for setting up IKE security Phase I (ISAKMP SA): Main Mode or Aggressive Mode Phase II (IPsec SA): Quick Mode The mGuard uses Main Mode for the establishment of Phase I.

VPN Basics – Main Mode Main Mode: Three two-way exchanges between the initiator and the responder for establishing ISAKMP SA (Phase I) 86 InitiatorResponder #1: Header, Security Association #2: Header, Key Exchange, Nonce #3: Header, ID, Hash (Preshared Key) Header, ID, Certificate, Signature (Certificates) #3: Header, ID, Hash (Preshared Key) Header, ID, Certificate, Signature (Certificates) Unencrypted Encrypted Diffie-Hellman Group Symmetric encryption and Hash Offer proposals Select a proposal UDP 500 UDP 500 / NAT: UDP 4500 STATE_MAIN_I1 STATE_MAIN_I2 STATE_MAIN_I3 STATE_MAIN_R1 STATE_MAIN_R2 STATE_MAIN_R3

VPN Basics – Quick Mode Quick Mode (Phase II) can be used after two parties have established a secure channel using either Aggressive Mode or Main Mode. Two purposes Negotiate general IPsec security services. Generate newly keyed material. Quick mode packets are always encrypted under the secure channel (the ISAKMP SA established in phase I) and start with a hash payload that is used to authenticate the rest of the packet. Basically quick mode is a three-packet exchange.

VPN Basics – Quick Mode InitiatorResponder #1: Hash, Proposal, Nonce I, DH Public key #1: Hash, Proposal Accept, Nonce R, DH Public key #2: Header, Key Exchange, Nonces STATE_QUICK_I1 STATE_QUICK_I2 STATE_QUICK_R1 STATE_QUICK_R2 Phase 2 (Quick Mode): Tunnel negotiation, Key exchange Acknowledge

VPN Basics – IKE Ports The mGuard uses IKE port UDP 500 to establish the VPN connection. Some NAT routers fail to perform NAT originating low UDP ports. If the VPN tunnel will be established across one or more gateways that have Network Address Translation (NAT) activated, the mGuard moves IKE from UDP 500 to UDP 4500 if possible (NAT-T port floating).

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

VPN Configuration - General Address of the remote VPN gateway: If the mGuard initiates the VPN connection, enter the IP address of the remote VPN gateway. When using PSK for authentication, the IP address of the remote VPN gateway must be entered, event if the mGuard waits for the connection. Enter %any when using certificates, if the IP address of the remote gateway is dynamic or unknown and if the mGuard waits for the connection.

VPN Configuration - General Interface to use for gateway setting %any: This parameter determines on which interface the mGuard listens for incoming VPN connections (normally: External).

VPN Configuration - General Connection Startup: Initiate: The mGuard initiates the connection to the remote entity. Initiate on traffic: The mGuard initiates the connection when traffic needs to be send through the tunnel. Wait: Waits for a connection from the remote entity. This option must be selected if Address of the remote sites VPN gateway = %any.

VPN Configuration - General Type=Tunnel: For connecting the specified local and remote network through a VPN tunnel / /24

VPN Configuration – Authentication (PSK) Either Pre-Shared Secret Keys (PSK) or X.509 certificates can as authentication method. VPN connections using PSK use the IP address of the peers as VPN identifier as default

VPN Configuration – Authentication (PSK) Restrictions for using Pre-Shared Secret Keys (PSK): PSK can not be used if the connection is established across one or more gateways that have Network Address Translation (NAT) activated. In this case certificates must be used. When using PSK, %any can not be used as remote sites VPN gateway on a waiting mGuard. On each site the IP address of the remote VPN gateway must be specified.

VPN Configuration – Authentication (Certificates) Using certificates requires an installed mGuard machine certificate. The machine certificate needs to be imported through the menu Authentication -> Certificates, tab Machine Certificates. allows to download the certificate (public key). This provides an easy way to get the mGuards certificate for importing it on a remote VPN gateway.

VPN Configuration – Authentication (Certificates) Authentication with certificates can be done either against the remote certificate (Site-to-Site VPN) or against the CA certificate which was used for signing the remote certificates.

VPN Configuration - Firewall VPN specific firewall rules may be specified when configuring the VPN connection. The VPN Firewall allows restricting the access through the VPN tunnel. You may configure the VPN firewall correspondingly, if required. By default, all incoming and outgoing connections will be passed through.

VPN Configuration – IKE Options Encryption/Hash ISAKMP SA (phase I) Encryption/Hash IPsec SA (phase II) Perfect Forward Secrecy ISAKMP SA / IPsec SA lifetimes Dead Peer detection (DPD)

VPN Configuration – IKE Options Encryption/Hash Algorithms One or more combinations of encryption and hash algorithms can be specified. An SA can be established between two peers if both support the same combination.

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

Certificate Management: X.509 Certificates Symmetric encryption uses the same key to encrypt and decrypt data (e.g. Pre-Shared Key). Pre-Shared Key: complicated_like_5Dy0qoD_and_long ALICE BOB Hi Bob! Decryption ALICE BOB Hi Alice! 3-)?*r {_9Ui Hi Alice! Decryption Encryption *&^1

Certificate Management: X.509 Certificates In asymmetric encryption, encryption and decryption functions use a key pair: A private key which is known only to the owner, A public key which can be given away to the world. The keys are mathematically linked. Data encrypted with the public key can only be decrypted with the corresponding private key. A private/public key is sequence of octets but it does not contain the information to whom the key belongs: AA:FE:9A:F9:58:52:2A:89:4E:36:D5:86:FC:C5:DD:4C... The RSA algorithm is the most commonly used encryption and authentication algorithm. RSA is an encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman.

Certificate Management: X.509 Certificates Anything encrypted with the public key can only be decrypted with the corresponding private key. Since the private key is known only to the owner, this is very powerful. ALICE BOB Bobs private key Bobs public key DecryptionEncryption ALICE BOB Alices public key Alices private key Decryption Encryption Hi Bob! Hi Alice! *&^1 3-)?*r {_9Ui

Certificate Management: X.509 Certificates A private/public key is a sequence of octets but it does not contain the information to whom the key belongs: AA:FE:9A:F9:58:52:2A:89:4E:36:D5:86:FC:C5:DD:4C... The public key is given to the world encapsulated in a X.509 certificate, which binds the public key to additional information, as for example to whom the certificate belongs.

Certificate Management: X.509 Certificates A certificate is like a personal ID: it must be unique for each entity. 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 the key pair is generated: the private key and the corresponding public key. Both keys are mathematically linked. Private Key CA:A7:3F:2E:40:31:D9... Public Key 00:A4:08:EF:5E:D5:19... Certificate Common Name = mGuard Organization = Innominate Organization Unit = Support State = Germany Locality = Berlin Country Code = DE =

Certificate Management: X.509 Certificates The private key is known only to the entity. The public key is given to the world encapsulated in a X.509 certificate. Therefore two exports of the certificate are required: Export in PEM format: certificate of the entity, containing the public key. Export in PKCS#12 format: container which contains the certificate and the private key. This export is also called the Machine Certificate. PKCS#12 Export (Machine Certificate) PEM Export (Certificate) Private Key CA:A7:3F:2E:40:31:D9... Public Key 00:A4:08:EF:5E:D5:19... Certificate Common Name = mGuard Organization = Innominate Organization Unit = Support State = Germany Locality = Berlin Country Code = DE =

Certificate Management: X.509 Certificates End entity certificates must be signed by the certificate of a Certification Authority (CA certificate) to become a valid certificate (except self-signed certificates). A CA certificate is always a self-signed certificate (signed by itself). When requesting an end entity certificate from a Certification Authority, usually a certificate chain is used for signing the certificate: Root CA of the Certification Authority Companys CA User Certificate, CN=mGuard 1, O=Innominate, OU=Support User Certificate, CN=mGuard 2, O=Innominate, OU=Support

Certificate Management: X.509 Certificates Example Certificate Chain: Root CA Sub CA 1 User Certificate, CN=mGuard 1, O=Innominate, OU=Support User Certificate, CN=mGuard 2, O=Innominate, OU=Support Sub CA 2 User Certificate, CN=mGuard 3, O=Innominate, OU=Development User Certificate, CN=mGuard 4, O=Innominate, OU=Development

Certificate Management: X.509 Certificates An X.509 certificate contains the following information: Signature algorithm identifier Period of validity Subjects public key info Signature Issuer, e.g.: CN=CA, O=Innominate, OU=Support Subject, e.g. CN=mGuard, O=Innominate, OU=Support

Certificate Management: X.509 Certificates A system can determine the validity of a certificate by checking against a Certificate Revocation List (CRL). A CRL contains the serial numbers of revoked certificates. CRLs must be actualized periodically for not being outdated.

Certificate Management: XCA-Demo

Certificate Management: mGuard Menu Authentication -> Certificates. Certificate Settings/CRL: CRL support Machine Certificates: One or more machine certificates which can be used as: SSH server certificate Local certificate for VPN connections CA Certificates: Import of CA certificates Remote Certificates: Not related to VPN connections (https/ssh)

Certificate Management: mGuard Check the validity period of certificates and CRLs No: Do not check the validity of certificates and CRLs Wait for synchronization with the NTP server: Check the validity of certificates and CRLs if the time is synchronized. If the time isnt synchronized, all certificates and CRLs are considered as invalid and VPN tunnels using certificates cant be established. Enable CRL Checking = Yes: Check the validity of certificates against the CRL.

Certificate Management: mGuard One or more machine certificates can be imported. When configuring a VPN connection you need to specify which machine certificate should be used as local certificate. Download Certificate downloads the public key of the certificate.

Certificate Management: mGuard One or more CA certificates can be imported. When using CA authentication to authenticate remote VPN peers, the CA certificate which was used to sign the certificate of the remote VPN peer must be imported here.

Certificate Management: mGuard In this tab, a CRL can be uploaded manually through the Upload section. Apart of this, an URL for uploading the CRL can be specified. The upload interval is defined in the tab Certificate Settings.

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

VPN – Local 1:1-NAT Internet /24 Network ANetwork B IPSec Tunnel No routing between A and B

VPN – Local 1:1-NAT / /24 Service Network Machine 1 Routing issues when more the one tunnel is up Mix-up of remote networks /24 Plant B /24 Machine 2 Plant A

VPN – Local 1:1-NAT VPN 1:1-NAT for the local network is used for establishing VPN tunnels to other locations which use the same network IP In the following example the branch offices Berlin and Paris have the same network IP ( /24).

VPN – Local 1:1-NAT VPN 1:1 NAT for the local network takes place on the mGuards located at the branch offices. Berlin will be reached from the headquarters through /24, Paris through /24.

VPN – Local 1:1-NAT The network part of the IP address will be mapped, keeping the host part unchanged (e.g. Berlin: / /24). Headquarters, Tunnel to Berlin Berlin

VPN 1-to-1 NAT for the local network can also be used for connecting two locations through a VPN tunnel, which have the same internal network IP. Local 1-to-1 NAT needs to be enabled on both mGuards. Virtual subnets need to be used for both internal networks. VPN – Local 1:1-NAT Location B /24 Virtual VPN subnet /24 Location A /24 Virtual VPN subnet /24 Internet IPsec VPN ping request SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: ping reply SRC IP: DST IP:

VPN – Remote 1:1-NAT Internet / /24 Plant IPSec Tunnel No communication from machine to service network Service Network No default gw Request Reply

VPN – Remote 1:1-NAT Internet / /24 Plant IPSec Tunnel Route to /24 has to be configured on each Service PC Default GW Service PCs

VPN – Remote 1:1-NAT Internet /16 IPSec Tunnel Service Network How does VPN 1:1 NAT for the remote network solves these problems? The mGuard maps the specified remote network or IP to the local network of the machine (e.g /32 -> /32). The ARP proxy on the mGuard will provide ARP resolution for this network/IP (e.g ). Therefore the target machine will direct the responses to the mGuard /24 Plant No default gw ping SRC IP: DST IP: SRC IP: DST IP: ping reply SRC IP: DST IP: SRC IP: DST IP:

VPN – Remote 1:1-NAT The remote IP /32 is mapped to the IP (the subnet mask is taken from the specified Remote network). The selected IP must not be used by another entity of the local network. The ARP proxy on the mGuard will provide ARP resolution for this network/IP.

VPN – Remote 1:1-NAT Internet / /24 Plant IPSec Tunnel Default GW Service PCs The mGuard at the service site maps the specified remote network ( /24) to a local (sub) network (e.g /24) The ARP proxy on the mGuard will provide ARP resolution for this network/IP No additional routes have to be configured for the service PCs / /24 ping SRC IP: DST IP: ping reply SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP:

VPN Local Masquerading maps the IP addresses of the internal network to one IP address, in the following example: / The VPN tunnel can only be used in one direction, from the mapped network to the remote network. Accessing the machines of the mapped network from the remote network is not possible. VPN – Local Masquerading Headquarter /24 Internet Headquarters /16 IPsec VPN ping SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: ping reply SRC IP: DST IP: SRC IP: DST IP: VPN Masquerading /

Using this feature makes sense if: A lot of VPN connections terminate at a central VPN gateway. The VPN tunnels are only used from the remote entities to the central VPN gateway. Advantage: This feature reduces the required address space for the VPN connections. VPN – Local Masquerading Headquarters /16 Office 1, /24 Local networkRemote network (VPN Masquerding) / /32 Office 2, / / /32 Office 3, / / /32 Office 4, / / /32 Office 5, / / /32

VPN – Local Masquerading Branch Office A /24 Internet Headquarters /16 IPsec VPN VPN Masquerading /

VPN Remote Masquerading maps the IP addresses of the remote VPN network to one IP address, in the following example: / Device with no default gateway in remote network can be reached The VPN tunnel can only be used in one direction. VPN – Remote Masquerading Service Network /24 Internet Plant /16 IPsec VPN ping SRC IP: DST IP: SRC IP: DST IP: SRC IP: DST IP: ping reply SRC IP: DST IP: SRC IP: DST IP: VPN Masquerading /

VPN – Remote Masquerading Service Network /24 Internet Plant /16 IPsec VPN VPN Masquerading /

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

VPN Scenarios: Tunnel Group Remote service scenario without Tunnel Group: Service Network /24 Plant /24 Plant /24 Plant n n.0/24 Internet L: /24 R: /24 L: /24 R: /16 Connections L: /24 R: /24

VPN Scenarios: Tunnel Group Remote service scenario without Tunnel Group: High configuration / rollout effort Error-prone Maximum of 250 configured VPN connections After 250 customers / machines a 2nd central mGuard has to be operated

VPN Scenarios: Tunnel Group Remote service scenario with Tunnel Group: Service Network /24 Plant /24 Plant /24 Plant n n.0/24 Internet Connection L: /24 R: /16 CA-Certificate

VPN Scenarios: Tunnel Group Remote service scenario with Tunnel Group: Just one single connection is necessary on the central mGuard Only remote mGuards have to be configured during rollout Remote mGuards are authenticated with a CA Certificate More than 250 remote networks can be connected to the service network 250 different tunnel group connections can be configured Easy migration to tunnel group

VPN Scenarios: Hub&Spoke Starting with version 5 the mGuard supports forwarding packets from one VPN tunnel directly into another tunnel Allow packet forwarding between VPN connections must be enabled on the central gateway (menu: IPsec VPN -> Global, tab Options).

VPN Scenarios: Hub&Spoke Starting with version 5 the mGuard supports forwarding packets from one VPN tunnel directly into another tunnel Allow packet forwarding between VPN connections must be enabled on the central gateway (menu: IPsec VPN -> Global, tab Options).

VPN Scenarios: Hub&Spoke Scenario: Head quarter – Branch offices Branch Office /24 Branch Office /24 Headquarters /24 IPsec Tunnel Hub & Spoke activated VPN Tunnel Settings Local: /24 Remote: /16 VPN Tunnel Settings Local: /24 Remote: /16 VPN Tunnel Settings Local: /16 Remote: /24 VPN Tunnel Settings Local: /16 Remote: /24

VPN Scenarios: Hub&Spoke Manufacturer /24 Scenario: Supplier – Manufacturer - Customer Customer /24 Customer /24 IPsec Tunnel Hub & Spoke activated Supplier /24 Supplier /24 IPsec Tunnel !

VPN Scenarios: Hub&Spoke Branch Office /24 Branch Office /24 Headquarters /24 IPsec Tunnel Hub & Spoke + Tunnel Group activated VPN Tunnel Settings Local: /24 Remote: /16 VPN Tunnel Settings Local: /24 Remote: /16 VPN Tunnel Settings Local: /16 Remote: /16 Hub&Spoke can be combined with Tunnel Group feature

VPN Scenarios: Fully Meshed Scenario: Critical communication processes between remote networks Plant A /24 Plant B /24 IT Department /24 Plant C /24

VPN Scenarios: Fully Meshed Advantages: Robustness: no single of point of failure Less impact on firewall missconfiguration: firewall rules are defined for each tunnel Easy to setup and operate Disadvantages: Large number of VPN connections: (n*(n-1))/2 Complex configuration and administration Connection receivers need static public ip addresses

VPN Scenarios: Fully Meshed vs Hub&Spoke Nr of mGuards Hub&Spoke Nr of connections Fully Meshed VPN Nr of connections

VPN Basics 2.VPN Configuration 3.Certificate Management (XCA) 4.NAT in VPN 5.VPN Scenarios 6.Rollout Agenda – mGuard VPN

The mGuard will be restored to the factory (default) settings, also the passwords. This procedure will erase existing configurations on the mGuard. You need to reconfigure the mGuard after flashing the firmware. If you want to update the version of the firmware then the online update through the web interface should be the preferred method. Do not interrupt the power supply during the flashing procedure. Otherwise the device could be damaged, may be left inoperable, and will require your device to be send to the manufacturer. Rollout – Flash procedure

Rollout – Flash procedure TFTP / DHCP Server mGuard 1. DHCP request 2. IP configuration 3. TFTP request 4. Firmware image 5. TFTP request 6. rollout.sh script 7. Execution of rollout.sh

Rollout – Static TFTP / DHCP Server mGuard 1. DHCP request 2. IP configuration 3. TFTP request 4. Firmware image 5. TFTP request 6. rollout.sh script rollout.sh 7. TFTP request: standard.atv 8. standard.atv

Example rollout.sh (static TFTP): #!/bin/sh -ex # The IP address of the DHCP/TFTP server is supplied by install.p7s server=$1 # This is the filename of the user supplied static configuration file on the host in the # TFTP-server directory cfg_name=preconfig.atv export PATH=/bin:/bootstrap # fetch the static configuration-file "preconfig.atv" tftp -g -l - -r "$cfg_name" "${server}" | dd bs=1M of=/bootstrap/preconfig.atv # create a small configuration-script that installs the configuration fetched from ${server} cat >/bootstrap/preconfig.sh <<EOF #!/bin/sh modprobe param_dev 2>/dev/null gaiconfig --silent --set-all < /bootstrap/preconfig.atv EOF # Make it executable. It will be executed after all packets are installed completely. chmod 755 /bootstrap/preconfig.sh Rollout – Static

Rollout – Dynamic TFTP TFTP / DHCP Server mGuard Serial-Nr.: DHCP request 2. IP configuration 3. TFTP request 4. Firmware image 5. TFTP request 6. rollout.sh script rollout.sh 7. TFTP request: atv atv

Example rollout.sh (dynamic TFTP): #!/bin/sh -ex # The IP address of the DHCP/TFTP server is supplied by install.p7s server=$1 export PATH=/bin:/bootstrap if test -x /bootstrap/sysmguard && \ test "`sysmguard kv`" -eq 6; then SERIAL=`sysmguard param oem_serial` else mount -t proc none /proc SERIAL=`cat /proc/sys/mguard/parameter/oem_serial` # /proc must be unmounted to enable unmounting of the jffs2 filesystem later. umount /proc fi # This is the filename of the user supplied configuration file on the host in the TFTP-server directory cfg_name="${SERIAL}.atv" # fetch the configuration-file "preconfig.atv" tftp -g -l - -r "$cfg_name" "${server}" | dd bs=1M of=/bootstrap/preconfig.atv # create a small configuration-script that installs the configuration fetched from ${server} cat >/bootstrap/preconfig.sh <<EOF #!/bin/sh modprobe param_dev 2>/dev/null gaiconfig --silent --set-all < /bootstrap/preconfig.atv EOF # Make it executable. It will be executed after all packets # are installed completely. chmod 755 /bootstrap/preconfig.sh Rollout – Dynamic TFTP

Rollout – Dynamic http TFTP / DHCP Server mGuard Serial-Nr.: DHCP request 2. IP configuration 3. TFTP request 4. Firmware image 5. TFTP request 6. rollout.sh script rollout.sh 7. HTTP request: atv atv Web Server

Example rollout.sh (dynamic http): #!/bin/sh -ex # The IP address of the DHCP/TFTP server is supplied by install.p7s server=$1 export PATH=/bin:/bootstrap if test -x /bootstrap/sysmguard && \ test "`sysmguard kv`" -eq 6; then SERIAL=`sysmguard param oem_serial` else mount -t proc none /proc SERIAL=`cat /proc/sys/mguard/parameter/oem_serial` # /proc must be unmounted to enable unmounting of the jffs2 filesystem later. umount /proc fi # This is the filename of the user supplied configuration file on the host in the TFTP-server directory URL= wget –q ${URL} –O /bootstrap/preconfig.atv # create a small configuration-script that installs the configuration fetched from ${server} cat >/bootstrap/preconfig.sh <<EOF #!/bin/sh modprobe param_dev 2>/dev/null gaiconfig --silent --set-all < /bootstrap/preconfig.atv EOF # Make it executable. It will be executed after all packets # are installed completely. chmod 755 /bootstrap/preconfig.sh Rollout – Dynamic http

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

The Innominate Device Manager (IDM) enables the convenient management of Innominate mGuard security appliances. The tool offers a template mechanism that allows to centrally configure and manage up to Innominate mGuard devices. Pools can be defined, which define a range of values or network addresses, which can be automatically assigned to variables. IDM is a client-server application and consists of SQL database (PostgreSQL) IDM Server for storing the configuration in a database, generating configuration files and uploading those files to the devices upon request. IDM Client for offering full control to all features of IDM IDM Certification Authority (CA) (optional) for creating the required certificates and for storing them in a database. IDM - Overview

IDM - Overview

IDM - Overview IDM Server IDM Client IDM CA CA SQL DB Device SQL DB ssh tcp (opt. ssl) http or https tcp (ssl)

IDM - Overview IDM Server IDM Client IDM CA CA SQL DB Device SQL DB tcp (opt. ssl) http or https tcp (ssl) HTTPS Server https

Enable SSH access: The IDM installs the configuration files on the mGuards using SSH. Therefore SSH access has to be permitted on the mGuards if IDM is using the external (un-trusted) interface to upload the configuration. Ensure that the communication between IDM server and the mGuards is not blocked by a firewall or a NAT device. If the mGuards pull their configuration from a HTTPS server, make sure that neither the communication between the HTTPS server and the IDM server nor the communication between the HTTPS pull server and the mGuards is blocked by a firewall or a NAT device. IDM - Overview Pre-Configuration of the Devices

Apart of the mGuard users root and admin two new roles have been introduced: user netadmin and user audit. Their passwords can only be configured through IDM. The user audit has only read access to the mGuard and cant apply changes to the configuration. The user netadmin can apply changes to the configuration of the device, as long as the corresponding variable is marked as local variable in IDM (will be explained later). The users root and admin still can apply changes to all variable of the configuration. IDM - Overview mGuard local users

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

IDM - System requirements Windows 2000 SP 2 (or higher) / Windows XP / Windows 7 or Linux Java Runtime Environment 6.0 PostgreSQL Version 9.0 or later Windows 2000 SP 2 (or higher) / Windows XP / Windows 7 or Linux Java Runtime Environment 6.0 Software A minimum of 4 GB RAM 100 GB free hard disk space A minimum of 512 MB RAM 500 MB free hard disk space Color monitor with at least 1024 x 768 resolution Hardware ServerClient

IDM – Virtual Machine Innominate provides a Virtual Machine (VMWare) with full IDM installation including all components (Demo)

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

IDM – Device configuration The Device Properties dialog contains a navigation tree on the left side that resembles the menu structure of the mGuard Web GUI.

IDM – Devices: General Settings Management ID: This ID is used to identify the device within IDM. The Management ID must be unique. The management ID must contain only alphanumeric characters or the - character. Firmware Version: Since different releases of the mGuard software have different sets of variables, the correct release has to be selected in IDM. Firmware Version on Device: Can be entered manually. IDM overwrites this value after uploading a configuration the first time. Template: Here you can assign templates to a device. There is no template assigned by default, i.e. you have to select a template out of the existing templates already created.

IDM – Devices: Accessible via Accessible via: This is the address used by the IDM server to access the mGuard for an SSH push of the configuration

IDM – Devices: Configuration Upload To start the upload, select either Update -> All, or Update -> Changed or Update -> Selected from the menu. Auto: Depending on whether an IP address Accessible via in General settings of the Device Properties dialog is set or not, IDM will either perform an SSH push upload or create an export of the configuration. Upload via SSH: IDM tries to upload the configuration using SSH push. Prepare pull configuration: IDM will export the configuration files to the file system.

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

Templates Templates offer a powerful mechanism to conveniently configure and manage a large number of devices. Templates contain a subset of mGuard variables and can be assigned to a device. Templates may inherit values from another template. By assigning the template to a device the device inherits the template settings and will use the values for the mGuard variables that are defined in the template. Depending on the permission settings, the template settings might be overwritten in the device configuration.

Templates Template A Template BTemplate C Device 1Device 2 Device 3 Device 4

Templates: Variables Below the Inherited option the selectable values are displayed. Local: A local variable can be managed by the netadmin on the mGuard and will not be managed by IDM anymore in order to avoid conflicts between IDM and the configuration applied by the netadmin. IDM will disable the control for the value of local variables. None: A variable set to none in the template must be set when configuring the device.

Templates: Variables You need to specify whether the value may be changed when configuring a device using this template: No override: The settings for the variable cannot be changed. May override: The settings for the variable can be changed. May append: This option is only available for tables (e.g. firewall rules). If a table variable is set to May append in the template then additional table entries can be appended.

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

Pools A pool defines a range of values or network addresses, which can be automatically assigned to variables in a template. For example, the virtual IP addresses for VPNs can be obtained from a defined pool. Pool values can only be used in templates. If a pool is used for a template variable, IDM will automatically assign a value to the variable of all devices using the respective template. In the pool table it is shown, how many values have been taken out of the pool (Use count) and how many values are still available in the pool (Available count).

Pools: Configuration dialog

Pools: Configuration dialog Network Mask w.x.y.z/: This field (CIDR notation) defines the range of single values to be taken out of the pool. They can be either single IP addresses (network mask = 32) or network IDs (e.g. network mask = 24). List of Source Networks: The list of networks from which IDM will take the single values. Note: Once defined, it is not possible to change or delete the source address ranges in the pool any more. It is only possible to add further ranges to the pool, i.e. increase the pool value range. So please carefully plan the definition of the pool ranges in advance!

Pools: Example 1 Network Mask w.x.y.z/ = 24 List of Source Networks = / /16 IDM will start getting the single networks out of the pool /16 with a network mask of 24: /24, /24, /24, …, /24 Now all values of the pool /16 are used. IDM will continue getting the single networks out of the pool / /24, /24, /24, …, /24

Pools: Example 2 Network Mask w.x.y.z/ = 32 List of Source Networks = / /24 IDM will start getting the single IP addresses (network mask = 32) out of the pool /24. The subnet ID ( ) and the broadcast address ( ) are omitted , , , …, Now all values of the pool /24 are used. IDM will continue getting the single IP addresses out of the pool / , , , …,

Overview 2.Installation 3.Devices 4.Templates 5.Pools 6.VPN Agenda – IDM

VPN IDM supports the configuration of VPN peers The configuration of a VPN channel has to be done one device only Service Network /24 Plant /24 Plant /24 Plant n n.0/24 Config 1 Config 2 Config 3 No config needed

VPN Tunnelgroup Tunnel Group Connections can be configured by the IDM as well Service Network /24 Plant /24 Plant /24 Plant n n.0/24 Internet Connection L: /24 R: /16 CA-Certificate

VPN DEMO

Licenses 2.Updates Agenda – Licenses and Updates

VPN-1010 VPN Tunnels VPN VPN Tunnels VPN-250 Tunnel Group Option 250 VPN Tunnels and Tunnel Group VPN-1000 Tunnel Group Option 1000 VPN Tunnels and Tunnel Group CIFS IMmGuard CIFS Integrity Monitoring FW RedundancyFirewall redundancy (License pair) HAFirewall and VPN redundancy (License Pair) MRUUpgrade of the mGuard firmware by one Major Release step MRU LFSLifetime Firmware Subscription MRU centerportUpgrade of the mGuard firmware by one Major Release step for the centerport MRU centerport LFSLifetime Firmware Subscription for the centerport License Types

Licenses can be added to devices which are already in use When a customer has purchased an additional feature (e.g. VPN- 250) he will receive a voucher for requesting the license. A voucher can be used on any device but only one time for requesting a license. A voucher consists of a serial number and a key, e.g. Serialnumber = Key = 80d2-398f-5e25-a7e2-58cd-e9bf License request

Requesting the license from the devices online Go to the menu Management -> Licensing, tab Install. Enter the voucher serial number and the voucher key. Click. The license will be created and uploaded to the device online. License request

Devices without Internet access Request the license from a workstation with Internet access. Use the URL You also need to provide the flash ID (including the checksum) of the device as it is displayed in the menu Management -> Licensing, tab Overview (e.g. 003c000b414efbe7-0282). This menu provides information about installed licenses. 192 License request

Devices without Internet access Enter the voucher data and the flash ID (including the checksum) of the device. License request

Devices without Internet access If the entered data are correct, you will be prompted to either modify the data or to request the license. License request

Devices without Internet access Once the license has been created online you can download it to your local system. The license needs to be installed in the section Manual License Installation: Click, select the license file and click. License request

Licenses 2.Updates Agenda – Licenses and Updates

Software version pattern: x.y.z (e.g ) x: Major Release Version y: Minor Release Version z: Patch Level Starting with an update to version 5 an update to the next major release version (X.y.z) requires an installed Major Release Update License. Minor releases (x.Y.z) and patch releases (x.y.Z) are free of charge until further notice. Customers need to purchase a Major Release Update Voucher which is used for requesting the Major Release Update License from the device. Updates

There exist two different Major Release Update voucher: Innominate mGuard MRU Upgrade of the mGuard firmware by one Major Release step for one mGuard field appliance Innominate mGuard LFS Lifetime Firmware Subscription for one mGuard field appliance, granting the right to install any standard firmware image or upgrade available from Innominate for the respective appliance platform. Updates

The firmware of the mGuard can be updated user friendly through the web interface. The update can be installed either locally (Local Update) or online through the Internet (Online Update or Automatic Update). Offline (push) update Online (pull) update (obsolete) Automatic online (pull) update Updates

Select one of the following options: for updating the device within one minor release version (e.g. from to 7.2.1). for updating to the next minor release (e.g. from 7.3.x to 7.4.x). for updating the device to the next major release (e.g. from 6.1.x to 7.4.0). Updates – Automatic Updates

At first you need to retrieve the firmware version which is currently installed on the device. Then you need to download the update file from our homepage ( -> Downloads -> Updates) Updates – Local Updates

In the section Local Update, click and specify the downloaded update file. Click. Updates – Local Updates

Overview 2.Importable Shares 3.CIFS Integrity Checking 4.CIFS Integrity Status 5.CIFS AV Scan Connector Agenda – CIFS IM

CIFS = Common Internet File System, better known as Windows File Sharing Monitoring Windows-based automation components against malware infections. CIFS Integrity Monitoring provides two possibilities to check file shares for malware infections: mGuard CIFS Integrity Checking mGuard CIFS Antivirus Scan Connector CIFS IM - Overview

CIFS IM - Overview

mGuard CIFS Integrity Checking Configurable monitoring of file shares of protected systems for unexpected modifications of executable code (e.g. *.exe, *.dll). Works without any malware signatures or virus pattern updates. mGuard CIFS Antivirus Scan Connector Configurable access for external antivirus scanner to file shares of protected systems. Works with any external scanner. CIFS IM - Overview

Overview 2.Importable Shares 3.CIFS Integrity Checking 4.CIFS Integrity Status 5.CIFS AV Scan Connector Agenda – CIFS IM

Define the shares which should be checked periodically. You need to refer to these shares when configuring CIFS Integrity Checking or CIFS Antivirus Scan Connector. CIFS IM - Importable Shares

Name: mGuard internal name for the share. Server: IP address of the machine. Share: Share name as specified on the machine. Workgroup/Login/Password: Account parameters for accessing the share on the machine. CIFS IM - Importable Shares

Overview 2.Importable Shares 3.CIFS Integrity Checking 4.CIFS Integrity Status 5.CIFS AV Scan Connector Agenda – CIFS IM

Configurable monitoring of file shares of protected systems for unexpected modifications of executable code (e.g. *.exe, *.dll). The results of an initial scan are stored in a database which contains the hash value of each file. This database is used as reference for the subsequent integrity check. The database is signed by a specified certificate (needs to be imported as machine certificate) for protecting it against unauthorized modifications. Optional notification via and/or SNMP trap after every check or in case of a failure or difference. CIFS Integrity Checking

CIFS Integrity Checking

Filename pattern definition CIFS Integrity Checking

Filename pattern definition, wildcard usage: **\*.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. Note: Only one wildcard is allowed per filename or directory. ** means all subdirectories. CIFS Integrity Checking

Overview 2.Importable Shares 3.CIFS Integrity Checking 4.CIFS Integrity Status 5.CIFS AV Scan Connector Agenda – CIFS IM

Displays the status of the last integrity check and allows to perform a couple of actions. CIFS Integrity Status

The following actions can be performed: Validate the report: Verify the validity of the recent check report against the certificate and the signature. Start a check: Start an integrity check right now. Cancel: Cancel the currently running integrity check. Initialize: (Re-)Build the integrity database. Cancel: Cancel the creation of the integrity database. Erase: Erase reports and the integrity database. CIFS Integrity Status

Overview 2.Importable Shares 3.CIFS Integrity Checking 4.CIFS Integrity Status 5.CIFS AV Scan Connector Agenda – CIFS IM

Configurable access for external antivirus scanner to file shares of protected systems. The mGuard mirrors the specified shares to the external network so that they can be mounted to the machine on which the antivirus scanner is running. CIFS AV Scan Connector

Server's workgroup, Login, Password: Account which needs to be provided when mounting the share on the machine on which the antivirus scanner is running. Exported share's name: Main directory name. In the previous screenshot you need to mount \\ \exported- av-share on the machine on which the antivirus scanner is running. Exported in Subdirectory: Directory name, including one or more share names of the machine mGuard Machine Server on which the shares are mounted CIFS AV Scan Connector

Q & A

Further Topics VPN Connection Debugging VPN Common Errors VPN in Stealth Mode VPN TCP Encapsulation VPN Software Switch Tranport Mode VPN Redundancy

VPN – Connection Debugging Internet I: ISAKMP SA (key exchange) II: IPsec SA (data exchange) VPN connections are established in two phases Phase I (ISAKMP SA or IKE SA: key exchange) -VPN gateways authenticate each other -They securely negotiate an encryption key to protect Phase II Phase II (IPsec SA: data exchange) -Using key from Phase I, negotiate IPsec connection parameters

VPN – Connection Debugging InitiatorResponder #1: Header, Security Association #2: Header, Key Exchange, Nonce #3: Header, ID, Hash (Preshared Key) Header, ID, Certificate, Signature (Certificates) #3: Header, ID, Hash (Preshared Key) Header, ID, Certificate, Signature (Certificates) Unencrypted Encrypted Diffie-Hellman Group Symmetric encryption and Hash Offer proposals Select a proposal UDP 500 UDP 500 / NAT: UDP 4500 STATE_MAIN_I1 STATE_MAIN_I2 STATE_MAIN_I3 STATE_MAIN_R1 STATE_MAIN_R2 STATE_MAIN_R3 Phase 1 (Main Mode):

VPN – Connection Debugging InitiatorResponder #1: Hash, Proposal, Nonce I, DH Public key #1: Hash, Proposal Accept, Nonce R, DH Public key #2: Header, Key Exchange, Nonces STATE_QUICK_I1 STATE_QUICK_I2 STATE_QUICK_R1 STATE_QUICK_R2 Phase 2 (Quick Mode): Tunnel negotiation, Key exchange Acknowledge

VPN – Connection Debugging Information about the status is displayed in the menu IPsec VPN -> IPsec Status All configured VPN connections should be displayed in this screen. If a connection is missing, its configuration probably contains wrong parameters. LocalRemoteStatus ISAKMP SA (phase I) Status IPsec SA (phase II)

#1: IKEv1 uptime= state=main-i1 remote= :500 local= :500 send={exchange-type=IKEv1... #1: IKEv1 uptime= state=main-i1 remote= :500 local= :500 rcvd={exchange-type=… #1: IKEv1 uptime= state=main-i1 remote= :500 local= :500 send={exchange-type=... #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 #1: IKEv1 uptime= newstate=main-i _17:45: pluto[1879]: #1: STATE_MAIN_I2: sent MI2, expecting MR2 #1: IKEv1 uptime= state=main-i2 remote= :500 local= :500 rcvd={exchange-type=... #1: IKEv1 uptime= state=main-i2 remote= :500 local= :500 send={exchange-type=... #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 #1: STATE_MAIN_I3: sent MI3, expecting MR3 #1: IKEv1 uptime= state=main-i3 remote= :500 local= :500 rcvd={exchange-type=IKEv1- identity-protection;msgid=... #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536} #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1 msgid:d329cee1 proposal=3DES(3)_192-MD5(1) IKEv1 uptime= state=quick-i1 remote= :500 local= :500 send={exchange… IKEv1 uptime= state=quick-i1 remote= :500 local= :500 rcvd={exchange-type=… IKEv1 uptime= state=quick-i1 remote= :500 local= :500 send={exchange-type=IKEv1-quick #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x0417d8ff <0x9e3f89a5 xfrm=3DES_0- HMAC_MD5 NATOA=none NATD=none DPD=enabled} VPN – Connection Debugging Initiator:

IKEv1 uptime= state=unknown remote= :500 local= :500 rcvd={exchange... IKEv1 uptime= state=main-r0 remote= :500 local= :500 send={exchange-... #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 #1: STATE_MAIN_R1: sent MR1, expecting MI2 #1: IKEv1 uptime= state=main-r1 remote= :500 local= :500 rcvd={exchange-t... #1: IKEv1 uptime= state=main-r1 remote= :500 local= :500 send={exchange... #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 #1: STATE_MAIN_R2: sent MR2, expecting MI3 IKEv1 uptime= state=main-r2 remote= :500 local= :500 rcvd={exchange-type=... IKEv1 uptime= state=main-r2 remote= :500 local= :500 send={exchange-type=... #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established IKEv1 uptime= state=main-r3 remote= :500 local= :500 rcvd={exchange-type=IKEv1-quick-… IKEv1 uptime= state=quick-r0 remote= :500 local= :500 send={exchange-type=IKEv1-quick-... #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 IKEv1 uptime= state=quick-r1 remote= :500 local= :500 rcvd={exchange-type=IKEv1-quick-… #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2 #2: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=> VPN – Connection Debugging Receiver:

IKEv1 uptime=30.95 state=main-i1 remote= :500 local= :500 send={exchange-type=IKEv1-identity- protection;msgid= ;icookie=6C2B66502C68C329;rcookie= ;encrypted=no;payloads={SA={doi=i psec;{ealg=3des-cbc;... #1: STATE_MAIN_I1: initiate ERROR: asynchronous network error report on eth0 (sport=500) for message to port 500, complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] VPN – Common Errors Initiator: initial Main Mode message received on :500 but no connection has been authorized with policy=PSK IKEv1 uptime= state=unknown remote= :500 local= :500 rcvd={exchange-type=IKEv1-identity- protection;msgid= ;icookie=6C2B66502C68C329;rcookie= ;encrypted=no;payloads={SA={doi=i psec;{ealg=3des-cbc;eklen=0;halg=md5;modp=1536-bit-dh-modp-group-5}... Receiver: Wrong proposals

IKEv1 uptime= state=main-i1 remote= :500 local= :500 send={exchange-type=-... IKEv1 uptime= state=main-i1 remote= :500 local= :500 rcvd={exchange-type=IKEv1-… IKEv1 uptime= state=main-i1 remote= :500 local= :500 send={exchange-type=IKEv1-… transition from state STATE_MAIN_I1 to state STATE_MAIN_I2; STATE_MAIN_I2: sent MI2, expecting MR2 transition from state STATE_MAIN_I2 to state STATE_MAIN_I3; STATE_MAIN_I3: sent MI3, expecting MR3 IKEv1 uptime= state=main-i3 remote= :500 local= :500 rcvd={exchange-type=IKEv1-… received 1 malformed payload notifies Possible authentication failure: no acceptable response to our first encrypted message Initiator: IKEv1 uptime= state=unknown remote= :500 local= :500 rcvd={exchange-type=IKEv1-... IKEv1 uptime= state=main-r1 remote= :500 local= :500 send={exchange-type=IKEv1-identity- transition from state STATE_MAIN_R1 to state STATE_MAIN_R2; STATE_MAIN_R2: sent MR2, expecting MI3 next payload type of ISAKMP Identification Payload (IPsec DOI) has an unknown value: 70 IKEv1 uptime= state=main-r2 remote= :500 local= :500 rcvd={exchange-type=IKEv1-... probable authentication failure (mismatch of preshared secrets?): malformed payload in packet sending notification PAYLOAD_MALFORMED to :500 Receiver: VPN – Common Errors Authentication error

initiating Main Mode... STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536} initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {...} IKEv1 uptime= state=quick-i1 remote= :500 local= :500 send={exchange-type=IKEv1-quick-... IKEv1 uptime= state=main-i4 remote= :500 local= :500 rcvd={exchange-type=IKEv1- informational … ignoring informational payload, type INVALID_ID_INFORMATION msgid= Initiator: responding to Main Mode... STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536} IKEv1 uptime= state=main-r3 remote= :500 local= :500 rcvd={exchange-type=IKEv1-quick... the peer proposed: /24:0/0 -> /24:0/0 cannot respond to IPsec SA request because no connection is known for /24=== === /24 sending encrypted notification INVALID_ID_INFORMATION to :500 Receiver: VPN – Common Errors Error in tunnel configuration

VPN – Single Stealth Mode The mGuard in Stealth mode does not have a real internal network. If the IP address of the client, protected by the mGuard, does not belong to the remote VPN network and if the client does not receive its IP settings from a DHCP server, you can establish the VPN tunnel between the IP address of the client and the remote VPN network. VPN tunnel between /32 and /16 Internet mGuard 2 Corporate Network /16 mGuard 1 Stealth Mode Branch Office /16 IPsec VPN

VPN – Single Stealth Mode If the IP address of the client, protected by the mGuard, belongs to the remote VPN network or if the client receives its IP settings from a DHCP server, a virtual IP address must be used as Local network. This virtual IP address shouldnt belong to an existing network. The mGuard performs automatically a 1-to-1 NAT from the virtual IP address to the real IP address of the client. Internet mGuard 2 Corporate Network /16 mGuard 1 Stealth Mode Branch Office /16 Virtual Network /32 IPsec VPN

VPN – Single Stealth Mode

VPN – Multi Stealth Mode Internet mGuard 2 Corporate Network /16 mGuard 1 Multi Stealth Mode Branch Office /24 IPsec VPN Management IP

VPN – TCP-Encapsulation Internet PlantService IPsec VPN TCP D-Port: 80

VPN – TCP-Encapsulation Internet PlantService IPsec VPN http-Proxy

This feature was implemented especially for remote maintenance of systems which are protected by mGuards. If an engineer from an other company needs remote access to the systems through a VPN tunnel, the connection can be activated temporarily. For enabling/disabling a VPN connection or for retrieving its status, use the URL: / nph-vpn.cgi?name= &cmd=up|down|status You need to login as user admin, root or user. If the VPN connection should be activated through the external interface of the mGuard, HTTPS remote access must be enabled. VPN – Software switch

Retrieving the status of a VPN connection returns one of the following values: Unknown: A VPN connection with this name does not exist. Void: The connection is inactive due to an error (e.g. the external network is down or the hostname of the remote peer could not be released in an IP address (DNS)). Ready: The connection is ready to establish channels or allow incoming queries regarding channel set-up. Active: At least one channel is set-up for the connection. VPN – Software switch

Starting with mGuard also the commands synup and syndown are supported. Whereas the commands up and down return almost immediately, the commands synup and syndown return when the command execution finished on the mGuard, providing also the relevant VPN logs. Those logs can be examined by a script for obtaining the status of the VPN connection. VPN – Software switch P synup name=RemoteMaintenance P deviceinfo uptime= tstamp= e serial=2TO00133 hostname=mguard P vpnconn uptime= id=v000_000 gw= P dnslookup uptime= ip= P routeinfo uptime= via=ext1( ) ifstate=up … P IKEv1 uptime= isakmp-sa=established id=v000_000 … P IKEv1 uptime= ipsec-sa=established id=v000_001 msg=IPsec SA 1 out of 1 is established on this side. R OKVUP uptime= msg=Connection is established on this side.

VPN – Transport Mode Scenario for using a Transport connection Note: A transport connection through a NAT device is not supported. mGuard Stealth mGuard Stealth IPSec Transport Network: /16

The redundancy feature allows two mGuards in Router Mode to operate as one virtual router. A virtual internal and external IP address is shared among the mGuards (the active mGuard replies to ARP requests for the virtual IPs). Devices of the internal network must use the internal virtual IP as default gateway. Redundancy in multi stealth mode is not yet supported Redundancy – Router Mode Internal Network mGuard mGuard 2 Default Gateway Virtual IP External Network Virtual IP / /16 active standby

The availability check is performed continuously by each mGuard of a redundancy pair. The purpose of this check is to detect the presence and priority of an active mGuard which should stay active. A customized version of the Common Address Redundancy Protocol (CARP) is used. Redundancy – Availablity Check Internal Network mGuard 1 mGuard 2 External Network active standby CARP Firewall State Replication CARP

While the active mGuard sends CARP announcements continuously to the internal and external network, both mGuards listen for them. The mGuard calculates the frequency of the announcements and the period after which an mGuard is considered as faulty automatically to achieve a configurable fail-over switching time. The Availability Check fails if the standby mGuard does not receive sufficient announcements in time through the internal or external network, or an mGuard receives CARP announcements of lower priority than its own. The mGuard becomes active and starts sending CARP announcements. Redundancy – Availablity Check

The connectivity check is performed continuously by each mGuard of a redundancy pair. The purpose of the connectivity check is to determine whether the mGuard has the required network connectivity. The mGuard performs two independent connectivity checks on the internal and on the external interface. The overall result is success only if proper connectivity exists on both interfaces. If the active mGuard detects a link failure, it switches into Fault state, stops sending CARP announcements and the standby mGuard becomes active (due to the outstanding CARP announcements). Redundancy – Connectivity Check

However, if the mGuards are connected through several switches and if the connection between two switches fails, the active mGuard will not notice this and will still be active whereas the standby mGuard will also become active due to the outstanding CARP announcements. To avoid this situation, the connectivity check may be extended by regular ICMP echo requests to specific target Redundancy – Connectivity Check

Redundancy – Connectivity Check Internal Network mGuard 1 mGuard 2 External Network / /16 active standby Connection failure Switch 1 Switch 2 Switch CARP

The mGuard supports 3 and 10 seconds fail-over switching time. It is nice to use the fastest supported fail-over time but it also needs to be considered that for achieving the fail-over time additional network traffic is required. Apart of this, the network latency between both mGuards must not exceed a certain value. Additional required network traffic for the availability check (CARP announcements): Redundancy – Network Performance Fail-over switching time [s] CARP announcements per secondMaximum network latency [ms] Bandwidth at layer 2 for high priority [bits/s] High priorityLow priority 36,63,

Additional required network traffic for the connectivity check (ICMP Echo Requests): Redundancy – Network Performance Fail-over switching time [s] ICMP echo requests per destination and second Bandwidth at layer 2 per destination [bits/s] 33,32,

VPN Redundancy is an additional feature based on two mGuard configured as redundant firewall (Router mode, Multi-Stealth mode currently not supported). This feature must be licensed separately. A High Availability license is required, which includes the FW Redundancy license. The state of established VPN connections is synchronized between both mGuards continuously, so that in case of a fail over established VPN connections will not be interrupted. Redundancy – VPN Internal Network A mGuard 1 mGuard 2 active standby VPN State Replication Internal Network B Internet Virtual IP VPN

The VPN connection is established against a virtual IP for which the active mGuard replies to ARP requests. The VPN configuration must be the same on both devices with respect to tunnel settings, authentication, VPN firewall and IKE options. Each mGuard must have its own machine certificate. Both machine certificates must be signed by the same CA certificate. Redundancy – VPN Internal Network A mGuard 1 mGuard 2 active standby VPN State Replication Internal Network B Internet Virtual IP VPN

CA authentication must be used on the site which waits for the VPN connection. %any must be specified as Address of the remote sites VPN gateway on the site which waits for the VPN connection. Both mGuards must use the same machine certificate. Redundancy – VPN Internal Network A mGuard 1 mGuard 2 active standby VPN State Replication Internal Network B Internet Virtual IP VPN

Exercises

Network Setup Network /24 Trainer PC Router Internet / mGuard / mGuard X X.1/ X.2 mGuard X / mGuard 15

mGuard ext. IPmGuard def. gwmGuard int. IPNotebook IP mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / mGuard / / Network Setup Trainer PC:

Exercise 1 – Initial Setup Configure your mGuards (factory default) as described in the network setup Try to reach the internet with your PC Create a configuration profile Base Your mGuard External IP = ____________ Internal IP = ____________ GW=____________ Internal Network ______________ Your PC IP = ____________ GW=____________ External Network /24

Exercise 2 – VPN Connection Work together with your partner Establish a VPN connection between your mGuards Your mGuard External IP = ____________ Internal IP = ____________ Remote mGuard External IP = ____________ Internal IP = ____________ Internal Network ______________ Your Laptop IP = ____________ Remote Laptop IP = ____________ Internal Network ______________ External Network /24

Exercise 2 – VPN Connection Execution: 1.Setup a VPN tunnel (PSK authentication and default settings) 2.Check the logs on both mGuards 3.Exchange data between the laptops (e.g. via ping) 4.Create a configuration profile VPN

Exercise 3 – User Firewall Work together with your partner Activate configuration profile Base Your mGuard External IP = ____________ Internal IP = ____________ Remote mGuard External IP = ____________ Internal IP = ____________ Internal Network ______________ Your Laptop IP = ____________ Remote Laptop IP = ____________ Internal Network ______________ External Network /24

Exercise 3 – User Firewall Enable the second mGuard to be pingable on the external interface Configure the first mGuard: Close the firewall on the first mGuard completely (incoming & outgoing) Add a user firewall user (Local DB authentication) Add a user firewall template that allows to ping the external ip adress of the second mGuard Try to ping the second mGuard with and without user authentication from Laptop 1 Create a configuration profile User Firewall