Archives de catégorie : Kemp

Configurer sa première Appliance Kemp dans Azure

J’avais déjà utilisé Kemp par le passé pour DirectAccess : Monitoring DirectAccess with Kemp. Vu que sous certains aspects ça ressemble beaucoup à ce que j’ai connu avec du TMG ou de l’UAG, j’ai décidé de passer un peu de temps avec. Vu que je passe beaucoup de temps dans Azure, cela impliquait de pouvoir monter des labs de manière industrielle. Tout de suite on pense à développer un template ARM. Sur le principe, je suis d’accord, cependant, c’est développer beaucoup d’énergie pour un sujet qui n’apportera pas beaucoup de gain. On ne déploie pas autant de machines virtuelles que d’Appliances virtuelles Kemp.

C’est pour cette raison que j’ai décidé d’explorer la création d’une Appliance virtuelle Kemp en PowerShell. Sur le papier, cela ressemble beaucoup à une machine virtuelle pour un quelconque Linux. Pourtant, il y a quelques subtilités à prendre en compte :

  • Kemp est un fournisseur du MarketPlace, ça change un peu les choses pour la déclaration de l’image source à utiliser (notion de plan)
  • L’Appliance virtuelle aura deux interfaces réseau (les templates mis à disposition sont tous mono-carte)
  • Un peu de sécurité (Network Security Group) est nécessaire pour faire les choses dans les règles de l’art

 

Pour les prérequis, je considère que les éléments existent préalablement :

  • Resource Group
  • Storage Account
  • Virtual Network avec ses deux Subnets

 

Mon objectif est de déployer un Load Balancer Kemp avec deux interface réseau. Ci-dessous les prérequis techniques de mon déploiement :

$LocationIPR = ‘<Azure Region Name>’

$ResourceGN = ‘<Resource Group Name>’

$VnetName = ‘<Virtual Network Name>’

$subscriptionname = ‘<Subscription Name>’

$StorageAccountName = « <storage account name> »

$storageAccountResourceGroupName = « <Storage Account Resource Group> »

$FWName = « <Virtual Machine Name> »

$instanceSize = « Standard_D3_v2 »

$subnetFrontName = « Front »

$frontIP = « 10.1.0.4 »

$subnetBackName = « Back »

$backIP = « 10.2.0.4 »

$reservedIPName = « FrontReservedIP »

$publicNICName = $FWName + « _ » +$subnetFrontName + « NIC »

$privateNICName = $FWName + « _ » + $subnetBackName + « NIC »

$FWPublicIPName = $FWName + « _ »+ « PublicIP »

$diskName = $FWName + « _OSDisk »;

clip_image001

Première subtilité Kemp, le nom du compte « root » de l’Appliance, ce sera « BAL ». On peut spécifier ce que l’on veut, ce sera toujours « BAL » pour le compte par défaut. On ne va donc pas le contrarier et générer un objet de type « SecureString » pour personnaliser le mot de passe initial.

$FWAdminUser = « bal »

$FWPassword = « LeMotDePasseIlaChangé! »

$SecurePassword = ConvertTo-SecureString -String $FWPassword -AsPlainText -Force

$FWSecureCredential = New-Object -TypeName « System.Management.Automation.PSCredential » -ArgumentList $FWAdminUser, $SecurePassword

clip_image002

 

No-Comment, …

$cred = Get-Credential

Login-AzureRmAccount -Credential $cred -SubscriptionName $subscriptionname

clip_image003

 

La première étape, c’est d’identifier le fournisseur nommé « Kemp Technologies » dans la région qui nous intéresse : West Europe :

$publisher = « kemptech »

$publishername = Get-AzureRmVMImagePublisher -Location $LocationIPR | Where {$_.Publishername -eq $publisher}

clip_image004

 

Puis d’identifier la ou les offres proposées par ce fournisseur. Avec Kemp, nous avons deux offres. La solution Kemp 360 Central est une Appliance destinée à centraliser l’administration d’un ensemble d’Appliances Kemp, l’offre qui nous intéresse est donc « VLM-Azure ».

Get-AzureRmVMImageOffer -Location $LocationIPR -PublisherName $publishername.PublisherName

clip_image005

 

