VPN

Part 2: VPN RFP Lab Eval
NetScreen

• Site-to-Site VPNs
• Virtual, Mapped, and Dynamic IPs
• Remote Access VPN Setup
• Three Levels of Authentication
• Enabling L2TP Over IPsec

by Lisa Phifer Vice President of Core Competence, Inc. [December 13, 2001]

Several months ago, ISP-Planet issued a Request For Proposal (RFP) for Virtual Private Network (VPN) appliances suitable for Internet Service Providers' (ISPs) deployment to broadband-enabled businesses of 10-200 employees. Using vendor RFP responses to build our short-list, we invited four contenders to submit their solutions to our lab for hands-on evaluation. In previous installments, we evaluated the solutions proposed by SonicWALL and RapidStream.

Here, we publish our second installment of our third evalution of Customer Premise Equipment (CPE) manufactured by NetScreen Technologies. The NetScreen-100 is a firewall/VPN/traffic management appliance for collocation facilities and medium-to-large enterprises. The NetScreen-5XP is an entry-level Internet appliance for small offices and teleworkers. Both can be provisioned and monitored from a NOC with NetScreen's Global Manager or Global PRO.nd contrast these offerings. If you need a brief review of what we've accomplished so far, start with Part One.

Site-to-Site VPNs
NetScreen supports the Internet Engineering Task Force (IETF) standard IPsec ESP and AH protocols in tunnel and transport mode, with mandatory encryption (null, DES, 3DES) and authentication (HMAC-MD5, SHA-1) algorithms. IPsec security associations (SAs) can be keyed manually or automatically with IKE. Options include Diffie Helman (DH) Group 1, 2, or 5, Perfect Forward Secrecy, and Replay protection.

These appliances have passed ICSA's IPsec certification and VPNC's Basic and Rekey conformance tests. This rigorous testing promotes multi-vendor interoperability, but it does not guarantee it. For example, we had little trouble creating site-to-site "any IP" tunnels between the NetScreen-5XP and SonicWALL, RapidStream, WatchGuard, and Nokia appliances. A significant factor was NetScreen's configuration flexibility. Using custom proposals and options, we were able to adjust the 5XP's IKE proposals to match assumptions made by WatchGuard and SonicWALL, and to change commit bit handling to pair with Nokia.

On the other hand, a tunnel carrying a single TCP protocol like Telnet was successful only between NetScreens. Even paired with NetScreen-Remote, we could not configure compatible source port selectors on NetScreen appliances. A NetScreen option to unset IKE policy matching successfully works around this problem. But it also limits each gateway to one tunnel, defeating our original intent: to create several granular site-to-site tunnels.

NetScreen IKE IDs can be IP addresses, hostnames, and e-mail addresses, but not X.509 Distinguished Names. NetScreen derives the ID type from the ID value. This shortcut is convenient, but occasionally complicates multi-vendor debugging. On the other hand, the CLI includes options to overcome common interoperability and deployment problems, including Don't Fragment bit, Commit bit, and Policy Checking options.

Site-to-site VPNs can use preshared secrets (PSS) or X.509/PKCS7 digital certificates, signed with RSA or DSA by any third-party certificate authority (CA). NetScreen has tested interoperability with RSA Keon, Netscape, Baltimore, Entrust, Verisign, and Microsoft CAs. If you plan to make extensive use of public key infrastructure, this kind of testing with your chosen CA is critical.

For RSA/DSA authentication, the NetScreen must have at least one device certificate (left). The WebUI Certificate tab generates a key pair (up to 2048 bits) and exports a Certificate Signing Request (CSR) to file or e-mail. We used a Microsoft CA to read each NetScreen's CSR, exporting RSA-signed certificates. We then imported CA and device certificates into each NetScreen. In Extranets with multiple CAs, NetScreens can authenticate certificates issued by other CAs or present different certificates to different IKE peers.

