ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Fix Win NAT-T for L2TP and IKEv2

Problem:  

Windows 2012 RRAS IPsec VPN does not support NAT-T out-of-the-box.  By default, RRAS only works with public IP addresses -no NAT.  Windows 10 clients cannot connect with L2TP from outside the office.  Windows 2016 does not support L2TP for any client from behind routers running NAT.

Solution:  

Enable NAT-T on both Windows servers and the clients.  NAT-T allows the VPN server to serve clients (e.g., Windows 10, Android, Apple iOS) from behind the NAT device.  Modify MTU. 

Background

Why NAT-T? 

IPsec uses Encapsulating Security Payload (ESP) to encrypt packet headers and payloads.  By default, ESP is not compatible with Port Address Translation (PAT).  This is because TCP uses ports and ESP does not.  

TCP and ESP are different Internet protocols. TCP uses protocol number 6.  N.B., TCP protocol number 6 is not the same thing as TCP port 6.  TCP ports are communication endpoints.  For example, TCP uses port 80 for web traffic.  

ESP uses protocol (i.e., not port) number 50.   ESP is a protocol without ports.  Network Address Translation (NAT) uses port translation PAT to bind traffic flows with internal hosts.  Therefore, ESP does not work with NAT.

NAT-T allows ESP to work from behind NAT.  It encapsulates ESP protocol 50 inside User Datagram Protocol (UDP) 4500.   N.B, NAT-T is not the same as IPsec over UDP.

Enable NAT-T 


NAT-T is enabled on most operating systems (e.g., Android) -Windows is the exception.  Fortunately,  we can enable NAT-T on Windows 10 and Windows 2012 with a few simple changes. 

Windows IPsec clients are supposed to work from any location.  Therefore, only enable NAT-T on the 2012 RRAS server.  

Create a new registry key to enable NAT-T.

  1.   Edit Registry or create GPO:

                         HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Parameters\

  1.   Create new DWORD value:   AssumeUDPEncapsulationContextOnSendRule

  1.   Modify DWORD value:  2

These changes will fix those pesky L2TP-NAT problem.  

Troubleshooting Issues

Make sure clients use the latest edition of Windows 10.  Early versions had quirks where clients simply would not connect via NAT-T.  

   NAT-T does not work with  the following editions:

  • version 10240
  • version 1511 (i.e. November Update)
   Unconfirmed (may or may not work):  
  • version 1607 (i.e., Anniversary Update)
   Confirmed:

  • version 1703 (i.e., Creators Update)
   NAT-T works great with the registry fix and Creators Update.

   Workarounds:  

