Branch Office VPN Tunnels and Mobile VPN

Transcription

1 WatchGuard Certified Training Branch Office VPN Tunnels and Mobile VPN Fireware XTM and WatchGuard System Manager v11.7 Revised: January 2013 Updated for: Fireware XTM v11.7

2 Notice to Users Information in this guide is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of WatchGuard Technologies, Inc. Copyright and Patent Information Copyright 2013 WatchGuard Technologies, Inc. All rights reserved. WatchGuard, Firebox, Fireware, LiveSecurity, and spamblocker are either registered trademarks or trademarks of WatchGuard Technologies, Inc. in the United States and other countries. This product is covered by one or more pending patent applications. All other trademarks and tradenames are the property of their respective owners. Printed in the United States. TRAINING SUPPORT U.S. and Canada All Other Countries ii WatchGuard Fireware XTM Training

3 Table of Contents Branch Office VPN Tunnels... 1 Introduction... 1 What You Will Learn... 1 Exercise... 1 What Branch Office VPNs Can Do For You... 1 What You Should Know... 2 How Branch Office VPNs work... 2 Terms and Definitions... 4 What Happens During Phase 1 Negotiations... 8 What Happens During Phase 2 Negotiations How VPNs Work With Multi-WAN How VPNs Work With Modem Failover Use IPSec Certificates for the IKE Credentials Add Policies in Policy Manager to Allow VPN Traffic Troubleshoot Branch Office VPN Tunnels Before You Begin Necessary Equipment And Services Management Computer Configuration Firewall Configuration Exercise Make a Manual VPN Between a Single-WAN XTM Device and a Multi-WAN XTM Device Frequently Asked Questions Related Courseware and Information What You Have Learned Test Your Knowledge Mobile VPN What You Will Learn Connect Remote Users Securely to the Corporate Network Types of Mobile VPN Enable the XTM Device for Mobile VPN Distribute Client Software and Configuration File Use Mobile VPN with IPSec with an Android Device Configure the IPSec VPN client on the Android Device Use Mobile VPN with IPSec With a Mac OS X or ios Device Configure the XTM Device Configure the VPN Client on an ios Device Configure the VPN Client on a Mac OS X Device Use Mobile VPN with L2TP with an ios Device Configure the XTM Device Mobile VPN with L2TP IPSec Settings Mobile VPN Exercises iii

4 Exercise 1: Set Up Mobile User VPN with L2TP Activate L2TP on the XTM Device Add Users to the L2TP-Users Group Configure the Client Computer Exercise 2: Configure Mobile VPN with IPSec and Prepare Mobile VPN Client Configuration Files Exercise 3: Restrict Mobile VPN with IPSec Users by Policy Exercise 4: Use the Shrew Soft IPSec Client Install the Shrew Soft VPN Client Connect and Disconnect the Shrew Soft VPN Client Exercise 5: Configure the XTM device for Mobile VPN with SSL Activate the XTM Device for SSL VPN Add Users to the SSLVPN-Users Group Restrict SSL VPN Users by Policy Exercise 6: Change the Port Used for Mobile VPN with SSL Exercise 7: Use the Mobile VPN with SSL Client Install the Mobile VPN with SSL Client Connect with the Mobile VPN with SSL Client Test Your Knowledge iv WatchGuard Fireware XTM Training

5 Fireware XTM Training Branch Office VPN Tunnels Creating IPSec VPNs in Fireware XTM Introduction What You Will Learn In this course, you learn how to make branch office virtual private networks (BOVPNs) between WatchGuard XTM devices with Fireware XTM, when one or both devices have multiple connections to the Internet. You learn how to make these VPNs manually, not with the WatchGuard Management Server. You also learn how VPN failover works. Exercise This course includes a step-by-step exercise to show you how to make VPNs in a multi-wan environment. It also illustrates a use case that might apply in your organization. Before you start the exercise, make sure to read Before You Begin, on page 41. This section has a list of the equipment and software you need for the exercise, and gives you basic information about how to prepare your device. What Branch Office VPNs Can Do For You A branch office VPN (BOVPN) enables computers at one office to securely transmit private data through an untrusted public network to computers at another office. The BOVPN provides these benefits: Privacy or confidentiality of the data The VPN uses encryption to guarantee that traffic between the two offices is secret. An attacker that intercepts the traffic cannot understand it. Data integrity The VPN guarantees that the data that passes through it has not been altered in transit. Data authentication The VPN guarantees that data that passes through the tunnel actually comes from one of the two endpoints of the VPN, and not from some attacker on the Internet. Direct private IP address to private IP address communication The computers at the two offices communicate as if they were not behind devices configured with Network Address Translation (NAT). The data tunnels through NAT for a transparent connection between the devices. About Side Notes Side notes include extra information that is not necessary to understand the training. They might be configuration or troubleshooting tips, or extra technical information. This training module does not include instructions to use Fireware XTM CLI or the Web UI. All configuration changes are made with Policy Manager, and you monitor the XTM devices with WSM and related tools. 1

