Share via

VPN Server on a windows PC

Question

Thursday, July 19, 2018 10:01 PM

Hello,

I have been having problems with this for months now, coming up to a year, so far I haven’t posted an actual very explanatory description of my problem and what I want to fix it, this is that, so please, dig in, read slowly, and please, find a solution.

I have a Desktop PC the stats are as follows:

Edition: Windows 10 Pro

Version: 1607

OS build: 14393.2189

Product ID: *****-*****-*****-*****

Processor: Pentinum(R) Dual-Core CPU E6500 @ 2.93GHz 2.93 GHz

Installed RAM: 2.00GB

System type: 64-bit  operating system, x64-based processor

Pen and touch: No pen or touch input is available for this display

I am trying to make the PC a vpn server, so this Pc will be referred to now by VPNSERVER, I am attempting to do this via the instructions of this website: https://www.howtogeek.com/135996/how-to-create-a-vpn-server-on-your-windows-computer-without-installing-any-software/ , this has been a success on the hosting end as far as I can tell, the VPNSERVER is in a DMZ all ports are forwarded, I have checked, the VPNSERVER is a static ip, everything on the pc is fine, as far as I can tell. I am trying to connect to it via a MacBook Pro running macOS Sierra, this is not connected to the same network as the VPNSERVER, it is connected to my iPhone hotspot, I have attempted to connect to it with a IKEv2 config, I have put the public ip as the server address, the remote ID as the VPNSERVER’s username, nothing is in the Local ID.

Please, Help

-Thank you

-M

All replies (28)

Wednesday, July 25, 2018 10:00 AM ✅Answered

I cannot find any useful guidance for what you want to achieve in the web. It would perhaps be useful to know what the "high-level" goal is for which a VPN has been selected as the enabling technology solution.

Out of personal (theoretical/learning) reasons, I have been playing with the Windows VPN support a bit. One step forward was "cutting out" a bit of the local IP subnet range managed by the router/firewall and handing this over to Windows to use for inbound VPN connection endpoints:

The next step was realizing that for all the VPN options involving IPsec, one has to configure IPsec oneself. "New-NetIPsecRule" and its related cmdlets have been the tools that I used to experiment with this. I could then get an L2TP/IPsec VPN between two Windows 10 PCs to work; however when I try to use a MacBook as the client, the connection fails with the "no policy" reason (it seems as though the MacBook is using a dynamic port for L2TP (Windows 10 uses the standard port) and this might be the reason (more work needed)).

One also possibly needs to add another rule to the firewall for UDP port 4500 (for IPsec NAT Traversal) - that depends on the firewall's capabilities.

It is all looking rather complicated, which is why one might want to reconsider whether this approach is really necessary.

Friday, July 20, 2018 2:32 AM

Hi,

Based on your description, I found an article may relate to your problem, please refer to the link:

You Cannot Connect to the Internet After You Connect to a VPN Server

https://support.microsoft.com/en-us/help/317025/you-cannot-connect-to-the-internet-after-you-connect-to-a-vpn-server

In addition, I also found a similar case may give you some points, please refer to the link:

Internet Unavailable after VPN disconnects, giving Ping response of No Resources

https://partnersupport.microsoft.com/en-us/par_clientsol/forum/par_win/internet-unavailable-after-vpn-disconnects-giving/0eae2fc8-b287-42f1-b7e6-f1a1223b81e8

You can also try troubleshooting tools and check the result.

Troubleshoot Always On VPN

/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-troubleshooting

Best Regards,

Tao

Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact [email protected].

Friday, July 20, 2018 10:15 AM

It would seem that I have expressed the problem incorrectly, the problem is not that I can't connect to wifi when connected to the VPN, it's that I can't actually connect to the VPN, nevertheless, I will try these links.

Sorry for not being able to justify the actual problem.

-M

Friday, July 20, 2018 11:20 AM

I would still like some help with this server, these links aren't any help sadly...

Friday, July 20, 2018 12:16 PM

I'm calling it a server, it isn't really though.

Friday, July 20, 2018 1:27 PM

A network trace (or, even better, two network traces - one from each system) would probably show what is going on/wrong. I think that tcpdump is available on the MacBook Pro and there are various tools for Windows (one could use the built-in command "netsh trace start scenario=lan capture=yes tracefile=why.etl" ("netsh trace stop" stops the trace)).

