Déployez une passerelle VPN OPNsense

Azure VPN Gateway est un service plébiscité pour sa sécurité, sa redondance et la simplicité de son intégration native dans Microsoft Azure. Cependant, pour des projets de plus petite envergure ou lorsque vous disposez déjà de compétences réseau et d’infrastructures maîtrisées, il peut être judicieux d’explorer des solutions open source ou des distributions spécialisées. C’est dans cette optique que nous verrons comment déployer un VPN OPNsense sur Azure.

Comment fonctionne un tunnel IPsec ?

Les tunnels IPsec se mettent en place en deux grandes étapes :

Phase 1 – IKE (Internet Key Exchange)

Les deux extrémités (pair A et pair B) négocient d’abord une association de sécurité IKE SA.
Elles s’authentifient mutuellement (certificat, clé pré-partagée, etc.) et conviennent des paramètres de chiffrement (algorithme, mode DH, durée de vie des clés).
À l’issue, un canal chiffré et authentifié est établi pour protéger les échanges de la phase 2.

Phase 2 – IPsec SA

Dans ce canal sécurisé, les pairs négocient plusieurs Security Associations secondaires (appelées Child SA), qui définiront le chiffrement et l’intégrité du trafic utilisateur.
Elles conviennent des sous-réseaux à protéger, des ports et protocoles autorisés, puis génèrent les clés de session IPsec.
Une fois la Child SA montée, le tunnel est opérationnel : tout paquet envoyé vers le sous-réseau distant est chiffré et encapsulé dans IPsec.

Qu’est-ce qu’une passerelle VPN Azure ?

Une passerelle VPN Azure (Azure VPN Gateway) agit comme un point de terminaison chiffré permettant d’établir des tunnels IPsec/IKE entre votre réseau on-premises (ou vos clients VPN individuels) et vos réseaux virtuels Azure.

Elle prend en charge plusieurs scénarios :

Site-à-Site (connexion permanente entre votre datacenter et Azure)
Point-à-Site (accès distant des utilisateurs)
VNet-à-VNet (liaison sécurisée entre réseaux virtuels)

Quels sont les SKUs disponibles pour les passerelles VPN Azure ?

Les passerelles VPN Azure se déclinent en versions classiques et zone-redondantes :

Génération	SKU	Tunnels S2S/VNet-to-VNet	Connexions P2S (IKEv2/OpenVPN)	Débit agrégé	BGP supporté	Zone-redondant
Gen 1	Basic	Max. 10	Non supporté	100 Mbps	Non	Non
	VpnGw1	Max. 30	Max. 250	650 Mbps	Oui	Non
	VpnGw2	Max. 30	Max. 500	1 Gbps	Oui	Non
	VpnGw3	Max. 30	Max. 1000	1,25 Gbps	Oui	Non
	VpnGw1AZ	Max. 30	Max. 250	650 Mbps	Oui	Oui
	VpnGw2AZ	Max. 30	Max. 500	1 Gbps	Oui	Oui
	VpnGw3AZ	Max. 30	Max. 1000	1,25 Gbps	Oui	Oui
Gen 2	VpnGw2	Max. 30	Max. 500	1,25 Gbps	Oui	Non
	VpnGw3	Max. 30	Max. 1000	2,5 Gbps	Oui	Non
	VpnGw4	Max. 100*	Max. 5000	5 Gbps	Oui	Non
	VpnGw5	Max. 100*	Max. 10000	10 Gbps	Oui	Non
	VpnGw2AZ	Max. 30	Max. 500	1,25 Gbps	Oui	Oui
	VpnGw3AZ	Max. 30	Max. 1000	2,5 Gbps	Oui	Oui
	VpnGw4AZ	Max. 100*	Max. 5000	5 Gbps	Oui	Oui
	VpnGw5AZ	Max. 100*	Max. 10000	10 Gbps	Oui	Oui

Combien coûte les passerelles VPN Azure ?

Le prix de la passerelle VPN dépend du SKU choisi. Voici quelques tarifs :