6 What You Should Know In this training, the gateway device at each location is a WatchGuard XTM device, but your XTM device can make an IPSec VPN tunnel to any device that implements the IPSec standards. How Branch Office VPNs work A Branch Office VPN tunnel (BOVPN) is a method that two networks can use to send data through an untrusted network (typically, the Internet), with an encrypted, authenticated connection. One gateway device at each location completes the IPSec encapsulation process for all the computers behind the gateway device. The computers at each location do not need any special software and they are not aware that the IPSec encapsulation process takes place. The XTM device looks at traffic that comes from and goes to computers on its protected networks. It knows what traffic to encrypt and send to the other office based on the source and destination IP address of the traffic and the VPN settings. Figure 1: Normal traffic and VPN traffic IPSec is built on a collection of several different protocols. BOVPNs can have more than 30 settings. The configuration on your XTM device must mirror the configuration of its peer device. We will look at every setting in the XTM device VPN configuration to give you the information you need to make successful VPNs every time. Ports, Protocols, and Traffic Types for IPSec VPNs UDP port 500 Internet Security Association and Key Management Protocol (ISAKMP) and Internet Key Exchange (IKE) Before you can send traffic through the VPN, the two devices must exchange a series of messages in what we call negotiations. You will learn about these message exchanges in the subsequent sections. These negotiations begin over UDP port 500. If UDP port 500 is not open between the two devices, IPSec VPNs do not work. UDP port 4500 NAT Traversal (NAT-T) NAT traversal can overcome the limitations of some NAT devices that are incompatible with IPSec traffic. If one of the devices is behind a network device that does Network Address Translation 2 WatchGuard Fireware XTM Training

7 What You Should Know (NAT), the VPN negotiations can move to UDP port 4500, and all subsequent traffic between the two devices uses UDP port NAT-T prevents the NAT device from interfering with the IPSecencoded traffic by re-encapsulating it in an additional layer of UDP and IP headers. IP Protocol 50 Encapsulating Security Payload (ESP) After VPN negotiations succeed, traffic between the two sites can be securely and privately sent over the tunnel with ESP. ESP authenticates and encrypts the traffic and encapsulates it in new IP datagrams with IP protocol 50. The ESP traffic may or may not be re-encapsulated in UDP port 4500 packets, depending on whether NAT-T is used. IP protocol 51 Authentication Header (AH) Similar to ESP, AH encapsulates VPN traffic between the two sites after VPN negotiations succeed. AH does not encrypt traffic, however, it only guarantees that the traffic came from the correct source and that it was not tampered with in transit. Because AH does not provide privacy (encryption), it is rarely used for IPSec VPNs today. IP protocol 50 and 51 are not ports; no ports are associated with ESP or AH. ESP and AH are distinct IP protocols, like ICMP (IP protocol 1), TCP (IP protocol 6), or UDP (IP protocol 17). About VPN Negotiations When two IPSec gateway devices want to make a VPN between them, they exchange a series of messages about encryption and authentication, and agree on many different parameters. This process of agreeing on the VPN parameters is called VPN negotiations. One device in the negotiation sequence is the initiator and the other device is the responder. VPN negotiations happen in two distinct phases: Phase 1 and Phase 2. Policy Manager puts the settings for the two phases in two areas: When you create the branch office gateway, you configure Phase 1 settings. When you create the branch office tunnel, you configure Phase 2 settings. Phase 1 The main purpose of Phase 1 is to set up a secure encrypted channel through which the two devices can negotiate Phase 2. When Phase 1 finishes successfully, the devices quickly move to Phase 2 negotiations. If Phase 1 fails, the devices cannot begin Phase 2. Phase 1 negotiations can use one of two modes: Main Mode or Aggressive Mode. We discuss the two modes in more detail in a subsequent section. Phase 2 The purpose of Phase 2 negotiations is for the two peers to agree on a set of parameters that define what traffic can go over the VPN, and how to encrypt and authenticate the traffic. This agreement is called a Security Association. About the Gateway Name and the Tunnel Name Phase 1 negotiations are often called IKE negotiations or ISAKMP negotiations. Depending on the mode used, they are also called Aggressive Mode Negotiations or Main Mode Negotiations. Phase 2 negotiations are often called IPSec negotiations or Quick Mode negotiations. When you create a gateway and tunnel, you assign names to each of them. These names are for your use only; the XTM device does not send them to the remote peer. Use a name that helps you identify the remote device for the gateway. Do not use the same name for the gateway name and the tunnel name. For the examples in the next sections, we call the gateway To_Main_Office, and we call the tunnel Main_Office_Tunnel. In the next section we introduce some terms you might see in the training. Then, we look at all the different parameters that the two VPN devices agree upon during the VPN negotiations. Finally, we show all steps required to set up a VPN between two XTM devices. Branch Office VPN Tunnels 3

8 IPSec is built on a collection of open standards, protocols, and algorithms that include: Internet Key Exchange (IKE) protocol Oakley key determination protocol Diffie-Hellman key exchange algorithm Internet Security Association and Key Management Protocol (ISAKMP) Authentication Header (AH) Encapsulating Security Payload (ESP) Encryption algorithms: DES 3DES AES (128, 192, or 256- bit key length) Authentication algorithms: HMAC-SHA1 HMAC-MD5 IPSec operates at the Network layer, Layer 3, of the OSI (Open Systems Interconnection) Reference Model. Terms and Definitions Use this list as a reference for the rest of the training course. AES Advanced Encryption Standard This encryption algorithm is the strongest available. Fireware XTM can use AES with encryption keys of length 128, 192, or 256 bits. AES is also more efficient and more secure than 3DES. Aggressive Mode One of the two modes that Phase 1 VPN negotiations can use. It uses a total of three messages between the two IKE peers. Aggressive Mode does not give protection for the identities of the two IKE peers. AH Authentication Header Defined in RFC 2402, AH provides security by adding authentication information to the IP datagram. Because AH does not provide encryption, it is not typically used for VPNs. Because AH calculates a message digest of the entire IP packet, AH can never be used behind a device that does network address translation (NAT). NAT, by definition, changes IP headers. This means that verification of the message digest that AH calculates will always fail when NAT is involved. The Internet Assigned Numbers Authority (IANA) assigned AH the IP protocol number 51. (Compare to TCP which is IP protocol 6, and UDP which is IP protocol 17.) DES Data Encryption Standard An older encryption algorithm that is still in wide use. It uses an encryption key that is 56 bits long. 3DES Triple-DES or three-des An encryption algorithm based on DES. The DES encryption algorithm is applied to a data set once with one symmetric key, and then the result is encrypted again with DES with a different key. Finally, this result is encrypted one more time with DES with the first key. Diffie-Hellman group (DH group) A group of integers used for the Diffie-Hellman key exchange. The Diffie-Hellman group is also called the DH group or key group. Fireware XTM can use DH groups 1, 2, and 5. The larger key groups give larger integers to use in the exchange, which provides stronger security. 4 WatchGuard Fireware XTM Training

9 What You Should Know Diffie-Hellman key exchange A method of making a shared encryption key available to two entities without actually exchanging the key. The encryption key for the two devices is used as a symmetric key for encrypting data. The security of the resulting encryption key comes from the extreme difficulty of solving certain mathematical problems in reverse (the discrete logarithm problem). Only the two parties involved in the key exchange can get the shared key, and the key is never sent over the wire. ESP Encapsulating Security Payload Defined in RFC 2406, ESP provides confidentiality and integrity of data. ESP takes the original data payload of a data packet and replaces it with encrypted data. It adds integrity checks to be sure that the data is not altered in transit, and that the data came from the proper source. The Internet Assigned Numbers Authority (IANA) assigns a number to each protocol. For ESP, the IP protocol number is 50. (Compare to TCP, which is assigned IP protocol number 6, and UDP, IP protocol number 17.) Hash A mathematical transform applied to a set of data. This transform takes a string of bits as input and produces an output called the hash or hash value. (The hash value is normally much smaller than the original data input.) A hash is generally a oneway function. It is not possible to find the original input if the only data you have is the hash. There are different hash algorithms, but for any given input and any given algorithm, the hash value is always the same. If two entities each have a set of data and they want to see if they are the same data set without actually exchanging the data, they can both use the same hash algorithm to compute the hash of their own data set. Next, they exchange the hash values that they each compute and compare them. If the two hash values match, then the input data is the same on each side. If the hash values do not match, then the data sets are not identical. VPN traffic uses a variation of the hash method called a Hashed Message Authentication Code or HMAC (sometimes also called a Keyed HMAC). Similar to the normal use of hash functions, each VPN peer computes hashes of data to guarantee the data s integrity. In addition, each side mixes the data with a secret key before the hash is computed. This guarantees the authenticity of the data; each side knows that the data came from the authorized peer and not an imposter or attacker. IKE Internet Key Exchange Defined in RFC 2409, IKE specifies methods to obtain authenticated keying material for use with ISAKMP. IKE peer The entity to which your XTM device makes a VPN tunnel. The IKE peer is typically another IPSec device such as another firewall, or a remote user s computer with software that can make an IPSec VPN tunnel. IPSec A collection of cryptography-based services and security protocols to protect communication between entities that send traffic through an untrusted network (such as the public Internet). ISAKMP Internet Security Association and Key Management Protocol Defined in RFC 2408, ISAKMP provides a framework to use to authenticate a communicating peer, for key generation techniques, and to manage (negotiate, form, and destroy) Security Associations. IKE and Oakley operate within this framework. Symmetric-key encryption is an encryption scheme where both parties share one key that is used to both encrypt and decrypt data. It is much faster than the alternative, asymmetric-key encryption. In what is known as public-key cryptography, one private key encrypts the data and a different public key decrypts it. It is not possible to use publickey encryption for every set of data that goes through a VPN fast enough for acceptable throughput. Public-key cryptography is used in the Diffie-Hellman key exchange algorithm, but ultimately a symmetric key is used to encrypt the data through the VPN. The symmetric key is derived through the highly secure Diffie- Hellman key exchange. Because the hash value is much smaller than the actual, raw data, it is much more efficient to compute hash values and use them to compare data sets than to exchange and compare the raw data. Branch Office VPN Tunnels 5

10 Phase 1 keys usually expire based on an amount of time, but some devices allow expiration of Phase 1 keys based on the amount of data exchanged. Fireware XTM expires the Phase 1 key based only on the amount of time passed. Phase 2 keys usually expire based on an amount of time or an amount of data sent. The first event that happens (time elapsed or amount of data sent) causes the key to expire. If you set either the time or data limit to zero, the XTM device disregards that limit. If you set both the time and data limits to zero, the XTM device expires the key after 8 hours. If you set the data limit to less than less than 24,576 kilobytes, then 24,576 kilobytes is used. Key expiration Phase 1 and Phase 2 session and encryption keys change periodically. This makes sure an attacker cannot get access to a large data set with the same encryption keys. When a key must change, the appliance declares the current key no longer valid and negotiates a new key with the IKE peer. Main Mode One of the two modes that Phase 1 VPN negotiations can use. It uses a total of six messages between the two IKE peers. Main Mode gives protection to the identities of the two IKE peers. MD5 Message Digest 5 This is a hash algorithm. Verification of the MD5 sum provides data integrity (a guarantee that the data has not changed in transit). In IPSec, authentication of the data (a guarantee that the data came from the proper source) is achieved by enhancing the hash with a shared secret key (see HMAC explanation in the definition of hash). MD5 is not considered as strong a hash algorithm as SHA-1. Oakley Oakley Key Determination Protocol This is a protocol for two parties to agree on a secret key. RFC 2412 describes the protocol named Oakley, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. PFS Perfect Forward Secrecy A guarantee that the keying material used to generate one encryption key is not used to generate a new encryption key. If one key is compromised, it gives the attacker no information about subsequent encryption keys. Quick Mode The mode that Phase 2 VPN negotiations use. Quick Mode is the only mode that Phase 2 uses. The two IKE peers exchange three messages to complete Quick Mode. Replay An attack that captures data packets sent from one IKE peer to another, and then sends them to the recipient again. The attacker can get information about the IPSec implementation from the responses it gets from the recipient. Fireware XTM uses the sequence numbers in ESP packets to reject duplicate packets and old packets, to protect against replay attacks. 6 WatchGuard Fireware XTM Training

11 What You Should Know SA Security Association This is a contract between two IPSec endpoints. The SA is an abstract object that contains all the information necessary for two entities to exchange data securely. Successful completion of each part of VPN negotiations, Phase 1 and Phase 2 negotiations, results in an SA. There is only one Phase 1 SA between two IKE peers. The Phase 1 SA defines encryption and authentication parameters that protect all Phase 2 negotiations. The Phase 2 SA is unidirectional. If a tunnel is a bidirectional tunnel (traffic can go in and out of the protected network), each peer has one incoming SA and one outgoing SA for that tunnel. Thus, each tunnel has at least one Phase 2 SA, and usually has two. However, there can be multiple tunnels between two IKE peers. Each Tunnel Route you add to the Branch Office Tunnel results in at least one unique Phase 2 SA (and usually two, because most tunnels are bidirectional) when Phase 2 negotiations finish. SHA-1 Secure Hash Algorithm 1 A type of hash algorithm called a cryptographic hash function. It provides data integrity (a guarantee that the data has not changed in transit) as well as authentication of the data (a guarantee that the data came from the proper source). SHA-1 is considered a stronger hash algorithm than MD5. SPI Security Parameters Index This is a unique 32-bit number that identifies an IPSec (Phase 2) SA. The SPI number is an identifier in the header of every IPSec data packet. This number tells the receiving gateway device to which IPSec data flow the packet belongs. The SPI number is not bidirectional. Each device keeps an SPI number for traffic it sends (outgoing SPI) and an SPI number for traffic it receives (incoming SPI). Traffic selector The configuration parameter that tells the gateway device what traffic should be handled by IPSec. Traffic selectors in Fireware XTM are called tunnel routes. Traffic selectors consist of source IP addresses and destination IP addresses. Each peer has a reverse match of the other peer s traffic selectors. If one peer has subnet A as the local part of its traffic selector and subnet B as the remote part of its traffic selector, then the other peer has subnet B as local and subnet A as remote. When a data packet comes in from a host on an internal network, Fireware XTM checks to see if the source and destination IP addresses of the packet match a traffic selector. If they do, and if there is a policy to allow the traffic, then Fireware XTM encapsulates the data packet in IPSec and sends it to the IPSec peer. Phase 1 SAs are sometimes called ISAKMP SAs. Phase 2 SAs are usually called IPSec SAs. In Fireware XTM and later, the XTM device does a route lookup first. If a traffic flow matches an IPSec traffic selector, but a route to the destination is also in the device s local routing table (not in the device s default route), the device can honor that route. You can configure the device not to use IPSec to handle the traffic when a non-default route exists in the local routing table. Branch Office VPN Tunnels 7

12 In previous versions of Fireware XTM 11.x, the XTM device always used IPSec to process the traffic when a traffic selector matches. In v and later, you can control this behavior in Policy Manager (select VPN > VPN Settings). To configure the XTM device to honor nondefault routes and use them to take precedence over IPSec traffic selectors, select the Enable the use of non-default (static or dynamic) routes to determine if IPSec is used check box. Tunnel The virtual path between two locations on the Internet that have a VPN between them. This virtual path is called a tunnel because data packets are encapsulated inside ESP headers and trailers, and inside a new IP header. Thus, two computers behind two IKE gateways can send packets to private IP addresses, effectively tunneling through the public Internet. What Happens During Phase 1 Negotiations The main purposes of Phase 1 are: To mutually authenticate the IKE peers. Each peer presents authentication credentials to its peer. The credentials can be either a shared secret or an IPSec certificate. If one peer does not accept the credentials of the other, Phase 1 negotiations fail. To set up a secure encrypted channel through which the two devices can negotiate Phase 2. When Phase 1 finishes successfully, the devices quickly move on to Phase 2 negotiations. The Phase 2 negotiations are protected by the encryption and authentication parameters agreed upon during Phase 1. If Phase 1 fails, the devices cannot begin Phase 2. When you configure a VPN, the first thing you do is to add a gateway. You configure all the Phase 1 settings when you create the gateway. To create a new Branch Office VPN Gateway: 1. Open Policy Manager for your XTM device. 2. Click. Or, select VPN > Branch Office Gateways. The Gateways dialog box appears. Figure 2: Add a Branch Office Gateway 8 WatchGuard Fireware XTM Training

