SmallNetBuilder

VPNs

The FVS336G first and foremost is a VPN device, with the ability to support up to 25 IPSec and 10 SSL VPN tunnels simultaneously. Either the SSL or IPsec tunnels can be used for remote access and there are enough IPsec tunnels to support multiple gateway-to-gateway secure links.

This a different approach than taken by the recently reviewed Linksys RVL200, which is primarily a VPN gateway with SSL tunnels for remote access and a single IPSec tunnel for connection back to a central corporate gateway.

IPSec tunnels are created via Site-to-Site configurations or via NETGEAR’s VPN Client software, as they were with the FVS124G [reviewed] or FVX538 [reviewed]. The SSL VPN tunnels are a newer addition, enabling VPN connectivity without the hassles of licensing, installing, and configuring client software.

IPSec Site-to-Site tunnels set up quickly on the FVS336G. I had no problem connecting the FVS336G to a SonicWALL TZ190W over the public Internet. Using the NETGEAR VPN Wizard, I created a VPN Policy as follows and depicted in Figure 3:

1. Select Gateway for tunnel type.
2. Enter a name and password in the Connection Name and pre-shared key fields. In the example below, I entered "VPN to Other Site" as my Connection Name and "mypassword" as the pre-shared key.
3. Enter WAN IP address or domain names for each endpoint, such as "othersite.domain.com" and "thissite.domain.com" as below. IP addresses are a more stable means of endpoint identification if you're using ISP services with static IP addresses. I have some additional comments later in this review on using domain names instead of IP addresses for VPNs.
4. Enter the subnet and mask of the remote network. (IMPORTANT: The remote network is the network on the other end of the tunnel, and it should be a different subnet than the local network.) In the example in Figure 3, I entered 192.168.1.0 and 255.255.255.0. Clicking Apply saves the new policy.

Figure 3: IPSec VPN Wizard

Using the VPN Wizard to create a VPN Policy automatically creates a corresponding IKE (Internet Key Exchange) Policy with the same name. I've found changing the Local and Remote Identifier Type fields to Local WAN IP and Remote WAN IP works best, even when using domain names instead of static IPs. Notice in Figure 4 how the Identifier Types are then grayed out.

Figure 4: Internet Key Exchange Policy configuration

Once the VPN and IKE Policies are built, they can be edited. For example, encryption can be changed from 3DES to AES-256 if desired. Note that Main Mode for Phase 1 and Perfect Forward Secrecy (PFS) for Phase 2 are automatically selected using the VPN Wizard. These options need to match on the far end for the tunnel to come up. 

The options to configure Local and Remote Identifiers in my experience create more opportunity for configuration mismatches. Keep in mind that tunnel security is already established through a pre-shared key.

I have had better success creating Site-to-Site tunnels between different brand routers with these two fields blank. I find getting a tunnel established with basic settings and then experimenting with additional settings later is a more efficient and less frustrating approach.

I experimented with a variety of encryption settings, and was pleased that 3DES and AES-256 encryption both worked well with the FVS336G. I had a little problem with AES-256 encryption and the FVX538, but no problems with the FVS336G. 

VPN Latency issues detected on the FVX538 also seem to be resolved with the FVS336G. I've updated Table 2 from our FVX538 review to include latency times for the FVS336G. As you can see, the latency issues we experienced in November with the FVX538 are not present in the FVS336G.

Table 2: Latency times

I noticed my NETGEAR-SonicWALL Site-to-Site VPN tunnel dropped several times over the course of my testing. I traced the problem to the fact that my ISP had changed my WAN IP, yet the NETGEAR dynamic DNS client hadn't updated the domain name service. So, the domain name for the WAN interface on the NETGEAR end of the Site-to-Site tunnel was no longer mapped to the correct WAN IP and the connection dropped.

I reported this issue to NETGEAR, and they're looking into it. Of course, using static IP addresses on both ends of the tunnel eliminates this issue.