Solution to QuickVPN Connection involving Domain Names.
Parameters of the connection issue: OS Vista 32, Connections work using STATIC IP Address, Connection Fails at "Verifying Network" stage when using a domain name from DynDNS.
For some time I have been struggling to understand why I was able to achieve a QuickVPN connection when I entered a static IP, but the connection process failed at the "Verifying Network" stage when using a domain name. Given that in order to reach the "Verifying Network" stage QuickVPN must have received a resolved address; for some reason it was losing the actual IP at the verification stage. It was interesting to note that if one checks the QuickVPN log (program files/cicso small business/quickvpn) the log will show the actual IP if a static address is provided, but lists the domain name when it is provided - this was a clue. The domain that failed was (myrouter).dynalias.net, even though when pinged the correct IP was returned. As an experiment I added an additional domain to my account (myrouter).dynalias.com (the only difference being .com instead of .net), and low and behold QuickVPN was able to achieve a connection with the new domain name. More importantly, when I checked the log, instead if the domain name, the actual IP was listed. There was also a difference in the way QuickVPN ran after clicking "Connect"; when using the .net version, that would ultimately fail, what followed was the "Connecting" window, however when using the .com version the "Connecting" window was preceeded by the "Command Prompt" window briefly flashing (too quick to read the contents). After the command prompt window flashed the normal sucession of connection stages followed, but this time the "Verifying Network" stage did not hang, and the complete connection was established.
It seems no one a Cisco is aware of this flaw in QuickVPN, they were always quick to blame it on ports being blocked, third party software, etc. Even though I pointed out that it couldn't be port blocking because the Static IP worked with out changing anything, and QuickVPN had to have gotten the resolved IP, or it wouldn't be able to reach the verification stage. Cisco would always retort with "it was working correctly our lab"; well now we know why, they probably used either a .com or .org extension for the domain name (these appear to work). I told Cisco that it was guaranteed that the flaw was in the way QuickVPN was handling the domain name at the "Verifying Network" stage - this proves it. It should be noted that both of my host names (myrouter).dynalias.net and .com return the correct IP when pinged - it has nothing to do with DynDNS either.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...