$Offer = « vlm-azure »

$ImageOffer = Get-AzureRmVMImageOffer -Location $LocationIPR -PublisherName $publishername.PublisherName | Where {$_.Offer -eq $Offer}

clip_image006

 

Prochaine étape, la SKU ou l’édition en français.

Get-AzureRmVMImageSku -Location $LocationIPR -PublisherName $publishername.PublisherName -Offer $ImageOffer.Offer

clip_image007

 

Celui qui va m’intéresser est l’édition « FreeLoadMaster », c’est pour du test :

$skuname = « freeloadmaster »

$sku = Get-AzureRmVMImageSku -Location $LocationIPR -PublisherName $publishername.PublisherName -Offer $ImageOffer.Offer | Where {$_.Skus -eq $skuname}

$sku

clip_image008

 

Le Marketplace propose toujours les trois dernières versions d’une solution. Il est donc logique de trouver cela :

Get-AzureRmVMImage -Location « West Europe » -PublisherName $publishername.PublisherName -Offer $offer -Skus $sku.skus

$image = Get-AzureRmVMImage -Location « West Europe » -PublisherName $publishername.PublisherName -Offer $offer -Skus $sku.skus | Select -Last 1

$image

clip_image009

 

Seconde subtilité, celle du Marketplace et la manière de référencer l’image à utiliser. Celle-ci vient du Marketplace Azure. Pour un déploiement automatisé, il nous faudra deux choses :

  • Définir la notion de plan (quelle ressource déployer)
  • Autoriser le déploiement automatique pour cette ressource

Pour la notion de plan cela se présente ainsi :

$vm1 = New-AzureRmVMConfig -VMName $FWName -VMSize $instanceSize

Set-AzureRMVMOperatingSystem -VM $vm1 -Linux -Credential $FWSecureCredential -ComputerName $FWName

Set-AzureRMVMSourceImage -VM $vm1 -PublisherName $image[0].PublisherName -Offer $image[0].Offer -Skus $image[0].Skus -Version $image[0].Version

$vm1.Plan = @{« name »= $sku.skus; « publisher »= $image.PublisherName; « product » = $image.Offer}

clip_image010

 

Note : Depuis la version 1.2.2 du module AzureRM, on dispose de la commande Set-AzureRmVMPlan.

Pour le second, cela se passera dans le portail, au niveau de la souscription. Nous avons un menu nommé « Programatic Deployment ». On remarque qu’il n’y a pas de menu pour ajouter / supprimer les fournisseurs du MarketPlace. Pour ajouter le fournisseur Kemp Technologies, j’ai dû réaliser un déploiement en utilisant le portail. Attention, le modèle d’autorisation ne considère pas que le fournisseur mais aussi la solution déployée.

clip_image011

Les bases sont posées. On revient maintenant sur du classique avec la déclaration du disque OS de notre future machine virtuelle.

$storageAccount = Get-AzureRmStorageAccount -ResourceGroupName $storageAccountResourceGroupName -Name $StorageAccountName

$osDiskURI = ($storageAccount.PrimaryEndpoints.Blob.ToString() + $FWName + « / » + $diskName + « .vhd »).ToLower()

Set-AzureRMVMOSDisk -VM $vm1 -Name $diskName -VhdUri $osDiskURI -CreateOption fromImage

$osDiskURI

clip_image012

Ma machine virtuelle devra avoir deux interfaces réseau, dont une avec une adresse IP publique et un nom DNS associé.

$vnet = Get-AzureRMVirtualNetwork -Name $VnetName -ResourceGroupName $ResourceGN

$subnetFront = Get-AzureRMVirtualNetworkSubnetConfig -Name $subnetFrontName -VirtualNetwork $vnet

$subnetBack = Get-AzureRMVirtualNetworkSubnetConfig -Name $subnetBackName -VirtualNetwork $vnet

$publicIP = New-AzureRMPublicIpAddress -name $FWPublicIPName -ResourceGroupName $ResourceGN -Location $LocationIPR -AllocationMethod Dynamic -domainNameLabel ($FWName.ToLower() + (Get-Random -Minimum 1 -Maximum 100))

$PublicIP

clip_image013

 

