The FVX538 has two WAN ports, both of which support PPPoE or basic Ethernet connections, with options for DHCP or Static IP addresses. The PPPoE connection, if password and login is required, will automatically log in and establish a connection on power up, reboot, or use, a useful automation.
The value of dual WAN connections is the ability to have continuous connectivity, even through loss of an ISP connection. A dual WAN router should be able to support multiple connections, provide the option of using them in a load balancing or failover mode, send all traffic to the active connection when one fails, and revert back to a desired state when the connections are restored.
I tested the failover on the FVX538 by setting up static Ethernet connections from the FVX538 to two different routers, both with connections to the Internet, using WAN1 as primary and WAN2 as failover. I simulated WAN failure by pulling the plug from WAN1 while running a continuous ping to a public Internet site, and timing how long before those pings were successful. Multiple runs of this test produced a disappointing 2 minute 45 second average. This is slightly improved from the 3 minute average measured on the FVS124G, but still a long time to switch over.
I used the FVX WAN status screen to watch the WAN port status, and it revealed an interesting detail. The FVX538 doesn't detect the primary WAN connection is down for nearly 2 minutes! Each time I pulled the WAN1 connection, I could see in the NETGEAR status screen that the router considered the WAN1 port "UP," even though there was nothing plugged in! The physical lights on the port went out the second the cable was removed, yet the software didn't recognize the interface as down for nearly 2 minutes.
The delay in the interface status detection is obviously a big contributor to the slow failover performance. Since the processor of the FVX538 is more than double the speed of the FVS124G, yet the failover performance is nearly the same, it appears the issue lies in the NETGEAR software.
Update 11/15/2007: In response to a helpful comment from Joe Sutherland, I went back and found the settings in the WAN mode section that allow adjustment of the amount of time before a WAN failure is detected and triggers a rollover.
There are two parameters; Test Period (default = 30sec), and Failover (default=4), representing the number of failed Test Periods before rollover. The Test Period default of 30 seconds is the minimum, the router won't allow you to set it any lower. However, the default value of 4 in the Failover field can be set to a lower number.
I repeated my test with the defaults, and then adjusted the Failover parameter. I was able to improve rollover time by 30 seconds for each "click" of this control, as would be expected.
BTW, to set up port forwarding in rollover mode when connecting to the secondary WAN port, specify the incoming interface (WAN1 or WAN2), then the port and internal server IP where you are directing the traffic. You need to set up the same rule for both WAN1 and WAN2 directed at the internal server. I tested this and was able to set up port forwarding for Remote Desktop Connection (tcp port 3389) traffic from both WAN interfaces to the same internal server.
NETGEAR links its support page to the menu of the FVX538, so I gave it a try. I submitted separate support requests to NETGEAR, asking about the availability of a Vista VPN client and VLAN support using MultiLAN functionality. Although neither answer was what I wanted to hear, the responses were received within 1-2 business days and were clearly written.
NETGEAR offers multiple support options, as well as a robust warranty for their ProSafe product line. I'll cover both at the end of this review.
I keep a Site-to-Site VPN tunnel going continuously between the two sites a couple of miles apart, using a Linksys RV042 on one end and a SonicWALL TZ190W on the other. I put the FVX538 in my lab and configured it to take the role of the Linksys RV042, and re-established the Site-to-Site VPN tunnel.
But I had some issues getting the tunnel to connect. Duplicating the configurations I had on the RV042 to the NETGEAR, I got the tunnel to work, and left it running overnight. The next morning, though, I couldn't log into the FVX. It presented the login screen, but didn't accept my user name and password. I ended up having to completely disconnect the NETGEAR from all connections and power cycle before I could log in again.
NETGEAR's support site has some useful VPN configuration instructions, and conveniently, a guide for a Site-to-Site VPN between a FVX and a SonicWALL device, here (PDF link). I followed the NETGEAR guide and defaults for a NETGEAR to SonicWALL tunnel, which did work. I had to step down the tunnel encryption from the more secure AES encryption to 3DES encryption, as well as modify several other options. Once the NETGEAR-recommended configurations were entered on both ends, the tunnel came up and was stable.
Update 11/19/2007: Netgear said it will create an application note on setting up a VPN tunnel using AES (versus 3DES).
However, I noticed that ping times changed dramatically from LAN to LAN over the VPN tunnel. To ensure there were no anomalies or errors, I repeated the tests and setup, and verified my results. For some reason, ping latency over the VPN tunnel using the RV042 was 15-25ms better than with the FVX538.
As you can see from Table 2, LAN-to-LAN ping times are significantly higher using the FVX to set up a tunnel to a SonicWALL than a Linksys RV042. The intent here isn't to compare the NETGEAR and the Linksys, but these results were repeatable and are a clear difference.
The LAN-to-LAN ping times reflect the delay end devices would experience connecting over the VPN. This Site-To-Site VPN tunnel is used to provide off site backup storage, so the added delay will impact data being copied from one site to the other.
|RV042 to TZ190W||9ms||11ms|
|TZ190W to RV042||16ms||16ms|
|FVX538 to TZ190W||9ms||36ms|
|TZ190W to FVX538||16ms||33ms|
Table 2: Ping times in various configurations
This data is surprising, as the FVX538 is rated to support 200 VPN tunnels, has a more powerful CPU, more RAM, and a separate Cavium Encryption processor. There is obviously some form of encryption / encapsulation delay being introduced by the NETGEAR VPN module.
Update 11/19/2007: Netgear told us that ping response is "one component of a comprehensive traffic mix that can be used to assess performance" and that the 538 wasn't particularly optimized for ICMP (used by ping).
The FVX538 includes five licenses of NETGEAR's VPN Client software based on a product called SoftRemote from SafeNet. SoftRemote now supports Vista, yet NETGEAR hasn't updated its version of the client to support Vista as of this writing. Version 10.7.2 is shipped with the FVX538, a newer release than the 10.7.1 that shipped with the FVS124G.
Update 11/19/2007: Netgear says they will be releasing a Vista VPN client "this quarter".
As with the site-to-site VPN, NETGEAR provides a useful guide here for configuring both a router and the VPN client for remote VPN connectivity. There are multiple ways to configure VPN Client access, including manually, using the wizard, or with Mode Config.
Mode Config is the more secure method, and this is the means outlined in the NETGEAR guide. Mode Config allows remote VPN clients connecting to your LAN to be assigned an IP address in a different subnet than your LAN, enabling remote access to your LAN, yet providing a logical separation between the remote clients and local clients.