Goal

Configure a MikroTik router as an IKEv2 VPN server for mobile and remote clients, including Windows, Android, and Apple iOS/iPadOS.

Clients authenticate using X.509 certificates and receive an address from a dedicated VPN address pool.

Why IKEv2?

IKEv2 provides a standards-based IPsec VPN that is well suited to mobile clients. It is supported natively by Windows and Apple operating systems and is widely supported by Android VPN clients.

Compared with older VPN protocols, IKEv2 provides strong cryptography, certificate-based authentication, NAT traversal, and reliable reconnection when a mobile device changes networks.

Configuration Overview

The configuration consists of four basic components:

• Certificates: Create a Certificate Authority, server certificate, and client certificates.
• Client addressing: Create an IP pool and configure DNS and routing information supplied through IKEv2 Mode Config.
• IPsec: Configure the IKEv2 profile, proposal, peer, identity, and policy template.
• Firewall and NAT: Permit IKEv2/IPsec negotiation and control what authenticated VPN clients may access.

Step 1: Certificates

IKEv2 certificate authentication requires three certificate types:

• Certificate Authority (CA)
• IKEv2 server certificate
• IKEv2 client certificate

The CA signs both the server and client certificates, establishing the chain of trust used during IKEv2 authentication.

Create the Certificate Authority

Create the CA certificate that will sign the server and client certificates.

Configure the Certificate Revocation List

Specify the public address from which the Certificate Revocation List can be retrieved.

Use the router's public IP address or a DNS name reachable by VPN clients.

The CRL location is published through the CA certificate. It does not need to be configured separately on the server or client certificates.

Sign the Certificate Authority

Create the IKEv2 Server Certificate

Create a certificate identifying the VPN server and sign it with Domain_CA.

The server certificate should contain the VPN server's DNS name in both the Common Name and Subject Alternative Name.

The certificate should include the tls-server key usage. After creating it, sign it with Domain_CA and mark the CA and server certificates as trusted.

Create Client Certificates

Create an individual certificate for each VPN client or user.

For maximum client compatibility, use the same identity in the Common Name and Subject Alternative Name.

The certificate should include the tls-client key usage.

Sign the certificate with Domain_CA, mark it as trusted, and export the certificate and private key as PKCS#12 (.p12) for installation on the client.

Using individual certificates allows a single client to be revoked without affecting every other VPN user.

Step 2: VPN Client Address Pool

Dedicate a subnet or address range to remote VPN clients.

This address space should not overlap existing LAN or remote networks.

The pool may be shared with other remote-access VPN services when appropriate, although separate pools can simplify firewall policy and troubleshooting.

Step 3: Configure IPsec

Mode Config

Mode Config supplies network configuration to connecting VPN clients.

The client receives an address from ikev2-pool, a /32 client address, and 192.168.88.10 as its DNS server.

For a split-tunnel VPN, internal networks may also be advertised using split-include.

Mode Config determines what routes the client is asked to install. Firewall policy still determines what the client is actually permitted to access.

Phase 1 Profile

The IPsec profile defines the cryptographic parameters used during IKE negotiation.

Phase 2 Proposal

Create a dedicated proposal for IKEv2 traffic.

A dedicated proposal is preferable to modifying the RouterOS default because unrelated IPsec tunnels will not inherit the remote-access VPN configuration.

Policy Group and Template

Create a policy group for dynamically generated IKEv2 client policies.

Create the corresponding policy template.

RouterOS uses this template to generate IPsec policies dynamically as clients connect.

IKEv2 Peer

Create a passive IKEv2 peer that listens for incoming client connections.

Because the MikroTik is acting as the VPN server, remote clients initiate the connection.

IKEv2 Identity

Associate certificate authentication, Mode Config, and dynamic policy generation with the IKEv2 peer.

The router verifies that each connecting client presents a certificate signed by a trusted CA.

A specific remote-certificate is deliberately not configured. Specifying one would bind the identity to a particular client certificate. Leaving certificate matching generic allows multiple clients signed by the trusted CA to authenticate.

Step 4: Firewall and NAT

The firewall performs two separate functions: permitting establishment of the IKEv2/IPsec tunnel and controlling what authenticated VPN clients may access after the tunnel is established.

Allow IKEv2 and IPsec

At minimum, the router must accept IKE and NAT Traversal from the Internet.

If native ESP must be accepted separately:

