none
L2TP VPN Error 809 & 789 with Windows 7 x64 - works with Vista and XP RRS feed

  • Question

  • I have a Windows 2008 Server to which I am trying to open a L2TP VPN connection on a Windows 7 x64 client.  I am using a pre-shared key.

    I have successfully connected to the Server with a 32 bit Vista client and a 32 bit XP client.  I use the exact same settings, internet connection, firewall, etc. on the Windows 7 64 bit client with no luck. 

    I have spent 8 hours searching the internet and attempting different solutions.  I have found a handful of people experiencing this problem.  Common advice is to:

    1.  Check firewall settings.

    2.  Check that pre-shared key is correct.

    3.  Modify registry to allow NAT Traversal with AssumeUDPEncapsulationContextOnSendRule=2.

    4.  Make sure "IPsec Policy Agent" and "IKE and AuthIP IPsec Keying Modules" services are running.

    I can get XP and Vista clients to connect on the same internet connection so 1 is out.  So is No. 2, I double-checked it and again, it works on other machines.  I did No. 3 and it made no difference.  The services are running as described in No. 4.

    One poster stated that he "restored" his Windows 7 machine and the VPN suddenly started working again.  He did not specify what he rolled back.

    Any ideas?  I would be eternally grateful, my world has come to a standstill because of this issue.

     

    Wednesday, August 11, 2010 4:42 AM

All replies

  • Did you get this working?  I am having the same issue.
    Tuesday, November 30, 2010 3:22 AM
  • Hi guys, 

    I have the same problem on Windows 7 Prof. 32bit + Wireless connection.   IPv6 is turned off, but VPN still don't works.

     
    OK, then tell me why this work on VMware Player with windows XP ?  I have VMware Player with Windows XP on my local machine,
    and VPN connection on WMVare Player work perfectly, but on local machine, VPN connection respond error 809.  
    I think, this VPN has nothing  with settings on router or port forward settings?
    Saturday, December 4, 2010 2:20 PM
  • Error 806: a connection between your computer and the VPN server has been established but the VPN connection cannot be completed.  The most common cause for this is that there is at least one internet device between your computer and the VPN server is not configured to allow GRE protocol packets Verify that protocol 47 GRE is allowed on all personal firewall devices or routers.  if the problem persists, contact your administrator.

    Resolutions: 
    1) if you have a router/firewall, make sure you open TCP Port 1723, IP Protocol 47 (GRE). 
    2) make sure you can reach the VPN server by using ping.  Sometimes, poor connection can cause this issue too.
    3) You may need to updated firmware on a router or firewall.
    4) The VPN server may not be able to get IP from DHCP for the VPN client. So, you may want to re-configure VPN host networking settings. For XP pro VPN host, go to the Properties of the VPN>Network, check Specify TCP/IP address and Allow calling computer to specify its own IP address, and uncheck Assign TCP/IP addresses automatically using DHCP.
    5) Make sure other secure software blocks your access, for example, if you use Norton secure software, you may need to add the remote client's IP so that the client can access.
    6) If your VPN running on a Windows RRAS with NAT enabled, you may want to check the NAT settings.

    Monday, January 17, 2011 7:46 PM
  • I got connecting to VPN network problem with error code 789.

    After a two-day research, I rollback my network card driver to the one provided by Microsoft, everything goes fine.

    Thursday, January 27, 2011 3:01 PM
  • The problem that I found was that if you try to use L2TP behind a firewall the first connection MAY be successful however additional connections will have problems because routers can't process port 0 correctly w/NAT.

    This will result in "no ports open" type errors similar to the 809 & 789 errors as if the server isn't responding/etc because port "0" will appear closed.

    So, this is one of the reasons why they don't support VPN connections behind NAT in addition to the security stuff that you'll see posted.  Here's are similar articles posted with more explination when using Direct Access (which requires 2 public static IPs):

    http://blog.concurrency.com/infrastructure/uag-sp1-directaccess-ip-addressing-the-server/

    And also ideas on how to change your Cisco router configuration:

    https://supportforums.cisco.com/thread/2135621

    Wednesday, October 23, 2013 8:24 PM
  • I had a similar problem. Ultimately, I got it working! What appears to have fixed it was the following:

    - Right-click on your VPN connection, select Properties

    - Select Networking

    - Verify IPv6 is unchecked

    - Click on Properties for IPv4, then click Advanced...

    - Click OK, OK, OK. (If you were currently connected already, it would say "Since connection is active, some settings may not take effect until the next time you dial in").

    Apparently that last step was critical for some reason. Even though I didn't change any IPv4 settings, just the act of confirming the IPv4 settings with the OK buttons somehow seems to have resolved the error 789 issue for me.

    Now, it could also be that one of the things I did before that were important as well, but they alone didn't seem to help:

    - I changed the VPN address from a URL to an IP address. Actually, this appears to be important. If I change it back from IP to URL, the VPN connection is broken again, as I just discovered...

    - Very odd. I was just able to restore the VPN connection now by enabling IPv6 and clicking ok, then disabling it again and clicking ok. 

    OK, I can't reproduce it anymore, now it seems to work every time. Odd. However, mostly I just fiddled with the "Networking" tab in the VPN properties, perhaps enabling/disabling IPv4 and IPv6 in the right order, when I finally got it working.

    Other things I did earlier, before I finally got it working for the first time:

    - I deleted and re-scanned various network drivers, including "hidden" devices

    - I updated Tinywall to the newest version

    - I made sure the IKE and IPSec services were not just running and set to "automatic" instead of manual

    - I verified the registry keys existed as follows:


    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent] "AssumeUDPEncapsulationContextOnSendRule"=dword:00000002 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters] "ProhibitIpSec"=dword:0000000


    Wednesday, April 15, 2020 8:31 PM