Configurer et tester une adresse IP alias sur Sophos Firewall

Une adresse IP alias associe une adresse IPv4 ou IPv6 supplémentaire à une interface physique existante de Sophos Firewall. Elle est utile lorsqu’un opérateur fournit plusieurs adresses publiques sur la même connexion WAN ou lorsqu’une interface interne doit desservir un second sous-réseau pendant une migration.

La distinction importante est qu’un alias n’est ni une deuxième connexion Internet, ni une zone distincte, ni un chemin de passerelle indépendant. L’adresse utilise la même interface physique parente. Le routage, les règles de pare-feu, le NAT et Device Access doivent donc toujours correspondre au design existant de l’interface.

⚠️ Avant d’ajouter une adresse IP alias publique, documenter une sauvegarde récente, une connexion d’administration indépendante, l’attribution de l’opérateur, l’état ARP d’origine ainsi que les règles de pare-feu et de NAT prévues. Une adresse supplémentaire ne publie pas un serveur à elle seule, mais elle peut rendre des services locaux du pare-feu accessibles selon les règles Device Access de la zone parente.

L’exemple utilise IPv4 sur une interface WAN. SFOS prend également en charge les alias IPv6 lorsque la version IP correspond à l’interface parente. La découverte des voisins IPv6 et NAT66 ne font toutefois pas partie de cet exemple concret.

IP alias en huit étapes

1. Confirmer que l’opérateur ou le réseau interne fournit réellement l’adresse supplémentaire sur la même interface physique.
2. Documenter l’interface parente, la version IP, l’adresse, le masque de sous-réseau et l’objectif.
3. Vérifier Device Access, les règles existantes et un chemin d’administration indépendant.
4. Associer l’adresse à l’interface parente sous Network > Interfaces > Add interface > Add alias.
5. Si nécessaire pour les règles et le NAT, créer un IP Host clairement nommé avec exactement cette adresse.
6. Configurer le DNAT ou le SNAT uniquement pour le flux prévu ; traiter le trafic système séparément.
7. Vérifier le chemin opérateur, ARP, Firewall Rule ID, NAT Rule ID ainsi que les deux sens avec une nouvelle connexion.
8. Tester le matériel de remplacement, le basculement HA et le rollback dans une fenêtre de maintenance avec le même flux.

Quand une adresse IP alias est adaptée

Une adresse IP alias est adaptée lorsque plusieurs adresses doivent utiliser le même chemin physique de couche 2 et la même passerelle. Les cas typiques sont les suivants :

• plusieurs adresses IPv4 publiques sur une connexion WAN statique ;
• une adresse publique dédiée au DNAT, au WAF ou à un service de messagerie ;
• une adresse source fixe pour certains flux transférés ;
• un second sous-réseau interne sur le même segment physique pendant une migration contrôlée ;
• plusieurs adresses opérateur dans le même sous-réseau, pour lesquelles des interfaces WAN séparées provoqueraient des problèmes ARP.

Plusieurs interfaces WAN dans le même sous-réseau ne constituent pas une solution propre. Sophos avertit que les passerelles peuvent devenir injoignables en raison de problèmes ARP et cite un alias ou un LAG comme formes d’interface appropriées. Zones et interfaces sur Sophos Firewall explique le choix de base entre ports physiques, VLAN, LAG, bridge et XFRM.

Un alias n’est pas adapté lorsqu’une seconde liaison, une passerelle propre, un état de lien indépendant, une autre zone de sécurité ou un véritable failover sont nécessaires. Il faut alors un design d’interface, de VLAN, de LAG, de WAN ou de routage dédié.

Si le pare-feu ne doit pas posséder localement une adresse IPv4 supplémentaire, mais seulement répondre en son nom à sa requête ARP sur un segment directement connecté, il s’agit d’un autre design. Configurer Proxy ARP sur Sophos Firewall explique le choix et la procédure CLI et de test strictement limitée.

Exemple et valeurs à remplacer

L’exemple publie un service HTTPS interne via une seconde adresse publique :

