Archives de catégorie : DirectAccess

DirectAccess now supported in Azure virtual machines

Note : This post was updated on 11 of november 2016 due to recent change : DirectAccess No Longer Supported in Microsoft Azure

I was expecting this news for a while. Until a few days, DirectAccess was considered as unsupported scenario in Azure according to KB2721672. On the 14th of July this year, this KB was updated. The Remote Access feature is not longer listed as unsupported and appear in the supported features list But the DirectAccess Feature remain an unsupported scenario.

clip_image001

 

Hosting a DirectAccess infrastructure in Azure introduce a new way to build IT. Everyday that pass, the need to a local IT infrastructure is reducing. Soon, we could consider building a complete IT infrastructure hosted in Azure and connect computers to it using DirectAccess.

Dear, I have other wishes about DirectAccess :

  • ARM template to build a DirectAccess infrastructure in Azure (using a certificate located in Azure Keyvault of course)
  • Having DirectAccess as a VPN gateway scenario choice

 

Thank you for the news Richard and for the update.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 6

After enabling the IPsec logging on our internal server we will have new security events logged on this server. When VIP user logged on a DirectAccess client located on Internet try to access sensitive data, we will see that in the Windows Firewall with Advanced Security console.

clip_image001

It’s our new IPsec Tunnel initiated from our DirectAccess client. In the security event log we will found events like this one, proving computer authentication:

clip_image002

And also user authentication.

clip_image003

Bonus, what would happened if we change the security group with something like « NT AUTHORITY\Organization Certificate » as filtering security group as illustrated bellow:

clip_image004

My VIP will require to logon with his smartcard to initialize IPSEC tunnel with the internal server, not because required certificate is on the smartcard but because when we log with a smartcard, we are automatically member of this group.

clip_image005

When user see this message on DirectAccess client-side, we have the following event on our internal server

clip_image006

So my VIP need his smartcard.

clip_image007

That’s the end of this blog-post series. Hope you enjoyed. It’s time for me to go back to clouds.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 5

Connection Security Rules are now in place on both sides. We just need some additional magic trick. First, I recommand to excempt ICMP messages from IPsec tunnels that end on our internal server. It’s for debuging purpose. It’s configurable at the Windows Firewall with advanced security, in the IPsec Settings tags.

clip_image001

 

Remember, it’s just for debugging purpose and helped me a lot to understand what happened under the hood. Last configuration, we need to configure the authorization model. It’s not at the Connection Security Rule level but at the Windows Firewall with Advanced Security node, in the IPsec settings tab and my recommendation would be to do not configure this setting in a GPO but directly on each server. With this approach, our server-side GPO remain generic.

clip_image002

 

Now it’s time for the big magic trick. You can test now if you want, you are not able to access internal server with sensitive data. It took me a long time (and a lot of aspirin) to understand why until I noticed this fucking checkbox in the infrastructure IPsec tunnel configuration on DirectAccess gateway.

clip_image003

 

In our scenario, our new Connection Security Rule is never used even if destination match because another Connection Security Rule is already applicable. That’s our case. On the DirectAccess gateway, default configuration includes two Connection Security Rules:

  • DirectAccess Policy-ClientToInfra (Infrastructure IPsec tunnel)
  • DirectAccess Policy-ClientToCorp (User IPsec tunnel)

Problem is located in this tunnel. If we have a look at tunnel endpoints, it include the 2002:836b:a:1::/64 prefix.

clip_image004

 

And my internal IPv6 destination is 2002:836B:a:1:0:5efe:192.168.1.101. It means that for this destination, traffic will go through the IPsec infrastructure tunnel. We have the same problem on the DirectAccess client-side. To solve this problem, we need to reconfigure default configuration for the DirectAccess Policy-ClientToCorp specify that network traffic that matches another IPsec connection security rule does not go through the IPsec tunnel.

That’s a big problem. If we use GPMC to reconfigure the required parameters (in both GPO), we risk to things:

 

