Steven M. Jordan

Understanding how prefix delegation, Router Advertisements (RA), Neighbor Discovery (ND), and

stateful firewalling interact is critical for a solid IPv6 deployment.

Goal:

This post walks through an IPv6 rollout using AT&T Internet (a non-SLA service behind an AT&T RG)

routed through a MikroTik CCR2004-16G-2S+ running RouterOS v7.20.

Unlike a Spectrum deployment which hands out generous /56 prefixes. AT&T 

delegates a single /64. Yep. A single measly /64. Needlessly stingy imo, but we can still work with that.   

Solution:

How to set it up and secure isolated IPv6 connectivity for a single Windows "test" VM.

1. Network Topology

• ISP: AT&T Business Internet (non-SLA)
• Upstream Edge: AT&T Residential Gateway (RG)
• Core Router: MikroTik CCR2004-16G-2S+ (RouterOS 7.20)
• CCR WAN Interface: ether1_untrust
• CCR LAN Bridge: bridge_ipv6
• CCR Physical Port: ether16_ipv6
• Hypervisor: Microsoft Hyper-V host running a Windows VM

add interface=ether1_untrust \
    request=prefix \
    pool-name=att_pd \
    pool-prefix-length=64 \
    add-default-route=yes \
    accept-prefix-without-address=yes

/ipv6 dhcp-client print detail

interface=ether1_untrust status=bound dhcp-server-v6=fe80::3aa0:67ff:fe81:d662 
request=prefix pool-name=att_pd pool-prefix-length=64 
prefix=2600:1700:1335:452f::/64

Note, ULAs are not used for this lab exercise.

/ipv6 address
add interface=bridge_ipv6 \
from-pool=att_pd \
advertise=yes

/ipv6 address print

2600:1700:1335:452f::/64 FROM-POOL=att_pd INTERFACE=bridge_ipv6 ADVERTISE=yes

/ipv6 nd
add interface=bridge_ipv6 \
    advertise-dns=yes \
    managed-address-configuration=no \
    other-configuration=no

/ipv6 nd
set [find where interface=bridge_ipv6] \
    dns=2001:4860:4860::8888,2001:4860:4860::8844 \
    advertise-dns=yes

Note: All devices do not natively support RDNSS. For example Android or Xbox devices may require
dual-stack and use IPv4 DNS servers for their IPv6 name resolution. Plan accordingly.

   +-----------------------------------------------------------------------+
   |                        ROUTER DISCOVERY                               |
   |                                                                       |
   |   [ Windows VM ] --- (Type 133: Router Solicitation) ---> [ ff02::2 ] |
   |   [ Windows VM ] <--- (Type 134: Router Advertisement) -- [ MikroTik ]|
   +-----------------------------------------------------------------------+
   |                        ADDRESS RESOLUTION                             |
   |                                                                       |
   |   [ Windows VM ] --- (Type 135: Neighbor Solicitation) -> [ Sol-Node ]|
   |   [ Windows VM ] <--- (Type 136: Neighbor Advertisement) -- [ Target ]|
   +-----------------------------------------------------------------------+

/ipv6 firewall filter
add chain=input action=accept connection-state=established,related comment="Accept established/related"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmpv6 comment="Accept essential ICMPv6"
add chain=input action=accept in-interface=ether1_untrust protocol=udp src-port=547 dst-port=546 comment="Allow DHCPv6 reply from RG"
add chain=input action=accept in-interface-list=trust comment="Allow trusted management"
add chain=input action=drop in-interface=ether1_untrust comment="Drop all other unsolicited WAN input"

/ipv6 firewall filter
add chain=forward action=accept connection-state=established,related comment="Accept established/related"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept protocol=icmpv6 comment="Allow ICMPv6 pass-through"
add chain=forward action=accept in-interface=bridge_ipv6 out-interface=ether1_untrust comment="Allow test LAN outbound"
add chain=forward action=drop in-interface=ether1_untrust out-interface=bridge_ipv6 comment="Block unsolicited WAN to LAN"

# DO NOT USE THIS RULE
/ipv6 firewall raw
add chain=prerouting action=drop in-interface=ether1_untrust src-address=fe80::/10

ipconfig /all

:: Test ICMP Reachability

ping -6 2001:4860:4860::8888

:: Test DNS Resolution

nslookup google.com 2001:4860:4860::8888

:: Trace Route

tracert -6 2001:4860:4860::8888

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!

NPS Azure AD Extension Certificate Renewal

The NPS Azure AD Extension creates a self-signed certificate that’s only valid for two years. If you forget to renew it, authentication will eventually start failing when that certificate expires.

Renewal

Renewing the certificate is simple. Just rerun the Azure MFA NPS Extension configuration script:

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

This will generate a new certificate and update the extension to use it.

PowerShell Error

When you run the script, you might see an error like:

