Déployer et router Sophos Firewall sur Azure
Sophos Firewall peut être déployé depuis Azure Marketplace comme appliance unique ou avec un modèle Load Balancer et deux firewalls. Sophos appelle le second design active-active, mais ce n’est pas un cluster HA SFOS natif. Configuration, sessions et état ne sont pas synchronisés comme entre deux appliances HA.
⚠️ Le routage Azure fait partie de la configuration firewall. Une règle SFOS correcte ne suffit pas si une User Defined Route, une Network Security Group ou le retour du Load Balancer manque. Chaque ouverture est validée sur le trajet aller-retour complet.
Choisir le modèle et la licence
| Modèle | Licence | Limite importante |
|---|---|---|
| Standalone | BYOL ou PAYG | Une appliance sans HA Azure natif, adaptée aux designs petits et contrôlables. |
| Active-active avec Load Balancer | Deux licences BYOL ou deux instances PAYG | Redondance cloud via Azure Load Balancer, pas HA SFOS. Le modèle ne prend en charge ni active-passive ni la gestion des tunnels VPN. |
Pour standalone, Sophos recommande au moins Standard_F2s_v2, deux vCPU et 4 GB de RAM. L’IP publique utilise la Standard SKU avec attribution statique. La Basic SKU est retirée et ne convient pas aux nouveaux déploiements.
Déployer standalone depuis Marketplace
- Sélectionner Sophos Firewall dans Azure Marketplace et choisir BYOL ou PAYG.
- Définir Resource Group, région et taille. VNet, subnets et réseaux distants ne se chevauchent pas.
- Associer PortA au WAN et PortB au LAN. N’ouvrir les NSG qu’aux sources d’administration requises.
- Terminer le déploiement et ouvrir WebAdmin sur
https://<public-ip>:4444. - Terminer de façon contrôlée assistant, enregistrement, licence et firmware.
- Définir l’adresse privée de la NIC LAN sur Static. Ajouter au subnet LAN une UDR
0.0.0.0/0, Virtual appliance, avec cette IP LAN comme Next Hop. - Tester IP Forwarding, NSG, règles SFOS et retour avec un client défini.
L’UDR force le trafic LAN sortant à travers la firewall. Sans elle, Azure utilise son chemin par défaut. Une connexion route-based à Azure VPN Gateway utilise aussi l’interface XFRM avec routes statiques, SD-WAN ou BGP.
Exploiter active-active avec Load Balancer
Le modèle Sophos crée deux firewalls et un Azure Load Balancer public et interne. Les valeurs initiales utilisent un VNet /16 et des subnets WAN et LAN /24; les plages sont adaptées avant le déploiement.
Les health probes atteignent WebAdmin sur 4444 et le proxy sur 3128. Azure utilise l’adresse de plateforme 168.63.129.16. Sophos crée les routes SD-WAN via PortA. Ces routes du runbook peuvent disparaître après une mise à niveau firmware; le Automation Runbook fourni est alors relancé et contrôlé.
Par défaut, la première firewall utilise 4444 et SSH 2222, la seconde 4445 et 2223. Ces ports ne sont ouverts qu’aux sources admin fixes. L’UDR LAN dirige 0.0.0.0/0 vers l’IP frontend du Load Balancer interne.
DNAT et chemin retour
Le Load Balancer public répartit le service entrant entre les firewalls et la règle DNAT SFOS traduit vers le serveur interne. Ce design utilise MASQ pour que la réponse revienne par la même firewall et le Load Balancer. Sans retour symétrique, les connexions fonctionnent par intermittence ou dans un seul sens.
La publication directe de RDP n’est pas recommandée. VPN ou ZTNA sont préférables. Si le service doit être publié, source, service et destination sont limités dans Azure et SFOS, logging et IPS sont activés et un test négatif est effectué.
Validation et exploitation
La validation couvre les deux firewalls, probes, Backend Pool, UDR, NSG, Rule IDs, DNAT, sortie internet et retour. Après chaque firmware upgrade, contrôler les routes vers 168.63.129.16, les ports de probe et le Automation Runbook. Les snapshots Azure ne remplacent pas un backup SFOS exporté.