I'm writing this because most of the discussions are either too technical, don't say why specific equipment was selected, or does not have a solution to the problem. I developed this solution because I had not seen it done completely anywhere else and none of the discussions identify security requirements at a business level. So here goes.
We had a need to deploy "virtual offices" for telecommuters. We needed to be able to keep communications secure, support multiple users as a single location, and be able to deploy/manage the offering at low-cost and with minimal technical support.
We found that we could utilize the PIX/ASA 525/535 series at our core (we had these) as a firewall and remote VPN Concentrator and we chose the NetGear FVS318v3 Firmware 3.0_26RC1 (minimum) as a remote endpoint.
The hurdles facing us were:
The FVS318v3 would support these needs because it would hand out DHCP to the home/soho user and we could program the DNS servers specifically so that the user's phone(s) and computer(s) would go to the core for DNS. We could not allow the router to hand out itself as a DNS server because the delay would cause issues with the phone (one-way communications due to DNS lookups).
The FVS318v3 could also be programmed to reboot periodically (once a day) to keep clean and to run IKE Keep-Alive to keep the tunnel active if it got torn down due to poor Internet connectiivty.
Lastly, we needed to force all traffic on the FVS318v3 over the vpn tunnel so that they could not have a compromised computer relaying information from our corporate network to a hacker at their home (e.g., through wireless gateway, virus, napster, lime-wire, bit-torrent clients, etc.).
We ran Microsoft terminal server at the core to reduce bandwidth requirements and keep our data in-house. That way if connectivity drop did occur no data was lost. The microsoft RDP client is on every desktop/laptop, and it solved lots of other business and technical issues as well.
Technical issues we solved, and how:
Generally, anytime a user had a connectivity issue they would power-cycle their router and would be reconnected within a minute or two.
This had been working perfectly for several years when we ran into an issue where a couple of people could NOT work over the VPN. We were able to determine, using sniffers and PIX debug logs that the VPN tunnel was coming up and that they keys, etc., were all good. We could see that when the user pinged a server in the core the ICMP echo request was going into the tunnel, emerging on the pix, and forwarding to the server. The server was replying and it would never make it back to the remote user. In fact, all network traffic would make it to the core and none of it would make it back. The byte-counters in the router were showing traffic both ways, so the tunnel was up.
What we figured out was that a tech had manually set the MTU to 1500 on the employee's home router, rather than AUTO and that would fragment the packets and the FVS318v3 was not able to re-assemble them. With minimal diagnostics we had nothing on the FVS318v3 telling us this and the PIX clusters were reporting no errors. Once we changed the the settings on their home router it worked. This problem has not been reported anywhere on CISCO's site or anywhere else.
Be sure to check all the equipment every step of the way for configuration details. This one change by this tech had worked for a year and then all of a sudden one day it would not and it took 2 days of research to track it down.
This configuration works extremely well:
If you need to set something like this up we can help. I hope the information I've provided above gives you the confidence to try this and to know it is doable. We have deployed this setup all over the U.S. and abroad dozens of times.
We are a premier fonality reseller