The package source https://www.powershellgallery.com/api/v2 is not reachable or resolved.

This usually means PowerShell isn’t using a modern TLS version when it tries to connect to the PowerShell Gallery.

Fix

Windows Server 2016, 2019, and newer support TLS 1.2, but PowerShell may still default to older protocols, depending on .NET and cryptography settings.

The quickest fix is to force TLS 1.2 in your PowerShell session and then rerun the script:

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

Once TLS 1.2 is enabled, the script can reach the PowerShell Gallery and the NPS Azure AD Extension certificate is renewed without further issues.

A practical guide to DHCPv6 Prefix Delegation, SLAAC, router advertisements, and dynamic IPv6 routing across multiple routers.

The Low-Down

Got Spectrum? Want IPv6? Want to route those prefixes? We can build that.

Why route IPv6 prefixes on something as ordinary as a home network? Because a flat network isn't a requirement. Conventional wisdom suggests we bridge a single Layer 2 network straight to the AP. That works. You can also go your own way. 

A single broadcast domain has two problems: security and noise. Cheap and beefy firewalls (hello, MikroTik) changed the math entirely. Each routed segment is its own security zone.  Policy becomes intuitive: this interface talks to that one, this zone to that zone, and everything else is a rule.

The other win is isolation. Chatty Wi-Fi clients throw broadcasts and multicast at everyone on the same domain. That noise is not stuck on the wireless side. It hits the wired LAN too. Ever try a wireless printer from your phone? The rest of the network feels broken. Not that I would know. 🤣

Routed segments fix that. Client isolation and private VLANs help, but they still live in one broadcast domain. Routing adds a real boundary.

Our Spectrum deployment demonstrates this architecture using two MikroTik routers:

• The Primary Firewall: The Internet edge router receiving Spectrum's /56.
• Secondary AP: A downstream router receiving a /58 from Martha and distributing /64 networks to its clients.

The result is a routed IPv6 network with automatic prefix assignment and routing, without NAT66 or static routes for the delegated global prefixes.

This article examines how that architecture works and why Router Advertisements, DHCPv6-PD, and Unique Local Addresses each have distinct roles.

Network topology

Spectrum provides a dynamically delegated /56 IPv6 prefix.

The primary firewall receives that prefix and manages its distribution.

The AP receives a /58 from the primary firewall and uses that delegated block to assign /64 prefixes to its internal networks.

Three distinct functions:

2001:db8:1234:5600::/56

/ipv6 dhcp-client
add interface=<spectrum-wan> \
    request=prefix \
    pool-name=spectrum_ipv6 \
    pool-prefix-length=56 \
    add-default-route=no

/ipv6 dhcp-client print detail
/ipv6 pool print detail

::/0
    gateway=fe80::xxxx%<spectrum-wan>

/ipv6 settings
set accept-router-advertisements=yes

Spectrum delegates:
2001:db8:1234:5600::/56

Edge firewall delegates to AP:
2001:db8:1234:5640::/58

/ipv6 dhcp-client
set [find where pool-name=spectrum_ipv6] \
    pool-prefix-length=58

/ipv6 dhcp-server
add name=dhcpv6_to_ap \
    interface=<ap-facing-interface> \
    address-pool=<pd-pool>

/ipv6 dhcp-client
add interface=<edge-uplink> \
    request=prefix \
    pool-name=spectrum_pool \
    pool-prefix-length=64 \
    add-default-route=no

Spectrum
     |
Edge Firewall /56
     |
Access Point  /58
     |
Wireless Clients /64

/ipv6 address
add interface=bridge_wifi \
    from-pool=spectrum_pool \
    advertise=yes

/ipv6 nd
add interface=bridge_wifi \
    advertise-dns=yes \
    managed-address-configuration=no \
    other-configuration=no

/ipv6 nd
set [find where interface=bridge_wifi] \
    managed-address-configuration=yes

Destination:
2001:db8:1234:5640::/58

Next hop:
AP

Problem: 

Solution: 

Command: 

Before:

After:

Problem

You need to move the FSMO roles, and you would rather do it in PowerShell than click through the old MMC snap-ins.

Solution

Use the Active Directory PowerShell module. If it is not already loaded, import it first.

Import-Module ActiveDirectory

See who has the forest roles

Get-ADForest contoso.com | ft DomainNamingMaster, SchemaMaster

See who has the domain roles

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

Move one role

This hands the PDC Emulator role to the domain controller named DCX.

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

PowerShell also accepts the role as a number:

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

Move several roles

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" -OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Move all of them by number

Move-ADDirectoryServerOperationMasterRole "DCX" -OperationMasterRole 0,1,2,3,4

That's it. Same command either way. Name the destination domain controller, then list the roles you want it to take.

References

Move-ADDirectoryServerOperationMasterRole

Migrating FSMO roles from Windows Server 2012 R2 to 2016

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:

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: