VPN

Part 2: VPN RFP Lab Eval
RapidStream

• Firewall Policies
• Site-to-Site VPNs
• Discovery And
  Setup Using CPM
• Remote Access VPNs

by Lisa Phifer Vice President of Core Competence, Inc. [November 15, 2001]

Earlier this year, ISP-Planet launched a VPN Appliance Review Series, evaluating IPsec hardware devices suitable for ISP deployment to broadband-enabled businesses of 10 to 200 employees. We gathered four responses that appeared, at least on paper, to satisfy our RFP. Our next step—a lab evaluation. By digging into each vendor's proposed solution, we hoped to compare and contrast these offerings.

Here, we publish our second set of results, evaluating two RapidStream Security Appliances (RSSAs). The RSSA 2000 is a VPN concentrator or edge firewall for small-to-medium businesses. The RSSA 1000 is a compact firewall/VPN appliance for branch offices. Both can be provisioned from a Network Operation Center (NOC) using RapidStream's Central Policy Management System (CPM). If you need a brief review of what we've accomplished so far, start with Part One.

Firewall Policies
The cornerstone of configuring a RapidStream Security Appliance (RSSA) is the Security Policy panel (left). RSSAs stateful inspection firewalls are in compliance with time-based enforcement of multi-dimensional policies as certified by the International Computer Security Association (ICSA)

Policies begin with the usual—source/destination IP, service and action. Built-in Address-objects exist for each RSSA port. Custom objects can include single IPs, subnets, ranges or other Address-objects. This hierarchical approach makes it easy to create groups like "RSSA Public Ports" or "HQ Sub-nets." This feature makes it easier to eyeball and update custom objects rather than hunt down raw IPs (below, right).

Built-in Service Group objects define common services; custom objects can include protocols/ports, port ranges, or other Service objects. Services identify destinations, not sources or ports. These policies are not packet filters—they control whether new sessions are permitted, authenticated, rejected or blocked.

Each policy applies to the public, private or DMZ port, or to internal traffic generated by the firewall itself. That is, Simple Network Management Protocol (SNMP) or SYSLOG. Policies can be further qualified with 802.1Q virtual local area network (VLAN) tags. Tags are useful when independent organizations send traffic to the same port, like multi-tenant scenarios, for example. Tags let you apply different policies to traffic from each group, so long as arriving packets carry tags. VLAN support is usually found in large concentrators like the RSSA 8000 system. But RapidStream offers this across its entire lineup.

Dynamic Network Address Translation (DNAT); actually, network and port translation can be applied to any private or DMZ policy. For example, the Wizard suggests DNAT be utilized for the default private port policy. With DNAT, source IPs in each outbound packet are updated to carry the RSSA's public IP, while responses are mapped back to the private or DMZ destination. Consequently, private and DMZ sub-nets remain hidden from the Internet.

Static Network Address Translation (SNAT) and Virtual IPs expose servers on the private or DMZ port. SNAT objects map between Address Groups—one with routeable public IPs and the other an equal number of private/DMZ IPs. VIP objects map one Service on the RSSA's public IP to a server pool. Inbound requests to the VIP are distributed across up to 16 servers using load-balancing algorithms. For example, we used VIPs to distribute inbound HTTP round-robin to DMZ Web servers and to relay Layer Two Tunneling Protocol (L2TP) to an inside LNS (See Remote Access).

Policies can also include daily/weekly Schedules, IPsec VPN, and QoS actions. QoS specifies a priority for Weighted Fair Queuing (WFQ). Type of Service (ToS) bits can be set in forward and reverse directions. Port shaping is enabled at the system level by defining aggregate bandwidth for each interface, but bandwidth cannot be allocated to individual policies. These features can be useful to smooth traffic to the Wide Area Network (WAN) and give top priority to mission-critical services. Because doing so requires packet inspection, combining firewall, VPN and traffic management in one box is optimal.

Overall, RSM makes it easy to visualize and update policies. For example, a Checker identifies which policy determines a packet's disposition, given a pair of IPs, RSSA port, and service. You can assess an update's impact by invoking the Policy Checker before committing changes. Or use the Checker for quick trouble-shooting after ill-advised updates trigger support calls. Using Clone to copy a proven policy makes for fast, reliable additions. Similarly, initializing a new RSSA is easier if you start by loading an existing configuration as a profile, then tweak a few Address Groups.