• Interface parente : Port2
• Zone parente : WAN
• Adresse principale : 203.0.113.9/29
• Passerelle opérateur : 203.0.113.14
• IP alias : 203.0.113.10/29
• Objet hôte de l’alias : WAN_ALIAS_APP_203.0.113.10
• Serveur interne : APP-DMZ_10.20.40.20
• IP du serveur : 10.20.40.20
• Service : HTTPS
• Hôte de test externe : 198.51.100.25

203.0.113.0/24 et 198.51.100.0/24 sont réservés à la documentation. Dans la configuration de production, ils sont remplacés par les adresses attribuées par l’opérateur et par un hôte de test externe autorisé.

Le masque /29 n’est qu’un exemple réaliste. Il ne doit pas être repris si l’opérateur fournit un bloc routé, une adresse individuelle /32 ou une autre taille de réseau. La documentation de l’opérateur, le modèle ARP ou de routage et la version IP utilisée sur l’interface parente déterminent la valeur correcte.

Ajouter l’alias à l’interface physique

Sous Network > Interfaces, l’adresse est directement associée à l’interface existante :

1. Sélectionner Add interface > Add alias.
2. Sous Physical interface, sélectionner Port2 ou l’interface parente réelle.
3. Régler IP version sur IPv4.
4. Sous IPv4/Netmask, saisir 203.0.113.10 et le masque confirmé par l’opérateur.
5. Enregistrer avec Save.

L’adresse supplémentaire apparaît ensuite sur l’interface parente. S’il existe plus de trois alias, SFOS n’affiche initialement que les trois premiers. Faire défiler la zone d’adresses visible pour afficher les autres entrées.

Un alias ne peut pas être activé ou désactivé indépendamment. Si l’interface physique parente est désactivée ou perd son lien, ses adresses alias deviennent également injoignables. Inversement, l’enregistrement d’un alias ne crée ni nouvelle entrée de passerelle ni route distincte.

Le formulaire Add alias ne possède pas de champ de zone distinct. La zone de l’interface parente reste donc pertinente pour les services locaux du pare-feu. Avant d’ajouter une IP alias publique, vérifier sous Administration > Device access quels services sont accessibles depuis WAN et utiliser une Local Service ACL Exception restrictive pour les sources d’administration fixes. Le SSO ou la MFA ne justifient pas un accès WebAdmin étendu.

Utiliser l’alias dans les règles et le NAT

L’alias associé et un IP Host remplissent des fonctions différentes :

• L’alias rend l’adresse présente localement sur l’interface physique.
• L’IP Host rend la même adresse clairement sélectionnable dans les champs de règle et de NAT.

Un objet hôte seul n’associe pas une adresse à l’interface. Inversement, un alias seul ne publie pas de serveur et n’autorise pas le trafic transféré. Utiliser correctement les IP Hosts et les services explique en détail les limites de ces objets.

Publier un service entrant avec DNAT

Pour cet exemple, créer sous Hosts and services > IP host l’objet WAN_ALIAS_APP_203.0.113.10 de type IP avec l’adresse 203.0.113.10. Créer ensuite une règle DNAT restrictive et une règle de pare-feu correspondante :

• Original source : réseaux externes autorisés ou volontairement Any
• Original destination : WAN_ALIAS_APP_203.0.113.10
• Original service : HTTPS
• Translated destination (DNAT) : APP-DMZ_10.20.40.20
• Translated service (PAT) : Original
• Inbound interface : Port2 ou l’interface d’entrée effectivement confirmée
• Translated source (SNAT) : normalement Original
• Log firewall traffic : activé

La règle de pare-feu autorise le même service externe depuis WAN vers la zone du serveur interne et utilise comme Destination network l’adresse alias publique de Original destination. Limiter autant que possible la source, le service et les fonctions de protection. La procédure complète avec la position de la règle, le loopback et le durcissement figure dans Publier un serveur avec DNAT.

Envoyer le trafic transféré via l’adresse IP alias

Si seul un serveur interne spécifique doit apparaître à l’extérieur avec l’adresse 203.0.113.10, créer une règle SNAT dédiée exactement à ce flux. Translated source (SNAT) utilise alors l’IP Host de l’adresse alias. Limiter la source, la destination, le service et les interfaces autant que le permet le cas d’usage.

