Windows Server 2012 and 2012 R2 End of Life

DirectAccess on Microsoft Windows

I want to remind you of a critical upcoming milestone that may affect your business. In just 60 days, we will reach the end of support for Windows Server 2012 and Windows Server 2012 R2. As of October 10, 2023, these operating systems will no longer receive security updates or technical support from Microsoft.

End of Support

End of support means your servers will be more vulnerable to security risks and potential threats. It is essential to take action now to ensure your IT infrastructure’s continued security and stability. Upgrading to newer, supported operating systems will protect your data and systems from potential cyber threats and provide access to enhanced features and performance improvements.

Don’t Wait

Now is the time to migrate those remaining workloads for those still running Windows Server 2012 and 2012 R2! Consider the following commonly deployed services that may still be running on Windows Server 2012 or 2012 R2 in your organization.

Remote Access – Windows Server Routing and Remote Access Service (RRAS) is commonly deployed to provide secure remote access for field-based workers. In addition, Absolute Secure Access (formerly NetMotion Mobility) is a widely implemented premium alternative to RRAS. Organizations may be hesitant to migrate these workloads because disrupting remote workers is painful.

DirectAccess – This remote access technology is widely deployed and extremely difficult to migrate. In addition, the complex nature of DirectAccess, with its many intricate interdependencies, poses a significant challenge to organizations migrating this role.

PKI – This is likely the most common enterprise service to be found running on Windows Server 2012 and 2012R2. Most organizations relying on Windows Active Directory Certificate Services (AD CS) to issue and manage enterprise certificates are reluctant to move this workload once it is deployed. This service is much easier to migrate than you might think! It can be done without disruption as well.

Consulting Services

We understand that upgrading might require careful planning and coordination, and our team is here to support you throughout the transition process. Don’t delay – take this opportunity to safeguard your organization’s data and systems by upgrading to the latest Windows Server version or exploring cloud-based solutions.

Get In Touch

Please don’t hesitate to contact us for further assistance or any questions regarding the upgrade process. Together, let’s ensure your business remains secure and productive. You can get started today by booking a free one-hour consultation to discuss your migration strategy. Just fill out the form below and I’ll provide more information.

Always On VPN SSTP and HSTS

HTTP Strict Transport Security (HSTS) is a feature commonly used by websites to protect against protocol downgrade attacks, where an attacker forces the use of insecure HTTP instead of HTTPS. If successful, the attacker can intercept unencrypted communication between the client and the web server. This is undesirable for obvious reasons. As such, web server administrators implement an HTTP response header named Strict-Transport-Security with some additional settings that instruct the user agent, in this case, a web browser, to only use secure HTTPS when communicating with the web server. Attempts to use HTTP will not work.

VPN and SSTP

As security is always a top concern when building an Always On VPN infrastructure, careful attention must be paid to VPN protocol configuration to ensure optimal security. Secure Socket Tunneling Protocol (SSTP) is a popular VPN protocol for Always On VPN user tunnel connections. SSTP uses Transport Layer Security (TLS) for encryption, so administrators are encouraged to implement recommended security configurations, such as disabling insecure protocols like TLS 1.0 and TLS 1.1 and optimizing TLS cipher suites as described here.

SSTP with HSTS

It would seem that enabling HSTS on a Windows RRAS VPN server would be ideal for improving SSTP security. However, that’s not the case. HSTS prevents protocol downgrade attacks from HTTPS to HTTP, but SSTP already uses HTTPS exclusively, making the use of HSTS irrelevant. If an attacker attempted a protocol downgrade attack on an SSTP VPN connection, it would fail because the service does not support HTTP between the client and the VPN gateway. Additionally, even if it were possible to configure RRAS to send an HSTS response header, it would be ignored by the client because the user agent is not a web browser.

Additional Information

Always On VPN SSTP Security Configuration

Always On VPN SSTP and TLS 1.3

Always On VPN SSTP Certificate Renewal

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN SSTP Certificate Binding Error

SSL and TLS Training for Always On VPN Administrators

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