These rules must appear before the router's general WAN input-drop rule.

Allow VPN Clients to Reach the LAN

Access from authenticated VPN clients into internal networks should be explicitly permitted according to policy.

Traffic not specifically authorized should remain blocked by the normal firewall policy.

NAT Considerations

Existing masquerade rules should not accidentally NAT traffic between VPN clients and internal networks.

Where necessary, place an IPsec NAT-bypass rule before the Internet masquerade rule.

The exact firewall and NAT configuration depends on whether the VPN is LAN-only split tunnel, includes multiple internal networks, or provides full-tunnel Internet access through the MikroTik.

Mode Config provides addressing and routing information. The firewall determines authorization.

That's It!

 Problem: 

PS C:\Program Files\Microsoft\AzureMfa\Config
> .\AzureMfaNpsExtnConfigSetup.ps1

PowerShell Error:

This error implies the package source 'https://www.powershellgallery.com/api/v2 is not reachable or resolved. 

Fix:

GPOs don't work on the VPN?

Problem:  

Definition:  Group Policy Slow Link Detection

Background:  

Group Policy Slow Link Detection:

Solution:

• Enter 0 to disable slow-link detection.
• Alternately, set high connection speed rate (e.g., 10000 Kbps is ~10 Mbps).

References:

How to Assign Active Network Location with PowerShell.

Step 1:  Identify networks and associated NICs.

Get-NetConnectionProfile

Name             : domain.com

InterfaceAlias   : Ethernet (Domain)

InterfaceIndex   : 1

NetworkCategory  : DomainAuthenticated

IPv4Connectivity : Internet

IPv6Connectivity : NoTraffic



Name             : Unidentified network

InterfaceAlias   : RDMA

InterfaceIndex   : 2

NetworkCategory  : Public

IPv4Connectivity : NoTraffic

IPv6Connectivity : NoTraffic

Step 2.  Change the NetworkCategory:

References:

Problem:  

Solution: 

Assumptions:  

Example 1.  Show forest FSMO roles (forest):

Example 2.  Show domain FSMO roles (domain): 

Example 3. Transfer single role to a domain controller.  

Example 4.  Transfer multiple roles.

Example 5: Transfer all roles with numbers: 

References:

Outline:

Problem: 

Solution:

Assumptions:

Domain Controller Priority within a Site

• ·     DC-X with a priority of 0 (i.e., preferred).
•        DC-Y with a priority of 2.

Domain Controller Weights

          

DC Preference Configuration

1. Set priority and weight via the registry:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
2. Create new 32-bit DWORDs:
   LdapSrvWeight
   LdapSrvPriority
3. Assign DC priority and weight values.
4. Restart the NETLOGON service to publish to SRV records

Subnet Prioritization

Additional Thoughts:

References:

Problem:

Solution:

Problem:    

Solution:  

root@SRX# load replace terminal    
[Type ^D at a new line to end input]
interfaces 
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                    address 192.168.1.2/24;
            }
        }
    }
}
load complete
[edit]
root@SRX# commit

Problem:    

1. SRX 300 Series:
   
   {primary:node0}
    smj@SRX> request routing-engine login node 1
   
   
2. SRX 1500 Series:
   
   smj@SRX% rlogin -T node1

Fun with Virtual Smart Cards!

Outline:

Assumptions:

Virtual Smart Card Configuration:

tpmvscmgr.exe create /name VSC /pin prompt /puk prompt /adminkey random /generate

Reset the Virtual Smart Card:

tpmvscmgr.exe destroy /instance root\smartcardreader\0000

PINs, PUKs, and Keys:

1. Smart Card Personal Identity Number (PIN).  The PIN is essentially a password.  The PIN can be changed by the end user from any domain computer:
   
    CRTL-ALT-Delete → Change Password → Change PIN.
   
2. Smart Card Personal Unlock Key (PUK).  Windows locks the PIN after three unsuccessful attempts.  End users can use their PUK to unblock their PIN:
   
    CRTL-ALT-Delete → Change Password → Unblock Smart Card.
   
   The PUK is optional but I recommend it.   It's simply too easy to lock the PIN! 
   
   The PUK changes the PIN.  Keep the PUK safe and only use it when its absolutely necessary.
   
   In addition, Windows does not include native tools to change the PUK. In order to choose a new PUK, the virtual smart card must first be deleted (i.e., destroyed) and then recreated.  Of course, this process deletes all certificates on the smart card.
   
