What ports and FQDN endpoints need to be allowed in FortiGate policy for Windows Server KMS activation?

Hello,

You only need to allow outbound HTTPS (TCP 443) from the KMS host VM to Microsoft’s activation service at kms.core.microsoft.com for the initial activation of the KMS host key. After that, the KMS host does not require ongoing internet access; all subsequent client activations and renewals happen entirely on your internal network over TCP 1688.

When you activate a KMS host key on Windows Server 2025, the host contacts Microsoft’s activation servers once to validate the CSVLK (Customer Specific Volume License Key). This communication is strictly outbound, encrypted over port 443, and directed to kms.core.microsoft.com. There are no additional endpoints or IP ranges you need to whitelist. Microsoft does not publish static IPs for this service, so the best practice is to configure a FortiGate FQDN address object for kms.core.microsoft.com and allow outbound TCP 443 from the KMS host VM. SSL inspection is not required, and in fact can interfere with activation, so you should exempt this traffic from deep inspection.

Once the host key is activated, the KMS host functions autonomously inside your network. KMS clients (your Windows Server VMs) discover the host via DNS SRV records (_VLMCS._TCP) and activate against it using TCP 1688. The activation validity interval is 180 days, and clients attempt renewal every 7 days by default. These renewals are strictly client-to-host traffic on your internal LAN; the KMS host does not need to recontact Microsoft for each renewal. The only time you would need outbound access again is if you reinstall the KMS host or change the host key and need to re-activate it.

In FortiGate, the recommended configuration is to create an FQDN address object for kms.core.microsoft.com, apply it in a firewall policy allowing outbound TCP 443 from the KMS host VM only, and keep the rule disabled after successful activation if you want to enforce a one-time activation policy. If you prefer to leave it enabled, it will not harm security since the traffic is minimal and only to Microsoft’s activation endpoint.

To summarize: whitelist kms.core.microsoft.com over TCP 443 for the KMS host VM, allow TCP 1688 internally for client-to-host activation, and no periodic outbound internet access is required beyond the initial activation.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HL.

Hello @aya aya

There are actually two different activation flows here, and I would separate them when configuring the FortiGate.

1. Your Windows Server VMs → your internal KMS host

This is the normal KMS traffic. By default, KMS clients discover the KMS host through the _vlmcs._tcp DNS SRV record and connect to the KMS host using TCP 1688

Microsoft confirms TCP 1688 as the default KMS client-to-host port.

Since your three client VMs and KMS host are on the internal network, this traffic doesn't need Internet access.

Your FortiGate/internal firewall policy therefore only needs to permit the required client-to-KMS communication internally:

Source: KMS client subnet/servers

Destination: Internal KMS host

Protocol: TCP

Port: 1688

You can verify connectivity from a client with:

Test-NetConnection <KMS-host-FQDN> -Port 1688

Microsoft also documents checking TCP 1688 when troubleshooting communication between KMS clients and a self-hosted KMS server.

2. Your KMS host → Microsoft for activation of the KMS host key

This is different.

You must first activate the KMS host key with Microsoft. Microsoft's Windows Server 2025 KMS documentation supports either:

• online activation, which requires Internet access, or
• phone activation.

I would therefore not build a permanent FortiGate Internet rule around kms.core.microsoft.com:1688 based on the assumption that this is the required KMS-host activation endpoint.

Also be careful not to confuse this with azkms.core.windows.net:1688. Microsoft documents that endpoint specifically for Azure VMs using Azure KMS. That's not the same architecture as your on-premises KMS host.

For an environment where Internet access must be extremely restricted, the cleaner option may actually be phone activation of the KMS host key. That avoids maintaining an outbound Internet firewall exception solely for initial KMS host activation. Microsoft explicitly supports phone activation when configuring a KMS host.

Once the KMS host itself is activated, the 180-day renewal you're referring to applies to KMS clients, not to the KMS host making an Internet connection to Microsoft every 180 days.

KMS clients renew against your internal KMS host. Microsoft's default KMS renewal interval is 10,080 minutes, or 7 days.

So the traffic flow is essentially:

For FortiGate, I would consequently avoid SSL inspection or application-control modifications for the internal TCP/1688 KMS flow unless your security requirements specifically require them. A simple restricted service policy from the KMS clients to the KMS host is easier to troubleshoot.

One additional point: you mentioned only three Windows Server KMS clients. Microsoft requires a minimum activation threshold of five Windows Server computers before KMS begins activating server clients. With only three eligible Windows Server clients, the KMS host won't meet the activation threshold yet.

You can check the current KMS host state/count with:

slmgr.vbs /dlv

So before troubleshooting FortiGate further, I'd verify the KMS count. Three Windows Server VMs won't meet the KMS activation threshold on their own.

Sharing these Microsoft references:

Create a KMS activation host in Windows Server

KMS activation planning for Windows Server

KMS client activation and product keys

The first thing I'd address in your environment is the five-server activation threshold, rather than the FortiGate Internet rule.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.