PPTP server not listening on port 1723 RRS feed

  • Question

  • I am having a strange problem with the built-in PPTP server in Windows 8.1. Every time that the machine is started with a cold boot, I can't connect to the VPN. I run netstat -ano, and confirm that it is not listening on TCP port 1723. It is not listed at all, so it doesn't seem to be used by another app. RRAS is running, and restarting the service does not change anything. Additionally, the "Incoming Connections" in present in the adapters page, and all the settings are correct.

    However, the issue is temporarily fixed by doing a restart. After a warm boot, the server is listening on port 1723, and I can connect to it with an outside client. This rules out all network and firewall issues on the server side, and all other issues on the client side.

    From my testing, it seems that if the server machine is shut down, and started from a cold boot (even after just a couple of minutes), it never listens on port 1723. I have tried setting RRAS to delayed start without success. But so far, it always listens on port 1723 after a warm boot (restarting).

    Does anyone have any ideas on why this is happening? Are there any diagnostic tools that I can use to pinpoint the problem? Thanks in advance for your suggestions!
    Monday, November 10, 2014 7:30 PM

All replies

  • PPTP uses IP   protocol 47, designed for "General Routing Encapsulation" or GRE packets. A common mistake in configuring firewalls for use with PPTP is to open PPTP port 1723 (allowing connections to be established) but forget to forward GRE protocol type 47 (denying port data from passing through the tunnel).



    Monday, November 10, 2014 8:50 PM
  • Hi Milos,

    As I mentioned above, after a restart (warm boot), the server machine listens on TCP port 1723, and I am able to connect it to with an external client. This is not a router configuration issue. IP Protocal 47 (GRE) and is open on the router, and TCP port 1723 is correctly forwarded. Additionally, both GRE and TCP 1723 is open in Windows Firewall.

    If this was a router or firewall issue, then I would never be able to connect to the server. Instead, the issue is the fact that the server machine is NOT listening to TCP port 1723 on initial startup from a cold boot. Once I do a restart, then it starts listening on 1723, and I am able to connect. This rules out all potential router or firewall issues. What I need to figure out is why the server is not listening on initial startup, but will listen after a reboot.

    Monday, November 10, 2014 11:10 PM
  • Hi  tenderchkn,

    Have you made any change before this issue?

    Please open the event viewer and check if there are any related error log. For more information about the event log, please refer to the following article. This link is about event viewer in windows 7, and it is similar in windows 8.1 .

    Best regards,
    Fangzhou CHEN

    Fangzhou CHEN
    TechNet Community Support

    Tuesday, November 11, 2014 11:07 AM
  • Hi Fangzhou,

    Thanks for your suggestion to look at the event viewer. I tracked down the error, which is:

    "Remote Access Connection Manager failed to start because the Protocol engine [IKEv2] failed to initialize. The request is not supported." Event ID is 20063. Are there any solutions? Why does this error only occur from a cold boot, but not after a restart? This was not an issue with Windows 7.

    EDIT: Actually, the error also shows up after doing a restart (when the server is working). The error is logged every time the RRAS is started or restarted, but isn't what is causing the problem. This is the only Remote Access related error. What else should I look at?

    EDIT 2: I did some more testing, and found something interesting. I tried setting "Routing and Remote Access" to Manual. After a restart, RRAS does not start by itself. I can manually start it, and the server will start listening on port 1723 (and I can connect with an external client). From a cold boot, RRAS does start by itself (even though it is set to manual), and the server machine does not listen on port 1723. Stopping and restarting RRAS does not change anything.

    I tried setting RRAS to disabled, and starting from a cold boot. After I enable it and manually start the service, the server works (listens on 1723, and I can connect). This seems like some other service is controlling RRAS when doing a cold boot, and causing problems. Is there a way to find out what services RRAS is a dependency of, and which one is starting it up?

    • Edited by tenderchkn Wednesday, November 12, 2014 4:27 AM
    Wednesday, November 12, 2014 3:03 AM
  • it is strange, use the clean boot to exclude the function of third-party app


    • Marked as answer by Michael_Martin Monday, November 24, 2014 7:24 PM
    • Unmarked as answer by Michael_Martin Monday, November 24, 2014 7:24 PM
    Monday, November 17, 2014 6:03 PM
  • In Windows 10 I found out, that similar problem can be solved by disabling Fast startup checkbox in Power options - Power button options.
    • Proposed as answer by Carolper Saturday, November 3, 2018 1:15 PM
    Sunday, September 6, 2015 4:21 PM
  • I am having the same issue with Server 2012 R2.  All is fine until the server goes to sleep, after the server wakes up, PPTP is not listening on port 1723.  I don't have the disable Fast Startup option as this is a Dell T20 Server box, and not a laptop.  I did not have this problem with Server 2012.  I would like to make this work, but I'm out of ideas.



    • Edited by party of 5 Saturday, January 9, 2016 3:12 PM added display name
    Saturday, January 9, 2016 3:10 PM
  • Hi,

    I have the exact same problem with Windows 10.

    After the systems wakes up from hibernation or sleep the PPTP port (1723) is no longer listening

    A restart of the RRAS service does not solve the problem. I can only recover the PPTP server if I restart the system.

    I would like to make this work after the system wakes up from sleep without having to restart the system.

    Any ideas?



    Wednesday, February 17, 2016 11:40 AM
  • This is still a problem with Windows 10 Anniversary edition with patches as of January. 30th 2017. Has anyone found a workaround short of a restart?
    Tuesday, January 31, 2017 11:17 PM
  • I encountered the same issue after updating Windows 10 to 1709. To correct the issue ensure that the service Remote Access Auto Connection Manager is running.

    1. Open the task manager
    2. Select the services tab
    3. Look for either the name RasAuto or description Remote Access Auto Connection Manager
    4. Once the service is running, open a command prompt
    5. Run the command netstat -a | more and confirm that TCP is listening
    Sunday, November 5, 2017 3:12 PM
  • Running "Remote Access Auto Connection Manager" service doesn't solve the problem. 1723 port isn't listening after hibernation. Only after Windows restart 1723 port is listed in "netstat -a" and I am able to connect to PPTP server.
    • Edited by Supr.A Saturday, September 22, 2018 10:21 AM
    Saturday, September 22, 2018 10:20 AM
  • We too have that problem, is there any solution yet? This problem is known for year, but Microsoft doesn't seem to be inclined patching this weird bug.
    Saturday, January 5, 2019 12:56 PM
  • Wow

    So many years and the issue has note been fixed. Having same problem on windows 10

    Monday, March 23, 2020 7:50 PM