(Back to Top)

Site-to-Site VPNs
RSSAs support Internet Engineering Task Force (IETF) standard IPsec ESP and AH protocols, with mandatory encryption (DES, 3DES) and authentication (HMAC-MD5, SHA-1) algorithms. IPsec security associations (SAs) can be keyed manually or automatically with IKE. Options include DH Group 1 or 2 (specified in modulus bits), Perfect Forward Secrecy and Replay protection. Site-to-site VPN authentication can use pre-shared secrets (PSS) or digital certificates signed with RSA or DSS by any third-party certificate authority.

RSSAs have passed the VPN Consortium's Basic and Rekey conformance tests, but have not yet completed ICSA certification. Mandatory IPsec/IKE features are supported, but this does not guarantee multi-vendor interoperability. For example, we had no trouble establishing a site-to-site tunnel between NetScreen and RapidStream appliances. But when we changed the Service from ANY to Telnet, the two could not agree on source port selectors.

With RSM, applying an IPsec Action to either uni- or bi-directional Security Policies configures site-to-site VPNs. The IPsec Action specifies one or more IKE Phase 2 transforms and the IKE Peer (far-end gateway) IP Address (above, left ).

IKE Actions are created to define IKE Phase 1 transforms which are then applied to IKE Policies. Each IKE Policy specifies an IKE Peer ID and PSS or certificate credentials. Peers are identified by IP, domain name, X.500 distinguished name or email address. Although just one ID value can be specified, it may be a partial specification. For example, the UserFQDN "corecom.com" matches any email address ending with this string (below, right).

At our HQ RSSA, we created IKE Policies for our BO RSSA and a teleworker gateway. We identified our BO Peer with an X.500 DN, authenticating with certificates. We identified our teleworker Peer (actually a NetScreen 5XP) by IP address, authenticating with a PSS. Both IKE Policies used the same IKE Action (3DES, SHA1, DH2). Then we created bi-directional Security Policies from the HQ subnet to branch office and teleworker subnets, tunneling ANY service through the HQ's public port. Finally, we applied a different IPsec Action to each Security Policy—each used the same transform, but contained the Peer Addresses IP of the far-end gateway. In this test, the far-end gateway was either the RSSA 1000 or the NetScreen 5XP.

In our opinion, RapidStream's object-oriented policy management approach is straight-forward, with one exception—IPsec Actions are loosely coupled to IKE Policies by Peer Address. Each outbound packet is matched to the "best fit" IPsec Action—the Action's Peer Address is then located in the IKE Policy list. For inbound packets, the source IP is matched first to an IKE Policy, then to an IPsec Action. We find re-entering Peer Address less intuitive than selecting an IKE Policy in each Security Policy. For example, if an IKE Peer's IP changes, every affected IPsec Action and IKE Policy must be updated. For the sake of consistency and simplicity, simply refer to the same Address Group from all of these related objects.

We created additional site-to-site policies as needed. For example, we started with tunneling SNMP traps from the RSSA 1000's internal port to an NMS behind the RSSA 2000. We also configured tunnel switching, RapidStream's implementation of hub-and-spoke VPN architecture. We enabled tunnel switching at our HQ RSSA 2000, then updated BO RSSA 1000 policies to tunnel packets to ANY destination through HQ. Unfortunately, we could not really test tunnel switching—spoke-to-spoke relaying through the HQ hub—without another spoke RSSA.

We created RSSA device certificates by using the RSM Certificate panel to generate and save Certificate Signing Requests (CSRs). We used a Microsoft CA to read each CSR exporting a signed certificate, which we imported back into the requesting RSSA. Ultimately, this functioned well, but we encountered baffling error messages and DER problems. For best results, import the CA's certificate first and import the device certificate second, exported in Base64 format. If tunneling to gateways with certificates issued by another CA, import that CA's certificate, too. If Certificate Revocation Lists (CRL) are posted on an LDAP server the CRL can be automatically refreshed; otherwise, import each CA's CRL. During authentication, when the RSSA encounters an expired CRL that cannot be refreshed, it generates an alarm but assumes that certificates have not been revoked. After configuring Security Policies, use the RSM Log Manager and System Information panels to see whether IKE and IPsec SAs are working as expected (left ).