NetScreens refresh Certificate Revocation Lists (CRLs) posted on LDAP or HTTP servers as needed or on a daily, weekly, or monthly schedule. During tunnel establishment, if an expired CRL is encountered, the NetScreen contacts the CRL distribution point (CDP) identified in the certificate. If the CDP cannot be resolved or is unreachable, a PKI problem is logged and IKE Phase 2 fails. Because this CRL check cannot be disabled, ensuring CA high availability is essential when designing a certificate-based NetScreen VPN. VPN Configuration and Topology To configure a full-mesh VPN, Gateways are created for each peer, specifying IKE ID and mode. IKE IDs can be raw static IPs; reusable Address objects cannot be applied here. Peers with dynamic IPs can use a hostname or e-mail ID—for example, allowing NetScreen-5XPs using DHCP or PPPoE to initiate site-to-site tunnels (right).

Up to four built-in or custom Phase 1 proposals may be specified for each Gateway. For example, we proposed 3DES encryption, SHA1 authentication, and DH Group 2 in two flavors. We preferred authenticating with X.509 certificates, but accepted preshared secrets as a fallback.

Next, AutoKey IKE objects are created for each IPsec tunnel, selecting a Gateway, Phase 2 proposals, tunnel/transport mode, and replay protection (above left). Even if you wish to apply the same parameters to every site-to-site tunnel, you must create an AutoKey IKE object for each Gateway.

Finally, AutoKey IKE objects are tied to traffic policies through VPN tunnel actions (right). Policy source, destination, and service parameters function as the IPsec selector, so at least one policy pair is required for each site. In earlier NetScreens, each SA required one (implicitly bi-directional) policy. In ScreenOS 2.6.0, NetScreen introduced separate Inbound and Outbound policies to allow asymmetry. Fortunately, a per-policy option to automatically create or update matching Inbound/Outbound policies appeared in ScreenOS 2.6.1.

Our test VPN required just a few policy pairs, but full-mesh topology can become unwieldy in large VPNs—particularly those with teleworker gateways. For central control with fewer tunnels, NetScreen also supports hub-and-spoke topology. To test this, we created a CompanyNet Address Group containing all protected subnets. At each NetScreen-5XP spoke, we created just one policy pair to tunnel all traffic between the CompanyNet and the local subnet through the NetScreen-100 hub. At the hub, we created a policy pair for each spoke. We could have routed spoke Internet traffic through our NetScreen-100 hub by substituting ANY for CompanyNet, but opted not to allow traffic from any source to ride over our VPN.

(Back to Top)

Virtual, Mapped, and Dynamic IPs
Virtual IPs (VIPs) or Mapped IPs (MIPs) translate incoming traffic sent to trusted LAN server(s). VIPs map a single TCP/UDP port to an inside server cluster (left). MIPs do reverse 1-to-1 NAT: public IP "A" is relayed to private IP "B."The NetScreen-5XP supports 10 MIPs and one VIP (which may be the existing untrusted IP). The NetScreen-100 supports 1000 MIPs and four VIPs (all must be unique IPs). For example, we used a VIP to expose our HQ website—but we might choose a MIP to expose our entire HQ mail server.

NAT/PAT or Dynamic IPs (DIPs) translate outgoing traffic sent from the trusted LAN. Apply ordinary network address translation (NAT) to an outbound policy to convert each packet's source IP to the NetScreen's untrusted IP. Or apply a DIP Pool to an outbound policy to convert each packet's source IP to an unused IP from the pool. Port address translation (PAT) can be added by unchecking "fix port." PAT translates TCP/UDP source ports, letting several private hosts share one public IP.

Many firewalls use NAT/PAT to hide private IPs from the public Internet. NetScreen appliances also use DIPs to hide private IPs from other private nets. Why? So that nets with overlapping private addresses can communicate. Many teleworkers use DSL/cable CPE configured with a common private subnet like 10.1.1.0. DIPs let you get around these address conflicts without renumbering.

Start by assigning a unique DIP Pool to each site. For example, we assigned 10.5.5.8/29 to HQ and 10.7.7.8/29 to BO (right). That is, translate packets sent by the HQ LAN to source IP 10.5.5.x; translate packets sent by the BO LAN to source IP 10.7.7.x.

Next, create a "tunnel interface" in the same subnet as the DIP Pool. A static route directs packets from the DIP Pool over the tunnel interface to the WAN router. For example, we routed 10.5.5.0/24 over HQ tunnel interface 10.5.5.1.

