Archives de catégorie : Virtual Network Gateway

BGP dans Azure

Azure est un univers merveilleux. Le problème, c’est avant de pouvoir découvrir ses merveilles, il faut en revenir aux fondamentaux avec le premier d’entre eux : Le réseau. Sans lui pas de merveilles. Normalement, c’est une phase qui se passe à peu près bien dès lors que vos interlocuteurs réseau et sécurité sont de bonne composition. De temps en temps, il arrive que cette phase pose un challenge particulier. C’est le sujet de ce billet. Voilà ma situation de départ :

clip_image001

Côté expression de besoin, c’est assez simple : Permettre aux utilisateurs du siège d’accéder aux ressources (IaaS) de toutes les souscriptions en utilisant une future connexion qui pourrait être de type ExpressRoute (mais ce n’est pas obligatoire pour commencer). Histoire de corser le sujet, on a quelques contraintes :

  • Les souscriptions ne sont pas liées au même tenant Azure Active Directory (sinon c’est pas drôle)
  • Les souscriptions sont dans des régions Azure différentes
  • L’extension du modèle avec de nouvelles souscriptions doit être simple

Mon sujet c’est l’interconnexion des différents Virtual Networks et d’assurer le routage entre eux tout en gardant en tête que cela devra fonctionner lors de la mise en place de l’interconnexion avec les réseaux locaux composant le siège.

A première vue pour l’interconnexion des Virtual Networks, le VNet Peering, c’est mort. Les contraintes sont juste bloquantes (tout du moins à ce jour). La seule solution qui nous reste, c’est donc le VNET To VNET. Ça tombe bien car :

  • VNET to VNET est capable d’interconnecter des Virtual Networks dépendant de souscriptions différentes
  • VNET to VNET est capable d’interconnecter des Virtual Networks dans des régions Azure sans distinction

Ce qui était bien avec le VNET Peering, c’est qu’il s’occupait automatiquement du routage. Lors de la mise en œuvre, le réseau distant était déclaré automatiquement dans le routage. On peut le constater si on regarde les routes effectives pour une machines virtuelle comme dans l’exemple ci-dessous :

clip_image002

Remarque : A ce jour, le User-Defined Routing ne prend pas encore en charge le VNET Peering comme choix de Next Hop type. Faudra patienter de ce côté.

Avec VNET to VNET, nous allons devoir travailler un peu. Quand on pense routage dans Azure, on pense à la fonctionnalité Azure Route Table. Quand j’ai révisé le sujet des Azure Route Table, je suis tombé ce cet avertissement.

clip_image003

Pas de problème pour envoyer du trafic mais comment le traiter de l’autre côté? UDR (User-Defined Routing) ne s’applique pas au trafic réseau entrant, … Par expérience, je regarde toujours les sujets dans les feedbacks Azure. Un sujet a attiré mon attention : Allow a UDR to specify any routable « next hop » IP address (not limited to the VNet or Region) :

clip_image004

Bref, on passe au plan B. En plus, UDR n’est pas dynamique. C’est du déclaratif. Bingo, c’est du routage dynamique dont j’ai besoin. Encore une fois, c’est un retour aux bons vieux fondamentaux. C’est à partir de maintenant que cela devient fun. On repasse en mode matériel mais dans Azure !

Il faut recommencer

C’est ma première leçon apprise sur le sujet de BGP dans Azure. C’est possible mais :

  • Ce n’est disponible que pour les Gateway de type Route-Based (routage dynamique)
  • Ce n’est pas par ce que la Gateway a été provisionnée en Route-Based qu’elle est prête à accepter de nouvelles informations de routage et de les propager

Ci-dessous deux Gateway créées avec le portail Azure. Quand on regarde spécifiquement la configuration de BGP, on a un problème :

clip_image005

 

Nos deux Gateway ont été configurées pour annoncer le même ASN. Autant vous dire tout de suite que ça ne va pas le faire. Le problème, c’est que le portail ne permet pas de configurer l’ASN annoncé lors de la création de la Gateway. Il faut donc recommencer la création de la Gateway pour préciser notre configuration de BGP.

Dans les choix des ASN, faites attention à ne pas réutiliser un ASN utilisé pour un service Microsoft voire même un de ceux utilisés On-Premises par vos équipes réseau. La lecture de la FAQ Overview of BGP with Azure VPN Gateways vous apprendra que dans la liste des ASN réservés, on a :

  • Azure Public ASNs: 8075, 8076, 12076
  • Azure Private ASNs: 65515, 65517, 65518, 65519, 65520