Without information like that, I doubt that there is much that anyone who has not got the same set-up as you could say to help...

Friday, July 20, 2018 2:43 PM

Ok, have done so, here are the files:

https://drive.google.com/drive/folders/1rM9ebUTEonAJy9AzRXjcPc3b5PTxrXb6?usp=sharing

Friday, July 20, 2018 3:33 PM

There were a couple of things that I did not explicitly write, which was rather silly of me.

The first is that it would be useful if both traces covered the same period of time, so that we can see if any "outbound" packets reach the target system (crossing whatever NAT/firewall devices are on the path).

The second thing is that one should try to establish the VPN connection whilst the traces are running (collecting data).

I looked at the traces, and they were both reasonably good (in terms of frame capture length, etc.) but they had some problems:

  • They did not temporally overlap (the Windows trace was made first and then the MacOS trace)
  • The Windows trace only captured 6 packets - nothing interesting there
  • The MacOS trace did not contain any traffic that looked plausibly like a VPN protocol - there was certainly no IKEv2 traffic over UDP port 500 to be seen.

If the MacBook Pro did recognize that a VPN connection was required, something prevented it from sending any packets.

Friday, July 20, 2018 4:23 PM

A quick question, when I scan with the Mac, do I scan on the VPNSERVER's wifi, or my hotspot?

Friday, July 20, 2018 4:36 PM

You should capture data on the Mac (with tcpdump) in the configuration that you expect to work (or is most likely to work).

Initially, we just need to see the MacBook sending some packets that look like VPN traffic. Based on what we see (e.g. outgoing packets but no responses), we could think about how to simplify the test, if necessary/possible (e.g. putting MacBook and VPN server on the same network (to eliminate port forwarding issues, etc.)). But we have not got that far yet...

Friday, July 20, 2018 5:28 PM

Ok, have done so, the Mac is on hotspot:

https://drive.google.com/drive/folders/1WW5oF9dVVOHmlGKbTF1b4sNF3khWz77k?usp=sharing

Friday, July 20, 2018 6:34 PM

OK, we can now see that the MacBook is trying to initiate a VPN connection, but it does not get beyond retransmitting the initial packet. Since there is never a response, a number of possibilities suggest themselves:

  1. (Most likely) the port forwarding to the VPN server is not working.
  2. Some firewall is blocking the traffic. If I correctly understand your set-up, this is unlikely.
  3. No VPN service is running on the VPN server.

This is why a network capture running on the VPN server at the same time is useful - it would indicate whether the IKE_SA_INIT never reaches the VPN server (next step: double and triple check the port forwarding) or it reaches the VPN server but no response is generated (next step: we use Event Tracing for Windows (ETW) to check what is happening in the VPN server).

Friday, July 20, 2018 7:10 PM

My VPNSERVER’s IP is in a DMZ, according to the router, this forwards everything, for ease, I use portforward, the application, it can find which ports are forwarded, specifically what ports do I need forwarding?

Friday, July 20, 2018 7:29 PM

This is probably where the misunderstanding arises. The boundary router probably performs Network Address Translation (NAT) on all outbound TCP "connections" (forwards the packets to the Internet after address translation and returns responses to the originating system after reversing the address translation) and does its best with UDP "connections" (UDP is not a connection-oriented protocol, so it is not so easy).

In the case of a VPN connection initiated from the Internet (using UDP port 500, in this case), the router cannot know which of the systems in the DMZ should receive the packet unless there is an explicit forwarding rule (e.g. forward any inbound UDP packet on port 500 to UDP port 500 on DMZ system a.b.c.d). This is the type of rule that we need - have you set such a rule?

To be specific, we need a rule to forward UDP port 500 to the VPN server.

Friday, July 20, 2018 8:04 PM

Ok, so on the port mapping section of the router, I have created another rule, when I use port checker to check port 500 UDP, it says: 'Could not test port 500 because some other application has that port locked. Please close any applications that may be using this port and try again.' All applications are closed, I even deleted the incoming connections section and tried again, nothing, so I re-created the incoming connections and tried a different port: 1723 UDP, Your port is OPEN on this computer!.

Still can't connect.

What do?