Incoming packets from the tunnel interface must be mapped to a trusted IP—in other words, a MIP. For example, on HQ tunnel interface 10.5.5.1, we mapped arriving packets for 10.5.5.2 to the HQ server at 10.1.1.2.

Finally, policies must permit traffic between these sites. For example, we configured a pair of policies permitting only encrypted VPN traffic from the BO DIP Pool (10.7.7.8/29) to the HQ MIP (10.5.5.2) (left).

To illustrate how this works, suppose BO client 10.1.1.2 sends an HTTP request to the HQ web server known publicly as 10.5.5.2. The BO NetScreen converts this packet's source to 10.7.7.9, an IP from the BO DIP Pool. The HQ NetScreen converts the packet's destination to the HQ web server's private IP, 10.1.1.2. Response packets are mapped in reverse. Neither subnet is aware that this client and server actually have the same private IP!

This policy-based NAT can be useful when integrating independent subnets: folding teleworkers into a corporate VPN, merging division subnets into a larger VPN, or serving several customer VPNs from the same data center VPN switch. The downside: conceptual complexity. We would make DIP options less prominent and/or make better use of on-line help to keep simple policies simple.

(Back to Top)

Remote Access VPN Setup
Travelers connecting to a NetScreen VPN have four client software options:

• Compulsory L2TP tunneling without any client software
• PGP IPsec Client on MacOS
• Dial Up Networking (DUN) L2TP-over-IPsec on Windows 2000
• NetScreen-Remote (SafeNet) on any Win32 platform

We did not test compulsory L2TP or MacOS; these were beyond the scope of our RFP. When we had no luck using Windows 2000 IPsec, NetScreen provided detailed instructions—for NetScreen-Remote. So we focused on that client, tunneling successfully from Windows 95, NT, and 2000 platforms over both IPsec and L2TP-over-IPsec.

With NetScreen-Remote, users install client software, a policy that matches the NetScreen appliance, and a certificate or secret. NetScreen appliances do not generate SafeNet policy files. Instead, NetScreen-Remote can be used to manually configure and export policies for distribution to authorized users.

Initially, we allowed remote access over "vanilla" IPsec to our HQ NetScreen-100. We created a Dialup User Group for roamers. We added several Users to this group, configuring a fully specified IKE ID (e-mail address) for each (right).

We added a Gateway for this User Group, selecting Aggressive Mode and Phase 1 proposals to prefer certificates, but permit a group preshared secret. Alternatively, we could have created per-User Gateways with unique secrets or identified our Users by static IPs (rare for remote access clients). We then added an AutoKey IKE object for our Gateway, specifying IPsec Tunnel mode.

Finally, we created an Inbound Policy to apply this AutoKey IKE VPN tunnel to traffic from "Dial-up VPN," a built-in Address representing anything arriving at the untrusted interface. It is not possible to configure a matching Outbound Policy. When an IPsec client is active, response traffic is automatically routed back over the tunnel. However, unrelated sessions cannot be initiated from the trusted LAN to the VPN client. (To do so, see L2TP-over-IPsec.)

Because each Policy has one AutoKey IKE VPN tunnel, each AutoKey IKE is bound to one Gateway, and each Gateway is bound to one User or User Group, certificate authentication requires just one Inbound Policy for all roamers. However, Users or Groups with unique preshared secrets require separate Inbound Policies, AutoKey IKE, and Gateway objects. Unique secrets are therefore possible, but do not scale well when it comes to remote access.

(Back to Top)

Three Levels of Authentication
NetScreen supports firewall authentication against the local User list or a RADIUS, ACE, or LDAP server (left). For example, the firewall can consult an ACE Server for SecurID token authentication of HTTP connect requests sent to a DMZ server. Firewall authentication can also be applied to VPN policies: Inbound Policies authenticate requests after they exit tunnels; Outbound Policies authenticate requests before they enter tunnels.

Although it may sound similar, IKE authentication is really quite different. IKE decides whether the VPN tunnel is established in the first place. Roamers tunneling with "vanilla" IPsec must be authenticated by PSS or certificate. NetScreen does not support XAUTH, a method of checking user credentials in the midst of tunnel setup. Instead, NetScreen supports PPP user authentication with L2TP over IPsec.