Seconde leçon, ce n’est pas par ce qu’on annonce utiliser un ASN que BGP est activé. Là encore, le portail ne nous pose pas la question. C’est à nous de l’exiger à la création de la Azure Virtual Network Gateway. J’ai jamais créé autant de Gateway que ces jours-ci!

Le portail Azure évolue tous les jours. En ce jour du 24 Aout 2017, j’ai pu constater une évolution du côté du portail lors de la création dune Azure Virtual Network Gateway. Il est désormais possible d’activer le support de BGP et l’ASN annoncé :

Tout ce dont j’ai besoin, c’est de trois Virtual Networks :

  • VNETLab1
  • VNETLab2
  • VNETInter

Bien entendu, pas d’overlaping des espaces d’adressage, sinon ce ne sera pas drôle pour la suite. Histoire d’être clair, notre socle réseau à mettre en œuvre est le suivant :

clip_image006

 

On va commencer par reconstruire la Gateway VNETLab1 avec un peu de PowerShell :

$Lab1PublicIPName = « LABVNET1-IP »

$Lab1ResourceGroupName = « VNETLAB1 »

$Lab1Location = « West Europe »

$Lab1gatewayIPConfigName = « LAB1GATEWAYIP »

$Lab1VnetName = « VNETLab1 »

$Lab1GatewayName = « LABVNET1Gateway »

$Lab1gatewayBGPASN = 65011

$Lab1GatewayIP = New-AzureRMPublicIpAddress -Name $Lab1PublicIPName -ResourceGroupName $Lab1ResourceGroupName -Location $Lab1Location -AllocationMethod Dynamic

$Lab1VNET = Get-AzureRmVirtualNetwork -ResourceGroupName $Lab1ResourceGroupName -Name $Lab1VnetName

$Lab1GatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $Lab1VNET

$GatewayIpConfigLab1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $Lab1gatewayIPConfigName -Subnet $Lab1GatewaySubnet -PublicIpAddress $Lab1GatewayIP

New-AzureRmVirtualNetworkGateway -Name $Lab1GatewayName -ResourceGroupName $Lab1ResourceGroupName -Location $Lab1Location -IpConfigurations $GatewayIpConfigLab1 -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $Lab1gatewayBGPASN -EnableBGP $True

clip_image007

 

C’est lors de la création de la Gateway qu’on associe le numéro d’ASN et qu’on active le support de BGP. Pas après. Ceci dit, faisons de même pour notre seconde Gateway :

$Lab2PublicIPName = « LABVNET2-IP »

$Lab2ResourceGroupName = « VNETLAB2 »

$Lab2Location = « North Europe »

$Lab2gatewayIPConfigName = « LAB2GATEWAYIP »

$Lab2VnetName = « VNETLab2 »

$Lab2GatewayName = « LABVNET2Gateway »

$Lab2gatewayBGPASN = 65012

$Lab2GatewayIP = New-AzureRMPublicIpAddress -Name $Lab2PublicIPName -ResourceGroupName $Lab2ResourceGroupName -Location $Lab2Location -AllocationMethod Dynamic

$Lab2VNET = Get-AzureRmVirtualNetwork -ResourceGroupName $Lab2ResourceGroupName -Name $Lab2VnetName

$Lab2GatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $Lab2VNET

$GatewayIpConfigLab2 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $Lab2gatewayIPConfigName -Subnet $Lab2GatewaySubnet -PublicIpAddress $Lab2GatewayIP

New-AzureRmVirtualNetworkGateway -Name $Lab2GatewayName -ResourceGroupName $Lab2ResourceGroupName -Location $Lab2Location -IpConfigurations $GatewayIpConfigLab2 -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $Lab2gatewayBGPASN -EnableBGP $True

clip_image008

 

Entre les deux, on va avoir notre Gateway d’interconnexion nommée LABVNETInterGateway :

$LabInterPublicIPName = « LABVNETINTER-IP »

$LabInterResourceGroupName = « VNETLabInterconnect »

$LabInterLocation = « West Europe »

$LabIntergatewayIPConfigName = « LABINTERGATEWAYIP »

$LabInterVnetName = « VNETLabInterconnect »

