Hello, 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: Needed to be able to deploy to a user's home with zero support Needed to be able to block out user's home network for both confidentiality and security reasons Needed to be able to operate over DSL/Cable, etc. Needed to be able to support one or more VoIP phones as though they were in the office (e.g., 4-digit dialing, internal conference calls, inbound/outbound dialing, call routing, and call-center capabilities) Needed to be able to support user's laptop or computer without need of any software. 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: By hard-coding the TFTP server in the phone, the phones to the PBX at the core they could get their configurations reliably By hard-coding the IP of the DNS servers in the phones the lookup latency was eliminated and 2-way traffic worked very well (otherwise one-way calling and traffic would happen) By using a VPN tunnel the traffic all became TCP rather than UDP and so it increased reliability when connectivity was not optimum. By pinging the inside interface on the FVS318V3 from  a monitoring system on the core we could tell when user's lost connectivity or were experiencing latency issue and we could contact the ISP on there behalf and address the issue before they did. How do we put a complex network setup into a user's hands who might be completely non-technical.  First we required everyone have a NATing  SOHO firewall at their house and that they use GeekSquad or somebody like that to set it up with DHCP on the inside.  Once that was done we preconfigured their FVS318v3 and their phone, tested them, shrink-wrapped them together and shipped them to the customer with cables color coded with "plug this cable into your cablemodem or firewall, plug this cable into your laptop", etc.  Then when they would turn the FVS318v3 on and then the phone, it would come up, establish a tunnel.  The phone would come up, get a remote network IP, pull it's configs from the TFTP server on the PBX and voila, instant phone-number, instant office. We solved the problem of Internet Access by using FireFox and Thunderbird as desktop clients remotely because we could program in the information for a PROXY server running in the core.  We set up SQUID and loaded a proxy.pac file with the necessary proxy settings and whenever their browser or email client would come up it would be able to do what it needed to through the proxy server by using the configuration it obtained from the proxy.pac file. The remote user's had DYNAMIC IPs so we could not hard-code an endpoint on their side.  We solved the problem because the  FVS318v3 was able to always "initiate" a connection and it could provide the authentication information we required to grant access. We needed to be able to support multiple phones/computers at a single location and NAT traversal for VoIP is difficult enough over the public Internet and especially if you have multiple VoIP phones. 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: easy to deploy reliable remotely manageable (e.g, we can remotely monitor the routers as well as access the router and employee phone to adjust configurations as needed) call quality is excellent (we've seen excellent call quality when we are seeing latency as high as 125ms).  Generally we see between 10 and 65ms between the PBX and the Phone. 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. Thanks, David We are a premier fonality reseller http://www.tekops.com dbeecher@tekops.com ... View more