Similarly, NetScreen does not support Mode Config for dynamic IP address assignment. Supported alternatives are configuring a static IP in the SafeNet policy, applying NAT to the NetScreen's Dial-Up VPN policy, or using L2TP for PPP address assignment.

IPsec standards for user authentication and dynamic addressing have made slow progress. Meanwhile, many vendors deployed XAUTH and Mode Config to meet customer requirements with Internet Drafts. Microsoft chose a different path, embedding L2TP-over-IPsec in Windows 2000 Dial-Up Networking. NetScreen followed suit in ScreenOS 2.6.0, bringing L2TP to market ahead of many VPN appliance competitors.

(Back to Top)

Enabling L2TP Over IPsec
On a NetScreen, permitting access via L2TP-over-IPsec is a bit more complex than "vanilla" IPsec. Two layers must be configured: an L2TP tunnel to encapsulate PPP from access clients, and an underlying IPsec transport mode connection to secure L2TP packets.

Start by configuring L2TP Defaults, selecting an authentication method (local database or RADIUS server), DNS addresses, and an optional IP Pool. The IP Pool is used to assign dynamic addresses to L2TP access clients, giving each a "virtual presence" in the trusted network. Traffic to the IP Pool must be routed over the untrusted interface to allow response or reverse traffic (right).

Next, create another Dialup User Group containing IKE/L2TP access clients. For each User, IKE authentication is based on the User's IKE ID and the associated Gateway's secret or certificate. PPP authentication is based on the User account name and password. This password can be specified in the User account or authenticated by the RADIUS server named in L2TP Defaults. Finally, each User account must provide an IP address, either static or dynamic (from an IP Pool). Then add an L2TP Table Entry, binding the IKE/L2TP Dialup User Group just created to an L2TP tunnel.

To configure the underlying IPsec transport, add a Gateway for the IKE/L2TP DialUp User Group, selecting certificate auth or a group preshared secret (left). Next, Add an AutoKey IKE object for this Gateway, specifying Transport mode. Finally, create an Inbound Policy that applies both the AutoKey IKE VPN tunnel and the L2TP Table Entry to traffic from the area titled "Dial-up VPN."

There are also two layers to be configured at the client. Using NetScreen-Remote, create a SafeNet policy to protect L2TP to the NetScreen using IPsec transport mode (right). The NetScreen's untrusted IP, UDP, and 1701are required as Remote Party, Protocol, and Port. Enter the IKE ID from the NetScreen User account and a secret or certificate which matches the NetScreen Gateway.

Finally, configure a Windows Dial Up Network VPN adapter on the client PC. Because L2TP tunnels PPP, DUN is used for any type of physical Internet connection. Configuration panels differ in each OS, but all require the NetScreen's untrusted IP, User name, and password.

Our L2TP-over-IPsec tests were successful, but getting there proved difficult. Documentation lags implementation, but a Tech Note is available upon request. Common mistakes, like entering IKE ID instead of User name, yield cryptic messages like "errcode=1." Config mistakes can be frustrating to correct. NetScreen User names cannot be modified—accounts must be deleted and re-added. Passwords cannot be modified without changing IKE ID—update both, then change IKE ID back. On Windows 2000, a registry key may block IPsec, generating unsecured L2TP. If so, a manual registry key fix is needed. In summary: NetScreen L2TP-over-IPsec works, but could use a dab of "user friendliness" polish.

Our RFP required RADIUS for remote access, so we tested L2TP-over-IPsec against our Interlink AAA. NetScreen requests did not contain NAS-IP-Address or NAS-Identifier attributes ("must" in RFC 2865, but "should" in past RFCs), so our AAA rejected them. Interlink responded immediately, helping to diagnose the problem and supplying a successful workaround (treat the NetScreen as a proxy). In contrast, NetScreen took weeks to recommend that we try Funk Steel Belted and Livingston Radius (both worked).

Interoperability problems happen. In another test bed, this mismatch may never have been noticed. But two key points are demonstrated here. First, a real RFP should be as specific as possible. Which RADIUS server? Which CA? Which version? Second, slow support can magnify any problem. An ISP on the hook to customers wants the rapid response that Interlink demonstrated here.

—End Part Two—