Because I spend now most of my time in clouds, I wrote a small PowerShell script that perform the following actions:

  1. Check for execution prerequisites (GPMC, RemoteAccess, …)
  2. Search a writable domain controller (PDCE in fact)
  3. Perform a Backup of Server-side and client-side GPO
  4. Create a GPOSession object to update required parameters in both GPO
  5. Update the required parameter in the GPOSession object
  6. Update GPO with the GPOSession

 

PowerShell script is available here.

Here an example of the script output with the STATE parameter. Script found DirectAccess GPOs and checked we have the default configuration.

clip_image005

And now the same script with the ENABLE parameter that enable our required parameter in both GPOs.

clip_image006

At this point, you are no longer supported by Microsoft as you just customized GPO configuration of DirectAccess. That’s why script alse have the DISABLE parameter to revert to initial configuration.

clip_image007

 

In a standard DirectAccess infrastructure, all IPsec tunnels terminate at the DirectAccess Gateway witch have an IPsec DOS protection layer. As our additional IPsec tunnel won’t terminate on the DirectAccess Gateway, we won’t be able to use extra security layer. If I have a look at Server-side GPO, now the checkbox is enabled on our DirectAccess gateway.

clip_image008

 

And on the DirectAccess client-side GPO configuration, it’s the same.

clip_image009

 

Now our new IPsec tunnel is operational. We will see that in the next blog post.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 4

If we have a client-side configuration of the tunnel, we need a remote-side. This configuration will be applied by GPO on our internal server with sensitive data.

clip_image001

It’s logic, we choose the oposite choice on remote side of the IPSEC tunnel.

clip_image002

Our internal Server will be the remote endpoint of the IPSEC tunnel. We must enforce authentication for inbound and ountbound communications.

clip_image003

If we require authentication we must also enforce authorization on the local tunnel endpoint. But wait a minute where is the IPv6 address of our internal server? You can include it yes. But if you do so, you will generate as much as GPO as internal server to secure. With my approach, we generate a generic GPO, applicable to a large number of internal server. You AD admin team will appreciate.

clip_image004

Because we are requesting authentication for inbound and outbound communications, we must have the same configuration on both sides of the IPsec tunnel. Our authentication will be composed of primary and a secondary authentication method.

clip_image005

It’s exactly the same configuration as on DirectAccess client-side. That’s my choice, to be able to filter on a computer or user criteria.

clip_image006

But one important point here. This configuration will only work if you have a certificate delivered to your internal server and this certificate must be delivered by the same Public Key infrastructure as the one used for DirectAccess clients. This new Connection Security Rule will only apply on Domain Windows Firewall profile.

clip_image007

This Connection Security rule will be name « SECURED ZONE ».

clip_image008

Now it’s time for a magic trick. Our new Connection Security Rule apply to all domain traffic, including both internal and external access (IE DirectAccess). Problem, I do not want to enforce IPSEC for internal access (not yet). That’s why I need an exception to manage this case. We will introduce a new Connection Security Rule on GPO targeting our server with sensitive data. This will be an Authentication exception.

clip_image009

This exception will cover my complete IPv4 internal IP range. If you already have IPv6 capable systems on your internal network that need to communicate with our secured server, I would recommend you to add these IP to the list, unless you want to establish a secure communication with IPsec tunnels.

clip_image010

This exception will only apply to the Domain Windows Firewall profile.

clip_image011

This Connection Security Rule will be named « LAN EXCEPTIONS ».

clip_image012

OK, prerequisites are in place. It’s time for the big magic trick. Why? Because at this stage, it does not work. That’s the most interesting part, unless you want to send your time hitting your head against the walls to find the solution.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 3

Let the fun begin and create new IPsec tunnel. We will be starting with the client-side. We will introduce this GPO configuration on a dedicated GPO applicable to our DirectAccess clients. Remember, it’s not supported to customize DirectAccess configuration (We will break that rule later, …).

clip_image001

We are in a client-to-gateway configuration and we to need to ensure that if network traffic match this rule we use this tunnel.

clip_image002

During IPsec Initialization, DirectAccess client send authentication information. These information will be required for filtering purpose on the DirectAccess gateway side.

