Welcome

to VPN Project 2.0’s

documentation!
Contents:

1. Purpose of this Document

2. Prerequisites
2.1 Requirements - Must
2.2 Requirements - Should
3. Tools and Software
4. FortiGate Configuration
4.1 Certificate Configuration (CA)
4.2 Certificate used for IPSEC Server Function
4.3 Configure PKI Users for use in Phase1-Interface
4.4 Configure Phase1-Interface
4.5 Configure Phase2-Interface
4.6 Configure Policy to Allow Traffic to and from the IPSEC Interface
4.7 Optional - Configure Ping and Telemetry Access to the IPSEC Interface
5. Windows 10 Configuration
5.1 Installing Intermediary and CA certificates.
5.2 Requesting a Certificate for VPN use
5.3 Creating a “User” VPN Configuration.
5.4 Verifying or Troubleshooting the “User” VPN Configuration
5.5 Creating a “Device Tunnel” VPN Configuration

Indices and tables

Index
Module Index
Search Page
1. Purpose of this Document
This document is a step-by-step guide of configuring FortiGate and Windows 10 Native VPN
Client for Always-On pre-logon VPN Access.

This is an alternative to using FortiClient with GINA Logon process or a user-initiated VPN.

Note: There is no user interaction with this VPN

2. Prerequisites
2.1 Requirements - Must
1. FortiGate v5.6.3+
2. Windows 10 Build 1709+ (Tested on 1803)
3. Windows 10 must be Enterprise Edition
4. Windows 10 must be joined to a Domain

2.2 Requirements - Should

1. Experience working with FortiGate CLI
2. Experience working with PowerShell and Powershell Scripting
3. Detailed knowledge of IPSEC (IKEv2)
4. Detailed knowledge of PKI Infrastructure
3. Tools and Software
All tools and software are in the attachments directory

1. PsExec.exe - used to escalate PowerShell to SYSTEM account

2. vpn.ps1 - used to provision the Windows 10 VPN Profile
3. ProfileXML-UserTunnel.xml - sample XML VPN Profile for manual User Tunnel
4. ProfileXML-DeviceTunnel.xml - sample XML VPN Profile for the DeviceTunnel
4. FortiGate Configuration
4.1 Certificate Configuration (CA)
For the FortiGate to authenticate Win 10 machine certificates it will require the certificate
authority (CA) certificate used to sign the client certificates. If an intermediary CA has been
used the FortiGate will require the whole certificate chain.

Specifically it will require the intermediary CA and the root CA certificate that signed it.

Certificate Authorities can be imported here:

SYSTEM –> CERTIFICATES –> IMPORT –> CA CERTIFICATE

Take note of the name of the Certificates under External CA Certificates.

In the image above the important certificate names are CA_Cert_1 and CA_Cert_2 we will
need these when we configure client authentication

4.2 Certificate used for IPSEC Server Function

1. Generate a CSR for the FQDN you will be using as the destination servers in IPSEC
configuration. - SYSTEM –> CERTIFICATES –> GENERATE
2. Sign the CSR using your CA (Outside of the FortiGate)
3. Import the signed certificate - SYSTEM –> CERTIFICATES –> IMPORT –> LOCAL
CERTIFICATE
4. You should now have an entry that looks like this:

4.3 Configure PKI Users for use in Phase1-Interface

Log on to your FortiGate using an SSH client of your choice with an admin user.

Then apply the following block modifying it as necessary to support your use case:
 1 config user peer
2 edit "sslvpncertuser"
3 set ca "CA_Cert_1"
4 next
5 end

NOTES

1. The user created will be added to a peergrp. This “user” represents all users with
certificates signed by the CA used in set CA as you can see from 4.1 this would be the
intermediate CA for shwoogle.com (a test domain belonging to D. Fligel)
2. User the CA that you will be signing your Win 10 Machine certificates with.

Now we will add this “User” to a PKI Group for user in the Phase-Interface

1 config user peergrp

2 edit "sslvpncertusers"
3 set member "sslvpncertuser"
4 next
5 end

NOTES

1. We have not created a “peergrp” containing the user we created earlier.

2. This is the “group” we will be using in the next section - Phase1-Interface

4.4 Configure Phase1-Interface

Log on to your FortiGate using an SSH client of your choice with an admin user.

Then apply the following block modifying it as necessary to support your use case:

1 config vpn ipsec phase1-interface