Some folks had to toggle the NAT-T registry value in order to connect (http://bit.ly/2r2CKnF).  I assume this fix was for the November or Anniversary Update.  

MTU

Don't forget to adjust the Max Segment Size (MSS):  
http://www.stevenjordan.net/2016/11/windows-ikev2-mtu.html.  

That's It!

Fix IKEv2 Mobile Scripts on IOS10

Problem:  

Pre-existing IKEv2 VPN mobile configuration scripts do not work with new iPhones.  The script installs the VPN but connection attempts fail.

iPhone7 does not connect to the IKEv2 VPN.  However, older iPhones running IOS8 and IOS9 continues to connect.

Solution:

Update the Mac OS and Apple Configurator 2 software.  Create a new mobile config after software updates are complete.

Explanation:  

IOS 10 cannot connect to IKEv2 VPNs using mobile scripts designed for IOS 8 & 9.

Additional Information:

http://www.stevenjordan.net/2016/11/mobile-config-gui.html

http://www.stevenjordan.net/2016/11/mdm-cert-enrollment.html

http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html


S4B Clients on Split-Tunnel VPNs.

S4B:  Bypass Split-Tunnel VPNs.

Take Away:  

Skype for Business (S4B) and Lync clients may experience problems when traversing a split-tunnel VPN.  Use Name Resolution Policy Table (NRPT) and Windows firewall group policies (GPOs) to bypass split-tunnel VPNs.  This solution is easy to administer and provides remote offices the best multimedia experience.

Problem:  

The DCA office experiences weird S4B/ Lync issues:  

  • Local S4B/ Lync clients cannot host conference calls for external clients.
  • All clients (external and DCA) can connect to conference calls hosted at at the company headquarters (JFK).  
  • Local S4B/ Lync clients cannot share multimedia content (e.g., screen-sharing, video, etc.) between external clients.  
  • All clients can share multimedia content when connected to conference calls hosted at JFK HQ.
  • Audio and video quality is poor (e.g., choppy or static) between DCA and JFK locations.

Topology:  

This business consists of two locations: JFK is the primary HQ office.  DCA is the branch office.
  • A site-to-site IPsec VPN tunnel connects the DCA and JFK offices.  
  • DCA uses split-tunneling to forward all corporate data.
  • DCA uses its default gateway to forward all other traffic to the Internet.  
  • JKF hosts all Lync servers:  Front End, Access Edge, and Reverse Proxy servers.
  • Both DCA and JFK use Active Directory (AD) integrated DNS servers.
  • External clients allow staff to work from home.
Figure 1.  Example of  Lync and organization topology.

ICE Framework:  

S4B-Lync uses network topology to select the best connection path.  It uses a peer-to-peer connection framework called Interactive Connectivity Establishment (ICE).   This framework includes Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols.

STUN identifies client Network Address Translation (NAT) (i.e., private IPs). This process also identifies the default gateway (i.e., public IP).  Multimedia travels directly between end-points when STUN is used.  S4B/ Lync clients prefer to communicate directly (i.e., peer-to-peer) between clients which reside on the same LAN.  N.B., LAN is not a reference for broadcast domains.  LAN, in this situation, includes all internal networks (i.e., subnets) with routes to the Front-End subnet.  Internal clients never use the Access Edge server for internal communication. 

Similarly, external clients prefer STUN for communicating multimedia content to other external peers.  The Access Edge server will only bridge external-to-external clients (i.e., TURN) if peer-to-peer communication is not possible.

Lync clients use TURN framework when end-points do not share a common LAN.  The TURN process creates dynamic ports on the Access Edge server; and in turn (pun), proxies external multimedia.  TURN is similar to Port Address Translation (PAT), just as the Access Edge server is similar to an Internet gateway.

To recap, S4B/ Lync clients prefer direct peer-to-peer multimedia communication.  Internal clients will never use the Access Edge server for internal multimedia communication.  External clients use the Access Edge server to bridge communication whenever peer-to-peer communication is unavailable; including external-to-external, and external-to-internal.

Split-Tunnel Problems:  

ICE framework (generally) provides the best multimedia experience.  However, it does not work well over split-tunnel VPNs.  Split-tunnel VPNs create STUN and TURN mismatches.  For example, the DCA branch office firewall forwards all domain traffic to the JFK primary office; all other traffic forwards out the local gateway (i.e., Internet).  DCA and external Lync clients interpret this topology differently (Table 1).

Table 1. 
Default Multimedia Network Traffic Between Lync Clients
     Source           Destination
JFK DCA External Client
JFK STUN STUN TURN
DCA STUN STUN TURN
External Client TURN STUN STUN
Notes:  DCA uses split-tunnel VPN to connect to JKF.  Stun represents Lync client-to-client.  TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement.    Blue represents split-tunnel topology.  Red represents client topology mismatch.  

The primary problem with split-tunnel VPNs is with how the S4B/ Lync client interprets the topology.  Recall, internal clients always use the Access Edge server for external communication.  Likewise, internal clients never use the Access Edge for internal conversations.  The VPN firewall forwards all domain traffic to the JKF network.  Therefore, DCA clients consider themselves as internal; and external clients as external.  DCA clients will only use the Access Edge server when communicating with external clients.

External clients have an entirely different interpretation of  the topology.  External clients are aware of the DCA Internet gateway, but they remain unaware of its split-tunneling.  External clients will therefore interpret DCA clients as external peers; multimedia traffic is sent directly to the DCA clients (i.e., STUN).

To recap, external clients are unaware of the DCA split-tunnel.  These external clients attempt to send audio and video (AV), and expect to receive AV, directly from the DCA clients.  Whereas DCA clients send AV, and expect to receive AV, proxied from the Access Edge server.

Figure 2.  Lync directional mismatch.

The split-tunnel VPN causes a secondary problem between JFK and DCA.   These clients use STUN to establish peer-to-peer connections across the VPN.   Users complain about overall client AV quality between these locations.

Multiple layers of encryption decreases overall AV quality.  Lync encrypts multimedia packets with TLS and SRTP protocols.  The VPN adds additional packet overhead as it encrypts and encapsulates each packet.  Staff at both locations can expect better AV if  DCA S4B-Lync clients bypass split-tunneling (i.e., TURN).

Figure 3.  Bypass the split-tunnel VPN.


Resolution:
 

S4B-Lync clients can bypass split-tunneling entirely:  (a) changes to DNS topology; and (b) changes to client firewalls.  Recall, both offices belong to a single AD domain, and each office uses recursive AD integrated DNS servers.  AD replication ensures internal name resolution is the same at each location.  Lync clients use DNS to locate S4B-Lync servers via S4B-Lync Discovery (Table 2). 
Table 2. 
S4B-Lync Client Discovery Preference Order
DNS Prefix lyncdiscoverinternal lyncdiscover
Discovery Order 1st preference 2nd preference
Client Internal clients External clients
Server Front-End Access-Edge
Notes:  Discovery preference assumes organization uses a split-brain DNS topology.  Topology consists of independent internal and external DNS servers.
  All internal clients, including those on the VPN, use internal DNS for Lync Discovery resolution.  External clients use external DNS for their Lync Discovery process.  Therefore, VPN clients can bypass split-tunneling using a process that distinguishes Lync traffic, and resolves it using external name records.  N.B., Internal DNS continues to resolve all other (i.e., non-Lync) requests.  Otherwise, what's the point of having a VPN?    

Name Resolution Policy Table:
 
  Split-brain DNS requires a confusing array of zone records.   Most Internet documentation suggests pin-point DNS zones to influence Lync traffic.  Instead, consider using NRPT, which simplifies the entire domain resolution process. 

Lync clients can bypass the VPN with NRPT group policy.   NRPT is configured with two simple rules:
  1. Forward all domain name requests for Lync services to external DNS servers.
  2. Use client DNS settings (i.e. internal)  for all other DNS resolution.
Create the NRPT Group Policy to allow S4B-Lync clients to bypass the VPN:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Name Resolution Policy.

  2. Configure the Advanced Global Policy Settings: 

    Figure 4.  NTRP GPO to bypass split-tunneling.

  3. Change the Query Resolution settings.  Enable "Configure query resolution options".  Enable Resolve both IPv4 and IPv6 addresses for names.

  4. Create rules that forward Lync FQDNs to external DNS servers.

    a.  To which part of the namespace does this rule apply?  Choose FQDN.
    b.  Click on the Generic DNS Server tab.
    c.  Toggle the Enable DNS settings check box
    d.  Click the Add button
    e.  DNS server:   Enter an external recursive DNS server; or the authoritative public (i.e., Internet facing) DNS server for your organization's sip-domain.
    f.  Click Apply.

   GPOs are applied to AD domains, sites, or Organizational Units (OUs).  In most situations, it makes sense to apply the NRPT GPO to the AD site that correlates with the branch office.

   From Group Policy Management:  Right click on Sites → Left click on Show Sites → Right click on the branch office site → Link an Existing GPO.     

   Alternately, create separate computer OUs per location.  Link the NRPT GPO OU that nests all branch office computers. 

Windows Firewall:

   NRPT influences clients to logically bypass the VPN.  However, there may be circumstances when Lync clients discover alternate (i.e., split-tunnel) paths to internal resources.  Lync clients, therefore, require both logical and physical divisions.  Windows Firewall compliments the NRPT GPO with two simple rules:
  • Restrict traffic based on application (i.e., S4B).
  • Restrict traffic based on source (i.e., DCA) and destination (i.e., JFK).
Create the Windows Firewall GPO:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall with Advanced Security → Inbound Rules.
  2. Right click on Inbound Rules → New Inbound Rule → Program → Path:  %ProgramFiles%\Microsoft Office\Office15\lync.exe → Block the Connection → Apply rule to Domain.  N.B, Use applicable application paths.  For example, Lync Basic and Lync Professional may use different paths.
  3. Edit the new Inbound Rule:  Right click on the new rule → Click on the Scope tab → Add all internal IP subnets (i.e., primary office) to the Remote IP address field → Click Add → Click OK.

    Figure 5.  Windows Firewall GPO to bypass VPN.

  4.  Apply the newly created Firewall GPO to apply the AD site that correlates with the branch office.  Alternately, apply this GPO to OU that nests branch office computers.

Conclusion:  

   NRTP and firewall GPOs force S4B-Lync clients to bypass split-tunnel VPNs.  These combined GPOs have two primary effects:  (a) DCA-to-external clients prefer STUN (i.e., client-to-client); and (b) DCA-to-JFK clients use TURN (i.e., client-to-Access Edge) for external AV communication (Table 3).  

Table 3. 
Effects of  Split-Tunnel GPOs on Multimedia Traffic 
     Source           Destination
JFK DCA External Client
JFK STUN TURN TURN
DCA TURN STUN STUN
External Client TURN STUN STUN
Notes:  DCA uses split-tunnel VPN to connect to JKF.  Stun represents Lync client-to-client.  TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement.  Blue emphasizes branch office traffic.   

That's It!

Android IKEv2 Client Setup

Task:  

Send end-user instructions on how to configure Android IKEv2 VPN clients.  

Solution:

Installation is a two-step process:

Step 1:  Install all three certificates.  The Administrator has sent a separate website link where you can download necessary certificates:  (a) user_device.PFX; (b) vpn_server.CER, and root.CER.  Open each attachment to start the installation.  Include the PFX password.

Step 2:  Configure the Android VPN client:  Android Settings → Connections → More Connection Settings → VPN → Add VPN.


VPN Settings (Figure 1):
N.B., Change the value for “IPSec user certificate” to “user_android”.
Figure 1.  Android IKEv2 VPN Settings.  
Hint:  VPN shortcut apps are available in the Google Play Store.  This provides a quick and easy method to connect.
For example:  https://play.google.com/store/apps/details?id=com.rosaneng.vpnsettings&hl=en


Also note, your device certificate contains a private key for your client certificate.  Anyone that gets a hold of this key can impersonate your account.  Please protect your device with a passcode and encryption.  This script is not intended for rooted devices.  I encourage you to delete this email from your mailbox after you’ve configured your devices. 

That's It!

Windows IKEv2 MTU


Problem:

How to set MTU on Windows Servers.  Windows Server 2012 VPN fragments packets after it applies encryption!  This issue causes latency and causes the VPN to disconnect clients -no good!

Background:

The default packet size is 1500.  Now consider how IPsec encryption adds a number of bytes to the original packet.  This process leads to post-fragmentation conditions.  In other words, packets are fragmented after encryption.  This condition degrades or disrupts VPN performance. 

Solution:

Adjust maximum segment size (MSS) on the outside interface so packet size is less that the default 1500 MTU.

Packet fragmenting occurs when a packet is larger than its default MTU.  TCP fragments the original data and sends it avoid encrypted packet.  According to Cisco, ESP overhead adds a maximum of 73 Bytes to each packet.  Therefore, we can adjust the MSS to a conservative 1400.

PowerShell:


Step 1:  Identify external interface.


PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside
 14           5        1500  connected     Outside

Step 2.  Modify external interface MSS.

PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 set subint "Outside" mtu=1350 store=persistent


Step 3.  Confirm MSS:
PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside


 14           5        1400  connected     Outside

That's It!

References:



Install Mobile-Config Script

Task:  

Setup instructions for manual distribution of mobile-config scripts for iPhones and iPads.

Assumptions:

These instructions assume the mobile-config script has already been generated,  These instructions are for situations when mobile device management (MDM) is not available.  It assumes email distribution from a private server.  Use caution whenever distributing certificates and private keys!

Background:

Mobile-device scripts run on any iPhone or iPad –simply open the email attachment to start the process.  It installs certificates and configures the IKEv2 VPN.  This script can configure multiple devices.

Security Considerations

Also note, the script includes the private key for the client certificate.  This provides identity validation, authentication, and authorization.  Anyone that gets a hold of this key can impersonate the account.  It’s critical to use a passcode and enforce encryption.  Do not install these files on jailbroken devices.  Delete the script from your mailbox after all devices are configured.

Brief instructions:

Step 1:  Open mobile-config file to start the profile installation.

· N.B., This script is not signed –that’s OK.
· Click Next.




Step 2:  Enter device passcode.

Step 3:  Consent.

· Brief description for mobile-config.
· Installation requires consent.
· Click Next.




Step 4:  Confirm Install.

· General VPN disclosure.
· Click Install.  Click Done.

Step 5.  Connect to the VPN.

· Open Settings.
· Toggle the VPN button.
· The VPN symbol appears in upper left-hand corner to confirm active VPN sessions.


The VPN is ready for action.  That's It!

Dynamic S2S VPNs


Task:

Create site-to-site (S2S) interfaces for dynamic IKEv2 VPN clients (e.g., iPhones).  Assign different cryptographic algorithms to each S2S interface.

What are dynamic S2S VPNs?

 S2S VPNs usually support static VPN endpoints.  For example, a dedicated (i.e., always-on) VPN that connects a branch office to its HQ office.  However, S2S VPNs can also connect mobile clients for dynamic connections.   This hybrid approach is for special circumstances.

Why use dynamic S2S VPNs?

Most folks should stick with the default RRAS dial-up VPN server.  It provides better management and reporting tools.  However, dynamic S2S VPNs support configuration features that are unavailable with the standard RRAS client VPNs.

For example, dial-up IKEv2 VPNs may authenticate any certificate issued from one of its trusted root certificates.  S2S VPNs can limit authentication to specific client certificates.  The best part, IMHO,  is the ability to apply unique cipher suites per S2S interface.  For example, we can create separate S2S interfaces for each client -including unique cipher suite standards.

How do we implement dynamic S2S VPNs?

PowerShell offers a straight-forward method to implement S2S VPNs.  However, consider using a GUI-Powershell hybrid approach that supports additional client management features.

Dynamic S2S via PowerShell:

The following example creates a new S2S interface with strong security targets:
• Certificate authentication
• IKEv2 Protocol
• Main Mode:   AES128-SHA256-DHGroup14
• Quick Mode:   AES256-SHA256

Add-VpnS2SInterface -name smj@stevenjordan.net -CustomPolicy -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod aes128 -IntegrityCheckMethod SHA256 -Destination 0.0.0.0 -Protocol IKEv2 -AuthenticationMethod MachineCertificates -ResponderAuthenticationMethod MachineCertificates -EncryptionType RequireEncryption

The interface name always matches the authentication certificate's subject name.  Some clients (e.g., iPhone) require a matching subject common name and matching subject alternative name (SAN) DNS name.  This attribute associates the authentication certificate with the S2S interface.  The destination flag is set to accept connection requests from any IP (i.e., it's dynamic).