Déployer une machine virtuelle avec une adresse IP publique sans Network Security Group est criminel. Vu que ça coute pas grand-chose et que cela ne nécessite que quelques lignes de PowerShell, nous allons faire l’effort pour filtrer le trafic réseau entrant pour uniquement deux protocoles :

  • Le portail d’administration de l’Appliance (8443 en HTTPS)
  • Le port SSH d’administration de l’Appliance

 

$NSGrule1 = New-AzureRmNetworkSecurityRuleConfig -Name « KempWebConsole » -Description « Allow Kemp web console Access » -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 8443

$NSGrule2 = New-AzureRmNetworkSecurityRuleConfig -Name « KempSSHConsole » -Description « Allow Kemp SSH Access » -Access Allow -Protocol Tcp -Direction Inbound -Priority 101 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22

$NSG = New-AzureRmNetworkSecurityGroup -ResourceGroupName $ResourceGN -Location $LocationIPR -Name ($FWName.ToUpper() + « _NSG ») -SecurityRules $NSGrule1, $NSGrule2

$NSG

clip_image014

 

Nous avons maintenant tout ce qu’il nous faut pour créer la première interface réseau et l’associer à notre objet machine virtuelle en cours de construction :

$frontNIC = New-AzureRMNetworkInterface -Name $publicNICName -ResourceGroupName $ResourceGN -Location $LocationIPR -PrivateIpAddress $frontIP -SubnetId $subnetFront.Id -PublicIpAddressId $publicIP.Id

$frontNIC.NetworkSecurityGroup = $NSG

$frontNIC | Set-AzurermNetworkInterface

Add-AzureRMVMNetworkInterface -VM $vm1 -Id $frontNIC.id -Primary

clip_image015

Note : C’est à cette première interface réseau qu’a été associé notre Network Security Group. Une fois la configuration de notre Appliance Terminée, je recommande vivement de reconfigurer les règles pour limiter l’accès à ces protocoles.

Il y a un sujet que je n’aborde pas dans cet article, c’est comment notre Kemp va-t-il pouvoir porter des VIP? Jusqu’à il y a peu, l’utilisation des adresses IP publiques sur les machines virtuelles étaient limitées en deux points :

  • Seule l’interface réseau « primaire » d’une machine virtuelle peut disposer d’adresse IP publique
  • Une interface réseau « primaire » ne peut avoir qu’une seule adresse IP publique

Au moment où j’écris ce billet, ces limitations sont encore d’actualité mais de nouvelles fonctionnalités actuellement en Preview vont permettre d’oublier ces limitations : Step-by-Step: Setup Multiple Public IPs on a VM in Azure.

La démarche pour la seconde carte réseau est identique à deux subtilités près. La première est que cette seconde interface ne sera pas considérée comme « primaire » mais comme « secondaire » et qu’aucune adresse IP publique n’est associée à cette interface.

$backNIC = New-AzureRMNetworkInterface -Name $privateNICName -ResourceGroupName $ResourceGN -Location $LocationIPR -PrivateIpAddress $backIP -SubnetId $subnetBack.Id

Add-AzureRMVMNetworkInterface -VM $vm1 -Id $backNIC.id

clip_image016

Nous en arrivons à la fin. La construction de notre objet machine virtuelle est terminée. Il ne nous reste plus qu’à ordonner son déploiement avec une dernière commande PowerShell :

New-AzureRMVM -ResourceGroup $ResourceGN -VM $vm1 -Location $LocationIPR

clip_image017

 

Après quelques minutes de déploiement, on devrait être en mesure de joindre le portail d’administration de notre Appliance pour s’authentifier. Dans mon cas, il est accessible à l’URL suivante : . Lors de la première connexion authentifiée, on arrive immédiatement à la configuration de la licence. Munissez-vous de votre Kemp-ID pour réaliser l’activation en ligne et vous pourrez commencer à configurer votre Appliance virtuelle Kemp

clip_image018

 

Maintenant, quelques détails purement Kemp :

  • Ne cherchez pas à déployer une quelconque VM Extension dans la machine virtuelle, le Linux VMAgent ne s’installera pas
  • Ne cherchez pas à activer le mode Transparency dans la configuration vos virtual services.

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)