VPN Client and Tunnels
Two things became apparent regarding the value of the SSL VPN client. First, it was easy! I didn't have to configure my PC's firewall or invest a lot of effort to get up and running. I found the setup to be only slightly more time consuming than a PPTP connection, which is built into XP and Vista. For an administrator of employee PCs, this simplicity can be a real blessing.
Second, SSL works at locations where IPSec doesn't. Many public websites disable VPN Pass-Through, a problem I have encountered at several public Internet sites, including my local library. I have never been able to get a PPTP or IPSec connection to my lab network from my library.
However, SSL VPNs use port 443, which is commonly open in most firewalls. Using the SSL VPN with the RVL200, I was able to access my lab network from my local library as well as from multiple locations over 1000 miles away while on a business trip. The point of VPNs is remote access, so there is value in a technology that can be used from the greatest amount of remote locations.
In addition to Client-to-Gateway VPNs, the RVL200 supports a single Gateway-to-Gateway VPN tunnel using IPSec technology. Since the RVL is designed as a satellite office device, it only supports a single Gateway-to-Gateway VPN tunnel. Gateway-to-Gateway VPN tunnel configurations were as straightforward as with the Linksys RV042, and equally stable.
I had no problem setting up a VPN tunnel between the RVL200 and a remote SonicWALL router using 3DES, AES-128, and AES-256 bit encryption. I set up all three tunnels and let them run for more than 24 hours each, with no failures. Latency over the Gateway-to-Gateway VPN tunnel was equivalent to the RV042.
A useful display in the System Summary screen shows the status of the VPN tunnels. As shown in Figure 4, my test RVL is running a Gateway-to-Gateway VPN tunnel and a Client-to-Gateway tunnel simultaneously.
Figure 4: VPN status in the System Summary screen
A neat detail the Linksys manual points out is how to manipulate the Windows route table to access devices on the far end of the Gateway-to-Gateway VPN tunnel via the Client-to-Gateway tunnel. Take a look at the graphic below. It depicts a remote PC able to access the LAN on the RVL200 and the LAN on the far end of the Gateway-to-Gateway tunnel.
Figure 5: Diagram showing device access though a Client-Gateway and Gateway-to-Gateway tunnel
My lab LAN on the left is 192.168.3.0/24, which is connected to a second LAN on the right using 192.168.5.0 /24 over a Gateway-to-Gateway tunnel. Simply adding the statement of route add 192.168.5.0 mask 255.255.255.0 192.168.3.200 at the Windows command line on my laptop made both LANs remotely accessible over the SSL VPN client.
The output of the DOS command netstat -r in Figure 6 shows the route table in my PC. Notice the circled entry routing the network 192.168.5.0 /24 to the next hop interface of 192.168.3.200, which is the IP address of the RVL200 VPN interface.
Note that the added route is not permanent. However, if I needed it to be, I could use the -p option of the route command.