clip_image003

On client-side of the tunnel our new tunnel must only be used if we try to access our server with sensitive information. IPv6 address of this server will be configured as a remote endpoint.

clip_image004

IPsec authentication is a negotiation process (Show me who you are and show me who are you).

I wanted to provide the same security level as default DirectAccess IPsec tunnels, so I choose to use a primary and a secondary authentications methods.

clip_image005

My choice, using Computer certificate plus Computer Kerberos ticket as primary authentication methods and only user Kerberos ticket for secondary authentication methods. With this choice I will be able to filter access based on computer account group membership or user account membership.

clip_image006

At last, this new IPSEC tunnel must only apply on DirectAccess scenarios, so limited to private and public firewall profiles.

clip_image007

This Connection Security rule will be name « SECURED ZONE ».

clip_image008

That’s all on DirectAccess client-side. On DirectAccess gateway-side we will follow the same logic. So until now it’s not so complicated. Not yet. Don’t worry headache is on the way.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 2

To make it clear. Every time we deployed DirectAccess, we always skip the optional configuration part. I’m talking about this screen.

clip_image001

 

First reason, application server must be IPv6 ready. IPv6 ready can be ISATAP or native IPv6. That’s the first challenge. Because it’s only a demonstration, environment built for this blog post will, I will be using ISATAP, not native IPv6 for internal network. I wanted to make the content more digest. In real production environment ISATAP would not be supported for multiple reasons but the same approach can be used.

So my first step will be to configure my internal server with sensitive datas as ISATAP client of my ISATAP router. By Default ISATAP DNS record is blocked for name resolution because it’s on the DNS Query Block List. Not a problem we will be configuring ISATAP client locally with a single Powershell command : Set-NetIsatapConfiguration -Router srv.directaccesslab.lan -PolicyStore PersistentStore :

clip_image002

 

Now in DNS I have two records for this server.

clip_image003

 

But on my DirectAccess client, name resolution does not provide the expected result. It’s not because of ISATAP, we would have the same problem with native IPv6. Where does this address come from?

clip_image004

 

If you are a DirectAccess expert, you immediatly recognize a NAT64 prefix and you know why if you are familiar to this old blog post of mine : DNS64 behavior change in Windows Server 2012. By default, the DirectAccess configuration no longer resolve IPv6 host names since Windows Server 2012. If we take a closer look at the DNS64 configuration, we will discover that in default configuration, only A records are resolved.

clip_image005

 

To enforce IPv6 DNS name resolution, we will reconfigure DNS64 configuration with the following command: Set-NetDNSTransitionConfiguration -OnlySendAQuery $false

clip_image006

 

After DNS64 reconfiguration, name resolution is better on DirectAccess client-side.

clip_image007

 

Even if DNS64 provide IPv6 addressing, it’s not IPv6 traffic than reach the internal Server. NAT64 act as a translation device between IPv6 on the ourtide and IPv4 on the internal network. Would be difficult to establish an IPsec tunnel in such situation.

Now we have IPv6 addressing from end to end, we can discuss about establishing new IPSEC tunnels. By default DirectAccess configuration generate two types of tunnels :

  • Infrastructure tunnel (IPSEC Tunnel mode)
  • User tunnel (IPSEC Tunnel mode)

If we use the approach proposed by Tom Shinder, this lead to a new IPSEC Transport. Too complicated to secure and not challenging enought. I already covered such scenario in this blog post series

So we will introduce a new IPsec Tunnel, starting in next post.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 1

It’s been a while since i published content on DirectAccess, that’s also why this post is in English. As I spend more and more of my time with Cloud Business (for Blue team), I do not spend much more time on DirectAccess. These days I had time to explore my OneNote on DirectAccess and rediscovered a subject we are not so much to deal with: The end-to end-mode of DirectAccess, the Myth of end to end security. That will be the subject of this blob post-series. Do you remember if the early days of DirectAccess, we used to present such diagram?

clip_image001