La règle NAT ne remplace pas une règle de pare-feu. Les règles NAT ne sont en outre évaluées que pour le premier paquet d’une nouvelle connexion. Après une modification, ouvrir une nouvelle connexion ; une session existante ne prouve pas le nouveau chemin NAT. NAT sur Sophos Firewall explique le traitement de SNAT, DNAT et PAT.

Traiter séparément le trafic système du pare-feu

Le trafic DNS, d’authentification, de messagerie ou tout autre trafic généré par le pare-feu lui-même ne suit pas automatiquement une règle SNAT destinée aux clients transférés. Sophos documente explicitement que les configurations de routage utilisent l’interface principale. Si un flux de trafic système précis et justifié doit utiliser l’IP alias comme source, une configuration CLI distincte est nécessaire.

Avant la modification, enregistrer l’état initial dans la Device Console :

show advanced-firewall

L’exemple suivant traduit uniquement le trafic système via Port2 vers la destination unique 198.51.100.25, avec l’IP alias 203.0.113.10 :

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

⚠️ Cette commande modifie l’adresse source du trafic du pare-feu. Elle ne crée pas de route et ne remplace pas de manière générale une règle NAT. La destination, le masque /32, l’interface et l’IP alias doivent correspondre à l’application réelle. Après la modification, tester précisément le service concerné et contrôler à nouveau l’entrée avec show advanced-firewall.

Pour le rollback, supprimer exactement la même entrée avec delete :

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Des masques plus larges traduisent le trafic vers un réseau de destination entier. Ne les utiliser que si cette portée plus large est voulue, documentée et testée.

Planifier des alias issus de sous-réseaux différents

Sophos autorise plusieurs adresses alias de sous-réseaux différents sur la même interface physique, mais impose deux conditions :

• Sophos Firewall doit être la passerelle par défaut des hôtes internes.
• Les équipements upstream qui servent de passerelle au trafic du pare-feu doivent posséder une adresse appropriée dans chaque sous-réseau d’alias utilisé.

Un alias ne rend donc pas automatiquement un second sous-réseau fonctionnel de bout en bout. La passerelle des hôtes, les pairs, la route de retour, ARP ou Neighbor Discovery, les règles de pare-feu et le NAT doivent également être corrects pour ce sous-réseau.

Pour une segmentation durable, un VLAN ou une interface physique distincte est généralement plus clair. Un alias multi-sous-réseaux convient davantage à une transition planifiée ou à une architecture opérateur dans laquelle les deux réseaux partagent réellement le même chemin de couche 2.

DHCP Server et DHCP Relay ne peuvent pas être configurés sur un Interface Alias. Un alias n’est pas non plus un Dedicated HA link valide. Ces besoins doivent être placés sur une interface physique ou virtuelle prise en charge.

Valider le chemin des données et ARP

La validation doit suivre la tâche réelle et ne pas se limiter à un ping :

1. Sous Network > Interfaces, vérifier l’interface parente, l’adresse alias, le masque et l’état du lien.
2. Sur l’équipement de l’opérateur ou l’équipement upstream, vérifier que l’IP alias est joignable via l’adresse MAC ou le voisin attendus.
3. Depuis 198.51.100.25, ouvrir une nouvelle connexion HTTPS vers l’IP alias.
4. Dans Log Viewer, vérifier les valeurs attendues de Firewall Rule ID, NAT Rule ID, Source, Original destination et la destination traduite.
5. Dans le Packet Capture intégré, comparer l’entrée sur Port2 et la sortie vers le serveur.
6. Sur le serveur interne, confirmer que la connexion arrive et que la réponse revient via Sophos Firewall.
7. Tester négativement un port volontairement interdit et une source non autorisée.
8. En HA, répéter un failover contrôlé avec une nouvelle connexion sans supposer qu’une session existante se poursuit sans interruption.

Un ping vers l’IP alias n’est pertinent que si Ping est volontairement autorisé pour la zone parente sous Device Access. Pour un service HTTPS publié, le test TCP et applicatif réel constitue une meilleure preuve de réussite. Packet Capture sur Sophos Firewall explique les filtres, la comparaison des interfaces et l’exportation.

Délimiter systématiquement les erreurs

L’alias est visible, mais injoignable depuis l’extérieur