$LabInterGatewayName = « LABVNETInterGateway »

$LabIntergatewayBGPASN = 65013

$LabInterGatewayIP = New-AzureRMPublicIpAddress -Name $LabInterPublicIPName -ResourceGroupName $LabInterResourceGroupName -Location $LabInterLocation -AllocationMethod Dynamic

$LabInterVNET = Get-AzureRmVirtualNetwork -ResourceGroupName $LabInterResourceGroupName -Name $LabInterVnetName

$LabInterGatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $LabInterVNET

$GatewayIpConfigInter = New-AzureRmVirtualNetworkGatewayIpConfig -Name $LabIntergatewayIPConfigName -Subnet $LabInterGatewaySubnet -PublicIpAddress $LabInterGatewayIP

New-AzureRmVirtualNetworkGateway -Name $LabInterGatewayName -ResourceGroupName $LabInterResourceGroupName -Location $LabInterLocation -IpConfigurations $GatewayIpConfigInter -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $LabIntergatewayBGPASN -EnableBGP $True

clip_image009

 

Personnaliser les policies IPSEC, ce n’est pas obligatoire mais par expérience, quand plusieurs équipements réseau On-Premises vont venir se connecter sur une Gateway, on a pas toujours les mêmes capacités sur tous les équipements. Là encore, c’est pas possible à configurer depuis le portail. Dans le cadre de ce billet, c’est optionnel :

$ipsecpolicy2 = New-AzureRmIpsecPolicy -IkeEncryption AES128 -IkeIntegrity SHA1 -DhGroup DHGroup14 -ipsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup PFS24 -SALifeTimeSeconds 7200 -SADataSizeKilobytes 4096

clip_image010

 

Vu qu’on va mettre en place des connections, on va travailler au niveau de nos Virtual Network Gateway, commençons par récupérer les informations en vue de construire les connections :

$gatewayLab1 = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $Lab1ResourceGroupName -Name $Lab1GatewayName

$gatewayLab2 = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $Lab2ResourceGroupName -Name $Lab2GatewayName

$gatewayLabInter = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $LabInterResourceGroupName -Name $LabInterGatewayName

clip_image011

 

On commence par les connections entre Lab1 et LabInterGateway

$ConnectionLabOneToLabInter = « ConnectionLab1toLabInter »

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabOneToLabInter -ResourceGroupName $Lab1ResourceGroupName -VirtualNetworkGateway1 $gatewayLab1 -VirtualNetworkGateway2 $gatewayLabInter -Location $Lab1Location -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

$ConnectionLabInterToLabOne = »ConnectionLabIntertoLab1″

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabInterToLabOne -ResourceGroupname $LabInterResourceGroupName -VirtualNetworkGateway1 $gatewayLabInter -VirtualNetworkGateway2 $gatewayLab1 -Location $LabInterLocation -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

clip_image012

 

Puis on poursuit avec les connections entre Lab2 et LabInterGateway

$ConnectionLabTwoToLabInter = « ConnectionLab2toLabInter »

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabTwoToLabInter -ResourceGroupName $Lab2ResourceGroupName -VirtualNetworkGateway1 $gatewayLab2 -VirtualNetworkGateway2 $gatewayLabInter -Location $Lab2Location -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

$ConnectionLabInterToLabtwo = »ConnectionLabIntertoLab2″

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabInterToLabtwo -ResourceGroupname $LabInterResourceGroupName -VirtualNetworkGateway1 $gatewayLabInter -VirtualNetworkGateway2 $gatewayLab2 -Location $LabInterLocation -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

clip_image013

 

Voilà, c’est en place.

clip_image014

Ce qui est intéressant, ce sont les effectives routes annoncées. Ci-dessous celles liée à une interface réseau liée à un sous-réseau dépendant de VNETLab1. La route vers VNETLab2 est bien annoncée avec la Virtual Network Gateway de VNETLab1 pour passer par la Gateway LABVNETInterGateway.

clip_image015

 

Même réponse depuis le Network Watcher : pour joindre une machine virtuelle dépendant de VNETLab2. Il annonce la Gateway de VNETLab1 :

clip_image016

 

Prochaine étape, quand j’aurai un peu de temps, l’intégration du VPN vers les réseaux On-Premises, toujours avec BGP.

 

BenoitS – Simple and Secure by design but Business compliant (with disruptive flag enabled)