advanced vpn training v11 9

8/10/2019 Advanced VPN Training v11 9

1/120

WatchGuard Certified Training

Branch Office VPN Tunnels and

Mobile VPN

Fireware XTM and WatchGuard System Manager v11.9

Revised: June 2014

Updated for: Fireware XTM v11.9


2/120

TRAINING

www.watchguard.com/training

[email protected]

SUPPORT

www.watchguard.com/support

[email protected]

U.S. and Canada +877.232.3531

All Other Countries +1.206.613.0456

ii WatchGuard Fireware XTM Training

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 2014 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.


3/120

ii

Table of Contents

Branch Office VPN Tunnels .................................................................................................... 1

Introduction .................................................................................................................... 1What You Will Learn ...................................................................................................................... 1

Exercises ....................................................................................................................................... 1

What Branch Office VPNs Can Do For You .................................................................................. 1

What You Should Know ................................................................................................. 2How Branch Office VPNs work ..................................................................................................... 2

Branch Office VPN Types .............................................................................................................. 4

Which VPN Type to Use? ............................................................................................................... 5

BOVPN Virtual Interface Routing Scenarios ............................................................................... 5Terms and Definitions .................................................................................................................. 7

What Happens During Phase 1 Negotiations .......................................................................... 11

What Happens During Phase 2 Negotiations .......................................................................... 28

How VPNs Work With Multi-WAN ............................................................................................... 36

How VPNs Work With Modem Failover ...................................................................................... 37

Use IPSec Certificates for the IKE Credentials ......................................................................... 37

Add Policies in Policy Manager to Allow VPN Traffic ................................................................ 41

See VPN Tunnel Status .............................................................................................................. 42

Troubleshoot Branch Office VPN Tunnels ................................................................................ 43

Disable or Enable Branch Office VPNs ..................................................................................... 45

Exercises Before You Begin ..................................................................................... 46

Training Environment ................................................................................................................. 46Necessary Equipment And Software ......................................................................................... 47

Management Computer Configuration ..................................................................................... 47

Firewall Configuration ................................................................................................................. 47

Exercise 1: Configure a Single-WAN XTM Device and a Multi-WAN XTM Device ....... 48

Exercise 2: Configure a Manual VPN and between the Single-WAN XTM Device and the

Multi-WAN XTM Device ................................................................................................... 51

Exercise 3: Configure a BOVPN Virtual Interface Between a Single-WAN XTM Device and

a Multi-WAN XTM Device ................................................................................................ 56

Exercise 4: BOVPN Virtual Interface with Metric-Based failover ................................. 61

Exercise 5: BOVPN Virtual Interface and Dynamic Routing ........................................ 70

Configure XTM Device A ............................................................................................................ 70Configure XTM Device B ............................................................................................................ 72

Frequently Asked Questions ....................................................................................... 75

Related Courseware and Information ........................................................................ 76

What You Have Learned .............................................................................................. 76

Test Your Knowledge ................................................................................................... 77

Mobile VPN ........................................................................................................................... 79

What You Will Learn .................................................................................................... 79

Connect Remote Users Securely to the Corporate Network ..................................... 79


4/120

iv WatchGuard Fireware XTM Training

Types of Mobile VPN .................................................................................................................. 80

Enable the XTM Device for Mobile VPN .................................................................................... 83

Distribute Client Software and Configuration File ................................................................... 84

Use Mobile VPN with IPSec with an Android Device .................................................. 85Configure the IPSec VPN client on the Android Device ........................................................... 86

Use Mobile VPN with IPSec With a Mac OS X or iOS Device ..................................... 87Configure the XTM Device ......................................................................................................... 87

Configure the VPN Client on an iOS Device ............................................................................. 88Configure the VPN Client on a Mac OS X Device ..................................................................... 88

Use Mobile VPN with L2TP with an iOS Device .......................................................... 89Configure the XTM Device ......................................................................................................... 89

Mobile VPN with L2TP IPSec Settings ........................................................................ 90

Use Mobile VPN with SSL with an Android or iOS Device ......................................... 90Download the Mobile VPN with SSL client profile ................................................................... 90