3. Admin Key.  The key benefit to the admin key is that it allows Administrators to generate certificate keys for enrolling-on-the-behalf of others.  Organizations that do not use enrollment stations should simply generate a random admin key.    

References:

Problem: 

• The Windows Update GUI provides a long list of KB updates.  
• Updates are organized by date and not by KB numbers.  
• It lacks a built-in search function! 

Figure 1.  Windows Update History: No search for you (CRL+F)!   :(

Solution:

wmic qfe list

wusa /uninstall /kb:xxxxx

T-Shoot Yubikey Minidriver

Problem:  

Error:  

Figure 1.  Smart card container error.

Assumptions:

• Yubikey runs as PIV smart card.
• Smart card has multiple authentication certificates.
• Certificates reside on slots 81-95.

Solution:

Important:

Figure 2.  How to Install the Yubikey Minidriver.

Problem:  

Errors:

• Could not install package
• COULD_NOT_GET_TEMP_DIRECTORY

Figure 1:  Chrome Temp Directory Error

Solution:

1. User logs onto RDP.  User does not open Chrome.
2. Admin creates a new directory on the system drive.  This new directory holds user Chrome AppData.  For example:  c:\\mkdir c:\Temp\RDP\
3. Move user’s Chrome AppData to the new directory.  For example:
   c:\move "c:\users\stevenjordan\AppData\Local\Google\Chrome" "c:\temp\RDP\stevenjordan\"
4. Delete original folder if necessary. 
5. Create new symbolic junction where the old data was located.  This junction links to the new location:

c:\mklink /j c:\users\stevenjordan\AppData\Local\Google\Chrome\
"c:\temp\RDP\stevenjordan\Chrome\"

Junction created for c:\users\smjordan\AppData\Local\Google\Chrome\
=== c:\temp\RDP\stevenjordan\Chrome\

Figure 2:  New Symbolic Junction for Chrome extension.

Analysis:

c:\Users  dir 
02/23/2018  11:29 AM  bgates {\??\Volume{a5ae22c7-18b8-11e8-968e-00145de79140}

c:\Users\bgates\AppData\Local\Google dir
 
 Directory of c:\Users\bgates\AppData\Local\Google

02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   JUNCTION  Chrome c:\temp\RDP\bgates\Chrome
09/16/2015  07:46 AM   DIR       Chrome Cleanup Tool
05/14/2014  06:09 AM   DIR       CrashReports
03/11/2014  04:26 PM   DIR       Google Talk
12/04/2017  02:27 AM   DIR       Software Reporter Tool

0 File(s)              0 bytes
7 Dir(s)  36,942,458,880 bytes free

Additional Thoughts:

Summary:

Problem: 

Symptoms:

• Hyper-V Manager shows a checkpoint.  No option to remove checkpoint.

• VM disk directory has VHDX and AVHD files:

Solution:

PS C:\Users Get-VMSnapshot -VMName tfs.stevenjordan.net

VMName  Name    SnapshotType CreationTime           
------  ----    ------------ ------------          
tfs     tfs     (2/13/2018 - 2:52:36 PM) Standard

PS C:\Users Get-VMSnapshot -VMName tfs
PS C:\Users

Guide:  

Overview:  

Topology:  

• Three office locations:  
• Primary office in Atlanta (ATL).   
• Branch offices in Chicago (CHI) and Washington D.C (DCA).
• CHI and ATL host local file servers (i.e., hosted cache mode).
• DCA is the only office without a dedicated file server (i.e., distributed cache mode).
• All clients use Windows Enterprise.
    

Implement BranchCache:

• Install the BranchCache Role and Feature.
• BranchCace SSL Certificates.  
• BranchCache Group policy.

Step 1.  Add Roles and Features.

Step 2.  Adjust Caching.

Adjust the Cache Location:

1. Add a server certificate in the personal certificate directory for each  BranchCache hosted cache server (e.g., ATL and CHI).
2. Bind the SSL certificate hash (i.e., thumbprint) to the hosted cache server.  Use the following command: NETSH HTTP ADD SSLCERT IPPORT=0.0.0.0:443 CERTHASH=xxxxxxxxxxx APPID={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

Step 4.  Group Policy

Policies for the File Servers:  

BranchCache Firewall Policies:

Optional:  BranchCache for WSUS and IIS Servers

Evaluate

References: