Cannot connect to VPN on Server 2012

8,128

It sounds to me like your VPN is using the PPTP protocol, rather than the other protocols supported by Windows Server.

PPTP is easy to publish through a firewall or router, you need two entries:

  1. TCP Port 1723
  2. IP Protocol number 47 (named "GRE" - Generic Router Encapsulation)

Some routers will do this automatically for you if you forward PPTP to your internal server.

The errors you are seeing relate to using L2TP and SSTP (both of which require SSL certificates). Unfortunately, you won't be able to fix this by restarting services or the server.

Can you describe what router you have? You'll need to make the changes there (and save - I suspect the changes made previously were not saved and thus were lost when you restarted it).

Share:
8,128

Related videos on Youtube

user214318
Author by

user214318

Updated on September 18, 2022

Comments

  • user214318
    user214318 over 1 year

    We run a small business and have a server that runs our VPN on Windows Server 2012.

    Our VPN was working fine until we restarted our router and it seems that restart procedure broke the VPN. We are not sure if it is a coincidence or not. At this stage we cannot connect to the VPN from any client. (There is a file server on the same server which we can access). We receive this message:

    Error 800: The remote connection was not made because the VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.

    On the server which we have remotely accessed, we have gone into Server Manager > Remote Access and had a look at the log and we receive multiple errors. One of which is different variations of:

    Failed to apply IP Security on port VPN0-104 because of error: A certificate could not be found. Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate.. No calls will be accepted to this port.

    The other error is:

    The Secure Socket Tunneling Protocol service either could not read the SHA256 certificate hash from the registry or the data is invalid. To be valid, the SHA256 certificate hash must be of type REG_BINARY and 32 bytes in length. SSTP might not be able to retrieve the value from the registry due to some other system failure. The detailed error message is provided below. SSTP connections will not be accepted on this server. Correct the problem and try again. The system cannot find the file specified.

    We have googled a SHA256 certificate and had a look in the registry for this file and it is not there. No one has accessed the server so is it possible that the certificate could have been deleted by itself?

    Another thing we have tried is we have gone into the Remote Access Management Console and clicked on Operational Status. We receive the following error:

    An unknown system error has occurred. Check if the Remote Access Management service is running.

    The resolution to this problem is:

    Enable (Start-Service ramgmtsvc) or restart (Restart-Service ramgmtsvc) the service at an elevated PowerShell prompt.

    As a result of seeing this error we have restarted DNS, DHCP, Remote Connection services numerous times but it has not helped. We have also restarted the entire server and this did not help either.

  • user214318
    user214318 about 10 years
    Hi Thanks for the response. I'm not sure how it was originally setup so it very well could be PPTP. We have a CISCO 857W router which to my understanding has no web interface for configuration.
  • DavidRa
    DavidRa about 10 years
    OK you'll need to look for the appropriate access list controlling your external interface (likely Dialer0, I suspect). Add new allow entries for source 0.0.0.0 to tcp port 1723, and for source 0.0.0.0 to ip protocol 47. I think ... something like: access-list 110 permit any any tcp eq 1723 and access-list 110 permit any any gre should cover it. I don't have a Cisco to cross check that, but this guide page suggests it's pretty close.