Eine der besten Übersichten dazu von MS. Zuerst weitere Links:
What’s New in Networking
Networking
Low Latency Workloads Technologies
Dynamic Host Configuration Protocol (DHCP) Overview
Core Network Guide and Companion Guides Overview
TCP v4 and V6
Remote Access combines three networking services into one unified server role. The three services are:
- DirectAccess
- Routing
- Remote Access
DirectAccess allows remote users to securely access enterprise shares, websites, and applications without connecting to a virtual private network (VPN). DirectAccess establishes bi-directional connectivity with a user’s enterprise network every time a user’s DirectAccess-enabled portable computer connects to the Internet, even before the user logs on. Users never have to think about connecting to the enterprise network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.
A router is a device that manages the flow of data between network segments, or subnets. A router directs incoming and outgoing packets based on the information about the state of its own network interfaces and a list of possible sources and destinations for network traffic. By projecting network traffic and routing needs based on the number and types of hardware devices and applications used in your environment, you can better decide whether to use a dedicated hardware router, a software-based router, or a combination of both. Generally, dedicated hardware routers handle heavier routing demands best, and less expensive software-based routers handle lighter routing loads.
A software-based routing solution, such as RRAS in this version of Windows, can be ideal on a small, segmented network with relatively light traffic between subnets. Enterprise network environments that have a large number of network segments and a wide range of performance requirements might need a variety of hardware-based routers to perform different roles throughout the network.
By configuring RRAS to act as a remote access server, you can connect remote or mobile workers to your organization’s networks. Remote users can work as if their computers are directly connected to the network.
All services typically available to a directly connected user (including file and printer sharing, Web server access, and messaging) are enabled by means of the remote access connection. For example, on an RRAS server, clients can use Windows Explorer to make drive connections and to connect to printers. Because drive letters and universal naming convention (UNC) names are fully supported by remote access, most commercial and custom applications work without modification.
An RRAS server provides two different types of remote access connectivity:
- Virtual private networking. A virtual private network (VPN) is a secured, point-to-point connection across a public network, such as the Internet. A VPN client uses special TCP/IP-based protocols called tunneling protocols to make a connection to a port on a remote VPN server. The VPN server accepts the connection, authenticates the connecting user and computer, and then transfers data between the VPN client and the corporate network. Because the data traverses a public network, you must encrypt data sent over the connection to ensure privacy.
- Dial-up networking. In dial-up networking, a remote access client makes a dial-up telephone connection to a physical port on a remote access server by using the service of a telecommunications provider, such as analog telephone or ISDN. Dial-up networking over an analog phone or ISDN is a direct physical connection between the dial-up networking client and the dial-up networking server. You can encrypt data sent over the connection, but it is not required because the phone line is typically considered secure.
The new features of Remote Access in Windows Server 2012 and Windows® 8 Release Preview address better connectivity on the Internet, tools for better management of remote computers, and better manageability of Remote Access settings through Windows PowerShell.
DirectAccess and RRAS Unified Server Role
Windows Server® 2008 R2 introduced DirectAccess, a new remote access feature that allows connectivity to corporate network resources without the need for traditional Virtual Private Network (VPN) connections. DirectAccess provides support only for domain-joined Windows 7 Enterprise and Ultimate edition clients. The Windows Routing and Remote Access Server (RRAS) provides traditional VPN connectivity for legacy clients and non-domain members. RRAS also provides site-to-site connections between servers. RRAS in Windows Server 2008 R2 cannot coexist on the same edge server with DirectAccess, and must be deployed and managed separately from DirectAccess.
Windows Server 2012 combines the DirectAccess feature and the RRAS role service into a new unified server role. This new Remote Access server role allows for centralized administration, configuration, and monitoring of both DirectAccess and VPN-based remote access services. Additionally, Windows Server 2012 DirectAccess provides multiple updates and improvements to address deployment blockers and provide simplified management.
What works differently?
The new unified server role for DirectAccess and RRAS provides a single point of configuration and management for remote access server deployment. Windows Server 2012 includes the following improvements over Windows 7 DirectAccess and RRAS.
- DirectAccess and RRAS coexistence
- Simplified DirectAccess management for small and medium organization administrators
- Removal of PKI deployment as a DirectAccess prerequisite
- Built-in NAT64 and DNS64 support for accessing IPv4-only resources
- Support for DirectAccess server behind a NAT device
- Simplified network security policy
- Load balancing support
- Support for multiple domains
- NAP integration
- Support for OTP (token based authentication)
- Automated support for force tunneling
- IP-HTTPS interoperability and performance improvements
- Manage-out support
- Multisite support
- Support for Server Core
- Windows PowerShell support
- User and server health monitoring
- Diagnostics
- Accounting and reporting
- Site-to-site IKEv2 IPsec tunnel mode VPN
DirectAccess and RRAS coexistence
Both DirectAccess and RRAS implement security features to protect the server from hostile inbound traffic. Previously these security feature settings conflicted with each other if both services attempt to run on the same server, preventing either DirectAccess or RRAS from functioning as expected.
DirectAccess relies on Internet Protocol version six (IPv6) transition technologies to establish client connections. RRAS implements Internet Key Exchange version 2 (IKEv2) Internet Protocol security (IPsec), and configures incoming and outgoing packet filters to drop all packets using transition technologies. This results in DirectAccess traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2.
DirectAccess implements IPsec Denial of Service Protection (DoSP) to protect resources on the corporate network. DoSP drops all IPv4 traffic, and all IPv6 traffic that is not protected by IPsec, except ICMPv6 packets. This results in all IPv4 packets and non-IPsec-protected IPv6 packets forwarded by RRAS being blocked if DirectAccess is installed.
Windows Server 2012DirectAccess and RRAS unified server role solves these problems by modifying IKEv2 policies to allow IPv6 transition technology traffic, and by modifying IPsec DoSP to allow VPN traffic. These changes allow both DirectAccess and RRAS to coexist on the same server.
Simplified DirectAccess Deployment
Windows Server 2012 includes features to facilitate deployment, particularly for small and medium size organizations. These new features include a simplified prerequisite list, removal of the need for a full PKI deployment, integrated certificate provisioning, and removal of the requirement for two consecutive public IPv4 addresses. Each of these features is discussed in more detail in the following sections.
Administrators can now deploy DirectAccess using a new Getting Started Wizard, which presents a greatly simplified configuration experience. The Getting Started Wizard masks the complexity of DirectAccess, and allows for an automated setup in a few simple steps. The administrator no longer requires an understanding of the technical details of things like IPv6 transition technologies and Network Location Server (NLS) deployment.
Removal of PKI Deployment as a DirectAccess Prerequisite
One major deployment blocker for Windows 7 DirectAccess is the requirement of a Public Key Infrastructure (PKI) for server and client certificate-based authentication. DirectAccess relies on IPsec AuthIP policies for authenticating and securing traffic from Internet-connected clients. In order to authenticate to domain resources using Kerberos, the client must first establish connectivity to DNS servers and Domain Controllers (DCs).
Windows 7 DirectAccess enables this connectivity by implementing two authentication methods in the AuthIP policies. The infrastructure IPsec tunnel is established using computer certificate as the first authentication method and user NTLM as the second method. Once this tunnel is established and a DC is available, the client can obtain a Kerberos token and establish the intranet IPsec tunnel using computer certificate and user Kerberos as the first and second authentication methods.
This implementation requires that the DirectAccess server and all clients be provisioned with computer certificates for mutual authentication. Managing an internal PKI is considered difficult by many small and medium organizations. Windows Server 2012 DirectAccess makes PKI deployment optional to simplify configuration and management.
This functionality is achieved by implementing an HTTPS based Kerberos proxy. Client authentication requests are sent to a Kerberos proxy service running on the DirectAccess server. The Kerberos proxy then sends Kerberos requests to Domain Controllers on behalf of the client.
The new Getting Started wizard provides a seamless experience for the administrator by configuring this solution automatically. In this simplified DirectAccess deployment, user level configuration options such as force tunneling, Network Access Protection (NAP) integration, and two-factor authentication are not available. This deployment requires only one IPsec tunnel to be established, and has the following requirements.
- IPsec ports (UDP 500/4500) and TCP port 443 must be open on the external Internet-facing firewall, if deployed
- The DirectAccess server must have TCP port 443 open on its firewall
- The DirectAccess server must have a server authentication certificate for TLS issued by a Certificate Authority (CA) that is trusted by the DirectAccess clients. This can be a public CA and does not require an internal PKI deployment. If no certificate is available, the DirectAccess server setup process will configure the necessary IP-HTTPS and KDC proxy certificate automatically as a self-signed certificate.
NAT64 and DNS64 Support for Accessing IPv4-only Resources
Windows DirectAccess is an IPv6-only technology from a client perspective. This means that clients can only access intranet resources accessible via IPv6 while connected remotely, and only if the client application itself supports connecting to an IPv6 resource. Intranet applications or resources are accessible directly via IPv6 if they are listening on the internal server’s IPv6 interface. For remote management of DirectAccess clients initiated by intranet computers, internal application or management servers must also be fully IPv6 compliant and the server applications they run must be IPv6 compatible.
To allow access to internal IPv4-only resources, Windows Server 2012 DirectAccess includes native support for a protocol translation (NAT64) and name resolution (DNS64) gateway to convert the IPv6 communication from a DirectAccess client to IPv4 for the internal servers. IPv4-only intranet computers cannot initiate connections to DirectAccess clients for remote management because the translation done with NAT64 is unidirectional (for traffic initiated by the DirectAccess client).
There are three primary instances where IPv6-only DirectAccess does not allow full access to corporate intranet resources.
- Intranet servers that are not fully IPv6 capable and support only IPv4, such as Windows Server 2003 file servers
- Environments where IPv6 has been administratively disabled on the network
- Applications running on IPv6 capable servers (such as Windows Server 2008) which are not IPv6 capable themselves (such as applications that are not able to listen and respond to traffic on the IPv6 interface)
To access these resources over DirectAccess, protocol translation must be done between the DirectAccess server and the internal IPv4-only resources, with subsequent translation back to IPv6 for responses sent to DirectAccess clients. NAT64 receives IPv6 traffic from the client and converts it into IPv4 traffic to the intranet. NAT64 is used in combination with DNS64. DNS64 intercepts DNS queries from clients, and sends responses after converting IPv4 answers into associated IPv6 mappings on the NAT64.
Note
Prior to Windows Server 2012 DirectAccess, the only method available to provide protocol translation for DirectAccess is through deployment of Microsoft Forefront Unified Access Gateway DirectAccess.
The DirectAccess setup wizard will seamlessly configure protocol translation components as a background operation, without any need for administrative interaction. There are no configuration options exposed to the administrator. The setup wizard will automatically enable NAT64 and DNS64 if the internal interface of the DirectAccess server has an IPv4 address assigned. To support this functionality, the setup wizard will configure an IPv6 network prefix for NAT64. The wizard assigns the NAT64 prefix automatically, and applies it to all IPv4 ranges in the enterprise. When a client attempts connection to an IPv4-only resource, the DirectAccess server returns an IPv6 address for the internal resource generated from this prefix.
Support for DirectAccess Server behind a NAT Device
A Windows Server 2008 R2 DirectAccess server requires two network interfaces with two consecutive public IPv4 addresses assigned to the external interface. This is required so that it can act as a Teredo server. In order for clients behind a NAT to determine the Teredo server and the type of NAT device, the Teredo server requires two consecutive IPv4 addresses.
This requirement presents difficulty for small and medium organizations that do not have access to consecutive, public IPv4 addresses. In the future this has the potential to become a deployment blocker as the available IPv4 address space is exhausted. Windows Server 2012 DirectAccess provides the ability to deploy the DirectAccess server behind a NAT device, with support for a single network interface or multiple interfaces, and removes the public IPv4 address prerequisite.
When the Remote Access Services setup Getting Started Wizard or Remote Access Setup Wizard is run, it will check the status of network interfaces on the server to determine if the DirectAccess server is located behind a NAT device. In this configuration, only IP over HTTPS (IP-HTTPS) will be deployed. The IP-HTTPS protocol is an IPv6 transition technology that allows for a secure IP tunnel to be established using a secure HTTP connection.
Simplified Network Security Policy
Windows Server 2008 R2 DirectAccess uses two IPsec tunnels to establish connectivity to the corporate network. The DirectAccess client requires the infrastructure tunnel to access infrastructure resources such as DNS, DC, and Management servers. These infrastructure servers are all listed as endpoints in the infrastructure tunnel IPsec policy. Then the intranet tunnel provides access to all other corporate intranet resources.
The endpoints listed in the infrastructure tunnel policy require periodic updates as the infrastructure changes, such as when DNS servers or Domain Controllers are added to or removed from the production network. Clients can lose connectivity to the domain when their IPsec policies are not updated to reflect the current infrastructure server endpoints, and this loss of connectivity will prevent them from receiving group policy updates to correct the failure.
In Windows Server 2012, the Simplified DirectAccess model provides a way to deploy DirectAccess over a single IPsec tunnel, which eliminates this problem. However, Simplified DirectAccess does not support certain capabilities, which rely on certificate-based authentication. Examples are two-factor authentication with smart cards, and NAP integration. Enterprises requiring a full featured DirectAccess experience will still need to deploy the two-tunnel model.
If the two-tunnel model is required for full functionality, there is additional functionality available to enable administrators to refresh the list of servers that are made accessible via the infrastructure tunnel. New domain controllers and SCCM servers are discovered and added to the list. Servers that no longer exist are removed from the list, and entries for servers whose IP addresses have changed are updated.
Windows Server 2008 R2 DirectAccess does not provide a full high availability solution, and is limited to single-server deployments. To provide limited hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover cluster configured for Hyper-V Live Migration. However, only one server node may be online at any time.
DirectAccess deployments have quickly grown beyond the point where a single server can provide adequate processing power. Enterprises need the flexibility to deploy additional servers quickly and transparently to meet changing load requirements. Additionally, the Network Location Server used for inside/outside detection must be highly available to prevent major outages for DirectAccess clients connected to the intranet.
Windows Server 2012 DirectAccess addresses these issues through built-in support for Windows Network Load Balancing (NLB) to achieve high availability and scalability for both DirectAccess and RRAS. The NLB configuration is simple to setup and automate through the new deployment wizard interface. The setup process also provides integrated support for third party external hardware-based load balancer solutions.
Important: Windows Server 2012DirectAccess provides a basic failover solution using Network Load Balancing for up to eight nodes. Although server load will be shared across all NLB nodes, existing connections will not automatically be transferred to other servers when one server becomes unavailable.
The DirectAccess setup wizard in Windows Server 2008 R2 can be used to configure DirectAccess for a single domain only. This means that remote clients from a different domain from the DirectAccess server will not be able to use DirectAccess. In addition, if application servers are in a different domain, remote clients will not be able to access them remotely via DirectAccess.
Although administrators can manually configure multiple domain support in Windows Server 2008 R2, the deployment requires manual edit of the DirectAccess policies after setup is completed. Windows Server 2012 DirectAccess provides integrated multiple domain support to allow remote client access to enterprise resources located in different domains.
Windows Server 2008 R2 DirectAccess supported the integration of Network Access Protection (NAP) by requiring a health certificate for the IPsec peer authentication of the intranet tunnel. A health certificate is a certificate with the System Health object identifier (OID). A NAP client can only obtain a health certificate from a Health Registration Authority (HRA) if it complies with system health requirements as configured on a NAP health policy server.
To integrate NAP with Windows Server 2008 R2 DirectAccess, the administrator must manually edit the Group Policy objects and policies created by the DirectAccess setup wizard after DirectAccess has been deployed. Windows Server 2012 DirectAccess provides the ability to configure a NAP health check directly through the setup user interface. This feature automates the policy and GPO modifications needed for NAP integration. NAP health check enforcement can be enabled from the Remote Access Setup Wizard.
Note
Although the new setup wizard simplifies NAP integration with DirectAccess, it does not automate the actual NAP deployment itself. An Administrator must configure the NAP IPsec enforcement and HRA infrastructure independently.
Support for OTP (Token Based Authentication)
To increase login security, many organizations have deployed One-Time Password (OTP) two-factor authentication, and mandate its use for remote access connections. Windows Server 2008 R2 DirectAccess provided support for two-factor authentication with Smart Cards, but was not capable of integrating with OTP vendor solutions, such as RSA SecurID. This prevented DirectAccess deployment in organizations that require this level of security.
Windows Server 2012 DirectAccess supports two-factor authentication with Smart Cards or OTP token based solutions. This feature requires a PKI deployment, so if the option is selected in the DirectAccess Setup Wizard, the Use computer certificates option is automatically selected and enforced.
In addition to support for standard smart card authentication, DirectAccess can use the Trusted Platform Module (TPM)-based virtual smart card capabilities available in Windows Server 2012. The TPM of client computers can act as a virtual smart card for two-factor authentication, thus removing the overhead and costs incurred in smart card deployment.
Automated Support for Force Tunneling
By default, DirectAccess clients are able to access the Internet, the corporate intranet, and local LAN resources simultaneously. Since only connections made to the corporate intranet are sent over the DirectAccess IPsec tunnels, this is known as a split-tunnel configuration. Split tunneling provides an optimal user experience when accessing resources on the Internet, while still providing strong security for traffic intended for the intranet.
Some administrators consider split tunneling to be a security risk. With legacy VPN connections, the potential exists for users to bridge traffic between networks, such as a home network and the corporate network, effectively making the client operate as a router. For this reason, it is common practice for administrators to disable split tunneling for VPN connections, forcing all network traffic to be routed through the VPN connection. This results in decreased performance when accessing Internet resources, since all traffic must traverse the VPN tunnel and then be proxied out to the Internet. It also consumes significant additional bandwidth on the corporate network.
The perceived security risk of split tunneling is not valid in a DirectAccess scenario, since the IPsec rules that enable DirectAccess require authentication by the client endpoint. If another endpoint attempts to route through the DirectAccess client, it will not be an authenticated source, and IPsec will prevent the connection. However, since some organizations have a requirement to force all traffic through the corporate proxy server so that it can be inspected, the DirectAccess Force Tunneling option provides this ability.
The Force Tunneling option was provided in Windows Server 2008 R2 DirectAccess, but required manual steps to enable it via group policy setting. Windows Server 2012 DirectAccess integrates the Force Tunneling option with the Setup Wizard and management UI to automate the required settings. Enabling the Force Tunneling option limits the DirectAccess client to using only the IP-HTTPS protocol for connectivity, and by default uses the DirectAccess server as the NAT64/DNS64 server to translate IPv6 resources to send to the IPv4 proxy server.
IP-HTTPS Interoperability and Performance Improvements
On certain networks, Internet firewall settings may prevent successful client connections using the 6to4 or Teredo IPv6 transition technologies. IP-HTTPS is an IPv6 transition technology introduced in Windows 7 to ensure that DirectAccess clients can connect to the corporate network even when all other IPv6 transition technologies fail. IP-HTTPS assigns a unique, globally routable IPv6 address to an IPv4 host, encapsulates the IPv6 packets within IPv4 for transmission over an HTTP tunnel, and routes IPv6 traffic between the host and other globally routable IPv6 nodes.
Windows Server 2012 provides several improvements to the implementation of IP-HTTPS. Changes to the technology allow IP-HTTPS clients to obtain proxy configuration information, and authenticate to an HTTP proxy if authentication is required. The Windows 7 requirement to deploy client certificates to each IP-HTTPS client has been removed.
IP-HTTPS works by creating an SSL/TLS connection between the client and server, then passing IP traffic across the connection. This data is encrypted by IPsec, which means that the data is encrypted twice, first by IPsec, and again by SSL. The result is poor performance and a negative user experience compared to the other IPv6 transition technologies 6to4 and Teredo, and limits the scalability of the DirectAccess server.
Windows Server 2012 DirectAccess includes several performance improvements for IP-HTTPS to increase scalability and reduce the overhead associated with this connectivity method. These optimizations include changes to batched send behavior and receive buffers, reduced lock contention, and the option to implement SSL with NULL encryption.
IP-HTTPS runs in a system context rather than a user context. This context can cause connection issues. For example, if a DirectAccess client computer is located in the network of a partner company that uses a proxy for Internet access, and WPAD auto detection is not used, the user must manually configure proxy settings in order to access the Internet. These settings are configured in Internet Explorer on a per user basis, and cannot be retrieved in an intuitive way on behalf of IP-HTTPS. In addition, if the proxy requires authentication, the client provides credentials for Internet access, but IP-HTTPS will not provide the credentials required to authenticate to DirectAccess. In Windows Server 2012, a new feature solves these issues. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD and IP-HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server.
When configuring IP-HTTPS in DirectAccess, you can use a certificate issued by a certification authority (CA), or you can specify that DirectAccess should automatically generate a self-signed certificate. A self-signed certificate is useful if you do not want to deploy a PKI.
DirectAccess clients establish connectivity to the corporate intranet whenever an Internet connection is available, even if there is no user logged in. This allows IT administrators to manage remote machines for patching and compliance enforcement even when they are not in the office. Some customers see this as the primary benefit to DirectAccess, and choose to keep their existing remote access solution in place for user connectivity, while using DirectAccess just for remote management.
Windows Server 2008 R2 DirectAccess does not provide an automated method to limit the deployment to manage-out only, and administrators must manually edit the policies created by the setup wizard. Windows Server 2012 DirectAccess provides support for a manage-out only configuration through a deployment wizard option that limits the creation of policies to only those needed for remote management of client computers. In this deployment, user level configuration options such as force tunneling, NAP integration, and two-factor authentication are not available.
DirectAccess servers can be deployed in multiple sites to increase capacity and provide more efficient access to the nearest entry point for intranet resources. This works well if clients remain in their respective sites and do not need to travel to different sites within the enterprise. However, setting up multisite DirectAccess requires careful planning and design if clients will roam between sites, to ensure that they connect through DirectAccess servers via the most efficient route.
There are many challenges to consider in a multisite environment, such as making sure the client locates the closest IP-HTTPS server, Teredo server, DNS server, and Domain Controller. Windows Server 2012 DirectAccess provides a solution that allows for deployment of multiple DirectAccess entry points across geographic locations, and allows clients regardless of their physical location to access resources within corpnet in an efficient manner.
Windows Server 2012 Remote Access servers can be configured in a multisite deployment that allows remote users in dispersed geographical locations to connect to the multisite entry point closest to them. For client computers running Windows Server 2012, entry points can be assigned automatically, or selected manually by the client. For Windows 7 client computers, entry points can be allocated statically. Traffic across the multisite deployment can be distributed and balanced with an external global load balancer.
Server Core is a minimal server installation option designed to reduce disk space, servicing, and management requirements, and decrease the operating system attack surface. The Server Core system does not support a Graphical User Interface, and administrators must use command line or remote management tools to accomplish all necessary configuration tasks.
A Server Core installation supports only a limited subset of the features available on a full installation of Windows Server, and currently does not include support for the DirectAccess feature or the Remote Access server role. A Windows Server 2012 Server Core installation includes support for the unified server role for both DirectAccess and RRAS.
The new Remote Access server role has complete Windows PowerShell support in Windows Server 2012 that may be used for installation, configuration and monitoring. The Remote Access server role can also be configured through remote server management.
DirectAccess in Windows Server 2008 R2 lacks a complete scripting and command line interface for configuration options. Windows Server 2012 provides full Windows PowerShell support for the setup, configuration, management, monitoring and troubleshooting of the Remote Access Server Role.
User and Server Health Monitoring
Monitoring and diagnostics capabilities for both RRAS server and DirectAccess are limited in Windows Server 2008 R2. For DirectAccess, the monitoring capabilities only include basic health monitoring of the DirectAccess and its components. The monitoring data and statistics available are of little significance or relevance to administrators.
User and server health monitoring introduced in Windows Server 2012 allows the administrator to understand the behavior of the DirectAccess clients and connections. The monitoring console is used to keep track of the load on the DirectAccess server, user activity, and current resource usage. The administrator uses this information to identify potentially undesirable or inappropriate usage activities. Diagnostic tracing can be enabled from the monitoring console as well.
User Monitoring
Administrators of remote access solutions require the ability to monitor not only which users are connected, but also which resources they are accessing. If users complain that a particular server or file share is inaccessible while remote, the administrator currently has no way to determine if other users are successfully accessing the resource from the remote access console. Multiple tools and applications are typically needed to troubleshoot issues such as particular users consuming excessive bandwidth.
The Dashboard is accessed from the new Remote Access server management console by selecting the Dashboard tab in the navigation pane. The dashboard displays overall health status and remote client activity and status. The administrator can also view quick reports directly from the dashboard.
The Monitoring Dashboard shows a summary of remote client connectivity status for the following items. The information is generated from the relevant Performance Monitor counters and accounting data.
- Total number of active remote clients connected – includes both DirectAccess and VPN remote clients
- Total number of active DirectAccess clients connected – only the total number of clients connected using DirectAccess
- Total number of active VPN clients connected – only the total number of clients connected using VPN
- Total unique users connected – includes both DirectAccess and VPN users, based on the active connections
- Total number of cumulative sessions – the total number of connections serviced by the Remote Access Server since the last server restart
- Maximum number of remote clients connected – the maximum concurrent remote users connected to the Remote Access Server since the last server restart
- Total data transferred – the total inbound and outbound traffic from the Remote Access Server for both DirectAccess and VPN since the last server restart
- Inbound traffic – Total bytes/traffic into the remote access server/gateway
- Outbound traffic – Total bytes/traffic out of the remote access server/gateway
In a cluster deployment, the Remote Client Activity and Status summary on the Remote Access Dashboard displays total values for all of the cluster nodes.
Administrators can see a list of all remote users currently connected, and can display a listing of all resources being accessed by clicking on a particular remote user. Administrators can display remote user statistics by selecting the Remote Client Status link in the Remote Access Management Console. The user statistics can be filtered based on criteria selections.
This feature allows administrators to manage and monitor the status of remote access deployments from a centralized monitoring console. The feature alerts administrators whenever an issue requiring attention is detected. The interface displays detailed diagnostic information with steps to provide resolution.
The Dashboard node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components.
The Server Operations Status node of the console tree shows the status of the Remote Access Server, including the status of remote access infrastructure and related components. By clicking on a particular component, administrators can see the state, change history, and monitoring details for that component.
If remote access servers are deployed in a cluster or multisite deployment, all servers in the cluster or multisite deployment are evaluated asynchronously, and are listed with their overall status. Administrators can scroll through the list of servers and expand or collapse the view to display DirectAccess and VPN server components.
The Remote Access components with status monitors displayed in the Server Operations Status pane are listed below.
- 6to4
- DNS
- DNS64
- Domain controller
- IP-HTTPS
- IPsec
- ISATAP
- Kerberos
- Management Servers
- NAT64
- Network Adapters
- Network Location Server
- Network Security (IPsec DoSP)
- Services
- Teredo
- Load Balancing
- VPN addressing
- VPN connectivity
Troubleshooting remote access connectivity failures for both RRAS and DirectAccess can be very complex due to the limited logging capabilities currently provided. Administrators typically require Network Monitor captures and RRAS tracing for troubleshooting, since Event Viewer logs are not very useful or prescriptive.
Windows Server 2012 provides the following diagnostic feature improvements for remote access troubleshooting.
- Detailed event logging for DirectAccess
Administrators can use improved event logging to identify problems and perform capacity and performance analysis. The event logs are standardized to ensure a consistent experience with other networking components. - Tracing and Packet Capture
Integrated tracing makes it easy for administrators to gather trace logs and network packet captures with a single click. Both tracing with packet capture and log correlation are done as part of a single process when the administrator clicks the Start tracing task in the Tasks pane. - Log Correlation
This feature provides automated collection and correlation of logs for different DirectAccess components with a single click, leveraging the Unified Tracing feature of Windows. The events gathered from different components are consolidated into a single file through correlation of Activity IDs. Activity IDs are GUIDs that identify a particular task or action. When a component logs an event, it associates an Activity ID with the event. The component then passes either this ID or a transfer event mapped to the ID to the component that performs the next task in the scenario, which associates its activity ID to log events. When analyzing the resulting trace file, the relationship between the various components relevant to a scenario can be reconstructed. - Enabling/Viewing Logs
Logging can be enabled from the Tasks pane of the Monitoring Dashboard, or from the command line, which also controls logging levels, keywords and filters. The resultant Unified Tracing ETL files generated can be read and viewed using Network Monitor.
A Windows Server 2012 remote access server can leverage an existing RADIUS server deployment or Windows Internal Database (WID) for accounting purposes. The NPS accounting store only contains user statistics, and server statistics and configuration changes are not stored in the remote accounting store. Information and historical data for load and server status are available through system Performance Monitor counters, and are stored in the WID accounting store. Whenever any connection is received or disconnected on the remote access server, all the remote user statistics (including the endpoints accessed) is saved in the accounting store as one user session. This allows session details to later be accessed for reporting and auditing purposes.
The accounting and reporting functionality provided in the Remote Access Server Role includes the ability to measure specific metrics. Available metrics include the number of users connected to a particular DirectAccess server, access status, and total bytes transferred. Administrators can create custom reports to identify traffic and usage patterns, including a history of these patterns.
DirectAccess and RRAS reporting capabilities enable administrators to generate rich usage reports on various user and server statistics such as remote user statistics, server availability and load. The inbox accounting store is leveraged to generate the usage report. Inbox accounting to a local WID database must be enabled in order to generate usage reports. NPS/RADIUS accounting is not used for generating reports.
The usage report provides a display of usage history including which users established remote connections, what resources they accessed, the total number of unique users, and maximum server load generated. The administrator can select a specific timeframe from which to generate the data.
Site-to-site IKEv2 IPsec tunnel mode VPN
Cross Premise Connectivity is a Windows Server 2012 feature that provides the network connectivity to enable service hosting providers to migrate their applications and infrastructure to the cloud. This feature includes a site-to site Internet Key Exchange version 2 (IKEv2) tunnel mode VPN connectivity solution and management interface. Windows Server 2008 R2 introduced IKEv2 support in RRAS for VPN connections. An IKEv2 VPN provides resilience to the VPN client when the client moves from one network to another or when it switches from a wireless to a wired connection. The use of IKEv2 and IPsec allows support for strong authentication and encryption methods. Windows Server 2012 RRAS provides added feature enhancements to enable IKEv2 for site-to-site VPN connections.