none
VPN Authentication Problems RRS feed

  • Question

  • Hello,

    I have two customers for whom I am trying to set up a simple PPTP VPN.  One is Essentials 2012, the other is Essentials 2016.  I am getting the same error on both; "The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server".  On the client side, I am specifying PPTP as the VPN type and MS Chap v2.  The server side configuration is the same as I have working on two server 2016 standard servers.  The only difference being that the standard servers have two NICs and the essentials servers each have only one.

    Thanks,

    Tim


    Tim in Dublin

    Wednesday, June 26, 2019 10:08 AM

All replies

  • hi,
    we can refer below document first 
    Manage VPN in Windows Server Essentials
    https://docs.microsoft.com/en-us/windows-server-essentials/manage/manage-vpn-in-windows-server-essentials

    No VPN Access using Server 2012 Essentials
    https://social.technet.microsoft.com/Forums/en-US/f4d5f777-3067-4b7a-9c46-c562e5a0f3fc/no-vpn-access-using-server-2012-essentials?forum=winserveressentials

    Server 2012 PPTP VPN With 1 NIC
    https://blog.thesysadmins.co.uk/server-2012-pptp-vpn-with-1-nic.html
    Please Note: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

    Best Regards
    Andy YOU
    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Friday, June 28, 2019 8:10 AM
    Moderator
  • hi,
    Is there any progress on your question?

    Best Regards
    Andy YOU
    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, July 2, 2019 6:29 AM
    Moderator
  • Hi Andy,

    I haven't been able to get back on site since I posted the first question.  I hope to be able to get to one of the sites tomorrow.

    Thanks,

    Tim


    Tim in Dublin

    Tuesday, July 2, 2019 8:49 AM
  • Stop using PPTP, use SSTP instead, it is the default in Essentials and is more secure than PPTP.

    Robert Pearman @titlerequired Windows Server Essentials.com

    Tuesday, July 2, 2019 2:57 PM
    Moderator
  • Robert,

    Thank you for your reply, but my post was a request for assistance on a specific problem, and not a request for advice on best practices.  I understand security concerns with PPTP, I am just trying to get a remote access solution up =very quickly= for a couple of clients as I am about to undergo major surgery that will leave me immobile for a couple of months.  My 2 clients are very small Irish businesses and unlikely targets for RDP breaches and, I don't have time to fool with certificates in the near term.  I have less than an a week to get this working so that I can support them from a hospital bed.  I can screw down the security once I have a workable remote access solution in place.

    A lesson I learned over 30 years ago; it doesn't have to be elegant, it just has to work.

    Regards,

    Tim


    Tim in Dublin

    Wednesday, July 3, 2019 1:53 PM
  • Hi Andy,

    I was onsite at one client last Friday.

    I looked at the links that you sent.  The third link is a basic "how to set up VPN in server 2016".  Those are the steps which I followed exactly (same as setting up in Server Standard), and I am getting the same authentication errors on both Essentials servers.  The second link appears to be a dead link. The first link describes the setup of "Anywhere Access".  I am not familiar with Anywhere Access, but in reading up on it, it doesn't look appealing at all.  Anywhere Access requires the client computer to be either joined to the domain, or connected to the domain network in order to establish a connection.  That is impractical for me and any of the client's users that may want to establish remote access in the future (I am not going to lug my two desktops into the client's office  and up two flights of stairs to get this working). Might be a good feature for laptops, but it is completely unreasonable for desktops.

    I do not understand why the same steps work for server standard and not server essentials.  I suppose that is the crux of my question.  The anywhere access thing is not going to be an option.  If I am reading this documentation correctly, it looks like the anywhere access solution creates a self signed certificate which it transfers to the client during the "Connect client computers to the server" phase.  Again, I need a very quick and simple PPTP VPN connection before I go into hospital and am not able to travel to the client sites for two months.  The last time a situation like this occurred for me, a client brought in an unknown "expert" that completely trashed their AD structure.  I don't want to do that again.

    Many thanks,

    Tim


    Tim in Dublin

    Sunday, July 7, 2019 2:05 PM
  • hi,
    because server essentials is domain control and file server .we can refer below document to test it ,if the server essential is installed in vm ,we can snapshot then test your idea.  There are a few people use PPTP on server essentials indeed ,more people are using SSTP on server essentials.

    Best Regards
    Andy YOU
    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Sunday, July 7, 2019 2:08 PM
    Moderator
  • Hi Andy,

    I don't really seem to be getting my message across; The server is not a VM.  It is a standalone physical server in a =very small= environment, hence essentials.

    You stated "There are a few people use PPTP on server essentials indeed, more people are using SSTP on server essentials."

    I appreciate that, but as I have stated earlier, I am under a significant time crunch in getting this going.  I have less than a week to get this working and have two clients in geographically distant locations.  I looked at the SSTP setup and whereas the PPTP setup should work in about 12 easy steps, the SSTP setup is about 185 easy steps.  My base question is why doesn't the setup for server essentials work the same as standard? I need a simple PPTP connection, no bells and whistles.  My client and myself are willing to accept the security risk.

    Tim


    Tim in Dublin

    Sunday, July 7, 2019 2:43 PM
  • SSTP on an Essentials server is three steps, cannot get any easier.

    Mariëtte Knap [alumna Microsoft SBS MVP]
    www.server-essentials.com | Linkedin | Migrations done the easy way
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, July 7, 2019 4:12 PM
  • Thanks, but I am not migrating anything.  This is a new installation.


    Tim in Dublin

    Sunday, July 7, 2019 4:22 PM
  • Chapter 3 of https://www.server-essentials.com/support/get-a-free-lets-encrypt-certificate-anywhere-and-automatically-renew-it describes the procedure. And a remote client does not need to be joined to the domain to use it. Because SSTP uses port 443 and nothing else it is much more repliable

    Mariëtte Knap [alumna Microsoft SBS MVP]
    www.server-essentials.com | Linkedin | Migrations done the easy way
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, July 7, 2019 4:22 PM
  • Thanks for that Mariëtte.  I'll have a look at that this morning.

    Tim


    Tim in Dublin

    Monday, July 8, 2019 8:23 AM
  • Hi Mariëtte,

    Thanks again for your reply.

    I was finally able to gain access to both of the problematic servers today in order to try your suggestion.  In going through the Certify The Web setup, I hit the same brick wall at both sites.  When I get to the "Test" phase, I get the response "Could not verify URL is accessible: http://remote.ants.ie/.well-known/acme-challenge/configcheck".  Couldn't find a lot of support resources at Certify The Web.  Everything I found was in a GitHub forum, and the requestors were all in China.  I have verified that ports 80 and 443, plus all of the applicable VPN ports are open on the firewall.  I followed the IIS settings in your instructions step for step.  I created subdomains for each client's domain previously (remote.[client].ie), with an A record pointing to their static IP, which resolves correctly via nslookup.  I have to think that this is either an IIS or DNS issue.  Can you please provide any insight?

    Thanks,

    Tim



    Tim in Dublin

    Friday, July 12, 2019 1:57 PM
  • Tim,

    Port 80 and 443 is closed at IP address [93.107.103.116] see https://www.yougetsignal.com/tools/open-ports/. Is that IP address correct?


    Mariëtte Knap [alumna Microsoft SBS MVP]
    www.server-essentials.com | Linkedin | Migrations done the easy way
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, July 12, 2019 2:10 PM
  • Hi Mariette,

    I don't quite get that.  The ports should be open/forwarded to the internal IP of the server; 


    Tim in Dublin

    Friday, July 12, 2019 5:41 PM
  • Maybe your ISP blocks those ports?

    Mariëtte Knap [alumna Microsoft SBS MVP]
    www.server-essentials.com | Linkedin | Migrations done the easy way
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, July 12, 2019 5:43 PM
  • Hi Mariëtte,

    I got the Certify The Web setup completed on both machines.  I then realized that one of the machines is actually Foundation edition and doesn't have Anywhere Access.  I'll set that machine aside for now.  The other is Essentials 2016.  When I try to configure Anywhere Access it fails saying that ports 80 and 443 are not open.  I have checked https://www.yougetsignal.com/tools/open-ports/ for IP 93.107.184.217, and it reports that those ports are open.

    


    Tim in Dublin

    Tuesday, July 16, 2019 9:28 AM