Republished with permission from
WatchGuard Technologies, Inc.
Deploying Mobile User (IPsec) VPN
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:
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.
This investment of time will save you from a lot of frustrating and inefficient experimentation later.
Constituency and Configuration
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.
Software and Configuration Distribution
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
IKE and MUVPN -- a breed apart
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 (18.104.22.168/26) from an address (22.214.171.124) somewhere on the Internet. My Firebox’s External Interface is 126.96.36.199.
77888 06/12/01 15:47:02 iked
77898 06/12/01 15:47:02 iked
77908 06/12/01 15:47:02 iked
77918 06/12/01 15:47:03 iked
77928 06/12/01 15:47:03 iked
77938 06/12/01 15:47:03 iked
77958 06/12/01 15:47:03 iked
77968 06/12/01 15:47:03 iked
77978 06/12/01 15:47:03 iked
Log entries 77888, 77898 and 77918 show the three messages that comprise an Aggressive Mode Phase 1 exchange initiated by a remote client at 188.8.131.52 to a Firebox. The first two messages (77888, 77898) use the following information to negotiate the security policy for the IKE SA:
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 184.108.40.206 from the Trusted Network and is connecting from outside the Firebox at a public IP address of 220.127.116.11.
IPsec and MUVPN
-- more of the same…
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
81858 06/12/01 15:57:48 iked
81868 06/12/01 15:57:48 iked
81878 06/12/01 15:57:49 iked
81888 06/12/01 15:57:49 iked
81898 06/12/01 15:57:49 iked
81908 06/12/01 15:57:49 iked
81918 06/12/01 15:57:49 iked
81928 06/12/01 15:57:49 iked
81938 06/12/01 15:57:49 kernel ipsec:
81978 06/12/01 15:57:51 firewalld
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 (18.104.22.168) to an FTP server (port 21) on the Trusted Network (22.214.171.124). 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 firstname.lastname@example.org.
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.