Don't forget to lock down the VPN server.  Enforcing subject names does not secure the server.  Recall, Windows VPN server leaves its front door wide open -by default.  Windows VPN security requires manual changes:  http://www.stevenjordan.net/2016/10/door-wide-open-on-win-ikev2.html

Managing S2S connections via PowerShell:

Managing client connections is cumbersome compared to traditional RRAS client VPN tools.  For example, RRAS and Remote Access Management provide simple GUI tools to manage dial-up connections (Figure 1).  However, Remote Access Clients does not display S2S connections.  Additionally, RRAS Network Interfaces does display S2S interfaces by deafult.

Figure 1.  RRAS Client Connections.
The RRAS management GUI does not play well with dynamic S2S connections.  The Remote Access Clients tab does not display active connections.  However, the GUI will display active IKEv2 WAN Miniports:

Figure 2.  Active WAN Miniports.  Good enough.
PowerShell provides a better method to view active S2S connections:
PS C:\Users\SMJ> Get-VpnS2SInterface
RoutingDomain Name Destination AdminStatus ConnectionState
------ ------- ----------- ----------- ---------------
XXXXXX-XXXX-SMJ {0.0.0.0} True Connected

Dynamic S2S GUI-Powershell Hybrid

Alternately, create dynamic S2S interfaces with the RRAS GUI.  This approach offers some S2S client management benefits.  Keep in mind, these S2S interfaces use default cryptographic algorithms.  We'll need to modify S2S security targets with PowerShell:

