Question : VPN Clients won't connect -- Error 721

I've already been working on this too long.  VPN is NOT that hard!  Before I even begin to explain the issue, my gut tells me I have bad firmware in the Linksys Router.

Ok, I have a client with a very simple, easy network.  They have a Windows 2000 Advanced server which has a static IP.  It connects to a Linksys WRV54G which connects to a switch, which connects to a Telepacfic Fractional T1.

Before you jump in there...I'm NOT using the Linksys QuickVPN utility.  Maybe I should :-)   Instead, I configured routing and remote access, as I've done many times before.  I've opened port 1723 and 47.  I've even opened port 130 - 138, and port 500.  I also tried turning the firewall off altoghether and it still doesn't work!!

when I try to establish a connection, it hangs for a couple of minutes on the "verifying username and password" before it times out and starts the redial, with error 721.

This isn't rocket science.  It's actually very straightforward...error 721 is a firewall issue.  But why? I turned the firewall off and it still won't work!!  

I'm really beginning to doubt the stability of Linksys.  I stayed with this line because Cisco bought them.  But at the end of the day, they're still Linksys.

My plan.... Try and use the quickvpn utility.  If that doesn't work, upgrade the firmware..Again... reset and reconfigure the router.

If anyone else has a better idea, or something I've overlooked, I'm listening....

Answer : VPN Clients won't connect -- Error 721

>>"I'm not comfortable putting a production server on the open internet "
Sorry I mean connect the client directly to the modem.

>>'//server/resource"
Assume a typo, but it needs to be; \\server\resource

Name resolution over a VPN especially with non-corporate routers is a very common problem. Have a look at the following list (I know a lot duplicates above) for options:
NetBIOS names  (computer names) are not broadcast over most VPN's.
You can resolve this in several ways:
1) Use the IP address (of the computer you are connecting to) when connecting to devices such as;   \\123.123.123.123\ShareName   or map a drive at a  command prompt using  
 Net  Use  U:  \\123.123.123.123\ShareName
2) An option is to use the LMHosts file which creates a table of IP's and computer names. LMHosts is located in the Windows directory under c:\Windows (or WINNT)\System32\Drivers\Etc\LMHosts.sam , instructions are included within the file. Any line starting with # is just a comment and is ignored. Open the file with Notepad and add entries for your computers as below;
192.168.0.101      CompName       #PRE
Hit enter when each line is complete (important), then save the file without a file extension. To be sure there is no extension ,when saving enclose in quotations like "LMHosts". Now when you try to connect to a computer name it should find it as it will search the LMHosts file for the record before connecting.
More details regarding LMHosts file:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnfd_lmh_qxqq.mspx?mfr=true
The drawback of the LMHosts file is you have to maintain a static list of computernames and IP addresses. Also if the remote end uses DHCP assigned IP's it is not a feasible option. Thus in order to be able to use computer names dynamically try to enable with some of the following options:
3) if you have a WINS server add that to the network cards configuration
4) also under the WINS configuration on the network adapter make sure NetBIOS over TCP/IP is selected
5) try adding the remote DNS server to your local DNS servers in your network card's TCP/IP configuration
6) verify your router does not have a "block NetBIOS broadcast" option enabled
7) test if you can connect with the full computer and domain name as  \\ComputerName.domain.local  If so, add the suffix DomainName.local to the DNS configuration of the virtual private adapter/connection [ right click virtual adapter | properties | TCP/IP properties | Advanced | DNS | "Append these DNS suffixes (in order)" | Add ]

If you wish to deal directly with the GRE issue:
First verify port forwarding is configured/working for PPTP, port 1723; from the VPN server go to the following site and test for port 1723:
http://www.canyouseeme.org
 
Assuming that is working correctly, Microsoft has a pair of test tools pptpsrv and pptpclnt, to test for GRE pass-through, which are available as part of the Windows resource kit or from:
http://www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en

Log onto the client or VPN server machine and connect to the other with remote desktop, or a similar remote management tool. At a command line on the client machine, run pptpclnt and on the server run pptpsrv. The client machine will send a set of GRE packets to the server and it should show as received if GRE is able to pass. The server is then supposed to respond and the client indicate received, but I have never had that part work. The one direction client to server is usually enough to test.

Following links outline the use of the test tools:
http://www.howtonetworking.com/Tools/testgre.htm
See VPN traffic:
http://www.microsoft.com/technet/community/columns/cableguy/cg0105.mspx