Steven M. Jordan

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: 

The NPS Azure AD Extension creates a self-signed certificate that is valid for two years.  This certificate must be renewed!

The renewal process is simple enough:

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:

Windows 2016, 2019, and up natively support TLS 1.2.  However, you might still need to update the .NET framework and cryptography.  At a minimum, manually enable TLS 1.2:

 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

That's it!

GPOs don't work on the VPN?

Problem:  

Branch office or managed laptops are missing group policies.

Definition:  Group Policy Slow Link Detection

Slow-link detection identifies slow connections:  Slow transfer rates or high latency.  This process can trigger applications to scale back feature and function.  For example, slow link detection may interfere with distributed file systems (DFS).   In other situations, slow link detection can prevent remote workstations from receiving GPO updates.

Background:  

Wide-spread high-speed Internet connections (e.g., 100 Mbps) were uncommon before c. 2009.  Older network protocols were less efficient (e.g., SMB2 vs SMB3).  Slow-link detection was designed to compensate for poor connections.  This legacy process continues to impact modern network services (e.g., Windows 2019). 

Group Policy Slow Link Detection:

Connection rates are measured between the domain controllers and the client.  Group policy changes are not distributed when this transfer rate is less than 500 kbps. 

500 kbps may seem reasonable -but it's not. 

Solution:

Disable slow link detection:

   GPO:  Policies\Administrative Templates\System\Group Policy\Slow Link Detection

Options:  Enable this policy.

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

That's it!

References:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978717(v=technet.10)

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

The above examples shows two NICs that belong to two different networks.

Step 2.  Change the NetworkCategory:

This example changes the active network for the NIC named RDMA.  The network location changed from Public to Private.  Confirm with Get-NetConnectionProfile.

That't It!

References:

https://docs.microsoft.com/en-us/powershell/module/netconnection/get-netconnectionprofile?view=win10-ps

Problem:  

How to use PowerShell commands to transfer FISMO roles?

Solution: 

Active Directory PowerShell module.

Assumptions:  

FISMO PowerShell management requires Active Directory PowerShell module.

  Import-Module ActiveDirectory

Example 1.  Show forest FSMO roles (forest):

PS> Get-ADForest contoso.com| ft DomainNamingMaster, SchemaMaster

Example 2.  Show domain FSMO roles (domain): 

PS> Get-ADDomain contoso.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

Example 3. Transfer single role to a domain controller.  

PS>; Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

#N.B., PowerShell FISMO role names:

0= PDCEmulator      
1= RIDMaster      
2= InfrastructureMaster
3= SchemaMaster
4= DomainNamingMaster

Example 4.  Transfer multiple roles.

Move-ADDirectoryServerOperationMasterRole -Identity “DCX” –OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster



Example 5: Transfer all roles with numbers: 

Move-ADDirectoryServerOperationMasterRole “DCX” –OperationMasterRole 0,1,2,3,4

Example 6.  Transfer FSMO roles between domain controllers:

Move-ADDirectoryServerOperationMasterRole

That's It!

References:

https://docs.microsoft.com/en-us/powershell/module/addsadministration/move-addirectoryserveroperationmasterrole?view=win10-ps
https://blogs.technet.microsoft.com/canitpro/2017/05/24/step-by-step-migrating-active-directory-fsmo-roles-from-windows-server-2012-r2-to-2016/