13 What You Should Know 3. Click Add. The New Gateway dialog box appears. The subsequent sections discuss the different parts of this dialog box. Figure 3: New Gateway The Devices Exchange Credentials During Phase 1, the two devices exchange credentials to ensure that only an authorized peer is able make a VPN tunnel. Each device sends its credentials to the other device along with a Phase 1 identifier. Phase 1 identifiers are examined in the section, The devices find and identify each other on page 10. You can select Pre-Shared Key or IPSec Firebox Certificate for the type of credentials the peers use to prove their identities to each other. Both gateway endpoints must use the same credential method. For example, if one peer uses preshared key, the other peer must also use pre-shared key. And, if one peer uses certificates, the other peer must also use certificates. Branch Office VPN Tunnels 9

14 You specify which method the peers use in the New Gateway dialog box, on the General Settings tab, in the Credential Method section. Figure 4: Credential Method Pre-Shared Key The pre-shared key is a way for each device to prove that it is the authorized IKE peer for this VPN. The devices use the pre-shared key, along with the Phase 1 identifier, to verify that the remote peer is the correct entity and not an imposter. Do not give the pre-shared key to anyone except the administrator of the remote IKE peer device. If you use a pre-shared key, make sure to choose characters that are difficult to guess. You can use a string of numbers, upper and lower-case letters, and punctuation marks. The pre-shared key must exactly match the pre-shared key that the remote device uses. We recommend that you use pre-shared keys for your first VPN. They are easier to configure than certificates, and it is less likely that you will make an error. IPSec Firebox Certificate A certificate is a document used to verify the identity of an unknown individual. For IKE negotiations, the unknown individual is the remote IKE peer. During Phase 1 negotiations, the two IKE peers exchange certificates. If each device accepts the peer s certificate, then each side trusts that the peer is actually who it claims to be. You can use an IPSec certificate for the credential method only if a certificate appears in the Select the certificate to be used for the Gateway list at the bottom of Figure 4. We discuss certificates in more detail in a subsequent section. The devices find and identify each other When your XTM device initiates Phase 1 negotiations, it determines: How do I identify myself to the remote peer? If I have more than one external interface, which one do I use to send IKE packets to the peer? Do I know how to find the remote device? Do I know its IP address or can I learn its IP address from a DNS query? 10 WatchGuard Fireware XTM Training

15 What You Should Know When your XTM device responds to IKE negotiations from the peer, your XTM device must decide: Does my configuration allow me to negotiate with this device, based on the way the device identifies itself and the source IP address of the IKE packets? If I specified more than one external interface for this peer to use for negotiations, did the IKE packets come to the correct one? You specify how the XTM device answers these question when you configure the Gateway Endpoints at the bottom of the New Gateway dialog box. The Use modem for failover check box appears only if serial modem failover is enabled in the device network settings. Figure 5: Gateway Endpoints Each row in the Gateway Endpoints list in Figure 5 represents one set of gateway endpoints. You can add more than one set of gateway endpoints if either device has more than one external interface it can use to send and receive IKE negotiations. This allows VPN Failover to occur. An IPSec device can terminate a specific VPN on only one interface at a time. However, if a device has more than one external interface and one of them is not available, your XTM device can try to negotiate the VPN through a different external interface. You can also use a modem for VPN failover, if you have enabled serial modem failover on the device. Your XTM device can do VPN failover if: Your XTM device runs Fireware 10.x or later, has more than one external interface, and the remote device can do VPN failover. You want your XTM device to use one external interface to make the first VPN connection. However, if that interface is not available, you want your device to use a different external interface to make the VPN connection. In Fireware XTM v11.7 and higher, modem failover is supported on XTM 2 Series, 3 Series, and 5 Series devices. The remote peer is a Firebox X e-series or WatchGuard XTM device that runs Fireware 10.x or later, and it has more than one external interface. You want your XTM device to make the VPN connection to one of the remote peer s external interfaces first. However, if that interface is not available, you want your device to be able to make the VPN connection with one of the remote peer s other external interfaces. Your XTM device has a dial-up modem connection that you can use for failover. You want your XTM device to use an external interface to make the VPN connection. However, if no external interfaces are available, you want to use the modem to make the VPN connection. We examine VPN failover in detail in a subsequent section. The XTM device automatically starts tunnel negotiation upon reboot if the Start Phase1 tunnel check box is selected. Branch Office VPN Tunnels 11

16 To add a set of gateway endpoints: 1. Open the New Gateway dialog box. 2. Click Add. The New Gateway Endpoints Settings dialog box appears. Figure 6: Add a new set of gateway endpoints This dialog box has two separate sections used to define a set of gateway endpoints: Local Gateway This section is for identification of the local gateway (at the top), and is used to configure how this XTM device identifies itself. Remote Gateway This section is for identification of the remote gateway (at the bottom), and is used to configure how the XTM device expects the peer to identify itself. A set of gateway endpoints is a set of Phase 1 identifier information for each IKE peer (your XTM device and the remote device). Phase 1 identifiers are used like this: Each side configures its device to send identifying information (Phase 1 ID) to the other side during Phase 1. The ID has a specific type and a value for that type. Each side also specifies an ID type and a value for that ID type for the remote device. This tells the local device what to expect from the remote device during Phase 1 negotiations. Each device s Phase 1 identifier must exactly match what the other device expects to receive. If the ID information that one device sends to its peer does not match what the peer expects, IKE negotiations fail. 12 WatchGuard Fireware XTM Training

