advanced vpn training v11 6

7/28/2019 Advanced VPN Training v11 6

1/86

WatchGuard Certified TrainingBranch Office VPN Tunnels and

Mobile VPN

Fireware XTM and WatchGuard System Manager v11.6

Revised: July 2012

Updated for: Fireware XTM v11.6


2/86

TRAININGwww.watchguard.com/training

[email protected]

SUPPORTwww.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 UsersInformation 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 InformationCopyright 2012 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/86

ii

Table of Contents

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

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

Exercise ......................................................................................................................................... 1

What BOVPNs Can Do For You ..................................................................................................... 1

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

Terms and Definitions .................................................................................................................. 4

What Happens During Phase 1 Negotiations ............................................................................. 8

What Happens During Phase 2 Negotiations .......................................................................... 25How VPNs Work With Multi-WAN ............................................................................................... 33

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

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

Troubleshoot Branch Office VPN Tunnels ................................................................................ 38

Before You Begin ......................................................................................................... 41Necessary Equipment And Services ......................................................................................... 41

Management Computer Configuration ..................................................................................... 41

Firewall Configuration ................................................................................................................. 41

Exercise ........................................................................................................................ 42Make a Manual VPN Between a Single-WAN XTM Device and a Multi-WAN XTM Device .... 42

Frequently Asked Questions ....................................................................................... 48

Related Courseware and Information ........................................................................ 49

What You Have Learned .............................................................................................. 49

Test Your Knowledge ................................................................................................... 50

Mobile VPN ........................................................................................................................... 51What You Will Learn .................................................................................................... 51

Connect Remote Users Securely to the Corporate Network ..................................... 51Types of Mobile VPN .................................................................................................................. 52

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

Distribute Client Software and Configuration File ................................................................... 54

Use Mobile VPN with IPSec With a Mac OS X or iOS Device ..................................... 55

Configure the XTM Device ......................................................................................................... 55Configure the VPN Client on an iOS Device ............................................................................. 56

Configure the VPN Client on a Mac OS X Device ..................................................................... 56

Exercise 1: Set Up Mobile User VPN with PPTP ........................................................... 57

Activate PPTP on the XTM Device .............................................................................................. 57

Add Users to the PPTP-Users Group ......................................................................................... 58

Restrict PPTP Users by Policy .................................................................................................... 59

Configure the Windows Client Computer ................................................................................. 59

Exercise 2: Configure Mobile VPN with IPSec and Prepare Mobile VPN Client

Configuration Files .......................................................................................................... 61


4/86

iv WatchGuard Fireware XTM Training

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

Exercise 4: Use the Shrew Soft IPSec Client ................................................................ 69

Install the Shrew Soft VPN Client .............................................................................................. 69

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

Exercise 5: Configure the XTM device for SSL VPN ..................................................... 72

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

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

Restrict SSL VPN Users by Policy .............................................................................................. 75Exercise 6: Change the Port Used for Mobile VPN with SSL ....................................... 77

Exercise 7: Use the Mobile VPN with SSL Client .......................................................... 78

Install the Mobile VPN with SSL Client ..................................................................................... 78

Connect with the Mobile VPN with SSL Client ......................................................................... 79

Test Your Knowledge ................................................................................................... 80


5/86

1

Fireware XTM Training

Branch Office VPN Tunnels

Creating IPSec VPNs in Fireware XTM

Introduction

What You Will LearnIn 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.

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

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

What BOVPNs Can Do For YouA 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.


6/86

2 WatchGuard Fireware XTM Training

What You Should KnowHow Branch Office VPNs workA 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 VPNsUDP 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/86

What You Should Know

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 NegotiationsWhen 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 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 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 1The 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 2negotiations. If Phase 1 fails, the devices cannot begin Phase 2.

Phase 1 negotiations can use one of two modes: Main Mode orAggressive Mode. We discuss the two

modes in more detail in a subsequent section.

Phase 2Phase 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 NameWhen you create a gateway and tunnel, you assign names to each of them. These names are for youruse 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. For the examples in the next sections, we call the gateway

RemotePeer, and we call the tunnel BranchOfficeTunnel.

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.


8/86


Terms and DefinitionsUse 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 KeyExchange (IKE)

protocol

Oakley key

determination

protocol

Diffie-Hellman key

exchange algorithm

Internet Security

Association and Key

Management Protocol

(ISAKMP)

Authentication

Header (AH)

EncapsulatingSecurity 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 (OpenSystems

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 a

device that does network address translation (NAT). NAT, by definition, changes IP headers. Thismeans 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 oncewith 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.


9/86



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 Code or

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.


10/86


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.


11/86



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

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

In Fireware XTM 11.3.1

and later, the XTM

device does a route

lookup first. If a trafficflow matches an IPSec

traffic selector, but a

route to the

destination is also in

the devices local

routing table (not in

the devices 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 localrouting table.

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


12/86


In previous versions of

Fireware XTM 11.x, the

XTM device always

used IPSec to process

the traffic when a

traffic selector

matches.

In v11.3.1 and later,

you can control this

behavior in PolicyManager (selectVPN >

VPN Settings). To

configure the XTM

device to honor non-

default 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

usedcheck 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 NegotiationsThe 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


13/86



3. ClickAdd.The New Gateway dialog box appears. The subsequent sections discuss the different parts of this dialog box.

Figure 3: New Gateway

The Devices Exchange CredentialsDuring 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 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.


14/86


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 KeyThe 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 CertificateA 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 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 Gateway list at the bottom ofFigure 4. We discuss certificates in more

detail in a subsequent section.

The devices find and identify each otherWhen 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?

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?


15/86



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.

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

with a different external interface.

Your XTM device can do VPN failover if:

Your Firebox X e-Series or WatchGuard 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 VPN first. However, if that

interface is not available, you want your device to use a different external interface to make the

VPN.

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

one of the remote peers other external interfaces.

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.


16/86


To add a set of gateway endpoints:

1. Open the New Gateway dialog box.

2. ClickAdd.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 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.


17/86



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.com or 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 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.


18/86


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 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 devices own

local Phase 1 identifier.

The main difference

between the User ID

on Domain and the

Domain Name ID

types when the

external IP address isdynamic 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 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 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 certificates 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 IdentifierIn 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


19/86



The details you include in the Local Gateway section 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 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 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 Information option. Then clickConfigure.

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

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

Information identifier:

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.


20/86


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

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 XTMdevice (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:

The ID Type X500 that

appears in Figure 10 is

not available for theLocal 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 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.


21/86



The Remote Gateway IdentifierIn 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 XTM device

cannot find the peer

with one of those

methods, then it

cannot initiate

negotiations. It mustwait 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 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.

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 clickConfigure. 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 canget this information from the remote device administrator or if you view the remote peers

certificate in a certificate viewer.


22/86


When you use Domain Name or User ID @ 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.

The Devices Decide Whether to Use Main Mode or Aggressive ModeYou 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 Gateway dialog box, select the Phase 1

Settings tab.

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


23/86



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 TraversalNAT 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 Settings tab.

Figure 13: NAT Traversal fields


24/86


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-TraversalThere 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 DeviceIf 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 NATIf 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-AliveThe 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).


25/86



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-alive packet 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 Interval affects 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 MessagesYou specify this on the Phase 1 Settings tab 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 Hello packet (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.


26/86


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 interval to a low value, such as 10

seconds, and set the Max failures to 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 DetectionYou specify Dead Peer Detection settings on the Phase 1 Settings tab.

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 timeout text box, set the amount of time traffic can be idle before the XTM

device sends a DPD probe to the peer.

In the Max retries text box, set the number of times the XTM device should send a DPD probe

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


27/86



The Devices Agree on a Transform to Use for Phase 1A Transform is 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 Settings section of the Phase 1 Settings tab.

Figure 16: Transform Settings

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

To add a transform, clickAdd.

To edit a transform, select a transform in the list and clickEdit.

The Phase 1 Transform dialog box appears.

Figure 17: Phase 1 Transform dialog box


28/86


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:

Authentication

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

You can use SHA1 or MD5 as the algorithm the peers use to authenticate IKE messages from each

other. SHA1 is more secure.

Encryption

Encryption keeps the data confidential. You can select DES, 3DES, orAES with 128, 192, or 256-bitkey 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 provides1,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 GroupThe 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 TransformsIf 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 more

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


29/86



When Phase 1 is FinishedWhen 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 LearnedYou 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 Gateways list.

What Happens During Phase 2 NegotiationsThe 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 the Tunnel in Policy Manager.


30/86


To add a tunnel:

1. Open Policy Manager for your XTM device.

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

The Branch Office IPSec Tunnels dialog box appears.

Figure 19: Click to add a new tunnel

3. ClickAdd.The New Tunnel dialog 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 BranchOfficeTunnel.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.


31/86



Peers Use the Phase 1 SA to Secure the Phase 2 NegotiationsThe 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 XTM device sends VPN traffic for this

tunnel, in the New Tunnel dialog box, select a gateway from the Gateway drop-down list.

Peers Exchange Phase 2 IDsThe administrators of both IPSec devices must agree on what traffic can pass through the VPN. The two

devices exchange Phase 2 IDs to specify the IP addresses behind each device that is allowed to send

traffic through the VPN.

Phase 2 IDs are always sent as a pair in a Phase 2 proposal: one Phase 2 ID shows which IP addresses

behind the local device can send traffic through the VPN, and the other Phase 2 ID shows which IP

addresses behind the remote device can send traffic through the VPN.

If more than one pairof local/remote IP

addresses can send

traffic over the VPN,

then a unique SA is

created for each pair.

The devices do a Quick

Mode negotiation for

each local/remote pair

Because the Phase 2 IDs are part of the Phase 2 Security Association (SA), they are sent as part of thePhase 2 negotiations. Fireware XTM supports three types of Phase 2 IDs:

Host IP address [ID_IPV4_ADDR]

This is a simple dotted-decimal IP address. For example, 192.168.50.200.

Network IP Address [ID_IPV4_ADDR_SUBNET]

This is a dotted-decimal IP address that represents a subnet, followed by the slash notation of the

subnet mask. Although you use slash notation for the network IP address, Fireware XTM sends the

Phase 2 ID as a dotted-decimal IP address followed by a dotted-decimal subnet mask.

For example, if the network IP address is 192.168.50.0/24, Fireware XTM sends the Phase 2 ID as:

192.168.50.0 255.255.255.0

IP address range [ID_IPV4_ADDR_RANGE]

This is a range of IP addresses. The range you specify includes the first IP address and the last IP

address you specify, as well as every IP address in between.

When you add tunnel routes on the Addresses tab of the New Tunnel dialog box, you specify the

Phase 2 IDs.

Figure 21: The Addresses tab for this tunnel includes IP subnets for the Phase 2 IDs.

The remote IKE peer must have the same type of Phase 2 IDs and they must be the reverse of the Phase

2 IDs on your XTM device.


32/86


About Broadcast over a BOVPN TunnelTo enable broadcast routing through the tunnel, check the Enable broadcast routing over the tunnel

check box for every tunnel resource.

Figure 22: Enable Broadcast routing over the tunnel

The devices on both ends of the tunnel must use Fireware XTM v11.x to enable this option. When you

enable broadcast routing, the tunnel supports broadcasts only to the limited broadcast IP address,

255.255.255.255. Local subnet broadcast traffic is not routed through the tunnel. (A local subnet

broadcast is also called a directed broadcast, such as the 192.168.1.255 in the 192.168.1.0/24 network).

If you select this option, make sure to configure Helper Addresses.

Figure 23: The Addresses tab for this tunnel shows the IP subnets in bold, to indicate that broadcast routing

is enabled for this tunnel.

If broadcast routing through the tunnel is enabled for the added tunnel routes, the tunnel resources

appear in bold. When broadcast routing is enabled, you must configure Helper Addresses, which are

unused IP addresses on the network at each end of the tunnel. The XTM device uses these addresses as


33/86



the endpoints of the GRE tunnel (General Routing Encapsulation tunnel protocol) inside the IPSec

BOVPN tunnel. The XTM device sends the broadcast traffic through the GRE tunnel.

The remote IKE peer must use the same Helper Addresses, and they must be the reverse of your XTM

device Helper Addresses.

When broadcast routing is not enabled the tunnel resources are not bold and the Helper Addresses are

not required.

About Multicast Over a BOVPN TunnelIn addition to Broadcast over BOVPN, Fireware XTM also introduces Multicast over BOVPN. This feature

lets you extend multicast beyond your LAN and private networks. When you enable Multicast over

BOVPN, you can configure your XTM device to route multicast traffic through a BOVPN tunnel to

another XTM device.

Multicast supports one-way traffic streams from a sender at one end of the BOVPN tunnel to a receiver,

or group of receivers, at the other end of the tunnel. The sendersends the multicast packets to the XTM

device through an internal interface, such as the Trusted or Optional interface. When the XTM device

receives a multicast packet on the internal interface, it forwards it through the BOVPN tunnel. When the

XTM device at the other end of the tunnel receives the multicast packet, it forwards it to its internal

interface. The devices that actually receive the multicast packets must first associate themselves with a

group IP address. This group IP address must be known on both ends of the tunnel.

Just like broadcast over BOVPN, multicast over VPN requires Helper Addresses to negotiate the GRE

Tunnel.

Figure 24: XTM device configured to send Multicast over BOVPN

The settings in Figure 24 show that the XTM device is enabled to send multicast traffic. This means that

the origination IP address is a host within the trusted interface network.

Origination IP The IP address of the multicast sending device at one end of the tunnel.

Group IP A reserved multicast group IP address that is associated with recipients of the

multicast traffic.


34/86


Input Interface The XTM device internal interface with the subnet that holds the origination IP

address as one of its hosts.

Figure 25: XTM device receiving Multicast over BOVPN

The settings in Figure 25 show that the XTM device is enabled to receive multicast traffic. The

origination IP address is an address on the other end of the tunnel.

Origination IP and Group IP The same values as in the tunnel configuration of the sending

XTM device.

Output Interface The XTM device internal interfaces where the multicast traffic is routed. The

receiving hosts must be located on one of the selected internal interfaces.


35/86



Peers Agree on Whether to Use Perfect Forward Secrecy and Which Diffie-Hellman Group to Use for PFSAt the top of the New Tunnel dialog box Phase 2 Settings tab, you specify whether to use Perfect

Forward Secrecy (PFS) and which Diffie-Hellman group to use to generate new keying material.

Figure 26: Perfect Forward Secrecy

About Perfect Forward Secrecy (PFS)Perfect Forward Secrecy (PFS) specifies how Phase 2 keys are derived. When PFS is enabled, both IKEpeers must use PFS, or Phase 2 rekeys fail.

PFS guarantees that if an encryption key that is used to protect the transmission of some of the data is

compromised, an attacker can get access only to the data protected by that key, not subsequent keys.

The two IKE peers always use the first Phase 1 SA to protect the first Phase 2 negotiations. The same

Phase 1 SA is used to protect Phase 2 rekey negotiations for as long as the Phase 1 SA is valid. If the

Phase 1 SA expires before the next Phase 2 SA expiration, then Phase 1 negotiations must start again

when the two IKE peers negotiate the Phase 2 rekey again. This is true whether PFS is enabled or

disabled.

When PFS is disabled, and Phase 2 SAs expire, the two peers use the existing keying material to derive a

new encryption key for the new Phase 2 SA.

When PFS is enabled, the two IKE peers must generate a new set of Phase 1 keying material for every

negotiation of a new Phase 2 SA. This ensures that when Phase 2 SAs expire, the encryption keys used

for new Phase 2 SAs are never generated from existing Phase 1 keying material.

When the two IKE peers generate new keying material as part of PFS, they do not complete a new set of

Phase 1 negotiations from the beginning. The encryption and authentication parameters the IKE peers

agreed upon in the Phase 1 SA negotiations are still valid, and the authentication of the peer is still

valid. These things are still valid as long as the Phase 1 lifetime does not expire.

Even though PFS does not require a new set of Phase 1 negotiations for each Phase 2 rekey, to generate

new session keys for every Phase 2 renegotiation is computationally expensive. Thus, PFS can cause a

short delay in the Phase 2 rekey negotiation process.


36/86


Peers Agree On a Phase 2 ProposalAs we saw previously, the IP addresses that can send traffic over the tunnel are part of the Phase 2 SA.

The remainder of the Phase 2 SA is a group of encryption and authentication parameters. Fireware XTM

sends these parameters in a Phase 2 proposal. The proposal includes the algorithm to use to

authenticate data, the algorithm to use to encrypt data, and the timeline to make new Phase 2

encryption keys.

To set these parameters, select or create an IPSec Proposal for the tunnel.

1. In the New Tunnel dialog box, select the Phase 2 Settings tab.

2. From the IPSec Proposals list, select a Phase 2 proposal.Or, clickAdd to create a new proposal.

Figure 27: Phase 2 Proposals

The New Phase 2 Proposaldialog box appears.

Figure 28: New Phase 2 Proposal dialog box


37/86



3. In the Proposal Details section, configure these options for the new Phase 2 proposal:

NameType a name for the proposal. Fireware XTM does not send this name to the IKE peer; it is only for

your identification purposes.

Type

Most often, you select ESP (Encapsulating Security Payload). ESP provides authentication and

encryption of the data that passes over the VPN. The other option,AH (Authentication Header),

provides no encryption to the data that passes over the VPN. AH only provides authentication of

the data. (If you select AH, the Encryption drop-down list in Figure 28 is not available.

Authentication

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

You can select either SHA1 or MD5 as the algorithm the peers use to authenticate IKE messages

from each other. SHA1 is more secure.

Encryption

Encryption keeps the data confidential.

You can select DES, 3DES, orAES with 128, 192, or 256-bit key strength. AES is the most secure.

Force Key Expiration

The longer a Phase 2 encryption key is in use, the more data an attacker has for mounting anattack on the key. Phase 2 expiration can happen based on the amount of time passed since the

SA was created, the amount of data that goes over the VPN since the SA was created, or both.

- Select the Time check box to expire the key after a quantity of time. Type or select thequantity of time that must pass to force the key to expire.

- Select the Traffic check box to expire the key after a quantity of traffic. Type or select the

number of kilobytes of traffic that must pass to force the key to expire.

If both Force Key Expiration options are disabled, the key expiration interval is set to 8 hours.

4. ClickOK to save the new proposal.

How VPNs Work With Multi-WANIn Fireware v10.x and Fireware XTM v11.x, you can configure each side of a BOVPN tun

advanced vpn training v11 6

Documents