ISPPlanet • Stallion ePipe - page 3

Remote Access VPN

PPTP configuration is very simple—just activate the PPTP server, select PAP or CHAP authentication, and supply an inside address range to be assigned to PPTP clients. Authentication requires a user database—one can be defined in the ePipe itself, or the ePipe can be pointed to an external RADIUS server.

We found SRA very easy to use and reliable. However, we wish the ePipe did a better job of hiding "secrets". Both SRA username/password and dial login/password are readily visible from the GUI, CLI, and support reports—this could be a privacy concern for customers seeking outside assistance.

Site-to-site VPN
The optional Site-to-Site VPN (SSV) feature creates authenticated, encrypted IPsec tunnels between ePipes. In the simplest case, tunnels extend from a "client" ePipe to an ISP POP, across the Internet or ISP backbone, to another POP, terminating at a "server" ePipe. E2B binds each tunnel to a connection bundle, balancing encrypted traffic across available links. Different physical interface types can be used at each end. For example, use SSV to create a secure Intranet with three sites:

• A remote office with bonded IDSL
• A remote office with bonded v.90
• A main office with high-speed ADSL and ISDN backup

The firmware tested supports basic IPsec with a healthy set of crypto options—DES, 3DES, or Blowfish; MD5, SHA1, or RMD160. But the Internet Key Exchange (IKE) is not yet supported, so matching indices and keys must be configured manually at both ends. Furthermore, tunnel granularity is limited to subnets, and each tunnel can be initiated from only one end, namely the "client" ePipe.

The client ePipe may have a dynamic address, but the server ePipe must have a static IP. To activate the tunnel, the client must be able to reach the server through this IP. Once the tunnel is active, E2B balances traffic across all links in the bundle, and traffic will flow without interruption even if the link with the static IP goes down.

The ePipe's client/server model is an unusual implementation. Most IPsec gateways use IKE to create peer-to-peer tunnels, initiated from either end. To accomplish this with ePipe, we defined two tunnels: one client A/server B, the other client B/server A. Had we no defined the two tunnels, we would have created a filter speciofically defined to prevent private packets from "leaking" onto the Internet from the server when the tunnel wasn't active.

We were distressed to discover packets leaking in the default configuration, and hope to see a "catch all" filter at least documented—better yet, added by default—in a future release. This should also improve when IKE is added in the next major firmware release.

Those looking to combine the ePipe with another IPsec gateway may note that the ePipe uses a ported OpenBSD kernel and stack. Stallion has tested IPsec between the ePipe and OpenBSD, but wider interoperability will require IKE. Even then, E2B will only be available between ePipes.

Monitoring status and performance
ePipe status displays make instantaneous performance metrics readily available. "Raw status" can be viewed for SIA, SRA, SSV, bundles and ports. SIA and SSV displays let you eyeball I2B and E2B status. Note that you'll need to enable logging to diagnose problems. The SRA display enumerates allocated addresses; the ability to view connected users by name would be a good addition—those using RADIUS authentication can obtain user stats from the RADIUS log.

We found the link throughput, uptime, and TTL displayed by bundle-level raw status very useful—those who prefer pictures will really like the ePipe's Port Graph.

The GUI also provides a General Report—a composite of raw status and config query commands and results. We found this report useful, but insufficient for fine-tuning filters or assessing I2B/E2B load balancing behavior. Such detail is available through the CLI or by logging to a syslog server.

E2B enables site-to-site, even over slow links
To demonstrate E2B, we measured site-to-site traffic with one or two calls active. We recorded application-level throughput for a stream of 256-byte UDP packets and FTP file transfers. We saw UDP throughput increase 75 to 89 percent when a second call was added. While our configuration did not stress the ePipe, our experience confirms that bonding with E2B can overcome slow-link limitations that may otherwise make site-to-site tunnels impractical.

We also illustrated that encryption has a big impact on application throughput. The stronger the crypto algorithm, the longer it took to FTP the same file. For example, a document that took an average of 162 seconds to transfer without encryption took 367 seconds with DES and just over 400 with 3DES. We saw comparable results with other files, transferred over one and two channels.

There are many parameters that affect tunnel throughput, including connect speed, fragment length and MTU size, choice of authentication and encryption algorithms, the type of traffic being transmitted, source/destination host utilization, and of course transit time across the public Internet. The examples cited here illustrate our own experience with firmware release 1.0.5b4 and a fragment length of 800 bytes.