17 What You Should Know Each device can use one of four types of identifiers, or Phase 1 ID types: IP Address (ID_IPv4_ADDR) The value for this ID type must be a dotted-decimal IP address, without a subnet mask. This is almost always the IP address assigned to the device interface that terminates the VPN. In some network topologies, the value for the IP address ID type can instead be the IP address of a device configured for Network Address Translation (NAT) that is between the IPSec device and the Internet. In these cases, the NAT device has a one-to-one NAT mapping that sends all ports and protocols to the IPSec device behind it. Domain Name (ID_FQDN) The value for this ID type is a string of text. This is usually a fully qualified domain name (such as example.domain.com or myexample.com) that has a record in the DNS system for the IP address assigned to the external interface. It is not necessary for this name to have a corresponding record in DNS. The value for this ID type can also be a simple name that serves only as a Phase 1 identifier, but does not have an address record in DNS. If your XTM device has a static IP address on the external interface and you publish a DNS record for this IP address, you can use the domain name for the Phase 1 identifier. To learn your XTM device IP address, the other device can send a DNS query for the domain name. However, in these cases you usually use the IP address for the Phase 1 identifier because the IP address never changes. If your XTM device has a dynamic IP address and you use the Dynamic DNS service, you can use the DynDNS host name for your Phase 1 identifier, for example, myexample.dyndns.org. The dynamic DNS service lets the remote peer find your XTM device with a DNS query even when your XTM device IP address changes often, so that the peer can initiate IKE negotiations. Remember, this ID type is intended to relate to a DNS record but it is not necessary. Consider this scenario: IPSec device A has a dynamic IP address but does not use a dynamic DNS service. Thus the DNS system has no record for device A s external interface. Device A can use Domain Name for its ID type, and the value can be a string of text that does not have a record in the DNS system. This is the only identifier information that the other IKE peer, device B, knows about device A. When device B wants to initiate IKE negotiations to make the VPN to device A, device B sends a DNS query to resolve this name to an IP address. The DNS query fails and device B cannot find device A. In this scenario, device A must be the initiator. IKE negotiations can succeed in this scenario as long as all other parameters match. Aggressive Mode must be used. If you use certificates for the credential method, the value for this ID type is the DNS Name or Domain Name field in the certificate. When you view the certificate with a Windows certificate viewer, the certificate field name is DNS Name, and it is listed as a Subject Alternative Name. If you enable VPN failover to a modem, you must configure the local gateway to use an ID (rather than an IP address) for the gateway ID type. The ID does not need to match an actual domain name. After each ID type we show the common representation of the ID type as it is defined in the relevant RFCs. For example, with the IP Address ID Type, the IKE RFCs define the ID type ID_IPv4_ADDR. When the appliance has a dynamic IP address but no DNS record, you can use this ID type and the next one (User ID on Domain) in a similar way. A later side note tells you the main difference between the two types in this situation. Branch Office VPN Tunnels 13

18 Some IPSec appliances can use User ID on Domain for the remote peer only, and cannot use it for the local identifier. Firebox SOHO, SOHO 6, and legacy (non-e- Series) Edge appliances cannot use User ID for the local gateway identifier. Devices running Fireware XTM and WFS can use User ID for the local ID. The main difference between the User ID on Domain and the Domain Name ID types when the external IP address is dynamic is this: the peer does not try to resolve a User ID on Domain with a DNS query, but it usually does try to resolve a Domain Name. With User ID on Domain, the peer simply waits for the remote device to begin IKE negotiations. With Domain Name the peer can try to initiate negotiations by first doing a DNS query to find the other device. User ID on Domain (ID_USER_FQDN) This is typically a user s ID in the form of an address, such as bsmith@myexample.com. It can also be a simple string of text that does not represent a real address, such as bobs_firebox. If you do not use certificates for the credential method, the value of the ID is only a string of identifying text. It can be a real address, or just a simple name. You usually use this ID type when the remote IKE peer is a user who connects from a single computer (instead of an IPSec device such as a firewall). This is the case with the WatchGuard Mobile VPN client: the software uses User ID on Domain for its local Phase 1 identifier. (In the profile settings of the WatchGuard Mobile VPN IPSec client software, the local identifier is called Fully Qualified Username. The Phase 1 ID type that the WatchGuard Mobile VPN client sends is actually ID_USER_FQDN.) If an IPSec appliance that acts as the IKE gateway supports it, this ID type can be the device s own local Phase 1 identifier. You can use this ID type for the local identifier if your XTM device has a static IP address or a dynamic IP address on its external interface. If the IP address on your XTM device is dynamic, this ID type creates a situation that is similar to the previous scenario (a domain name that does not resolve to an IP address in DNS). When a device has a dynamic IP address and it uses this ID type for its Phase 1 identifier, it must be the initiator. This is because the identifier alone is not sufficient information for its peer to find it. The value for this ID type never resolves to an IP address in DNS. If you use certificates for the credential method, the value for this ID type is usually the address field in the certificate. The certificate field name is RFC822 Name, and is listed as a Subject Alternative Name when you view the certificate with a Windows certificate viewer. X500 name (ID_DER_ASN1_DN) Use this ID type only when you use certificates for the credential method. The value for the ID is the value of the certificate s Subject field. The format of an X500 name is similar to the format of a distinguished name in an LDAP-style directory service. For example: CN=MyExample,OU=Main Office,O=myexample.com,ST=NY,C=US The Local Gateway Identifier In the Local Gateway section, you configure the gateway identification information for the XTM device. You also configure the external interface that sends and receives local packets when the XTM device uses the local gateway. Figure 7: Local Gateway information 14 WatchGuard Fireware XTM Training