2 edit "W10Native"
3 set type dynamic
4 set interface "port1"
5 set ike-version 2
6 set authmethod signature
7 set peertype peergrp
8 set mode-cfg enable
9 set proposal aes256-sha384 aes256-sha512
10 set dhgrp 21 20 19
11 set certificate "vpn_shwoogle_com"
12 set peergrp "sslvpncertusers"
13 set ipv4-start-ip 10.109.0.100
14 set ipv4-end-ip 10.109.0.110
15 set ipv4-netmask 255.255.255.0
16 set dns-mode auto
17 set ipv4-split-include "ubunet"
18 next
19 end

NOTES

1. The set peergrp function is used to allow authentication only to machine certificates
signed by our CA
2. The set certificate function is used to define the certificate that the IPSEC tunnel will
serve to the client. This MUST match the FQDN configured as the server in the client.
3. The set ipv4-split-include function is used to specify the range of traffic that will be
permitted over the tunnel. All other traffic should be routed by the client’s default route.
This setting requires further experimentation.
4. The security setting for proposal and DH Group are the strongest possible security
settings supported by the W10 Native IKEv2 Client.
5. Do not amend settings unless absolutely necessary and only after verifying functionality
using the “client tunnel”
4.5 Configure Phase2-Interface
Log on to your FortiGate using an SSH client of your choice with an admin user.

Then apply the following block modifying it as necessary to support your use case:

1 config vpn ipsec phase2-interface

2 edit "W10Native"
3 set phase1name "W10Native"
4 set proposal aes256-sha384 aes256gcm aes256-sha512 aes128gcm aes256-sha256
5 set dhgrp 21 20 19
6 set keylifeseconds 1800
7 next
8 end

NOTES

1. The security settings used are the strongest possible security settings supported by the
W10 Native IKEv2 Client - do not amend unless absolutley necessary.

4.6 Configure Policy to Allow Traffic to and from the

IPSEC Interface
Log on to your FortiGate using an SSH client of your choice with an admin user.

Then apply the following block modifying it as necessary to support your use case:

1 config firewall policy

2 edit 0
3 set name "ipsec pol"
4 set srcintf "W10Native"
5 set dstintf "port2"
6 set srcaddr "all"
7 set dstaddr "ubu" "ubunet"
8 set action accept
9 set schedule "always"
10 set service "ALL"
11 next
12 end

NOTES

1. Replace set dstaddr with approprate destination matching 4.4 Note 3

Then configure the reverse policy:

1 config firewall policy

2 edit 0
3 set name "ipsecd pol reverse"
4 set srcintf "port2"
5 set dstintf "W10Native"
6 set srcaddr "ubu" "ubunet"
7 set dstaddr "IPSECrange"
8 set action accept
9 set schedule "always"
10 set service "ALL"
11 set comments "Reverse of ipsec pol"
12 next
13 end

4.7 Optional - Configure Ping and Telemetry Access to

the IPSEC Interface
1 config system interface
2 edit "W10Native"
3 set vdom "root"
4 set allowaccess ping
5 set fortiheartbeat enable
6 next
7 end
5. Windows 10 Configuration
Please confirm the following before proceeding.

1. The client is Windows 10 Enterprise build 1709 or later

2. The Windows 10 Machine is joined to the Domain
3. Open a command prompt and ping the FQDN of the VPN (as matching the CN in the certificate of the FortiGate VPN) - Confirm this resolved -
confirm this is addressable
4. Check for any pre-configured VPNs - delete any that exist.
5. Check your attachments folder and confirm you have - vpn.ps1 - PsExec.exe - ProfileXML-User - ProfileXML-DeviceTunnel

5.1 Installing Intermediary and CA certificates.

For the IKEv2 Native VPN client to work it needs to trust the CA of the certificate used by the FortiGate.

As we will be using Machine Certificates we need to install the CA and Intermediate certs in the Machine Certificate Stores.

To access this run the MMC as an Administrator

WINDOWS KEY–> TYPE MMC –> RIGHT CLICK –> RUN AS ADMINISTRATOR

Then add the certificates snap-in for the Computer Account

5.1.1 First we import the Root Certificate

Note: Although not explicitly stated you can import .pem certificates. No requirement to convert to .pfx

5.1.2 Second we import the Intermediary Certificate if Necessary

Note: Although not explicitly stated you can import .pem certificates. No requirement to convert to .pfx

5.2 Requesting a Certificate for VPN use

Windows 10 Native VPN is has very strict requirements concerning the certificate. The NAME of the host MUST match the CN of the certificate and
the Extended Key Usage (EKU) Parameters must be set correctly for the VPN Client to use the Machine Certificate.

The certificate must also use a ECDH_P384 Private Key. If this is not used DH Groups selected will result in failed IKE negotiations. As the Windows
Native VPN dos not support very large or secure RSA keys for DH groups I advise using Elliptic Curve

