How Windows Tunnel Stacks Actually Negotiate Paths

Always On VPN and DirectAccess both implement fallback logic that most firewall documentation understates. The negotiation sequence matters more than any single port entry in your NSG.

For Always On VPN using IKEv2:

1. The client attempts UDP 500 (ISAKMP) for initial IKE negotiation.
2. If NAT is detected mid-handshake, the stack switches to UDP 4500 (NAT-T) automatically — no user action, no policy trigger.
3. If UDP is blocked entirely, the client falls back to SSTP, which wraps the tunnel inside TLS on TCP 443.

For DirectAccess, the IPv6 transition technology selection follows its own priority order:

1. Native IPv6 is attempted first.
2. 6to4 is tried if a public IPv4 address is available.
3. Teredo (UDP 3544) is attempted for clients behind NAT.
4. IP-HTTPS (TCP 443) is the final fallback, encapsulating IPv6 inside an HTTPS stream.

This is where static port-based DLP rules collapse. The DLP engine sees TLS on port 443. It does not see the IPv6 packet encapsulated inside, nor the SMB session running inside that IPv6 packet, nor the file transfer happening inside that SMB session. Each layer of encapsulation removes another inspection opportunity.

Port Multiplexing and the Inspection Gap

Port multiplexing compounds the problem. Protocols like SSTP and IP-HTTPS are not just using port 443 — they are multiplexing multiple logical sessions over a single TCP connection. From the perspective of a network appliance performing stateful inspection, this looks like a single long-lived HTTPS session. The appliance has no visibility into the multiplexed streams unless it performs deep packet inspection (DPI) with TLS decryption.

Most enterprise environments do not perform TLS decryption on traffic destined for internal VPN gateways. The certificate pinning and mutual TLS configurations used by Always On VPN and DirectAccess make interception technically complex and operationally risky. The result is a consistent blind spot: multiplexed tunnel traffic that traverses the network without triggering any DLP or threat detection rule.

Split tunneling introduces a second dimension to this problem. When split tunneling is enabled, only traffic destined for corporate resources routes through the tunnel. Internet-bound traffic exits directly from the client. If your DLP policy is applied at the VPN gateway, it has zero visibility into the direct internet path. If your DLP policy is applied at a cloud proxy, it may not see traffic that routes through the tunnel. The coverage gap depends entirely on how split tunneling routes are defined — and those routes are frequently misconfigured or undocumented.

What Intune Policies Actually Enforce — and What They Don't

Microsoft Intune VPN profiles configure the client-side tunnel parameters: the server endpoint, authentication method, protocol selection, and split tunneling routes. What Intune does not control is the fallback negotiation behavior of the underlying Windows VPN stack. If you configure an Always On VPN profile for IKEv2, the Windows stack will still attempt UDP 500, then UDP 4500, then SSTP — regardless of what your firewall team documented in the change request.

Intune's Windows VPN profile (configured under Devices → Configuration → VPN) allows you to specify:

• Connection type: IKEv2, SSTP, L2TP, Automatic
• Split tunneling: Enabled or disabled, with explicit route inclusions
• Custom XML: Extended configuration via ProfileXML for Always On VPN

The Automatic connection type is particularly problematic from a governance perspective. It instructs the Windows stack to select the best available protocol, which means the actual protocol in use at any given moment is determined by network conditions, not by policy. An endpoint on a hotel network may use SSTP while the same endpoint on a corporate LAN uses IKEv2 — and your firewall rules may only account for one of them.

To enforce a specific protocol and eliminate fallback ambiguity, configure the VPN profile with an explicit connection type and deploy it via Intune using ProfileXML:

<VPNProfile>
  <NativeProfile>
    <Servers>vpn.contoso.com</Servers>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
    <Authentication>
      <MachineMethod>Certificate</MachineMethod>
    </Authentication>
  </NativeProfile>
  <AlwaysOn>true</AlwaysOn>
  <RememberCredentials>false</RememberCredentials>
</VPNProfile>

Setting NativeProtocolType to IKEv2 explicitly removes SSTP as a fallback option. This is a deliberate trade-off: you gain port predictability at the cost of connectivity resilience in environments where UDP is blocked. That trade-off must be a documented architectural decision, not an accidental default.

Identifying Active Tunnel Ports in Production

Before adjusting any policy, establish a baseline of what ports your tunnel traffic is actually using. The following PowerShell command identifies established connections associated with the Windows VPN client process:

Get-NetTCPConnection -State Established |
  Where-Object { $_.OwningProcess -ne 0 } |
  ForEach-Object {
    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
      LocalAddress  = $_.LocalAddress
      LocalPort     = $_.LocalPort
      RemoteAddress = $_.RemoteAddress
      RemotePort    = $_.RemotePort
      ProcessName   = $proc.Name
      PID           = $_.OwningProcess
    }
  } |
  Where-Object { $_.ProcessName -match "svchost|vpnagent|rasphone" } |
  Sort-Object RemotePort

