FatPipe's MPVPN WAN interfaces support DHCP addressing. For some functionality, however, such as VPN connections or Fatpipe's proprietary SmartDNS, you'll need a static IP address on those WAN interfaces. Also, FatPipe's MPVPN does not support PPPoE (PPP over Ethernet).

FatPipe's MPVPN comes with four standard Fast Ethernet interfaces: One connection is for the LAN, and up to three are for WAN links. The unit sits on the edge of the network. FatPipe recommends putting the MPVPN on the WAN side of the firewall. This is mostly for simplicity in setting up the network. You can just as easily put a firewall on each of the WAN links. The device can then either load balance or failover between the multiple WAN links.

Load balancing is done via round robin or response time. Response time measures the average response time for each WAN link by looking at how fast the session setup times are and by utilizing the faster link more often. Failover only (no load balancing) also is an option. Load balancing and failover are not just limited to VPN traffic. Internet traffic originating from the local LAN also reaps performance and stability benefits.

The biggest drawbacks to this product are the lack of centralized management, which could become tedious in environments with several VPN tunnels, and the unit's cost.

The Testbed

The infrastructure setup for my review consisted of three routers, four VLANs (virtual LANs), two VPN boxes, two FatPipe MPVPNs and two servers.

With this setup, I created a site-to-site VPN connection between two remote offices (High and Low). Each office was then outfitted with two network connections from two independent ISPs: On the left, a 500-Kbps frame-relay circuit from Darthnet, using a Cisco 2509 and a 3620; on the right, a 10-Mbps link from Vadercom through a Cisco 4700. The four switches represented in the map are separate VLANs on Catalyst 2900XLs.

I used a SonicWall XPRS2 and a SonicWall SOHO2 for the VPN gateways. Finally, Yacko and Warner, two Dell Optiplex GX1s, ran Windows NT4 SP6A with Microsoft IIS and FTP servers installed, which I used to manage both the SonicWalls and the MPVPNs.

The VPN tunnels were set up to use 3DES (triple data encryption standard) and IKE (Internet key exchange).

Failover Testing

The FatPipe MPVPN, by itself, works like a standard, Internet gateway NAPT (network address port translation) device. I set IP addresses for each of the WAN interfaces on separate subnets (representing connections from different ISPs). Each MPVPN was set up to send VPN traffic to the other one. You do this by telling each FatPipe the subnet of the VPN network, the opposite end's VPN gateway address and the IP address of the other FatPipe.

At the heart of MPVPN are its Internet and VPN failover capabilities. I initiated a large FTP transfer from Warner to Yacko and another simultaneous FTP transfer from Yacko to Warner. The MPVPN was set up for round-robin load balancing.

As these transfers were speeding along, I had the Vadercom ISP suffer a power failure (I pulled the power plug on the router). The FTP transfer continued, albeit at a slower speed. When I plugged Vadercom back in, the transfer speed returned to its previous level. MPVPN's management interface shows the transfer rates (incoming, outgoing and total) for each WAN connection as well as for the overall throughput.

FatPipe claims that sending data across multiple links improves security. The idea is that if one of the lines is tapped, the network analyzer would get only partial information. Technically, this is true. When you consider the security of a 3DES VPN tunnel using IKE, however, this does not add a great deal to the overall security of the VPN.

Incoming Data and Port Mapping

FatPipe's MPVPN behaves like an NAPT box; it's similar in some regards to a Linksys SOHO router. As an example, assume for the moment that there is only one active WAN link (in this case, the other ones can be merely failover lines). All outgoing traffic appears to originate from the external interface of the MPVPN. VPN transfers work in a similar fashion.

Normally, VPNs and NAPTs don't like each other very much (see "Why Can't IPsec and NAT Just Get Along?"). When two offices are behind different NAPTs, the problems compound. In such situations, the MPVPN distinguishes itself from other FatPipe products that perform similar actions, but without VPN support. You input the VPN subnet, gateway and destination MPVPN at both ends of the tunnel.

In the test network, incoming VPN packets (on the FatPipe-High side) from Sonic-Low are forwarded to Sonic-High; these packets appear as if they came from the LAN interface of FatPipe-Low. The traffic gets NATted at one FatPipe and deNATted at the other. Across the Internet, the same packets appear to be just ESP (encapsulating security protocol) IP traffic between the WAN interfaces of the FatPipes.

When you look at the connection with a network analyzer, you'll see that no information about either of your VPN setup or your internal addressing schemes is revealed. Keep in mind, however, that both MPVPN devices act like NAPT boxes. Just because VPN traffic can transfer between the FatPipes does not mean all traffic between the two devices is necessarily passed. To forward other kinds of traffic, as well as for letting general Internet users connect to a server on the LAN, you need to set up port forwarding.

FatPipe calls port forwarding "reverse port mapping."Simply put, if you receive traffic on port X on any of the WAN interfaces, forward that traffic to LAN IP address A.B.C.D. This lets you set up an e-mail server on the inside of your network with fault tolerance.

You're probably wondering how someone connecting to mail.company.com would know about the multiple links. In traditional schemes, you would assign mail.company.com to one particular IP address.

When dealing with multiple connections as the MPVPN is designed for, it's a bit trickier: You have to take downed links into account. Each WAN link would be registered as a domain server IP (WAN1 could be ns1.company.com, WAN2 ns2.company.com and so on). When a DNS query comes in, the MPVPN sends back the IP address of one of the WAN interfaces. This is done by round robin. Thus, when viewed from a third-party perspective, a server may appear to be on two different IP addresses at the same time.

Individual clients don't really care. Mail.company.com exists at 1.1.1.1 for ClientA, and the same domain exists as 2.2.2.2 for ClientB. DNS responses are made with a six-second TTL (time to live) field. This way, if a link goes down, the Internet will still be able to resolve your domain name and communicate with the server.

Vendor Information FatPipe's Multi-Path VPN, Unit's list price, $14,500; FatPipe Networks, (800) 724-8521 (within the USA), (801) 281-3434; Fax: (801) 281-0317www.fatpipeinc.com

Drawbacks

The MPVPN does not have any central management capabilities. If you want to add a VPN connection or make other configuration changes, you must log into each MPVPN individually. As the number of VPN tunnels grows, so does the number of entries in the VPN setup. And this grows exponentially. If you have two WAN links and one VPN tunnel, you need to set up two VPN routes (one for each WAN interface on the other end). Two VPN tunnels require four mappings, three VPNs eight and so on, per FatPipe. This can get a bit ugly as you expand the number of FatPipes.

MPVPN units do have some SNMP capabilities. Right now, this is basically showing which interfaces are up or down. FatPipe plans to add some diagnostic capabilities, such as ping, trace route and packet drop, as well as export connection throughput information in the future.

You also can set up failover boxes -- two FatPipes in one location. If one unit dies, the other takes over. My beta version of the software did not have this capability during the test period.

Finally, the price of this technology is a bit high. Each FatPipe MPVPN unit has a list price of $14,500. Two offices with a dual-line VPN connection would cost $29,000; this fee is before the cost of the VPN devices, the other infrastructure and the cost of four Internet connections.