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 redondance, pour des workloads contrôlés avec une fenêtre de maintenance acceptée. |
| Active-active avec Load Balancer | Une licence BYOL par firewall ou PAYG | Deux firewalls autonomes derrière des Standard Load Balancers avec HA Ports; le modèle ne prend pas en charge active-passive. |
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
Créer et sécuriser l’appliance
- 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 LAN et PortB au WAN. N’ouvrir les NSG qu’aux sources d’administration requises.
- Terminer le déploiement et ouvrir WebAdmin sur
https://<dns-name>: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 à chaque subnet de workloads 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 le 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.
Préparer le plan d’adressage
Pour un nouveau déploiement, créer d’abord l’IP publique sous Public IP addresses > Create avec IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static et Routing preference: Microsoft network. Définir un DNS name label unique et choisir Domain name label scope: None. Sophos indique aussi DDoS protection > Protection type: Network pour cette procédure. Cette option nécessite un plan Azure DDoS adapté et peut entraîner des coûts supplémentaires; valider donc le plan avec le responsable Azure avant la création. Sélectionner ensuite l’adresse dans Public IP name. Pour cette procédure, Sophos ne prend explicitement en charge que la zone 1. L’ancienne option Basic dynamique n’est plus adaptée depuis son retrait par Azure.
Un plan transférable utilise VNet 10.20.0.0/16, LAN 10.20.10.0/24 sur PortA, WAN 10.20.20.0/24 sur PortB et 10.20.10.4 comme IP LAN statique. Ces valeurs RFC 1918 sont remplacées par des plages libres, sans chevauchement avec peering, VPN ou on-premises.
Créer l’UDR LAN avec les champs Azure exacts
Sophos demande d’arrêter la VM avant le passage de l’IP LAN en statique: Virtual machines > Allocation: Static. Après redémarrage, créer la table sous Route tables > Create. Dans Subnets > Associate, associer chaque subnet de clients ou de workloads dont le trafic doit traverser l’appliance. Si les clients se trouvent directement dans le subnet LAN de PortA, associer ce subnet LAN, comme dans l’exemple de base Sophos. Ne pas associer le subnet WAN du firewall. Dans Routes > Add, saisir Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance et Next hop address: 10.20.10.4. Vérifier Enable IP forwarding sur les deux NIC. Ne conserver Propagate gateway routes: Yes que si cela correspond au design VPN/ExpressRoute. Créer enfin une règle LAN vers WAN restrictive et journalisée sous Rules and policies > Firewall rules.
Exploiter active-active avec Load Balancer
Le modèle Sophos crée deux firewalls et un Standard Load Balancer externe et interne avec HA Ports. Il impose un VNet /16 et des subnets LAN et WAN /24; Sophos demande de consulter son interlocuteur avant toute autre taille de subnet.
Les health probes atteignent WebAdmin sur 4444 et le proxy sur 3128. Les probes internes dépendent aussi de routes spéciales vers l’adresse de plateforme 168.63.129.16, injectées dans la table de routage du noyau par l’Automation Runbook. Ces routes ne persistent pas après une mise à niveau firmware; le runbook fourni est alors relancé et contrôlé.
Pendant le déploiement, Trusted network doit temporairement valoir * pour permettre l’accès du Azure Automation Runbook depuis des IP Azure publiques. Dès son succès, restreindre la NSG aux CIDR admin documentés. La première firewall utilise WebAdmin 4444 et SSH 2222, la seconde 4445 et 2223. Les deux appliances sont enregistrées séparément et reçoivent les mêmes règles firewall, NAT et routing.
Configurer les probes et l’egress
Sur les deux firewalls, créer les gateways sous Routing > Gateways et les routes de probe sous Routing > SD-WAN routes; la route externe reste au-dessus de l’interne. L’UDR 0.0.0.0/0 des workloads utilise Next hop type: Virtual appliance et l’IP frontend du Load Balancer interne. Les probes TCP 4444 et 3128 apparaissent dans l’appliance avec la source 168.63.129.16. Si les ports changent, les probes interne et externe doivent rester distinctes. Dans la NSG, autoriser leur chemin avec le Source Service Tag AzureLoadBalancer; les listeners SFOS et les routes spéciales Sophos doivent également correspondre. Ni le Service Tag ni l’adresse de plateforme ne constituent une source Internet généralement fiable. Vérifier les deux backends sous Load balancer > Monitoring > Insights ou Health Probe Status; une probe saine ne valide pas l’application ni son retour.
DNAT et chemin retour
Le Load Balancer externe choisit un firewall. Les HA Ports transportent les flux NVA sur tous les protocoles et ports, mais ne remplacent pas une publication propre au service. Pour le service TCP publié, créer sur le Load Balancer externe une health probe adaptée et une règle de Load Balancing qui utilise cette probe. La règle NAT SFOS traduit ensuite vers le serveur. Dans Rules and policies > NAT rules, Translated source (SNAT): MASQ force le serveur à répondre à l’IP LAN de ce même firewall. Sans MASQ, le retour peut passer par l’autre firewall et casser la session.
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é.
Valider, dépanner et revenir en arrière
Contrôles de réception
- Dans Effective routes d’une VM de test, vérifier que
0.0.0.0/0pointe vers l’IP LAN SFOS ou, en active-active, vers l’IP du Load Balancer interne. - Tester DNS, HTTPS et l’application, puis confirmer Rule ID, source et destination dans Log viewer > Firewall. Pour un service publié, effectuer un test positif autorisé et un test négatif non autorisé.
- En active-active, contrôler Health Probe Status et Backend Pool. Uniquement en fenêtre de maintenance, retirer un firewall, tester les nouvelles connexions via l’autre, puis rétablir un backend sain avant le second passage. Les sessions existantes ne sont pas synchronisées et peuvent être interrompues.
Erreurs typiques
Sans egress, vérifier dans l’ordre Effective Routes, association au subnet de workloads, IP LAN statique, IP forwarding, NSG et Rule ID SFOS. Pour une probe unhealthy, contrôler protocole/port TCP, listener, NSG et routes SD-WAN vers 168.63.129.16. Après un firmware upgrade, les routes injectées ne persistent pas: relancer le runbook Sophos pour les deux VM, vérifier les probes et rétablir immédiatement les CIDR admin dans la NSG SSH. Pour un DNAT intermittent, comparer les règles des deux appliances, MASQ, Backend Pool et route retour du serveur.
Avant un retour arrière egress, noter le Next Hop précédemment approuvé. Réassocier l’ancienne Route Table ou isoler le subnet de workloads pendant le changement. Une simple dissociation peut activer la route système Azure 0.0.0.0/0 -> Internet et contourner le firewall; elle n’est permise que si ce chemin a été vérifié et accepté. Ne supprimer l’UDR et les règles temporaires qu’après validation du retour rétabli. Pour DNAT, désactiver d’abord la règle du Load Balancer externe. Les snapshots Azure ne remplacent pas un backup SFOS exporté.