All posts in category routing

Always On VPN and RRAS on Windows Server Core

Windows Server Core is a refactored version of the full Windows Server operating system. Server Core does not include a Graphical User Interface (GUI) and must be managed via the command line or with PowerShell. The Routing and Remote Access Service (RRAS) is a supported workload on all supported versions of Windows Server including Windows Server 2022. Always On VPN administrators should consider installing and configuring RRAS on Windows Server Core to ensure their VPN infrastructure’s best security and performance.

Server Core Benefits

Windows Server Core is a minimal installation option of the Windows Server operating system that provides numerous benefits, particularly for environments where security, resource efficiency, and reduced maintenance overhead are essential. Here are some of the key benefits of using Windows Server Core.

Minimized Attack Surface – Windows Server Core has a smaller footprint compared to the full GUI version, which means fewer components and services are installed by default. This reduces the potential attack surface and minimizes security vulnerabilities.

Enhanced Security – With fewer components and a reduced attack surface, there are fewer potential vectors for malware or unauthorized access. This makes Windows Server Core a more secure choice for critical server roles like RRAS.

Reduced Maintenance – Since there are fewer components to update, patching and maintaining a Windows Server Core system is quicker and requires less effort. This is especially beneficial in large-scale server deployments.

Improved Stability – By removing the graphical user interface (GUI), Windows Server Core has fewer processes running in the background, leading to a more stable and predictable server environment.

Simplified Management – Windows Server Core is designed for remote administration. It allows the administrator to manage it using command-line tools, PowerShell, or remote management tools like the Remote Server Administration Tools (RSAT) and Windows Admin Center. This makes it easier to manage multiple servers from a single location.

Faster Reboots – Windows Servers require periodic reboots. With Windows Server Core, reboot times are considerably faster, resulting in less downtime during maintenance periods.

RSAT

The Remote Server Administration Tools (RSAT) can be installed on Windows clients and servers to enable remote administration using the familiar Routing and Remote Access Management console (rrasmgmt.msc) and Remote Access Management console (ramgmtui.exe) GUI tools.

Windows Client

To install the Remote Access Management tools on Windows client operating systems, navigate to Settings > Apps > Optional Features. Click Add a feature, select RSAT: Remote Access Management Tools, then click Install.

Optionally the Remote Access Management tools can be installed by running the following PowerShell command.

Add-WindowsCapability -Online -Name Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0

Windows Server

To install the Remote Access Management tools on Windows Server run the following PowerShell command.

Install-WindowsFeature -Name RSAT-RemoteAccess

Windows Admin Center

The Windows Admin Center is a free remote management tool from Microsoft for managing Windows Server (core and GUI) remotely. It is especially helpful for Server Core management as it provides a GUI for many common administrative tasks.

You can download Windows Admin Center here.

Additional Information

Windows Server Core Installation Option

Windows Server Core vs. Desktop

PowerShell Remote Server Administration

Windows Admin Center

Always On VPN RRAS Internal Interface Non-Operational

Windows 10 Always On VPN Routing Configuration

Always On VPN administrators troubleshooting connectivity issues may find the Internal network interface in the Routing and Remote Access management console (rrasmgmt.msc) administrative status indicates ‘Unknown’. They will also notice the Operational Status shows Non-operational.

Internal Interface

For clarification, the ‘Internal’ network interface in the Routing and Remote Access management console, as shown above, is not a physical network adapter on the server. Instead, it is a virtual network interface used only for incoming VPN connections.

Non-Operational

The Internal virtual network interface will not be created until the VPN server accepts its first VPN connection. Because of this, the Internal interface will have an operational status of non-operational until the first client attempts to connect. When this occurs, RRAS creates the interface, then assigns it the first IP address from the static IPv4 address pool. Alternatively, if DHCP is configured, it will assign the first IP address returned by the DHCP server.

Interface Names

While discussing network interfaces, I typically recommend renaming them in Windows to identify their function, especially when using two NIC configurations. However, be careful not to name the server’s internal network adapter ‘Internal’, as this can be confusing in the future. In my example above, I use the name ‘LAN’ to identify the internal adapter to distinguish it from the server’s ‘Internal’ virtual interface.

Additional Information

Windows Server RRAS Service Does Not Start

Windows Server RRAS Monitoring and Reporting

Microsoft Always On VPN and RRAS in Azure

Microsoft Always On VPN and RRAS with Signle NIC

Always On VPN Client Routes Missing

When configuring Always On VPN for Windows 10 and Windows 11 clients, administrators may encounter a scenario where an IPv4 route defined in Microsoft Endpoint Manager/Intune or custom XML is not reachable over an established Always On VPN connection. Further investigation indicates the route is added to the configuration on the endpoint but does not appear in the routing table when the connection is active.

Routing Configuration

When split tunneling is enabled, administrators must define routes to IP networks that are reachable over the Always On VPN connection. The method of defining these routes depends on the client configuration deployment method.

Endpoint Manager

Using Microsoft Endpoint Manager, administrators define IP routes in the Split Tunneling section of the configuration settings for the Always On VPN device configuration profile. Routes are defined by entering the destination prefix and prefix size. In this example, the 10.0.0.0/8 and 172.21.12.0/21 IPv4 networks are defined for routing over the Always On VPN tunnel.

Custom XML

Using custom XML deployed using Microsoft Endpoint Manager, System Center Configuration Manager (SCCM), or PowerShell, routes are defined in the XML file using the following syntax.

Client Configuration

Validate the routing configuration has been implemented on the endpoint successfully by running the following PowerShell command.

Get-VpnConnection -Name <Connection Name> | Select-Object -ExpandProperty Routes

As you can see here, the IPv4 routes 10.0.0.0/8 and 172.21.12.0/21 are included in the client’s Always On VPN configuration, as shown below.

Missing Route

However, after establishing an Always On VPN connection, the 172.21.12.0/21 network is not reachable. To continue troubleshooting, run the following PowerShell command to view the active routing table.

Get-NetRoute -AddressFamily IPv4

As you can see above, the only IPv4 route in the VPN configuration added to the routing table is the 10.0.0.0/8 network. The 172.21.12.0/21 IPv4 route is missing.

Network Prefix Definition

IPv4 routes missing from the Always On VPN client’s routing table result from incorrect network prefix definition. Specifically, the IPv4 route 172.21.12.0/21 used in the example here is not a valid network address. Rather, it is a host address in the 172.21.8.0/21 network, as shown below.

The Get-Subnet PowerShell cmdlet is part of the Subnet PowerShell module. To install this module, run the following PowerShell command.

Install-Module Subnet

Resolution

Using the example above, enabling access to the 172.21.12.0/21 subnet would require defining the IPv4 prefix in the routing configuration as 172.21.8.0/21. The moral of this story is always validate routing prefixes to ensure they are, in fact, network addresses and not host addresses.

Additional Information

Always On VPN Routing Configuration

Always On VPN Default Class-based Route and Microsoft Endpoint Manager/Intune

15 Comments

by Richard M. Hicks on November 8, 2021 • Permalink

Posted by Richard M. Hicks on November 8, 2021

https://directaccess.richardhicks.com/2021/11/08/always-on-vpn-client-routes-missing/

Richard M. Hicks Consulting, Inc.

Awards

Pluralsight

Consulting

Newsletter

All posts in category routing

Always On VPN and RRAS on Windows Server Core

Server Core Benefits