19 What You Should Know The details you include in the Local Gateway section depend on how the external interface is configured: If your XTM device has a static public IP address on the external interface, your XTM device should use the external interface IP address to identify itself to the remote device. Select the By IP Address option. In the IP Address text box, select or type the external interface IP address. If your XTM device has a dynamic IP address on the external interface (DHCP or PPPoE), the IP address assigned to your XTM device external interface changes often, so the remote peer cannot expect your XTM device to use the external interface IP address as the IKE identifier. In this case, you must select the By Domain Information option. Then click Configure. In versions prior to 11.x, the IP Address drop-down list in Figure 7 shows the IP addresses for all the XTM device interfaces. Be careful to not select an optional or trusted IP address. The XTM device can terminate BOVPNs only on external interfaces. Figure 8: Local Gateway ID information if the XTM device has a dynamic address The Configure Domain for Gateway ID dialog box appears: Figure 9: Local Gateway ID information if you do not use certificates Branch Office VPN Tunnels 15

20 If you use pre-shared keys for the credential method, you can specify two different types of Domain Information identifier: The XTM device Dynamic DNS capability uses only the service provided by Dynamic Network Services (also known as DynDNS.com or DynDNS.org). There are other Dynamic DNS services with the same capability. If you use one of these services, you usually have a computer on a network behind the XTM device that runs a Dynamic DNS updater client software package. The ID Type X500 that appears in Figure 10 is not available for the Local ID if you do not use certificates. It is always available for the Remote ID. By Domain Name If you registered your own domain name, use that name. Because the remote peer will usually send a DNS query to find your XTM device IP address, the DNS system should always resolve this domain name to the external IP address of your XTM device. If you use the Dynamic DNS capability of the XTM device, you can use the DynDNS domain name that you register. This way, the remote device can find your XTM device by DNS lookup. It is not necessary for the DNS system to have a record associated with the name you use here. If the DNS system does not have a record for this domain name, then the remote device cannot find your XTM device by DNS lookup. In this case, your XTM device must be the one to initiate the IKE negotiations. Remember that the remote peer usually does a DNS query to resolve this name to an IP address, even when the DNS system has no such record. If you do not register a DNS name for your XTM device (whether DynDNS or a static record), you should use the next ID type, User ID on Domain, so that the remote peer does not waste CPU cycles with an unnecessary DNS query. By User ID on Domain Use this ID type if the DNS system has no address record for your XTM device external interface IP address. In this case, your XTM device must be the initiator. If the XTM device has a certificate available and you use certificates for the credential method in Figure 4, one additional option appears in the Figure 9 dialog box: By x500 Name: Figure 10: Local Gateway ID information if you use certificates for the credential method You can use this type of local gateway identifier only if you use certificates for the credential method. The X500 name is the distinguished name in the certificate you select for this gateway. This name appears in the certificate as the Subject Name. When you use certificates for credentials and you select By Domain Information for the local gateway identifier, you cannot edit the value for the local ID type you select. Policy Manager automatically puts the correct value for the ID type you select, based on the information in the XTM device certificate. 16 WatchGuard Fireware XTM Training

21 What You Should Know The Remote Gateway Identifier In the Remote Gateway section, you configure the information for the remote IKE peer. This is how the XTM device expects the remote peer to identify itself. Figure 11: Remote Gateway information For this XTM device to find the remote device, one of these conditions must be true: The XTM device must know the IP address of the peer ahead of time. If the remote device has a static IP address, select Static IP address and type the IP address in the IP Address text box. The XTM device must know a domain name that the DNS service can resolve to an IP address. If the remote device has a dynamic IP address, select Dynamic IP address. If there is a domain name the XTM device can use to find the remote device, you set it in the next section. If your XTM device cannot find the peer s IP address with a DNS query, the remote device must be the initiator. In Phase 1, the remote IKE peer must identify itself correctly. To identify itself, the remote device can use any of the four ID types discussed at the start of this section. If the XTM device cannot find the peer with one of those methods, then it cannot initiate negotiations. It must wait for the other device to initiate negotiations. In the Specify the gateway ID for tunnel authentication section, you select which ID type the remote peer uses, and the value of that ID type. If the remote device has a static IP address, it should use that IP address for the phase 1 identifier. Select By IP Address and type the remote peer IP address. For the other three identification types, select By Domain Information and click Configure. Refer to the previous sections for information on these ID types. If you use certificates and you do not use an IP address for the remote ID type, you must manually type the domain information (whether Domain Name, User ID on Domain, or X500 name). You can get this information from the remote device administrator or if you view the remote peer s certificate in a certificate viewer. Branch Office VPN Tunnels 17

22 When you use Domain Name or User Domain to specify the remote gateway ID, the Attempt to resolve check box controls whether the XTM device attempts to resolve the domain. Select the Attempt to resolve check box if the remote gateway uses dynamic DNS to maintain a mapping between a dynamic IP address and a domain name. You must use Aggressive Mode if the credential method is pre-shared keys and one of the devices has a dynamic IP address. The Devices Decide Whether to Use Main Mode or Aggressive Mode Phase 1 negotiations can use one of two modes: Main Mode or Aggressive Mode. The device that starts the IKE negotiations (the initiator) sends either a Main Mode proposal or an Aggressive Mode proposal. The responder can reject the proposal if it is not configured to use that mode. Aggressive Mode communications take place with fewer packet exchanges than Main Mode communications. Aggressive Mode is less secure but faster than Main Mode. To specify how the XTM device starts negotiations, in the New Gateway dialog box, select the Phase 1 Settings tab. Figure 12: Select the mode to use for Phase 1 negotiations 18 WatchGuard Fireware XTM Training