Exercise 1: Set Up Mobile VPN with L2TP .................................................................... 91

Activate L2TP on the XTM Device .............................................................................................. 91

Add Users to the L2TP-Users Group ......................................................................................... 93

Configure the Client Computer ................................................................................................. 94

Exercise 2: Configure Mobile VPN with IPSec and Prepare Mobile VPN ClientConfiguration Files .......................................................................................................... 96

Exercise 3: Restrict Mobile VPN with IPSec Users by Policy ..................................... 101

Exercise 4: Use the Shrew Soft IPSec VPN Client ...................................................... 104

Install the Shrew Soft VPN Client ............................................................................................ 104

Connect and Disconnect the Shrew Soft VPN Client ............................................................ 105

Exercise 5: Configure the XTM device for Mobile VPN with SSL ............................... 107

Activate the XTM Device for SSL VPN ..................................................................................... 107

Add Users to the SSLVPN-Users Group .................................................................................. 109

Restrict SSL VPN Users by Policy ............................................................................................ 110

Exercise 6: Change the Port Used for Mobile VPN with SSL ..................................... 112

Exercise 7: Use the Mobile VPN with SSL Client ........................................................ 113Install the Mobile VPN with SSL Client ................................................................................... 113Connect with the Mobile VPN with SSL Client ....................................................................... 114

Test Your Knowledge ................................................................................................. 115


5/120

1

Fireware XTM Training

Branch Office VPN Tunnels

Creating IPSec VPNs in Fireware XTM

Introduction

What You Will Learn

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 includeinstructions 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.

Fireware XTM offers two methods to manually create a secure branch office virtual private network

(BOVPN) connections between networks at different sites. In this training module you learn:

How branch office VPNs and VPN negotiation works.

The difference between a BOVPN virtual interface and a standard BOVPN interface.

How to troubleshoot BOVPN tunnels.

How to configure branch office virtual private networks (BOVPNs) between WatchGuard XTM

devices with Fireware XTM, when one or both devices have multiple connections to the Internet.

How to configure a BOVPN virtual interface between two XTM devices.

How VPN failover works.

Exercises

This course includes step-by-step exercises to show you how to configure VPNs in a multi-WAN

environment. Before you start the exercises, make sure to read Exercises Before You Begin, on

page 46. This section has a list of the equipment and software you need for the exercises, 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 betweenthe 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 actuallycomes 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 tunnelsthrough NAT for a transparent connection between the devices.


6/120

2 WatchGuard Fireware XTM Training

What You Should Know

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.

In this training, thegateway device at

each location is a

WatchGuard X TM

device, but your XTM

device can make an

IPSec VPN tunnel to

any device that

implements the IPSec

standards.

One gateway device at each location completes the IPSec encapsulation process for all the computersbehind 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


7/120


Branch Office VPN Tunnels 3

(NAT), the VPN negotiations can move to UDP port 4500, and all subsequent traffic between the

two devices uses UDP port 4500. NAT-T prevents the NAT device from interfering with the IPSec-

encoded 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 ofmessages 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 1and 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.

When you create a BOVPN virtual interface, you configure both Phase 1 and Phase 2 settings.

Phase 1 negotiations

are often called IKEnegotiations or

ISAKMP negotiations.

Depending on the

mode used, they are

also called Aggressive

Mode Negotiations or

Main Mode

Negotiations.

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 ModeorAggressive Mode. We discuss the two

modes in more detail in a subsequent section.

Phase 2

Phase 2 negotiations

are often called IPSec

negotiations or Quick

Mode negotiations.

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

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.


8/120


Branch Office VPN Types

In Fireware XTM, there are three ways to configure a branch office VPN:

Managed VPN Tunnel

A managed VPN tunnel is a BOVPN tunnel that you create between your centrally managed Firebox

and XTM devices. From your WatchGuard Management Server, you can drag-and drop one

managed device onto another managed device to start the wizard and quickly build a managed

VPN tunnel between the two devices. Managed VPN tunnels are not discussed in detail in thiscourse, but use the same security settings and protocols as a manual VPN tunnel.

A managed VPN

tunnel is equivalent to