Friday, July 20, 2018 8:21 PM | 1 vote

It sounds as though you are using "Port Forward Network Utilities" - a product that I do not know.

The bottom line is that port forwarding needs to be set correctly before the VPN connection has a chance of working. That is where you need to concentrate your efforts.

Friday, July 20, 2018 8:28 PM

Ok, Port 500 is open, I have checked here is a photo if you wish: https://drive.google.com/open?id=18vxCT17bL5piQLHMvoEUcsLhUNtcOLJh

Friday, July 20, 2018 9:08 PM

That looks good. We now need to repeat the network traces (ideally at both ends at the same time) to verify that the VPN server is receiving the packets sent to it on UDP port 500 and to see how it responds (if at all). If that is difficult, then a trace taken from just one end is better than nothing (when things start to work, we only need traces from one end) but might still leave us "in the dark" if there is no response at all to the initial packet (IKE_SA_INIT).

Saturday, July 21, 2018 10:34 AM

Ok, have done so with both computers with the MacBook connected to a hotspot:

https://drive.google.com/open?id=1gvNy-CDY_zBQ8FO9iQHLiwJIbTjcBwzj

Saturday, July 21, 2018 6:48 PM

What do?

Monday, July 23, 2018 8:16 AM | 1 vote

The trace shows that the IKEv2 packets are reaching the Windows PC, but no responses are generated. The ancillary information recorded by "netsh trace" shows that the problem is ERROR_IPSEC_IKE_NO_POLICY.

Comparing the Windows Filtering Platform (WFP) configuration before and after enabling "Incoming Connections" indicates that this only enables PPTP, L2TP and SSTP endpoints and not IKEv2. This explains the ERROR_IPSEC_IKE_NO_POLICY error.