SKU	Prix mensuel estimé (€)
Basic	22,95 €
VpnGw1	121,11 €
VpnGw2	312,33 €
VpnGw3	796,77 €
VpnGw4	1 338,57 €
VpnGw5	2 326,56 €

Attention : ces prix correspondent uniquement au coût de compute de la passerelle (744 heures d’utilisation par mois) et n’incluent pas les frais de transfert de données sortantes.

L’ancien VPN de type basique présentait un tarif particulièrement attractif :

Le service le moins cher est maintenant le SKU VpnGw1, mais le prix est plus élevé :

En comparaison, le service OPNsense déployé via une VM affiche un coût un plus faible :

Voici également le tarif appliqué pour le VPN OPNsense pour un engagement d’un an sur la machine virtuelle :

Qu’est-ce que la passerelle VPN OPNsense sur Azure ?

OPNsense VPN est la solution de création de tunnels sécurisés intégrée à OPNsense, un pare-feu/routeur open-source basé sur FreeBSD. Elle prend en charge plusieurs protocoles majeurs :

IPsec : idéal pour les liaisons site-à-site ou les connexions distantes, avec négociation IKEv1/IKEv2, clés pré-partagées ou certificats, et prise en charge de BGP pour le routage dynamique.
OpenVPN : pour les accès distants sur TCP ou UDP, avec authentification par utilisateur, certificats ou serveur RADIUS, et options de chiffrement AES-GCM.
WireGuard : un protocole moderne, léger et performant, offrant des temps de mise en place réduits et une empreinte cryptographique simplifiée.

Peut-on déployer la passerelle VPN OPNsense sur Azure ?

Oui, il est tout à fait possible de déployer OPNsense dans Azure en tant que machine virtuelle. Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Pour tester mon environnement, j’ai également provisionné les deux machines virtuelles suivantes pour simuler des ressources opposées :

J’y ai également mis en place une passerelle Bastion :

Enfin, j’ai également déployé une passerelle VPN Azure pour tester le tunnel :

Commençons par créer une nouvelle machine virtuelle Azure contenant la passerelle VPN OPNsense.

Etape I – Préparation de la machine virtuelle OPNsense :

Pour cela, cliquez sur le lien GitHub suivant pour déployer le template ARM sur votre environnement Azure : https://github.com/dmauser/opnazure

Sélectionnez ensuite le scénario OPNsense souhaité et renseignez les informations de base, puis cliquez sur Suivant :

Conservez ou ajustez la taille de la VM, puis validez en cliquant Suivant :

Constatez la présence de deux sous-réseaux, Trusted et Untrusted, puis lancez la validation Azure :

Une fois la validation réussie, le déploiement des ressources démarre automatiquement :

Patientez quelques minutes, puis cliquez ici pour accéder aux ressources créées :

Copiez les adresses IP privées et publiques de la VM OPNsense :

Modifiez la règle de pare-feu pour autoriser l’accès HTTPS à la VM :

Vérifiez la présence du sous-réseau Trusted, puis copiez son plan d’adressage :

Connectons-nous maintenant à notre console d’administration OPNsense pour avancer sur la configuration de notre tunnel.

Etape II – Configuration d’OPNsense :

Ouvrez votre navigateur, collez-y l’IP publique de la VM OPNsense, renseignez les identifiants ci-dessous, puis cliquez sur Login :

Login : root
Mot de passe : opnsense

Changez immédiatement le mot de passe pour des raisons de sécurité :

Commencez par créer une clé partagée destinée au handshake IPsec :

Dans la section VPN IPsec, cliquez-ici pour créer une nouvelle connexion et choisissez vos propositions de chiffrement :

Renseignez les champs requis : l’IP locale de la VM OPNsense et l’adresse IP publique de la passerelle VPN Azure :

Ajoutez une authentification locale en réutilisant la clé partagée, puis enregistrez :

Répétez l’opération pour l’authentification distante, puis sauvegardez :

Éditez ensuite la section Child en renseignant les plans d’adressage respectifs, puis cliquez sur Enregistrer :

Cliquez sur Sauvegarder :

Enfin, cliquez sur Appliquer pour finaliser la configuration IPsec :

Dans la section pare-feu, constatez la règle sortante déjà préconfigurée :

