Deploying Mobile User (IPsec) VPN
by David Piscitello, Core Competence, Inc.
Communication has always been the most important application for the Internet. The ideal is to be connected, any time, over any distance; and moreover, connected securely and privately. This ideal is largely achievable using Mobile User Virtual Private Networking (MUVPN). But the process of implementing MUVPN requires diligence. This article explains the steps required to get IPsec MUVPN going with your WatchGuard Firebox, including:
-
Planning your MUVPN implementation
-
Documenting your constituency and configuration
-
Managing client software and its distribution
-
Using the Firebox logs to monitor remote access connections.
Below, I'll detail what happens when things go well. In next week's article, "Debugging Mobile User VPN," I'll show you how to troubleshoot failed MUVPN connections.
Planning Eliminates
Surprises
As with site-to-site IPsec VPNs, secure remote
access requires careful planning. It also demands a good understanding of your
IP addressing, the IPsec capabilities of your Firebox, and the IPsec client
software that you license for use. If you saw my column, Incorporating
a Firebox into a Multi-vendor VPN, you’ll recall I stressed the
importance of documenting your site-to-site VPN before you attempt to build it.
Planning is no less important when you connect remote users. Before you start
increasing outside connections past your network defenses, I recommend you:
-
Determine how the addition of remote users affects the topology of the network, and the configuration of your Firebox, DNS, and routes to servers.
-
Create a topology map to illustrate all the (IP) networks that users will be permitted to access using VPN tunnels.
-
Identify the networks by domain name, IP address, and subnet mask.
This investment of time will save you from a lot of frustrating and inefficient experimentation later.
Document Your
Constituency and Configuration
Try to view remote user management as a
painstaking rather than painful process. Document as you go. For a remote access
deployment of up to several hundred users, an Excel spreadsheet or text file
works well as a database of users, identities, and the pre-shared secrets
that are used for authentication. If your number of users is greater than that, you really need to
consider using a public key infrastructure (PKI) rather than pre-shared secrets.
In addition to the obvious user and credentialing information, you may find it
worthwhile documenting equipment, adapter cards, and Windows OS versions. Review
this information to ascertain whether your user’s client environment can
support MUVPN.
For each user, you must enter a unique identifier (typically, an e-mail address) and passphrase; the phrase is the pre-shared secret key for tunnel encryption. You’ll also configure ESP tunnel protection. I recommend you choose the strongest protection available, currently SHA1-HMAC and 3DES-CBC, for all users. Remote users are generally bandwidth constrained and they won’t see a performance hit when you use stronger encryption.
The Firebox implementation of remote access IPsec requires that you specify an unused IP address for each remote user (the Virtual IP). This address is needed to route protected traffic back to the user, through the tunnel. This static assignment is simple to deploy for small numbers of users, but can become challenging should your mobile and teleworker population grow. You may wish to create a separate Secondary Network on your Trusted Interface solely for the purpose of addressing remote users.
Finally, consider your firewall policy configuration. You must add an ANY service and permit the ipsec_users group Incoming and Outgoing access through this service. Enable logging for Incoming and Outgoing allowed and denied packets to assist in debugging. You may further restrict access through additional IPsec tunnel and service policies, but these are additive: you must allow IPsec traffic through the firewall. If you added a Secondary Network for remote users, consider whether your existing firewall rules must be revised to accommodate users numbered from this new IP address space.
Manage Client
Software and Configuration Distribution
With routing and addressing considerations
under your belt, you'll then want to figure out how you can securely and
conveniently deliver the MUVPN client software that the configuration
(<username>.EXP) file generated when you added remote users, and plan how
you'll deliver “installation and use” instructions to mobile users. Explain
to those users the importance of maintaining the integrity of the .EXP file --
any unauthorized changes a user makes may cause problems. Spend some time
explaining where to find the log files generated by the MUVPN client and how to
e-mail logs to support staff; as I’ll show later,
a log file can save you and your users time and aggravation by keeping
them connected and productive.
Common methods for delivering this content include using a secure Web server, push (secure) e-mail, or removable medium (CD-ROM or floppy), hand delivered and signed upon receipt (or sent registered mail). To prevent theft, you also need a separate process for informing users of their remote access user ID and password. A FAQ page and a short list of how to troubleshoot and resolve commonly encountered problems is well worth the time, even if it saves only one helpdesk call.
You can avoid “one-off” problems resulting from permutations and combi- nations of Windows OS, third party software, adapter cards, and device drivers by utilizing a standardized client environment (e.g., everyone uses Windows 98), and using hardware and adapters demonstrated to work with MUVPN. If you haven’t implemented standardized desktops, prepare for helpdesk calls.
Use Firebox Logging
to Understand Mobile User (IPsec) VPN
You’re now armed and ready to manage the
onslaught of remote access. At this point, make use of your firewall logs to
understand how IPsec is implemented for MUVPN.
IKE and MUVPN -- a breed apart
The Internet Key Exchange (IKE) provides key and security session management
between MUVPN clients and your Firebox. IKE has two phases
of operation. During Phase
I, the Firebox and MUVPN client employ Aggressive
Mode to identify and authenticate each other, and agree on the parameters of
the IKE security association (SA). Aggressive Mode is different from Main Mode
used in Branch Office VPN in two important ways:
-
The process of establishing IKE SA’s takes three messages rather than six, and
-
Identity information exchanged between a remote user and the Firebox is not encrypted. Aggressive Mode configurations that use dynamic addressing sacrifice identity protection.
Let’s look at a successful Phase 1 exchange in a Firebox log to appreciate the Aggressive Mode. In this example, a remote user, lisa, attempts to connect to the Trusted Network (207.86.152.128/26) from an address (207.246.161.212) somewhere on the Internet. My Firebox’s External Interface is 64.53.71.51.
77888 06/12/01 15:47:02 iked[90]
FROM 207.246.161.212 AG-HDR ISA_SA ISA_KE
ISA_NONCE ISA_ID
77898 06/12/01 15:47:02 iked[90]
TO 207.246.161.212 AG-HDR ISA_SA ISA_KE
ISA_NONCE ISA_ID ISA_HASH
77908 06/12/01 15:47:02 iked[90]
CRYPTO ACTIVE after delay
77918 06/12/01 15:47:03 iked[90]
FROM 207.246.161.212 AG-HDR ISA_HASH
77928 06/12/01 15:47:03 iked[90]
Phase 1 completed as responder
77938 06/12/01 15:47:03 iked[90]
Updated lisa000 channel for lisa rgw
77958 06/12/01 15:47:03 iked[90]
User "lisa" at 207.86.152.186 logged in
77968 06/12/01 15:47:03 iked[90]
Add Host 8 207.86.152.186 ipsec_users lisa
succeeded
77978 06/12/01 15:47:03 iked[90]
lisa bound to 207.246.161.212
Log entries 77888, 77898 and 77918 show the three messages that comprise an Aggressive Mode Phase 1 exchange initiated by a remote client at 207.246.161.212 to a Firebox. The first two messages (77888, 77898) use the following information to negotiate the security policy for the IKE SA:
- Security
Association proposal (ISA_SA). The IKE security policy for MUVPN is the same
as Branch Office VPNs, so the ISA_SA specifies
- - authentication method is pre-shared keys
- - encryption algorithm is DES-CBC
- - message hash algorithm is MD5-HMAC
- - Diffie-Hellman group is 1
- - SA lifetime is 3600 seconds
- Diffie-Hellman public values, or key exchange material (ISA_KE)
- A one-time random value called a nonce, which protects against replay attacks (ISA_NONCE)
- The Identity (ISA_ID), which for MUVPN is the User Fully Qualified Domain Name assigned when we created this remote user. By convention, this is typically an e-mail address of the form user@domain.com; in our examples, however, we’ll simply use “lisa.”
The second and fourth messages (77898, 77918) also authenticate the responder and initiator using a keyed hash (ISA-HASH). Log entries 77928-77978 confirm IKE Phase 1 related actions (success!). The Firebox has assigned a remote user “lisa” the Virtual IP address 207.86.152.186 from the Trusted Network and is connecting from outside the Firebox at a public IP address of 207.246.161.212.
IPsec and MUVPN
-- more of the same…
IKE SAs created between the Firebox and MUVPN client provide a secure
control channel for creating Phase II
IPsec SAs. Here, parameters are negotiated for IPsec security associations
that permit data transfer. These
parameters, discussed earlier, are selected when you create a remote user.
Phase II begins at log entry 81848. The security policies selected for MUVPN IPsec Security Associations are negotiated using Quick Mode (log entries 81848, 81868). These messages are encrypted with DES (note the *), and a keyed message hash and nonce are included for message integrity and protection against replay, respectively.
81848 06/12/01 15:57:48 iked[90]
FROM 207.246.161.212 QM-HDR*-7E36F121
ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
81858 06/12/01 15:57:48 iked[90]
Getting IPSEC preferences as Responder
propnum=1, mode=(Tunnel),
laddr=64.53.71.51,
raddr=207.246.161.212
81868 06/12/01 15:57:48 iked[90]
TO 207.246.161.212 QM-HDR*-7E36F121
ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID
81878 06/12/01 15:57:49 iked[90]
FROM 207.246.161.212 QM-HDR*-7E36F121 ISA_HASH
81888 06/12/01 15:57:49 iked[90]
Load outbound ESP SA,
Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1
Life=3600sec/0KB SPI=6985177e
81898 06/12/01 15:57:49 iked[90]
207.86.152.128/26 <-> 207.86.152.186/32
81908 06/12/01 15:57:49 iked[90]
Load inbound ESP SA,
Algs=ESP_3DES/AUTH_ALG_HMAC_SHA1
Life=3600sec/0KB SPI=0004a135
81918 06/12/01 15:57:49 iked[90]
207.86.152.128/26 <-> 207.86.152.186/32
81928 06/12/01 15:57:49 iked[90]
Committing SAs for channel=0 established
with QM message_id=7e36f121
81938 06/12/01 15:57:49 kernel ipsec:
make bundle for channel 0, 1 in SA's,
1 out SA's
81978 06/12/01 15:57:51 firewalld[74]
allow in ipsec0 64 tcp 20 128 207.86.152.186
207.86.152.181 1532 21 syn (Any)
Log entries 81888 and 81898 show the security policies selected for the two IPsec SA's between my Firebox and the MUVPN client used by lisa. There are two IDs (note them at the end of 81868) because IKE shows one apiece for the local networks at each end of the tunnel.
Log entry 81978 shows an incoming TCP connect request (SYN packet) allowed in from lisa’s host (207.86.152.186) to an FTP server (port 21) on the Trusted Network (207.86.152.181). Success! The Firebox blocks incoming FTP requests over eth0 but allows encrypted FTP sessions from authenticated remote users through the virtual interface ipsec0.
Now you've seen what a successful MUVPN connection looks like. But not everyone achieves a successful MUVPN tunnel on the first attempt. In next week's column, we'll troubleshoot unsuccessful remote access connections. See you then! ##
Was this article helpful to you? Is there a topic you'd like us to cover? Let us know by e-mailing lsseditor@watchguard.com.
Copyright© 2001, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.