a manual BOVPN

gateway with an

associated BOVPN

tunnel. You cannot use

the Management

Server to configure a

BOVPN virtual

interface.

Manual BOVPN gateway and associated BOVPN tunnels

You can create a manual BOVPN gateway and add associated BOVPN tunnels for that gateway. This

configuration option enables you to set up a BOVPN tunnel between two Firebox or XTM devices, or

between a Firebox or XTM device and a third-party VPN device that uses the same gateway and

tunnel settings.

When you manually add a BOVPN gateway and associated tunnels to configure a BOVPN tunnel,

you explicitly define the sources and destinations for the traffic you want to send through the

tunnel. The XTM device always routes a packet through the BOVPN tunnel if the source and

destination of the packet match a configured BOVPN tunnel.

BOVPN Virtual InterfaceA BOVPN virtual interface is a manual BOVPN configuration option for a VPN connection between

two XTM devices that use Fireware XTM v11.8 or higher. A BOVPN virtual interface appears as

another external interface in the configuration. It offers more flexibility in configuration, because

the XTM device decides whether to route a packet through the virtual interface tunnel based on the

outgoing interface specified for the packet. You can specify a BOVPN virtual interface as the

destination for traffic in a policy. You can also specify a BOVPN virtual interface when you configure

static routes, dynamic routing, and policy-based routing.

To use a BOVPN virtual interface in your dynamic routing configuration, you must assign virtual

interface IP addresses to the local and remote endpoints. You use the virtual IP addresses in the

dynamic routing configuration.

All of the branch office VPN types use the same protocols and tunnel negotiation procedure. Thesettings shown in this training for a manual BOVPN gateway and manual BOVPN tunnel are the same

settings you configure for a BOVPN virtual interface.


9/120



Which VPN Type to Use?

How do you decide which VPN type to use? Here are some guidelines to consider.

BOVPN Virtual Interface Routing Scenarios

When you select the interface to use for static, dynamic, and policy-based routing, you can choose to

use a BOVPN virtual interface. This provides for many flexible configuration options. Some examples of

the routing scenarios you can configure with a BOVPN virtual interface include:

Metric-based VPN Failover and FailbackFor two sites that are connected with an MPLS link, you can configure the XTM device to

automatically failover and failback to a secondary BOVPN virtual interface connection over an

IP network.

To do this, you configure the external interface for the primary connection between the two sites

over the MPLS network. Then, configure a BOVPN virtual interface for the secondary link between

the two sites. Add a BOVPN virtual interface static route and set a high metric (such as 200) for the

route, so it is only used if the primary connection is not available. You could also configure metric-

based VPN failover between a primary and secondary BOVPN virtual interface.

BOVPN Virtual Interface with Policy-Based RoutingYou cannot configure

policy-based routing

to enable failoverfrom a BOVPN virtual

interface to any other

interface.

If two sites are connected by two VPN tunnels, and you want to send certain types of traffic through

a specific tunnel, you can enable policy-based routing to redirect traffic managed by the policy to aspecific tunnel. This encrypts the packets and sends them through the tunnel. This can be useful if

you have tunnels with different cost or latency, and you want to send only latency-sensitive traffic,

such as VoIP traffic, through the tunnel with the lowest latency.

VPN Type When to Use It

Managed BOVPN Managed BOVPN tunnels are useful if you want to create and manage a

large number of tunnels between Firebox or XTM devices managed by a

WatchGuard Management Server. On the Management Server, you can

create Security Templates and VPN Firewall Policy Templates that can beused for one or more managed VPN tunnels. The templates make it easier

to configure a large number of VPN tunnels with consistent settings.

Manual BOVPN For a VPN tunnel between a Firebox or XTM device and a third-party

device, you must configure a manual BOVPN tunnel. This type of VPN is

also appropriate for a VPN between any two Firebox or XTM devices, if you

do not need to separate the routing of traffic from the VPN security

association.

BOVPN Virtual

Interface

For a VPN tunnel between two XTM devices that use Fireware XTM OS

v11.8 or higher, you can configure a BOVPN virtual interface. A BOVPN

virtual interface separates the routing from the security associations. This

enables you to use this type of tunnel in many different network routingscenarios, some of which are described in the subsequent section.

If you want to route traffic between two IPv6 networks through an IPv4

BOVPN tunnel, you must use a BOVPN virtual interface. IPv6 virtual

interface routes are supported in Fireware XTM v11.9 and higher.


10/120


BOVPN Virtual Interface with Dynamic Routing

You can configure dynamic routing over a BOVPN virtual interface to enable the two sites to

dynamically exchange route information about multiple local networks through a secure VPN

tunnel. This avoids the need to manually add and maintain configured routes between all the

private networks at each site. To do this, you configure a BOVPN virtual interface, and configure

virtual IP addresses for the VPN endpoints. Then, you enable and configure dynamic routing

between the two sites, and use the virtual IP addresses as the peer network IP addresses.

Dynamic routing protocols are described in detail in the Fireware XTM Advanced Networking course.


11/120



Terms and Definitions

This section introduces some terms you might see in the training. Use this list as a reference for the rest

of the training course.

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-SHA2

HMAC-MD5

IPSec operates at the

Network layer, Layer 3,

of the OSI (Open

Systems

Interconnection)

Reference Model.

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 adevice 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-DESor 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 v11.9 and higher can use these DH groups:

- DH Group 1: 768-bit group





- DH Group 19: 256-bit elliptic curve group

- DH Group 20: 384-bit elliptic curve group

For DH groups 1 - 15, the larger key groups give larger integers to use in the exchange, which

provides stronger security. The elliptic curve groups use an algorithm that provides even stronger

security.


12/120


Diffie-Hellman key exchange

A method of making a shared encryption key available to two entities without actually exchanging

the key.

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 public-

key encryption for

every set of data that

goes through a VPN

fast enough for

acceptable

throughput.

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 one-

way 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.

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.

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 Codeor

HMAC(sometimes also called a Keyed HMAC). Similar to the normal use of hash functions, each VPNpeer computes hashes of data to guarantee the datas 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.

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.

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 users 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.


13/120



Key expiration

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. FirewareXTM 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 thetime 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.

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.


14/120


SA

Security Association

Phase 1 SAs are

sometimes called

ISAKMP SAs. Phase 2

SAs are usually called

IPSec SAs.

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 and SHA-2

Secure Hash Algorithm 1 and Secure Hash Algorithm 2

These are types of hash algorithms called cryptographic hash functions. They provide 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. SHA-2 is stronger than SHA-1, but is more computationally intensive.

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 peers trafficselectors. 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.

In versions of Fireware XTM prior to v11.3.1, the XTM devices always used IPSec to process the traffic

when a traffic selector matches. In Fireware XTM v11.3.1 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 also

exists in the devices local routing table (not in the devices default route), the device can honor that

route. To configure the XTM device to honor non-default routes and use them to take precedenceover IPSec traffic selectors, in VPN settings (select VPN > VPN Settings), 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 tunnelingthrough the public Internet.


15/120



What Happens During Phase 1 Negotiations

In this section, we look at all the different parameters that the two VPN devices agree upon during the

VPN 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 a BOVPN gateway or edit a BOVPN virtual interface.

This section describes

how to configure

Phase 1 settings for a

branch office VPN

gateway. You can

configure the same

settings in the Phase1

tab for a BOVPN virtua

interface.

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 Gatewaysdialog box appears.

Figure 2: Add a Branch Office Gateway


16/120


3. Click Add.The New Gatewaydialog 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 13.

You can select Pre-Shared Keyor IPSec Firebox Certificatefor 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 pre-

shared key, the other peer must also use pre-shared key. And, if one peer uses certificates, the other

peer must also use certificates.


17/120



You specify which method the peers use in the New Gatewaydialog box, on the General Settingstab,

in the Credential Methodsection.

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. Thedevices 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 certificateis 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 peers 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 Gatewaylist 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 initiatesPhase 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?


18/120


When your XTM device respondsto 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?

The Use modem for

failover check box

appears only if serial

modem failover is

enabled in the device

network settings.

You specify how the XTM device answers these question when you configure the Gateway Endpoints

at the bottom of the New Gateway dialog box.

Figure 5: Gateway Endpoints

Each row in the Gateway Endpointslist in Figure 5represents 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 haveenabled serial modem failover on the device.

Modem failover is

supported on XTM 2

Series, 3 Series, and 5

Series devices, and

Firebox T10 devices.

Your XTM device can do VPN failover if:

Your XTM device runs Fireware 10.x, 11.x, or higher, 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.

The remote peer is a Firebox X e-Series or WatchGuard Firebox or XTM device that runs Fireware

10.x or higher, and has more than one external interface.

You want your XTM device to make the VPN connection to one of the remote peers 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 peers 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 tunnelcheck

box is selected.


19/120



To add a set of gateway endpoints:

1. Open the New Gatewaydialog box.

2. Click Add.The New Gateway Endpoints Settingsdialog 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 thelocal device what to expect from the remote device during Phase 1 negotiations.

Each devices 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.


20/120


Each device can use one of four types of identifiers, or Phase 1 ID types:

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 IDtype ID_IPv4_ADDR.

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 andprotocols 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.comor myexample.com)that has a record in the DNS system for the IP address

assigned to the external interface.

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 similarway. A later side note

tells you the main

difference between the

two types in this

situation.

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 staticIP 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 youusually use the IP address for the Phase 1 identifier because the IP address never changes.

If your XTM device has a dynamicIP 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 As external interface. Device A can use Domain Namefor 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 Nameor

Domain Namefield 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 domainname.


21/120



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 useUser ID for the local

gateway identifier.

Devices running

Fireware XTM and WFS

can use User ID for the

local ID.

User ID on Domain(ID_USER_FQDN)

This is typically a users ID in the form of an email address, such as [email protected]. It can

also be a simple string of text that does not represent a real email 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 email 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 Domainfor 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 devices own

local Phase 1 identifier.

The main difference

between the User ID

on Domainand the

Domain NameID

types when the

external IP address isdynamic is this: the

peer does not try to

resolve a User ID on

Domainwith 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 Namethe

peer can try to initiatenegotiations by first

doing a DNS query to

find the other device.

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 email

address field in the certificate. The certificate field name is RFC822 Name, and is listed as a Subject

Alternative Namewhen 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 certificates Subjectfield. 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 Gatewaysection, 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


22/120


The details you include in the Local Gatewaysection depend on how the external interface is

configured:

In versions prior to

11.x, the IP Address

drop-down list in

Figure 7shows the IP

addresses for all the

XTM device interfaces.

Be careful to not selectan optional or trusted

IP address. The XTM

device can terminate

BOVPNs only on

external interfaces.

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 Addressoption. In the IP Addresstext 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 IPaddress 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 Informationoption. Then click Configure.

Figure 8: Local Gateway ID information if the XTM device has a dynamic address

The Configure Domain for Gateway IDdialog box appears:

Figure 9: Local Gateway ID information if you do not use certificates


23/120



If you use pre-shared keys for the credential method, you can specify two different types of Domain

Informationidentifier:

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.

The XTM deviceDynamic 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 anetwork behind the

XTM device that runs a

Dynamic DNS updater

client software

package.

If you use the Dynamic DNS capability of the XTM device, you can use the DynDNS domain namethat 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 IPaddress. 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 9dialog box:

The ID Type X500 that

appears in Figure 10is

not available for the

Local ID if you do not

use certificates. It is

always available for

the Remote ID.

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 Informationfor 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.


24/120


The Remote Gateway Identifier

In the Remote Gatewaysection, 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 addressand type the IP address in the

IP Addresstext box.

The XTM device must know a domain name that the DNS service can resolve to an IP address.

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.

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 peers IP address with a DNS query, the remote device must bethe 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.

In the Specify the gateway ID for tunnel authenticationsection, 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 Addressand 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 manuallytype 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 peers

certificate in a certificate viewer.


25/120



When you use Domain Nameor User ID @ Domainto specify the remote gateway ID, the Attempt to

resolvecheck box controls whether the XTM device attempts to resolve the domain.

Select the Attempt to resolvecheck box if the remote gateway uses dynamic DNS to maintain a

mapping between a dynamic IP address and a domain name.

The Devices Decide Whether to Use Main Mode or Aggressive Mode

You must use

Aggressive Mode if the

credential method is

pre-shared keys and

one of the devices has

a dynamic IP address.

Phase 1 negotiations can use one of two modes: Main Mode orAggressive 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 Gatewaydialog box, select the Phase 1Settingstab.

Figure 12: Select the mode to use for Phase 1 negotiations


26/120


The XTM device can use one of three methods to start IKE negotiations:

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 informationeach packet contains.

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 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 ofthe 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 Settingstab.

Figure 13: NAT Traversal fields


27/120



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

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.

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 4500. 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 flows original source port).


28/120


The NAT device maintains this map for only a short time when there is no traffic that matches the map.

If the device does not see traffic that uses the NAT map for a certain amount of time, it closes the NAT.

NAT timeouts for UDP traffic are typically much lower than NAT timeouts for TCP connections.

If UDP-encapsulated traffic is sent from behind the NAT device, NAT is opened on the NAT device.

To keep the IPSec tunnel active when NAT-T is used, the IPSec devices keep the NAT map alive. The

IPSec device behind a NAT sends a NAT-T keep-alivepacket to keep the NAT map active. The peer that

receives the NAT keep-alive packet replies with a keep-alive ACK to keep the NAT active on the remoteNAT device.

The Keep-Alive Intervalaffects your XTM device only if your XTM device is the IKE peer behind the

NAT. It specifies how often your device sends a NAT keep-alive packet to keep the NAT map active on

the NAT device in front of the XTM device.

When the remote IKE peer is behind a NAT, it has its own settings for the keep-alive interval. Your XTM

device responds to the NAT keep-alive messages it gets from the other side, but your XTM device does

not influence the interval that the peer uses between the keep-alives it sends.

Each Device Decides Whether to Send IKE Keep-alive Messages

You specify this on the Phase 1 Settingstab of the gateway.

Figure 14: Keep-alive interval

IKE Keep-alive and Dead Peer Detection (DPD, discussed in the next section) messages enable the XTM

device to detect if the IKE peer is still alive. For VPN failover, either IKE Keep-alive or DPD is the method

the XTM device uses to determine whether to fail over to another gateway endpoint pair.

This is the only part of the gateway configuration that is not actually part of the Phase 1 negotiations.

This setting is only to enable or disable the option, and to specify the interval between the messages.

For IKE Keep-alive to work, each peer must be able to respond to the keep-alive messages sent by the

other side.

All WatchGuard

products respond to

IKE Keep-alive

messages. However,

they are specific to

WatchGuard products,

so other vendors

appliances might not

respond.

When both peers can use IKE Keep-alive messages, each device sends a Hellopacket (the IKE Keep-alive

message) to the other side at regular intervals. When a device receives an IKE Keep-alive packet, it

returns an acknowledgement (a keep-alive ACK) to the peer that sent the message. When the sending

peer gets the ACK, it knows that the remote peer is still alive and that the Phase 1 SA between them is

still valid.

If a device sends a specified number of keep-alive messages that get no response, the device closes the

VPN and tries to start tunnel negotiations again.


29/120



If you use VPN failover and the maximum number of keep-alive failures is reached, the XTM device

starts negotiations with the next gateway endpoints pair in the list (see Figure 5). If there is only one

pair in the list, the device starts IKE negotiations again with that pair.

For a fast VPN failover, we recommend you set the Message intervalto a low value, such as 10

seconds, and set the Max failuresto a lower value, such as 2.

If you have only one gateway endpoint pair for the gateway (you do not use VPN failover), keep the

default settings.

For a VPN to a third-party device (not a WatchGuard product) we recommend you do not use this

option. To configure the XTM device to not send keep-alive messages, clear the IKE Keep-alive

check box.

For a VPN to any Firebox or XTM device that can use Dead Peer Detection, we recommend you do

not use this option. To configure the device to not send keep-alive messages, clear the IKE Keep-

alive check box.

The Devices Decide Whether to Use Dead Peer Detection

You specify Dead Peer Detection settings on the Phase 1 Settingstab.

Figure 15: Dead Peer Detection settings

Dead Peer Detection (RFC3706) is a traffic-based detection of an inactive peer. It works in a similar (but

more intelligent) way to IKE Keep-alive. When Dead Peer Detection (DPD) is enabled, the XTM device

sends a DPD probe (a message similar to the IKE Keep-alive message) only if traffic is not received from

the peer for a specified length of time, and data is waiting to be sent to that peer. This method is more

scalable than IKE Keep-alive messages because DPD probes are sent only when no traffic is received

from the other side for some amount of time. (Compare this to the IKE Keep-alives mechanism, which

sends keep-alive messages at regular intervals regardless of the health of the tunnel.)

In the Traffic idle timeouttext box, set the amount of time traffic can be idle before the XTM

device sends a DPD probe to the peer.

In the Max retriestext box, set the number of times the XTM device should send a DPD probebefore the peer is declared dead because it received no response.

Dead Peer Detection is an industry standard that is used by most IPSec devices. If it is supported by the

devices on both ends, we recommend you use Dead Peer Detection instead of IKE Keep-alive,

particularly for VPN failover.

Note

Do not select both IKE Keep-alive and Dead Peer Detection. Use one or the other, but not both. Use

Dead Peer Detection if both endpoint devices support it.


30/120


The Devices Agree on a Transform to Use for Phase 1

A Transformis a set of authentication and encryption parameters and the amount of time the Phase 1

SA lasts. The initiator sends one or more transform proposals to the responder. The responder either

selects one of the proposed transforms, or it rejects the Phase 1 proposal.

You specify the transform proposals your XTM device sends when it is the initiator, or the transforms it

can accept if it is the responder, in the Transform Settingssection of the Phase 1 Settingstab.

Figure 16: Transform Settings

The Transform Settingslist includes the Phase 1 transforms the XTM device can send for this VPN.

To add a transform, click Add.

To edit a transform, select a transform in the list and click Edit.

The Phase 1 Transformdialog box appears.

Figure 17: Phase 1 Transform dialog box


31/120



The Phase 1 transform settings must exactly match the settings for the Phase 1 transform that the IKE

peer accepts, or IKE negotiations fail. The items you can set in the transform are:

SHA2 is not supported

on XTM 21, 22, 23, 510,

520, 530, 515, 525, 535,

545, 810, 820, 830,

1050, and 2050

devices. The hardware

cryptographicacceleration in those

models does not

support SHA2.

Authentication

Authentication ensures that the information received is exactly the same as the information sent.

You can use SHA1, MD5, or SHA2with 256, 384, or 512-bit key strength as the algorithm the peers

use to authenticate IKE messages from each other. SHA2 is the most secure.

Encryption

Encryption keeps the data confidential. You can select DES, 3DES, orAESwith 128, 192, or 256-bit

key strength. AES is the most secure.

The Phase 1 SA is

commonly called the

IKE SA. The technically

correct term is the

ISAKMP SA.

SA Life

When Phase 1 is completed, the two peers have a Phase 1 Security Association(SA). This SA is

valid for only a certain amount of time. After the Phase 1 SA expires, any new Phase 2 renegotiation

requires the two peers to also renegotiate Phase 1.

If the remote IKE peer

can set a KB limit for

the Phase 1 SA Life,

make sure to set its

Phase 1 SA Life to 0 KB,

and use a time setting

that matches the

Fireware XTM peers

Phase 1 SA life.

Fireware XTM does not

use an amount of data

for Phase 1 SA

expiration.

Diffie-Hellman Group 1

provides 768 bits of

keying material, Group

2 provides 1,024, and

Group 5 provides

1,536.

Some IKE peers can also specify an amount of data, in KB, that can pass through the VPN before the

Phase 1 SA Life expires. Fireware XTM does not specify a data lifetime. In general, if the peer

requires a value for Phase 1 SA data limit, you set the peer to use 0 KB to specify no KB timeout.

Key Group

The Diffie-Hellman Group specifies the length of a mathematical parameter used for the Diffie-Hellman key exchange. You can select group 1, 2, or 5. A higher number indicates a more secure

key exchange.

Use Multiple Phase 1 Transforms

If you are not sure what Phase 1 transforms the remote peer is configured to accept or propose, you can

add multiple transforms for the XTM device to use. To do this, Phase 1 must use Main Mode.

When the XTM device is the initiator, it can send multiple Phase 1 transforms in the Main Mode

proposal it sends to the IKE peer. This lets the peer select the transform it can use.

Conversely, when your XTM device is the responder to a Main Mode proposal, and you added morethan one Phase 1 transform to the gateway settings, your XTM device can review multiple transforms in

the configuration to determine if the transform sent by the peer is acceptable (or to select one of

multiple transforms sent by the peer).

Because there are many different possible combinations of values for the four items in the Phase 1 SA

proposal, it is always better to get the exact Phase 1 parameters that the remote peer uses. Try not to

guess, or to rely on multiple possibilities.

In some situations, however, the administrator of the remote device may give you incomplete

information. Or, the peer device may have certain IKE or IPSec settings hard-coded and the

configuration might not show these settings. In other words, the administrator might not know what

the device will send or accept for some parameter and cannot configure it. In these situations, get as

much information as you can. Tell the administrator of the peer device to check the manufacturersdocumentation to discover the values for hard-coded parameters.

Note

You can add more than one Phase 1 transform only if you use Main Mode for Phase 1. If you use

Aggressive Mode, you can only have one Phase 1 transform in the gateway configuration.


32/120


When Phase 1 is Finished

When Phase 1 finishes, the two devices can negotiate Phase 2 over a secure encrypted channel. Their

Phase 2 negotiations are protected by the Phase 1 SA (Security Association).

Through the Phase 1 negotiations, the two IKE peers generate keying material to use for Phase 2

negotiations. We look at this aspect of Phase 1 when we discuss Perfect Forward Secrecy.

What you Learned

You learned about the different settings that control Phase 1. All the information is in the gateway

object you create. After you create a new gateway, it appears in the Gateways dialog box.

Figure 18: The newly configured gateway appears in the Gatewayslist.

What Happens During Phase 2 Negotiations

The purpose of Phase 2 negotiations is to establish the Phase 2 SA (sometimes called the IPSec SA). The

IPSec SA is a set of traffic specifications that determines what traffic the XTM device can send over the

VPN, and how to encrypt and authenticate that traffic.

Unlike Phase 1 negotiations, which have two different modes (Aggressive Mode and Main Mode),Phase 2 uses only one mode: Quick Mode.

Like Phase 1, a goal of Phase 2 negotiations is for the two peer devices to agree on a set of parameters.

You specify all the Phase 2 parameters when you create theTunnelin Policy Manager, or when you edit

a BOVPN virtual interface.


33/120



To add a BOVPN tunnel:

This section describes

how to configure

Phase 2 settings for a

branch office VPN

tunnel. You can

configure the same

settings in the Phase2

tab for a BOVPN virtuainterface.

1. Open Policy Manager for your XTM device.

2. Click .Or, select VPN > Branch Office Tunnels.

The Branch Office IPSec Tunnelsdialog box appears.

Figure 19: Click to add a new tunnel

3. Click Add.The New Tunneldialog box appears.

Figure 20: New tunnel. Make sure to select the correct gateway.

4. In the Tunnel Name text box, type a friendly name for the tunnel.For this example, we type Main_Office_Tunnel.

Do not give the VPN

tunnel the same name

that is used for a VPN

Gateway.

Fireware XTM does not send this name to the peer device. It is only used to identify the tunnel in your devicesconfiguration.

The subsequent sections describe the purpose of each element in the tunnel configuration.


34/120


Peers Use the Phase 1 SA to Secure the Phase 2 Negotiations

The Phase 1 SA that the two peers create applies only to the two peers that negotiated the SA. If you

have multiple VPNs to different remote devices, your XTM device makes a unique Phase 1 SA to each

device.

Because the Phase 2 negotiations are protected by the Phase 1 SA, you must select the correct gateway

to use for the tunnel. To select the gateway for the remote peer device to which the X

advanced vpn training v11 9

Documents