Step 1.  RRAS → VNS server → Right-click Network Inerfaces → New Demand-Dial Interface:

• Interface Name:  Certificate's subject common name.
• Connection Type:  VPN → Next
• VPN Type:  IKEv2 → Next
• Hostname:  None (leave blank) → Next
• Protocols & Security:  Route IP packets on this interface → Next
• Static Routes:  None (or add based on your organization's needs).
• Dial-Out Credentials:  None → Next → Finish.

Step 2:  Edit S2S interface properties → Options tab.
• Connection type:  Persistent connection →  OK.

Step 3:  Edit security targets for S2S interface in PowerShell.
PS C:\Users\SMJ> Set-VpnS2SInterface -name xxxx-xxxx-SMJ -CustomPolicy -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod aes256 -IntegrityCheckMethod SHA256 -EncryptionType RequireEncryption

WARNING: VPN site-to-site adapter xxxx-xxxx-SMJ will be modified and the parameters 
other than IPv4Subnet/IPv6Subnet will be applicable next time the connection is dialed.

Check Hybrid S2S Connection from GUI:

 RRAS → VNS server → Network Interfaces:  Connection Status


Figure 3.  S2S connection status via RRAS GUI.

The RRAS Network Interface GUI now includes a list of S2S interfaces and connection status.  It also provides a simple method to disconnect or disable client connections.

Troubleshoot:

Use PowerShell to check server IPsec crypto-sets:
• Get-NetIPsecMainModeCryptoSet
• Get-NetIPsecQuickModeCryptoSet


Confirm server-client security targets work as intended:
• Get-VPNS2SInterface
• Get-NetIPsecMainModeSA
• Get-NetIPsecQuickModeSA

I also recommend using the Best Practice Analyzer (BPA) to check for any obvious S2S security warnings.
https://technet.microsoft.com/en-us/library/ee922676(v=ws.10).aspx


That's It!

MDM Cert Enrollment

Task:

How to manually request and enroll certificates for BYOD devices with Windows CA server.

Background:

Automated mobile device management (MDM)  (e.g., Microsoft Workplace-Join,) provides a secure method for device key management.  However, rolling out the right MDM solution can be a serious undertaking.  It may be overkill for some organizations.

This article covers device key-management for special use situations.  It provides instructions on how to manually generate device (e.g., iPhone) certificates for mutual authentication (e.g., IKEv2 VPNs).

Assumptions:

Solution:

Step 1:  Request the device certificate from from any workstation:

  • Start → MMC → File → Add Snap-In:  Add Certificates - Current User
  • Certificates → Current User →  Personal → Certificates → All Tasks → Request New Certificate


Step 2:  Complete the Certificate Enrollment Wizard:                 

  • Select Policy: No changes.  Click Next.
  • → Request Certificates:  User Device Auth → Click Details →  Click Properties.
  • → Certificate Properties:      

        →  [Subject Tab]
                  Subject Name:
                       Common Name (CN) = user_device@stevenjordan.net;  add.
                       Email = user_email@stevenjordan.net;  add. Given Name:  First and last name; add.
                  Alternative Name:
                        DNS = user_device@stevenjordan.net; add. N.B., DNS must match Full CN.
                        Email = user_email@stevenjordan.net; add.
         → [General Tab]
                   Friendly name:  user_device@stevenjordan.net
         → Click OK.

         → Request Certificates:  Add checkmark for User Device Auth → Click Enroll.
  • Note that status = Pending.
Step 3:   Approve request from Certificate Authority (CA) server.  

  • Open CA Server  MMC:
       → Certification Authority (Local) → Root-CA →  Pending Requests → Issue: 
Step 4:  Export certificate from workstation that initiated request:  
  • Certificates → Current User →  Certificate Enrollment Requests:
    → Certificate Export Wizard
         → Export Private Key:  Yes, export the key.
         → Export File Format:  Check Include all certificates in path.  Next.
         → Select Policy: No changes.  Click Next.
         → Security:  Check Password.  Enter Password.  Next.
                               N.B., Password = choose_password
         → File to Export:  Choose location:  C:\source\cert\user_device.pfx.  Next.
         → Export Root Certificate and VPN server certificate:  Location: \\securefileshare\
  • Repeat similar process to export CA public root certificate (CER).
  • Log onto the VPN server and repeat similar process to export public certificate (CER).
Step 5:  Distribute certificate files to client devices.
  • Distribute the client certificate and private key (e.g., PFX).  
  • Include the public VPN server and root certificates (e.g., CER).

Distribution methods: 

Security Considerations:

Safeguard your client PFX files!!  PFX files include certificates and their private keys.  An attacker can use this information to impersonate identity.  That means, it can be used to connect to the VPN, collect email, etc.  Do not let these PFX files fall into the wrong hands!  Mitigation:
  • Account for all PFX instances -these are security vulnerabilities!
  • Delete/ remove all device certificates generated from workstations.
  • Save client PFX file to secure off-line media. 
  • Consider IT policy that requires face-to-face installation with IT staff.
  • Email attachments can be forwarded -risk!
  • Internal web server on internal Wi-Fi SSID is preferred.  
  • Ad-Hoc Wi-Fi may be preferable to infrastructure mode. 
  • Do not enable the certificate's export flag.
  • Do not install on any rooted or jailbroken device.  
  • Ensure devices use encryption and passcodes.
  • Above all, use common sense!

That's It!