In an attempt to see if there was any other way of establishing an IKEv2/IPsec VPN server, I looked at:

  • "netsh advfirewall consec add rule". This cannot add IKEv2 rules.
  • "Windows Defender Firewall with Advanced Security" MMC snap-in. This cannot add IKEv2 rules.
  • "Add-VpnS2SInterface" PowerShell cmdlet. Not part of Windows 10.
  • "New-NetIPsecRule" PowerShell cmdlet. This cannot specify EAP-MSCHAPv2 authentication. Also specifying both "-KeyModule IKEv2" and "-Mode Tunnel" together causes an error (I don't know why).

My current feeling is that, without programming or installing additional products, one cannot enable an IKEv2/IPsec VPN server on an out-of-the-box Windows 10 client.

Monday, July 23, 2018 1:50 PM

So, which one should I use?

https://drive.google.com/open?id=1hOwXTLOhQwc_HIfkw_vihSuVxf5kbS90

should I use a Different connecting software?

Wednesday, July 25, 2018 10:06 AM | 1 vote

Ok, i’ll just use linux, Thank you and i really appreciate the help Yours sincerly, -M

Wednesday, July 25, 2018 10:17 AM

Thank you for providing the impetus to look at this - I am having fun doing so.

Sunday, September 30, 2018 2:56 PM

It has taken a long time, but I think that I now have a good overview of how to establish a VPN connection from a macOS client to a Windows 10 server using built-in functionality.

The version of macOS (High Sierra, 10.13.6) that I am using offers 3 “types” of VPN:

  1. L2TP over IPSec
  2. Cisco IPSec
  3. IKEv2

Windows 10 offers 4 types:

  1. PPTP
  2. L2TP/IPsec
  3. SSTP
  4. IKEv2

Cisco IPsec uses “Extended Authentication within IKE (XAUTH)” (for which there is a draft RFC from 2001: draft-beaulieu-ike-xauth-02.txt). Windows rejects connection attempts that try to negotiate these extensions.

SSL VPN (VPN over SSL) clients are available for macOS from the Apple Store, but a cursory examination did not find any that claim compatibility with Microsoft SSTP.

Using L2TP over IPsec

There are two options for “Machine Authentication” (IKEv1 Phase 1 authentication):

  1. Shared Secret
  2. Certificate

Shared Secret

“Shared Secret” seems easiest for a simple home network set-up, but the Windows “Network Connections” control panel applet does not provide any “user interface” for setting a shared secret (this applies to the user interfaces for both the VPN client and server). There is however a trick that seems to work: define a “dummy” IPsec tunnel with “Preshared key” authentication; any tool can be used to do this (e.g. the “Windows Defender Firewall with Advanced Security” control panel applet, the “netsh advfirewall consec add rule” command or the “New-NetIPsecRule” PowerShell cmdlet.

Here are examples of creating suitable “dummy” IPsec tunnels (the endpoint value can be any address that does not apply to any potential traffic) with a shared secret of “XXX”:

netsh advfirewall consec add rule name="Dummy" endpoint1=192.168.3.1/32 endpoint2=any mode=tunnel action=requireinrequireout auth4=computerpsk auth4psk="XXX"

New-NetIPsecRule -DisplayName "Dummy" -Phase1AuthSet (New-NetIPsecPhase1AuthSet -DisplayName "Dummy" -Proposal (New-NetIPsecAuthProposal -Machine -PreSharedKey "XXX")).InstanceID -InboundSecurity Require -OutboundSecurity Require -KeyModule IKEv1 -Mode Tunnel -LocalAddress 192.168.3.1/32 -RemoteAddress Any

Obviously, having more than one IPsec tunnel definition with a pre-shared key is problematic.

Certificate

The “Certificate” option is also not straightforward. By default, the registry value of “ServerFlags” (documented in section 2.2.3.4.6 of [MS-RRASM]: Routing and Remote Access Server (RRAS) Management Protocol) under the key “HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters” does not include the option “Authentication using certificates is allowed on the RRAS server” (0x04000000), so this must be explicitly added.

One also needs to create and manage a small certificate authority. I initially made a mistake by omitting the text highlighted below when creating a “root authority” certificate:

New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -KeyAlgorithm RSA -KeyLength 4096 -KeyExportPolicy Exportable -KeyUsage CertSign -NotAfter 2061-08-01 -Subject "CN=insert your name here" -Type Custom -TextExtension "2.5.29.19={text}CA=True"

The absence of the highlighted text did not affect the efficacy of the “root” certificate under Windows but caused “Trust evaluate failure: [root AnchorTrusted BasicConstraints]” under macOS.

When configuring the L2TP VPN under macOS, there is a field named “Server Address”; for the “Shared Secret” option, I could use a dotted notation IPv4 address but for the “Certificate” option I had to use a name (matching the certificate) and add the name/address to /etc/hosts.

Phase 2 (User) Authentication

macOS offers 5 possibilities (Password, RSA SecurID, Certificate, Kerberos, CryptoCard), only one of which I bothered to pursue: “Password” – this choice results in MSCHAPv2 authentication taking place.

Using IKEv2

When configuring the IKEv2 VPN under macOS, there are fields named “Server Address” and “Remote ID”; in contrast to the L2TP VPN, I had to use a dotted notation IPv4 address for the “Server Address” because it seemed as though macOS only tried to resolve the name via DNS (and not via /etc/hosts). The “Remote ID” field needed a name matching the VPN server certificate.

The “Authentication Settings” for IKEv2 are structured differently from L2TP; macOS offers: Username, Certificate, None.

The name “None” is a bit misleading – one can interpret it as “do not use EAP” (i.e. include an AUTH payload from the first message in the IKE_AUTH exchange – the absence of such a payload indicates that EAP will be used instead). In this case both server and client must possess and use certificates to authenticate.

EAP

“Certificate” means authenticate with EAP-TLS and “Username” means authenticate with EAP-MSCHAPv2 or PEAP.

The “Username” authentication method needs to use EAP, but this is also disabled by default in the Windows RemoteAccess “ServerFlags” setting. One needs to explicitly set “EAP protocol can be negotiated for remote access and demand dial connection authentication” (0x00008000).
The file %SystemRoot%\System32\ias\ias.xml seems to be a replacement for the policy database of a full NPS and some changes need to be made there too. In the section “Connections_to_Microsoft_Routing_and_Remote_Access_server”, the collection of “msNPAuthenticationType2” elements needs to be expanded to include “5” (IAS_AUTH_EAP) and optionally “11” (IAS_AUTH_PEAP); if IAS_AUTH_PEAP is added (and one wants to use PEAP) then the collection of “msNPAllowedEapType” elements needs to be expanded to include “19000000000000000000000000000000”.

Missing EAP Component

Windows 10 does not include the “Microsoft EAPHost Authenticator service” DLL (eapahost.dll) although it does include many (all?) other EAP components. Fortunately, this DLL seems to have a simple task: to isolate the Windows VPN components from custom EAP implementations and to unify the two types of custom EAP implementations: legacy EAP methods and EapHost methods.

One just needs to implement the interface below and package the result as a COM out-of-process server:

[ComImport, InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid("5A8371A3-0C6D-487B-B3C8-46D785C4C940")]
interface IEapHostAuthenticatorSessionApis
{
    void BeginSession(uint flags, EAP_HOST_AUTHENTICATOR_METHOD_DATA_ARRAY methods, EAP_ATTRIBUTES ea, uint maxpack, [MarshalAs(UnmanagedType.LPWStr)] string identity, out uint session, out EAP_ERROR error);
    void UpdateInnerMethodParams(uint session, uint flags, [MarshalAs(UnmanagedType.LPWStr)] string identity, EAP_ATTRIBUTES ea, out EAP_ERROR error);
    void IsReplay(uint session,  uint n, EapPacket packet, [MarshalAs(UnmanagedType.Bool)] out bool replay, out EAP_ERROR error);
    void ReceivePacket(uint session, uint n, IntPtr p, out EAP_METHOD_AUTHENTICATOR_RESPONSE_ACTION action, out EAP_ERROR error);
    void SendPacket(uint session, out uint n, out IntPtr p, out EAP_AUTHENTICATOR_SEND_TIMEOUT timeout, out EAP_ERROR error);
    void GetAttributes(uint session, [Out] EAP_ATTRIBUTES ea, out EAP_ERROR error);
    void SetAttributes(uint session, EAP_ATTRIBUTES ea, out EAP_METHOD_AUTHENTICATOR_RESPONSE_ACTION action, out EAP_ERROR error);
    void SetAuthenticateResult(uint session, uint status, [Out] EAP_ATTRIBUTES ea, out EAP_METHOD_AUTHENTICATOR_RESPONSE_ACTION action, out EAP_ERROR error);
    void GetResult(uint session, [Out] EAP_METHOD_AUTHENTICATOR_RESULT2 result, out EAP_ERROR error);
    void GetFinalPacket(uint session, [MarshalAs(UnmanagedType.Bool)] bool success, out uint n, out IntPtr p, out EAP_ERROR error);
    void EndSession(uint session, out EAP_ERROR error);
}

This can be made to work and my implementation (including all necessary C# structure and enumeration definitions) is about 500 lines of “proof-of-concept” quality code, but it violates the “using only built-in functionality” goal. Using the “None” authentication method is the way to meet that goal.

Addressing, Routing and Firewall

The only interesting setting option on the Windows 10 “Incoming Connections” object is the “IP address assignment”. The option “Assign IP addresses automatically using DHCP” does work, even if there is no DHCP service – if there is no DHCP service, the VPN server allocates addresses itself from the 169.xxx.xxx.xxx range; however a VPN connection attempt might fail with ERROR_IPSEC_IKE_INNER_IP_ASSIGNMENT_FAILURE before it is determined that no DHCP service is available. I chose “Specify IP addresses” and used a range like 192.168.2.xxx.

Although Windows 10 will forward IP traffic, the Windows 10 VPN server does nothing to advertise routes. The Windows 10 VPN server will however respond appropriately to ARP requests for its VPN clients.

By default, the VPN network will be assigned to the “Public” firewall profile (which, by default, blocks access to many services). I tried changing the profile to “Private”, but packets were still dropped by a blocking WFP filter with a FWPM_CONDITION_ORIGINAL_PROFILE_ID condition.

Gary

Thursday, May 30, 2019 7:28 AM

Gary, that is seriously interesting. Thanks for this, I mean it!

But I could not find %SystemRoot%\System32\ias\ias.xml

on any Windows 10 machine (mainly 1809), but of course I can find it on Server 2016 with RRAS/NPS enabled

Seb

Thursday, May 30, 2019 8:21 AM

Hello Seb,

I think that the file is created when needed by RRAS - perhaps when the first "New Incoming Connection..." is created.

Gary

Thursday, May 30, 2019 4:53 PM

Yes, that is correct! Thanks