• Confirmer que l’opérateur fournit réellement l’adresse précise via Port2.
• Comparer l’IP, le masque et l’interface parente avec l’attribution de l’opérateur.
• Vérifier l’entrée ARP ou de voisin sur l’équipement upstream.
• Examiner Device Access uniquement pour les accès au pare-feu lui-même.
• Pour les services transférés, vérifier Firewall Rule ID, NAT Rule ID et le chemin de retour du serveur.

Après le remplacement d’un pare-feu, le routeur upstream peut encore conserver l’ancienne adresse MAC pour l’IP alias. Sophos indique dans ce cas de vider le cache du routeur ou de redémarrer celui-ci. En pratique, actualiser d’abord uniquement l’entrée ARP ou de voisin concernée selon la procédure documentée de l’équipement upstream ; un redémarrage complet doit être effectué dans une fenêtre de maintenance.

Le trafic sortant utilise toujours l’adresse principale

Pour le trafic transféré, vérifier si la règle SNAT attendue correspond à une nouvelle connexion. Source, Destination, Service, Inbound interface, Outbound interface et NAT Rule ID doivent correspondre.

Pour le trafic système du pare-feu, une règle SNAT normale ne constitue pas la bonne preuve. Vérifier plutôt l’entrée sys-traffic-nat concernée, la route, la destination et le flux de paquets réel. Ne pas ajouter une traduction large sur la base d’une simple supposition.

Seul le second sous-réseau interne ne fonctionne pas

Vérifier que Sophos Firewall est réellement la passerelle par défaut des hôtes concernés et que l’équipement upstream possède une adresse adaptée dans ce sous-réseau. Contrôler ensuite séparément la route de retour, le masque de l’hôte, ARP, la règle de pare-feu et le NAT. Un alias visible ne prouve pas ces dépendances.

Le tunnel IPsec via un alias est actif, mais ne transporte aucun trafic

Relever d’abord la version et le build SFOS, le modèle d’appliance, l’utilisation de PPPoE, l’association de l’alias, IPsec Acceleration et le chemin réel des paquets. SFOS 22 comporte des cas particuliers d’alias et d’accélération liés à des versions précises, qui ne doivent pas être appliqués à chaque problème d’alias. La procédure de diagnostic délimitée figure dans Dépannage IPsec pour les interfaces alias.

Exploitation, matériel de remplacement et rollback

Documenter les adresses alias avec l’attribution de l’opérateur, DNS, les certificats, le NAT, les règles de pare-feu et le service responsable. Avant de remplacer un pare-feu, les alias publics et le changement ARP ou de voisin attendu doivent faire partie de la validation.

Pour un rollback :

1. Documenter les utilisations actives de l’alias et de l’IP Host associé.
2. Retirer de manière contrôlée les services publiés du DNS, de la supervision ou du load balancing.
3. Désactiver d’abord les règles de pare-feu et NAT associées et confirmer l’arrêt du flux prévu.
4. Supprimer toute entrée sys-traffic-nat avec la commande delete exacte.
5. Ne supprimer l’alias et l’objet hôte que lorsqu’il ne subsiste plus aucune dépendance en production.
6. Vérifier à nouveau l’interface parente, l’adresse principale, la passerelle et les services non concernés.
7. En HA, répéter la même validation après un failover planifié.

Un alias ne peut pas servir de Dedicated HA link. HA sur Sophos Firewall explique les interfaces, les adresses d’administration du pair et les tests de failover nécessaires à un cluster.

Liste de contrôle

• L’attribution de l’opérateur, l’interface parente, la version IP, l’adresse et le masque sont confirmés.
• Une sauvegarde et une connexion d’administration indépendante sont disponibles.
• Device Access et la Local Service ACL de la zone parente ont été vérifiés.
• L’alias et l’IP Host du même nom ne sont pas confondus.
• Les règles de pare-feu et NAT sont limitées au flux prévu.
• Le trafic système n’est traduit séparément que si le besoin est justifié.
• Firewall Rule ID, NAT Rule ID, ARP et les deux sens sont confirmés.
• Une source non autorisée et un service interdit ont été testés négativement.
• Le matériel de remplacement, le failover HA et le rollback sont documentés.

Questions fréquentes