Failure to meet all of these requirement will result in a certain failure and extremely difficult troubleshooting.

When generating the CSR for the CA to sign follow these steps as closely as possible:

BEFORE YOU BEGIN

Copy your HOSTNAME to clipboard you will be using it in step 4,5,6 etc.

5.2.1

5.2.2
5.2.3

5.2.4

Assign it a Friendly Name - I recommend the hostname - as this will be the CN

5.2.5
5.2.6

5.2.7

It is critical that the EKU setting are enabled as displayed I would hasten to add that IP Security and IKE Intermediate Option may also be added
depending on your use case. In my testing I added it.

5.2.8
5.2.9

Then hit OK and NEXT

CORRECTION Use Software Provider not Smart Card Provider if you do not wish to store the machine certificate on a smart card.

5.2.10

Get your CA to Sign Certificate. This will be the certificate used by the VPN profile created in 5.3

5.3 Creating a “User” VPN Configuration.

5.3.1 - Open an administrator Powershell session

START –> POWERSHELL –> RIGHT CLICK –> RUN AS ADMINISTRATOR

Your prompt should look like this. Specifically C:WindowsSystem32

Navigate to your attachments folder

And run
 1 .\vpn1.ps1 -xmlFilePath ProfileXML-UserTunnel.xml -ProfileName UserTunnel

Your output should look like this:

If you cannot run the script you may need to set execution policy as follows:

1 Set-execution policy unrestricted

Answer Y to the Policy Change

Now we must apply the necessary IPSEC Security Parameteres to the newly created VPN as follows:

1 Set-VpnConnectionIPsecConfiguration -ConnectionName UserTunnel -EncryptionMethod AES256 -CipherTransformConstants AES256 -IntegrityCheckMethod SHA256,SHA384 -PfsGroup ECP256,ECP25

Answer Y to the necessary question.

5.3.2 - Verify the VPN entry has been correctly created and is working

Verify the VPN Entry has been created with:

1 Get-VpnConnection -name UserTunnel

and:

1 Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01

If everything has been created correctly you can connect to the VPN using the Win10 GUI or from Powershell command line by typing:

1 rasdial.exe UserTunnel

You can disconnect with:

1 rasdial.exe UserTunnel /disconnect

5.4 Verifying or Troubleshooting the “User” VPN Configuration

The types of errors will dictate what troubleshooting methods to follow

5.4.1 - IPSEC Connection

As the FortiGate is the receiver it is the ideal place to troubleshoot these types of connections from an SSH session to the FortiGate run the following
commands:

1 diag debug application ike -1

2 diag debug enable

When you are done run:

1 diag debug disable

You can also run a packet sniff with very specific criteria to verify the packets are hitting the FortiGate such as:

1 diagnose sniffer packet any 'udp and (port 500 or 4500)'

5.4.2 - Policy and Routing

As with IPSEC connectivity issues the use of diag sniffer packet is usually best to see if the packets are attempting to enter the FortiGate. Failure to
traverse the FortiGate will be either a policy or a routing issue. First confirm there is a route on the FortiGate with:

1 get router info routing-table all

or from the Windows client:

1 route print

1. Ping from W10 Host to a destination across the VPN

2. Ping from the Destination to the W10 Host
3. Use exec ping on the firewall to ping the W10 host
5.5 Creating a “Device Tunnel” VPN Configuration
I would advise removing the User VPN tunnel at this point. This can be achieved from an Administrator elevated Powershell session as follows:

1 Remove-VpnConnection -name UserTunnel

We can not create the DeviceTunnel

5.5.1 - Open and administrator Powershell session

START –> POWERSHELL –> RIGHT CLICK –> RUN AS ADMINISTRATOR

Your prompt should look like this. Specifically C:WindowsSystem32

Navigate to your attachments folder

And run

1 PsExec -i -s Powershell

This will open a Powershell session in the SYSTEM contect you can verify this by running:

1 whoami

From the context of SYSTEM we can now create the DeviceTunnel

1 .\vpn1.ps1 -xmlFilePath ProfileXML-DeviceTunnel.xml -ProfileName DeviceTunnel

You can now verify the tunnel has been created by running

1 Get-VpnConnection -AllUserConnection

and

1 Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01

If everything is showing correctly. The VPN should now automatically establish and stay up whenever it is available. You now have an always on VPN
tunnel to the FortiGate.

Repeat troubleshooting from 5.4.2 to confirm the tunnel is up.

NOTE The tunnel will not appear under rasdial.exe or in the User session under VPNs NOTE You can if you wish create a User VPN tunnel to different
destination. W10 will support one device tunnel and one user tunnel simultaneously
Index