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
8/10/2019 Advanced VPN Training v11 9
2/120
TRAINING
www.watchguard.com/training
SUPPORT
www.watchguard.com/support
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.
8/10/2019 Advanced VPN Training v11 9
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
8/10/2019 Advanced VPN Training v11 9
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
8/10/2019 Advanced VPN Training v11 9
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.
8/10/2019 Advanced VPN Training v11 9
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
8/10/2019 Advanced VPN Training v11 9
7/120
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 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/10/2019 Advanced VPN Training v11 9
8/120
4 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
9/120
What You Should Know
Branch Office VPN Tunnels 5
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.
8/10/2019 Advanced VPN Training v11 9
10/120
6 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
11/120
What You Should Know
Branch Office VPN Tunnels 7
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 2: 1024-bit group
- DH Group 5: 1536-bit group
- DH Group 14: 2048-bit group
- DH Group 15: 3072-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.
8/10/2019 Advanced VPN Training v11 9
12/120
8 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
13/120
What You Should Know
Branch Office VPN Tunnels 9
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.
8/10/2019 Advanced VPN Training v11 9
14/120
10 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
15/120
What You Should Know
Branch Office VPN Tunnels 11
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
8/10/2019 Advanced VPN Training v11 9
16/120
12 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
17/120
What You Should Know
Branch Office VPN Tunnels 13
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?
8/10/2019 Advanced VPN Training v11 9
18/120
14 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
19/120
What You Should Know
Branch Office VPN Tunnels 15
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.
8/10/2019 Advanced VPN Training v11 9
20/120
16 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
21/120
What You Should Know
Branch Office VPN Tunnels 17
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
8/10/2019 Advanced VPN Training v11 9
22/120
18 WatchGuard Fireware XTM Training
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
8/10/2019 Advanced VPN Training v11 9
23/120
What You Should Know
Branch Office VPN Tunnels 19
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.
8/10/2019 Advanced VPN Training v11 9
24/120
20 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
25/120
What You Should Know
Branch Office VPN Tunnels 21
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
8/10/2019 Advanced VPN Training v11 9
26/120
22 WatchGuard Fireware XTM Training
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
8/10/2019 Advanced VPN Training v11 9
27/120
What You Should Know
Branch Office VPN Tunnels 23
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).
8/10/2019 Advanced VPN Training v11 9
28/120
24 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
29/120
What You Should Know
Branch Office VPN Tunnels 25
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.
8/10/2019 Advanced VPN Training v11 9
30/120
26 WatchGuard Fireware XTM Training
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
8/10/2019 Advanced VPN Training v11 9
31/120
What You Should Know
Branch Office VPN Tunnels 27
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.
8/10/2019 Advanced VPN Training v11 9
32/120
28 WatchGuard Fireware XTM Training
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.
8/10/2019 Advanced VPN Training v11 9
33/120
What You Should Know
Branch Office VPN Tunnels 29
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.
8/10/2019 Advanced VPN Training v11 9
34/120
30 WatchGuard Fireware XTM Training
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