(Back to Top)

Discovery And Setup Using CPM
Using RSM to configuring two RSSAs is easy. But for managing tens or hundreds of RSSAs, we recommend a more scalable solution like RapidStream's Central Policy Management (CPM) system (below right).

ISPs and larger enterprises can use CPM to manage and monitor a network of RSSAs from a NOC. Each appliance is added to CPM by entering basic System Configuration parameters similar to those covered by the RSM Installation Wizard. Existing appliances can be used as "templates" for new appliances. Discovery is also supported by the CPM Deploy panel. (See next section). CPM attempts to reach the RSSA port designated for CPM management, sending heartbeats to continuously monitor reachability.

Appliances cannot be managed from CPM until a CPM account password is entered through the appliance's CLI (left). Unless the CPM Server happens to be local, the RSSA's default policies must also be updated to permit HTTPS on the public port. Using a site-to-site VPN to reach the RSSA's private port is another option, but separating CPM/RSM administration and customer VPN policies can be operationally and politically useful.

We recommend backing up the RSSA before using CPM, because CPM overwrites the existing configuration—including the RSM admin password. There is no synchronization between changes made through CPM, RSM, and the CLI. On the plus side, you can use the CLI or RSM to experiment with temporary changes, without affecting "known good" policies in the CPM database. On the other hand, you're in a bind if CPM cannot derive your desired Security Policies.

Each managed RSSA appears on the CPM's Appliance List window (right), along with summary inforomation like CPM reachability, port status, unacknowledged alarms and software version. Columns can be customized to show more or less information—hiding the RSSA's management IP or ignoring unused DMZ ports, for example. Clicking on an appliance offers menu access to System Configuration and Certificate settings, Operations like reboot, shutdown and software upgrade, as well as Log Files stored on the RSSA. Note that a single RSSA cannot be backed up or restored from CPM. To back up an RSSA's running configuration, use RSM. To back up the entire CPM database squirreling away a copy of configured policies for all managed devices, use CPM Backup/Restore.

(Back to Top)

Site-to-Site VPNs Using CPM
Like RSM, Security Policies are the cornerstone of CPM. While RSM polices apply to a single RSSA, CPM policies span an entire network. Instead of using RSM to add complementary objects to each RSSA, let CPM derive all RSSA objects needed to implement one centrally specified policy.

For example, use the CPM Policy Manager to configure a full-mesh VPN by defining one Address object for all company subnets (left). Then define one Policy that tunnels IPsec bi-directionally between company subnets. IKE Pair objects are generated for each RSSA combo—tweak them as needed to select an IKE Proposal and then pick an ID type and set credentials—by default, 16-digit secrets (below right). To connect a new branch office, just add the private subnet to the company subnets Address object. Hub-spoke VPNs use two Address objects—one for the hub subnet and another for all branch office subnets.

Logically, CPM policy details are similar to those seen in RSM. Include/Exclude lists make Address, Service and Schedule objects easy to group. CPM IPsec and IKE Proposals are similar to RSM Actions, but CPM IPsec Proposals are more reusable than RSM IPsec Actions because they lack Peer Addresses. In addition, CPM introduces a Foreign Gateway object for policies that tunnel to VPN gateways outside of CPM's domain.

As with RSM, policies are added by Source/Destination Address, Service and Schedule. Firewall, IPsec, NAT, Load Balancing and QoS/ToS actions are applied in a slightly different fashion, but with similar effect. However, two features cannot be specified in CPM policies—firewall authentication and VLAN tags. Using a checkbox on the left, CPM policies can be applied to any set of RSSAs. CPM lacks the RSM Policy Checker, but includes a Consistency Checker to catch logical errors. This means you cannot apply Load Balancing to a Policy with multiple Destination ports.

After saving updates in the CPM Server database, the CPM Deploy tool is used to derive and push symmetric Security Policies to each individual RSSA (right). Policy derivation is a time-saver that greatly reduces error—but this implementation still has a few kinks. In one case, derived Security Policies contained an invalid Service Group whereby a specified TCP range 20-25 mysteriously became 0-0. In another case, derived Security Policies were inexplicably missing specified Load Balancing Actions.

The Deploy tool assigns a version number to each derived configuration and tracks whether deployment is needed for each RSSA. For example, during "deploy all," some RSSAs may not be reachable. If so, CPM lets you repeat deployment later. In our tests, BO RSSA deployment often timed out, but deploying HQ and BO configurations separately proved more reliable. Like RSM, the CPM Deploy tool can discover RSSAs on the local subnet so IP addresses and existing Policies can be pushed to any discovered appliance.

Consistent Security Policies and site-to-site VPNs are very easy to create with CPM. A Policy Wizard even creates "default" Security Policies that enable CPM administration (right). However, asymmetric features like DNAT are less intuitive in CPM and derived Security Policies are more cryptic than hand crafted equivalents. Derived policies can be visually inspected before deployment, but details like embedded Service and Load Balancing objects are not visible from CPM. Instead, the admin must use RSM or the CLI to view actual Security Policies after they have been deployed to the RSSA.

(Back to Top)

Remote Access VPNs
RSSAs support IPsec remote access by travelers and teleworkers using the RapidStream (SafeNet) VPN Client (left). Remote users must install client software, a policy that matches the RSSA's Security Policy and a certificate or secret. RapidStream does not generate SafeNet policy files. Instead, use an installed client to manually configure and export SafeNet policies for user import.

When using basic IKE authentication or RADIUS-based Extended Authentication (XAUTH), remote access Security Policies can be configured from RSM or CPM. However, if you want to use XAUTH to authenticate against a local RSSA user database you must start with RSM.

The RSM Policy Panel (right) can create up to 2000 user accounts, assigning each a login, password, expiration, and concurrency limit. Users belong to Groups that define inner IP/DNS addresses and session/idle timeouts. Concurrency limits and IP addresses are typically supplied by RADIUS—RapidStream goes further by including these in the local database, enforced by the RSSA at user and group levels. We successfully authenticated users with the local database, our Interlink AAA Server, and a Funk Steel-Belted RADIUS Server. Two RADIUS IPs can be configured; if authentication fails because both are unreachable, the RSSA generates an alarm.

Use CPM or RSM to create Security Policies that permit one-way tunnels from ANY address or specific IPs to complete Remote Access VPN setup. For example (left), create an IKE Action requiring Main Mode with XAUTH. Next, create an IKE Policy that accepts ANY Peer ID and then create an IPsec Action that does not specify a Peer Address. Finally, create a Security Policy that applies this IPsec Action to traffic arriving on the RSSA's public port.

With pre-shared secrets, IKE Main Mode requires static IPs. But VPN clients usually have dynamic IPs. One solution would be to use the same secret by all clients. But this is very risky. Another alternative is Aggressive Mode with unique secrets per client. But this too, is risky, because the client's identity is usually e-mail address and not cryptographically protected.

Aggressive Mode with unique secrets is an arguably stronger solution than Main Mode with a group secret. Both are weaker than issuing digital certificates to each client. But to do so requires added infrastructure. Whether using secrets or certificates, Main Mode or Aggressive Mode, XAUTH can be added for interactive user authentication before IPsec SAs are established.

Unfortunately, RapidStream does not support XAUTH with Aggressive Mode and a hash bug prevents using certificates in Aggressive Mode. We conclude that RapidStream remote access VPNs are effectively limited to Main Mode, with either certificates or a group secret and XAUTH.

The VPN client's inner IP can be dynamically assigned, using an Address Group as a pool. Traffic from the private network to this Address Group must be routed out the RSSA's public port. RapidStream uses Mode Config between IKE Phases 1 and 2 to supply the VPN client with IP and DNS addresses. Packets tunneled from the VPN client appear to originate from this source IP; packets may be tunneled to an active VPN client using this destination IP.

XAUTH and Mode Config are popular non-standard solutions for user authentication and address assignment. A standard alternative, L2TP-over-IPsec, has been implemented by a handful of vendors—notably Microsoft. An RSSA cannot be an L2TP Network Server (LNS). However, an RSSA can terminate the IPsec transport, load-balancing L2TP (or PPTP) to Microsoft Windows 2000 Servers. According to RapidStream, this configuration puts crypto on dedicated hardware (the RSSA), enabling high-volume remote access by Windows 2000 VPN clients. Although we find this scenario a bit of a stretch, the configuration does seem possible.

—End Part Two—