23 What You Should Know The XTM device can use one of three methods to start IKE negotiations: Main Mode Main Mode IKE negotiations require a total of six messages (three two-way exchanges of information). The peers never exchange their identities in the clear. Use Main Mode when both devices have static external IP addresses. If you use pre-shared keys for the credential method, to use Main Mode, both sides must use an IP address as the Phase 1 ID. If one side or the other does not use an IP address for the Phase 1 ID type, you can use Main Mode only if you use certificates for the credential method. The XTM device will not use Aggressive Mode if you select Main Mode. Aggressive Mode Aggressive Mode IKE negotiations require a total of four messages. Each message includes more information than in a Main Mode exchange. This makes Aggressive Mode more efficient than Main Mode, but not as secure, because the peers exchange their identities without encryption. Use Aggressive Mode when one of the devices has a dynamic external IP address, or both have dynamic IP addresses. An exception is possible when you use certificates for the credential method instead of pre-shared keys. See the previous description about Main Mode. Main failback to Aggressive To start IKE negotiations, the XTM device sends a Main Mode packet. If the remote gateway device rejects the first packet, the XTM device sends an Aggressive Mode packet to try to start IKE negotiations again. When the XTM device is the responder, it completes either a Main Mode or an Aggressive Mode exchange, depending on the way the peer initiates IKE negotiations. Select this option if it is possible for the remote peer to use Main Mode, but you want negotiations to succeed if the remote peer can only use Aggressive Mode. The two devices agree on all the same Phase 1 parameters regardless of which mode is used. The difference is the number of packet exchanges and how much information each packet contains. The Devices Agree on Whether to Use NAT Traversal NAT Traversal (NAT-T) is an IPSec extension that can resolve problems that occur when one or both of the IKE peers is behind a device with NAT. Some devices use NAT in a way that breaks IPSec, or in a way that makes it impossible to allow more than one IPSec connection through the NAT at the same time. To enable NAT Traversal, select the Phase 1 Settings tab. Figure 13: NAT Traversal fields Branch Office VPN Tunnels 19

24 There are many different types of Vendor-IDs. The NAT-T Vendor-ID includes a special hash to signify that it is for NAT-T. When the IKE peers agree to use NAT Traversal, they make an additional step for each data packet sent over the VPN. After an IPSec device encapsulates a data packet inside the IPSec wrapper, it encapsulates it one more time inside a UDP wrapper. By re-encapsulating traffic in UDP packets, the IKE peers can overcome the problems that IPSec has with some implementations of NAT. Traffic goes over UPD port 4500 when NAT Traversal is used. How the Peers Agree on Whether to Use NAT-Traversal Each side advertises its ability to use NAT-T in the first IKE packet. If a device can use NAT-T, the first IKE packet from the device contains a part called a Vendor-ID payload. If both the initiator and the responder include the NAT-T Vendor-ID payload, then they can use NAT-Traversal. How the Peers Detect Whether One of Them is Behind a NAT Device If the peers can both use NAT-T, the second IKE packet from each peer includes a part called the NAT- Discovery payload. The NAT-Discovery payload that one device sends includes the result of a computation that is based on the source and destination IP addresses and the source and destination ports of the packet when it leaves the IKE device. When the peer device gets the NAT-Discovery payload, it performs the same computation in reverse, based on the same type of information. However, the receiving end does the computation based on the information it sees for the packet (which can be different from the information the sending device sees when a NAT device is between the two). Both sides compare the results of their own computation with the corresponding value each gets from the other side. If one or both of the devices is behind a NAT, then the two results of the same computation do not match because NAT changes the source IP addresses, the source ports, or both. The mismatch means that there is a NAT device in front of one of the IKE peers. If the values do match, then no NAT is detected and the devices do not use NAT-T. Even though both devices can use NAT-T, it is not necessary if neither device is behind a NAT. How Data Traverses the NAT If both devices can do NAT-Traversal, and if a NAT is detected, then the devices immediately change the port they use to communicate. The remaining IKE negotiations switch to UDP port Data transfers over the VPN also use UDP port 4500, instead of ESP as the transport method. After the VPN finishes negotiation of Phase 1 and Phase 2, actual data can be sent over the VPN. When NAT-T is used, data sent over the VPN is encapsulated in IPSec before the device sends it, just as the device normally does without NAT-T. However, with NAT-T each packet is re-encapsulated once more inside a UDP port 4500 packet before the device sends it. When the peer gets a NAT-T packet that contains data, it unwraps the IPSec packet from the UDP encapsulation. Then it can process the resulting packet as it normally does for IPSec traffic. The NAT Traversal Keep-Alive The NAT-T keep-alive keeps the NAT open on the NAT device. A NAT device does outbound Network Address Translation by changing the source port and source IP address of a packet before it sends it. The device keeps a map of the original source port/ip address and the new source port/ip address. It uses the map so that when a packet returns in response (when the destination of the response packet is the translated source port and translated source IP address), it can send the response back to the correct computer (the response to the original IP address that started the data flow is sent with the flow s original source port). 20 WatchGuard Fireware XTM Training