Créez une nouvelle règle entrante pour autoriser l’accès depuis la passerelle VPN Azure :

Activez cette nouvelle règle pare-feu :

Sur le pare-feu OPNsense, ajoutez les règles nécessaires pour établir la liaison IPsec dans la section WAN :

La configuration OPNsense est maintenant terminée. La prochaine étape consiste à configurer la passerelle VPN Azure pour se connecter à la première.

Etape III – Configuration de la passerelle VPN Azure :

Copiez l’adresse IP publique de la passerelle VPN Azure :

Dans le Network Security Group de votre VM OPNsense, créez une règle pour autoriser l’IP de la passerelle VPN Azure :

Créez une Local Network Gateway en renseignant l’IP publique de votre passerelle VPN OPNsense et le plan d’adressage du sous-réseau Trusted :

Établissez ensuite la connexion VPN Azure pour finaliser l’interconnexion entre les deux passerelles :

Collez la clé d’authentification, puis enregistrez la configuration de la connexion :

Associez également une table de routage au sous-réseau Trusted, en y incluant le préfixe 0.0.0.0/0 afin de diriger tout le trafic via la VM OPNsense :

Tout est maintenant en place pour le test de connectivité entre nos deux machines virtuelles.

Etape IV – Test de la connexion VPN :

Retournez dans le menu des connexions IPsec OPNsense, puis cliquez ici pour démarrer la connexion IPsec côté OPNsense :

Attendez quelques secondes jusqu’à l’apparition de la Phase 2 de la connexion IPsec :

Une fois la Phase 2 affichée, cliquez ici pour visualiser le journal contenant les événements IPsec :

Constatez l’apparition des différents états de la connexion entre les deux passerelles VPN :

Vérifiez l’apparition de Security Associations dans la base de données IPsec :

Vérifiez l’apparition de Security Policies dans la base de données IPsec :

Retournez sur le portail Azure et observez le changement de statut de la connexion VPN Azure :

Démarrez les deux machines virtuelles de test pour valider la liaison :

Sur les deux VM de test, désactivez temporairement la règle de pare-feu ICMP suivante pour autoriser le ping :

Effectuez des tests de ping réciproques entre les deux machines virtuelles :

Interrompez la connexion depuis OPNsense :

Constatez la disparition de la Phase 2 dans la console OPNsense :

Vérifiez également l’échec du ping entre les deux VM :

Relancez la connexion IPsec depuis OPNsense et observez la réapparition de la Phase 2 :

Confirmez la reprise du ping sur les deux machines virtuelles de test :

Conclusion

Si Azure VPN Gateway reste la solution de référence pour une interconnexion cloud sécurisée et redondante, l’utilisation d’une VM OPNsense sur Azure offre une alternative open source particulièrement adaptée aux petits projets ou aux environnements où vous souhaitez tirer parti de vos compétences réseau existantes.

Vous gagnez en flexibilité de configuration, en contrôle détaillé des politiques VPN et en possibilité d’étendre facilement vers d’autres protocoles (OpenVPN, WireGuard).

Cette approche hybride combine la robustesse du cloud Azure et la puissance d’OPNsense pour bâtir un VPN sur mesure parfaitement aligné avec vos besoins.

Faites du NAT avec Azure VPN

Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?

Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.

Qu’est-ce que le NAT ?

Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.

Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :

Comment fonctionne le NAT ?

Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :

Le routage du trafic impacte alors le traffic de données dans les deux sens :

Sortant : le paquet quitte le réseau interne avec l’adresse publique.
Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.

Quels sont ses avantages et ses limites au NAT ?

Avantages

Économie d’adresses IPv4
Masquage du réseau interne (sécurité renforcée)
Contrôle centralisé du trafic sortant/entrant

Limites

Complexité de dépannage (tables de traduction)
Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
Impact potentiel sur la latence et le débit

SNAT vs DNAT ?

En pratique, le NAT (Network Address Translation) se décline en deux grands modes :

Mode	Abréviation	Fonction principale	Exemple d’usage
Source NAT	SNAT (Source NAT)	Modifier l’adresse source et/ou le port d’une connexion sortante	Votre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NAT	DNAT (Destination NAT)	Modifier l’adresse de destination et/ou le port d’une connexion entrante	Internet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)

Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.