For UDP-based IKEv2 and NAT-T sessions, use:

Get-NetUDPEndpoint |
  Where-Object { $_.LocalPort -in @(500, 4500, 3544) } |
  Select-Object LocalAddress, LocalPort, OwningProcess

Run these commands across a representative sample of endpoints using Intune Remediations (formerly Proactive Remediations). Deploy the detection script to collect port data and return it as output, then aggregate results in Log Analytics via the Intune diagnostic data pipeline. This gives you an environment-wide view of which protocols are actually negotiating which ports — not what your documentation says they should be using.

Azure Network Security Groups and the Dynamic Port Problem

Azure Network Security Groups (NSGs) operate on static rule sets. They evaluate traffic against source/destination IP, protocol, and port range. They have no awareness of tunnel encapsulation, protocol fallback sequences, or multiplexed sessions. An NSG rule permitting TCP 443 inbound to a VPN gateway will pass SSTP tunnel traffic without any additional inspection.

To account for the full IKEv2 and NAT-T port surface, your NSG inbound rules for a VPN gateway subnet should explicitly include:

$nsg = Get-AzNetworkSecurityGroup -Name "vpn-gateway-nsg" -ResourceGroupName "rg-network"

$rules = @(
  @{ Name = "Allow-IKE";   Port = "500";  Protocol = "Udp" },
  @{ Name = "Allow-NATT";  Port = "4500"; Protocol = "Udp" },
  @{ Name = "Allow-SSTP";  Port = "443";  Protocol = "Tcp" },
  @{ Name = "Allow-Teredo"; Port = "3544"; Protocol = "Udp" }
)

$priority = 100
foreach ($rule in $rules) {
  $nsg | Add-AzNetworkSecurityRuleConfig `
    -Name $rule.Name `
    -Protocol $rule.Protocol `
    -Direction Inbound `
    -Priority $priority `
    -SourceAddressPrefix "VirtualNetwork" `
    -SourcePortRange "*" `
    -DestinationAddressPrefix "*" `
    -DestinationPortRange $rule.Port `
    -Access Allow | Out-Null
  $priority += 10
}

$nsg | Set-AzNetworkSecurityGroup

Explicitly defining these rules serves two purposes. First, it documents the actual port surface your tunnel stack uses. Second, it creates a baseline against which Microsoft Defender for Cloud network recommendations can be evaluated — if Defender for Cloud flags an unexpected open port, you have a documented justification or a genuine anomaly to investigate.

Detecting Tunnel Anomalies with Microsoft Sentinel

If your environment feeds network telemetry into Microsoft Sentinel, the following KQL query identifies endpoints where tunnel traffic is observed on ports outside the expected IKEv2/NAT-T/SSTP surface — a potential indicator of unauthorized tunnel tools or misconfigured VPN clients:

// Detect tunnel-related traffic on unexpected ports
NetworkCommunicationEvents
| where RemotePort !in (443, 500, 4500, 3544, 1723)
| where InitiatingProcessFileName in~ ("vpnagent.exe", "rasphone.exe", "svchost.exe")
| summarize
    ConnectionCount = count(),
    DistinctPorts = make_set(RemotePort),
    DistinctRemoteIPs = make_set(RemoteIP)
  by DeviceName, InitiatingProcessFileName, bin(Timestamp, 1h)
| where ConnectionCount > 5
| order by ConnectionCount desc

This query surfaces endpoints where VPN-associated processes are communicating on ports that fall outside the documented tunnel surface. Investigate results for unauthorized VPN clients, split-tunnel misconfigurations, or third-party tunnel tools that bypass corporate inspection entirely.

Governance Considerations for Port-Based DLP Policies

The governance failure here is not technical — it is procedural. Port-based DLP policies are reviewed and certified based on documentation, not on observed traffic. The documentation says the VPN uses IKEv2 on UDP 500. The auditor checks that UDP 500 is in scope. The audit passes. The SSTP fallback on TCP 443 is never mentioned because it is not in the architecture diagram.

Addressing this requires three changes to your governance process:

First, replace port-based DLP coverage assertions with protocol-aware coverage assertions. Instead of certifying "egress on port 443 is inspected," certify "SSTP tunnel traffic is decrypted and inspected at the gateway" — or explicitly document that it is not, and accept the residual risk.

Second, include tunnel protocol fallback behavior in your network change management process. Any change to VPN gateway configuration, NSG rules, or Intune VPN profiles should require a documented review of which fallback protocols remain active and which inspection points cover them.

Third, run the PowerShell and KQL queries above on a scheduled basis and feed results into your compliance reporting. Observed port behavior should be compared against documented expected behavior quarterly. Deviations are findings, not background noise.