advanced vpn training v11 6
TRANSCRIPT
-
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
-
7/28/2019 Advanced VPN Training v11 6
2/86
TRAININGwww.watchguard.com/training
SUPPORTwww.watchguard.com/support
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.
-
7/28/2019 Advanced VPN Training v11 6
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
-
7/28/2019 Advanced VPN Training v11 6
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
-
7/28/2019 Advanced VPN Training v11 6
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.
-
7/28/2019 Advanced VPN Training v11 6
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/28/2019 Advanced VPN Training v11 6
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.
-
7/28/2019 Advanced VPN Training v11 6
8/86
4 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
9/86
What You Should Know
Branch Office VPN Tunnels 5
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.
-
7/28/2019 Advanced VPN Training v11 6
10/86
6 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
11/86
What You Should Know
Branch Office VPN Tunnels 7
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.
-
7/28/2019 Advanced VPN Training v11 6
12/86
8 WatchGuard Fireware XTM Training
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
-
7/28/2019 Advanced VPN Training v11 6
13/86
What You Should Know
Branch Office VPN Tunnels 9
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.
-
7/28/2019 Advanced VPN Training v11 6
14/86
10 WatchGuard Fireware XTM Training
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?
-
7/28/2019 Advanced VPN Training v11 6
15/86
What You Should Know
Branch Office VPN Tunnels 11
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.
-
7/28/2019 Advanced VPN Training v11 6
16/86
12 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
17/86
What You Should Know
Branch Office VPN Tunnels 13
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.
-
7/28/2019 Advanced VPN Training v11 6
18/86
14 WatchGuard Fireware XTM Training
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
-
7/28/2019 Advanced VPN Training v11 6
19/86
What You Should Know
Branch Office VPN Tunnels 15
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.
-
7/28/2019 Advanced VPN Training v11 6
20/86
16 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
21/86
What You Should Know
Branch Office VPN Tunnels 17
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.
-
7/28/2019 Advanced VPN Training v11 6
22/86
18 WatchGuard Fireware XTM Training
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
-
7/28/2019 Advanced VPN Training v11 6
23/86
What You Should Know
Branch Office VPN Tunnels 19
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
-
7/28/2019 Advanced VPN Training v11 6
24/86
20 WatchGuard Fireware XTM Training
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).
-
7/28/2019 Advanced VPN Training v11 6
25/86
What You Should Know
Branch Office VPN Tunnels 21
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.
-
7/28/2019 Advanced VPN Training v11 6
26/86
22 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
27/86
What You Should Know
Branch Office VPN Tunnels 23
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
-
7/28/2019 Advanced VPN Training v11 6
28/86
24 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
29/86
What You Should Know
Branch Office VPN Tunnels 25
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.
-
7/28/2019 Advanced VPN Training v11 6
30/86
26 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
31/86
What You Should Know
Branch Office VPN Tunnels 27
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.
-
7/28/2019 Advanced VPN Training v11 6
32/86
28 WatchGuard Fireware XTM Training
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
-
7/28/2019 Advanced VPN Training v11 6
33/86
What You Should Know
Branch Office VPN Tunnels 29
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.
-
7/28/2019 Advanced VPN Training v11 6
34/86
30 WatchGuard Fireware XTM Training
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.
-
7/28/2019 Advanced VPN Training v11 6
35/86
What You Should Know
Branch Office VPN Tunnels 31
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.
-
7/28/2019 Advanced VPN Training v11 6
36/86
32 WatchGuard Fireware XTM Training
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
-
7/28/2019 Advanced VPN Training v11 6
37/86
What You Should Know
Branch Office VPN Tunnels 33
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