Et le NAT dans Azure c’est possible ?

Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :

Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.

Microsoft Learn

Quels services Azure proposent du NAT ?

Oui, plusieurs services Azure permettant de faire du NAT entre votre réseau Azure et votre infrastructure on-premise :

Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?

La réponse est oui :

Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.

Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.

Microsoft Learn

Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :

Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :

NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
Les mappages de ports peuvent servir pour les protocoles TCP et UDP.

Et en pratique ?

Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :

Le premier simulant un réseau on-premise
Le second correspondant à un réseau virtuel Azure

Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :

Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :

Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :

Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :

J’ai commencé par ajouter des règles NAT sur la passerelle Azure :

Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
- adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par votre réseau on-premise
Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur votre réseau on-premise
- adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure

J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :

Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
- adresses internes : l’adressage IP configuré sur ton réseau on-premise
- adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par ton réseau on-premise

Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :

L’une pour présenter le réseau on-premise à la passerelle Azure
L’autre pour présenter le réseau Azure la passerelle on-premise

La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :

La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :

J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.

Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.

J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :

Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :

Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :

Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :

Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :

Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :

Conclusion

Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses

Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.

Azure WAN

Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎

Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.

Qu’est-ce qu’Azure WAN ?

Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.

Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.

Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

Microsoft Learn

Voici quelques-unes des fonctionnalités principales :

Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).

Connectivité VPN de site à site.

Connectivité VPN d’un utilisateur distant (point à site).

Connectivité privée (ExpressRoute).

Connectivité multicloud (connectivité transitive pour les réseaux virtuels).

Interconnectivité ExpressRoute des VPN.

Routage, Pare-feu Azure et chiffrement pour la connectivité privée.

Microsoft Learn

Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.

Dans quel cas considérer Azure WAN ?

Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.

Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.

Quels SKUs sont disponibles pour Azure WAN ?

Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.

A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :

Type de Virtual WAN	Type de Hub	Configurations disponibles
De base	De base	VPN de site à site uniquement
standard	standard	ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel

Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :

Connexion entre les hubs
Connectivité ExpressRoute
Connectivité VPN utilisateur/point à site
Connectivité de réseau virtuel à réseau virtuel Azure
Azure Firewall

Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :

Quels sont les autres coûts liés au services Azure WAN ?

La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.

Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :

Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste là.

Tarification de la liaison :

Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :

Tarification de la données en transit :

Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :

Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :

Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.

Mon test d’Azure WAN :

Mon environnement WAN de test est constitué des éléments Azure suivants :

1 Azure WAN avec 2 Azure Hub :

4 réseaux virtuels Azure contenant chacun une machine virtuelle :

2 VPN Gateway Site à Site :

2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :

J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :

2 réseaux en connexion site à site avec 2 passerelles VPN :

2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :

Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :

Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :

Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.

Configuration WAN :

Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :

J’ai activé les liaisons suivantes via la configuration de mon WAN :

Configuration des 2 hubs :

Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :

Connexions aux 4 réseaux virtuels Azure :

Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :

J’ai utilisé la route par Default pour chacune des liaisons :

Connexions aux réseaux locaux Site à site :

Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :

Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :

Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :

Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :

Connexions Points à site :

Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :

Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :

Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :

J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :

La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :

Poste 1 :

Poste 2 :

Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :

Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.

Tests des accès :

Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :

J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :

J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :

Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
Serveur ayant une connexion Site à Site ouverte sur le même hub
Serveur ayant une connexion Site à Site ouverte sur l’autre hub
Serveurs ayant un appairage de réseau virtuel sur le même hub
Serveurs ayant un appairage de réseau virtuel sur l’autre hub

Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪

Surveillance des liaisons :

Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.

Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :

De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.

J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :

A peine les tests créés, Connection Monitor affiche les résultats :

Différentes informations sont disponibles sur ces tests :

Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :

A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :

Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :

Azure Monitor affiche également les 2 alerte déclenchée :

Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :

Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :

Quelques minutes plus tard, les alertes générées sont automatiquement résolues :

De retour sur Connection Monitor, tous les tests repassent alors en vert :

Conclusion

En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.