In such scenario a DirectAccess infrastructure could be configured to offer an extra security layer for VIP trying to access sensitive data. VIP would be invited to use his smartcard to authenticate to initialize the application tunnel. For many people, it was a myth. In fact not really some smart people published some content about this : A Short Introduction to UAG DirectAccess End to End Security. It was very helpful to be to start thinking. It was UAG based but we are able to do it with Windows 2012 R2, nothing changed.

clip_image002

But one point is missing in Tom Shinder article (Sorry). How do we filter connections and add our extra security layer (enforce smartcard authentication to access servers with sensitive data? That the pain point. In fact, it’s possible with Tom Shinder approach but complex. Why? Because it relies on IPsec transports, not IPsec tunnels. This means that we must secure each incoming protocol at the Windows Firewall level of our servers to enforce a specific option

clip_image003

It’s possible from a technical point of view but complex to setup and maintain. Would it be possible to secure all communications? Yes, but it would rely on IPsec tunnels, not IPsec Transports. This is a hudge change that require to customize default DirectAccess configuration, what is not supported by Microsoft.

It will be a long path to achieve this objective, so multiple blogs posts will be needed:

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

MS-OTPCE – One-Time Password Certificate Enrollment Protocol

I had many questions these days about DirectAccess OTP authentication mechanism. I already published multiple blog posts on the subject:

All these blog post are useful to understand and troubleshoot DirectAccess OTP scenario but on resource was missing : the Windows protocol definition for [MS-OTPCE]. Now you have all information to clearly understand the authentication process.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

RIP Network Access Protection, miss you

Windows 10 just been released a month ago. Because I do not have enough time to actively participate to the insider phase, I did not yet tested with DirectAccess. Off course, it’s working. But there are a few changes some good, one bad. Let’s start with the bad one. My old friend Network Access Protection passed away.

If you have a look at the DirectAccess Unsupported Configurations, Network Access Protection was deprecated since Windows Server 2012 R2.

clip_image001

 

It was still included in Windows 7 / 8.1, but in Windows Server 2012 R2, it was the last Microsoft operating system that included Network Access Protection. If you have a look at your Windows 10 computer (Enterprise SKU off course), you will discover that’s true, the Network Access Control agent no longer exists.

clip_image002

 

And it’s the same on DirectAccess gateway. Even if we are on Technical Preview Stage, NAP integration with DirectAccess was removed. The Network Access Protection Checkbox was removed.

clip_image003

 

Why Microsoft removed Network Access Protection?

  • It was an old approach

Do you have an idea when NAP was introduced? With Windows Vista and Windows XP SP3. So more than a decade. During this decade many things changed. Something called Cloud emerged.

  • It was designed to protect LAN

Network Access Protection was designed du protect corporate networks from rogue computers and unsecured computers. At cloud era we need compliance enforcement anywhere.

  • Compliance definition changed

With NAP, compliance expression was limited to five criteria configured to true of false. Developing complex compliances policy was not easy. Even if we were able to extend with Desired Configuration Manager from SCCM, we were limited to Windows Devices

  • It was limited to Windows devices

At Vista time, company had very limited choices for devices. Vista introduced the first generation of tablets. Today we are at the BYOD era. Company must be able to manage any device, from Microsoft to IOS and even Android. Yes some partners were able to manage MACOS & Linux, but it’s not built-in.

  • It was complex to setup

That was the pain point. NAP was a combination of multiples technologies. If perfectly assembled, it was working like a charm.

 

How can we manage compliance with Windows 10 devices?

  • At the cloud era, response is simple : Windows Intune. We cannot rely on MDM capabilities provided by Office 365 because it does not include Windows devices
  • With Windows Intune we have the Extensible Windows PC Devices Configuration Settings that allow to perform WMI check and even registry key checks. We were not able to achieve this with Network Access Protection without DCM.
  • We can use App Compliance policies to restrict access to application (was very difficult to achieve with Network Access Protection)
  • We can use Selective Wipe to managed stolen DirectAccess enabled devices

Yes Windows Intune is not built-in Windows 10 Operating system generation, but things changed so much since introduction of Windows Vista.

RIP Network Access Protection, miss you.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Monitoring DirectAccess with Kemp

Introduction

DirectAccess is a wonderful remote access solution highly appreciated by end-users, happy they are to do not have to understand how it works, it just work. On the other side, we have the network team that is not really happy when they discover that monitoring DirectAccess can become complicated, especially for HLB deployments.

From an HLB point of view, DirectAccess gateways are only HTTPS endpoints. If they respond with an HTTP 200 response code, it means that it’s up and running. In reality it’s much more complicated. DirectAccess rely on multiple components. If a single one come to be unhealthy, DirectAccess is no longer able to operate properly. In many deployments, customers of mine chosen to deploy DirectAccess in HLB scenario such as F5 or Kemp. Those appliances are able to check DirectAccess gateways availability by checking IPHTTPS endpoint. Not easy to monitor.

How to monitor DirectAccess health?

It’s a good question. Microsoft provide the Remote Access Management console, some Powershell Commandlets and a Management Pack. From HLB solution vendor hey only have HTTP response. It appear to be complicated because many network teams consider that they have to discover information by their own way.

It’s time to consider another approach. If HLB solution cannot evaluate the health status of a DirectAccess gateway maybe DirectAccess gateway can provide this information to the HLB solution. Have a look at Exchange 2013 Managed Availability. Exchange 2013 generate probe pages to be used by load-balancer solution. If they can reach the probe page, status is OK. It’s a very interesting approach.

Let’s start see how we can develop the same approach with DirectAccess. If we have a look at the Get-RemoteAccessHealth Powershell commandlet, we got almost all we need. In example bellow, I just filtered relevant components to be monitored :

Get-RemoteAccessHealth -Verbose | Where {$_.HealthState -ne « Disabled »} | Format-Table -Property Component, HealthState – AutoSize

clip_image001

 

That was only the beginning. While writing this article, a valuable MVP colleague pointed out that we don’t need to consider Network Location Server availability because if it’s not available, it does not disrupt service offered to end-users located outside company building (it’s another problem for users located on corporate network). So we will exclude this component from the tests. Here is the test we will be using to monitor DirectAccess :

Get-RemoteAccessHealth -Verbose | Where {($_.HealthState -ne « Disabled ») -And ($_.Component -Ne « Network Location Server ») -And ($_.Component -Ne « Server »)}

clip_image002

 

Note : Server was excluded from the list because it does not provide a relevant information for monitoring / troubleshooting.

Once we have relevant monitoring information, next challenge is to provide this information in a comprehensive form for a HLB solution. It’s too complicated to write rule to parse this content, that’s why I was considering the Managed Availability feature of Exchange 2013. As I’m not a dev-guy, I know I could not develop a solution like this. My approach was a little bit more basic :

  • Status is OK : Create a probe page to be monitored by the HLB solution
  • Status is not OK : Delete the probe page to be used by the HLB solution

This approach worked, but it was not as elegant as the Managed Availability feature of Exchange 2013. After some discussions with a colleague of mine, he pointed out the availability of a Powershell commandlet for Kemp load balancers. While reading the Kemp documentation, I discovered how easy it was to query and change configuration in Kemp LoadMaster appliance with just some PowerShell commands. If Kemp cannot consume monitoring information my DirectAccess gateway produce, maybe just more simple to change Kemp load balancer configuration.

 

The Kemp Approach

Kemp provide a pretty good Deployment guide for DirectAccess. I would like to thanks Richard Hicks, valuable MVP working like me on DirectAccess for this excellent contribution. So it was very easy to build an HLB lab in less than two hours. Diagram bellow only focus on high availability for DirectAccess deployment, you can also use Kemp solution to provide high availability for the Network Location Server.

clip_image003

 

When we setup DirectAccess in HLB scenario, up to height DirectAccess gateway will share a common configuration and some network information :

  • A virtual Address for the external interface managed by the External load balancer
  • A virtual Address for the internal interface managed by the Internal Load balancer

In Kemp, load balancing is managed with virtual services. That’s the object I will be looking for in my configuration. But first I need to configure the Web Administrative Access in Kemp as illustrated bellow to enable Kemp API access from the Internal network interface.

clip_image004

 

Now we can start using PowerShell to authenticate against the Kemp appliance with the Initialize-LoadBalancer Powershell command. We just need to build a secure string for the password. Once authenticated, we can test if communication is established with a Test-ServerConnection command.

$KempAPI = 192.168.2.115″

$KempPort = 443

$KempAdmin = « bal »

$KempPassword = « Password123 »

$SecureString = ConvertTo-SecureString -String $KempPassword -AsPlainText -Force

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $KempAdmin, $SecureString

Initialize-LoadBalancer -Address $KempAPI, LBPort $KempPort -Credential $credential

Test-ServerConnection -ComputerName $KempApi -Port $KempPort

clip_image005

 

Note : Watch-out, account is case sensitive!!

It’s time to explore virtual services with the Get-VirtualService Powershell Command :

$VirtualServiceName = « DirectAccess-IPHTTPS »

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

clip_image006

 

We have here some valuable piece of information. First, we know that external VIP is running and directing HTTPS network traffic to some Real Servers. In my environment, I have two DirectAccess gateway configured in a single HLB configuration. So it’s logic to have two real servers behind the external VIP. Let’s have more details about real servers by exploring the Virtual Service Object :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

clip_image007

 

We just need to be more precise, what is the status of the Real server linked to a specific DirectAccess gateway. We just need to know the external IPv4 address of our DirectAccess gateway. Too easy :

$InternetInterfaceName = (Get-DaServer).InternetInterface

$InternetIPAddress = ((Get-NetIPConfiguration -InterfaceAlias $InternetInterfaceName).IPv4Address).IpAddress

$InternetIPAddress

clip_image008

 
Now the magic trick

We know the status of our DirectAccess gateway, we know how to query the status of the external VIP and related real servers. Now we just need to be able to change the status of the real server linked to our DirectAccess gateway. In case bellow, I will be considering that my second gateway is no longer able to service end-users. I will be using the Disable-RealServer Powershell Command to disable the linked real server :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

Disable-RealServer -IpAddress $InternetIpAddress

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

clip_image009

 

Related real service is now disabled on Kemp external load balancer.

 

Envision the big picture

Before starting developing the big thing, here are the guideline I used to develop my script :

  • Each DirectAccess gateway will be responsible to evaluate its own status (So script will be running on all DirectAccess gateway composing my HLB deployment)

  • Each DirectAccess gateway will be updating only linked real server (We’ve just seen how to get it)

  • Each gateway must manage a « maintenance flag » in order to close service (for patch management for example)

  • All activity must be logged in event logs in order to keep trace of information in monitoring solution such as SCOM

  • Keep the script as simple as possible

  • Script will be relying on Powershell wrapper provided by Kemp

Script is available at this location. It was designed to run as scheduled task on each DirectAccess node involved in an HLB configuration. Script accept the following parameters :

  • KempAPI : Mandatory parameter that must contain name or IP address of the Kemp LoadMaster with Web Administrative Access enabled

  • KempPort : Not mandatory parameter, default value is 443

  • KempAdmin : Mandatory parameter that must contain account with administrative access to Kemp LoadMaster. Watch-out, Kemp is case sensitive for account!!

  • KempPassword : Mandatory parameter that must contain the password to be used with the KempAdmin parameter

  • VirtualServiceName : Mandatory parameter that must contain name of the virtual service for the External VIP of DirectAccess

Let’s see some situations. Script detect that DirectAccess node is not healthy and reconfigure real server status to do not forward network traffic to that failing node.

clip_image010

 

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now disabled.

clip_image011

 

When problem was fixed, script detected that DirectAccess node is now healthy, Real server status for 192.168.2.211 is updated to forward network traffic to restored node.

clip_image012

 

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now Enabled.

clip_image013

 

So it’s not so complicated to monitor DirectAccess after all.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)