Aller au contenu
Avanet

Configurer un VPN SSL Site-to-Site sur Sophos Firewall

Sophos Firewall

Un VPN SSL Site-to-Site relie les réseaux internes de deux Sophos Firewall par un tunnel chiffré. Contrairement à IPsec, les deux côtés ont un rôle fixe : le pare-feu client initie toujours la connexion et le pare-feu serveur l’accepte.

Cette solution est particulièrement adaptée lorsqu’une succursale possède une adresse IP publique dynamique ou qu’IPsec rencontre des difficultés dans un réseau en amont. Le siège disposant d’une adresse statique ou d’un FQDN stable devient le serveur, et la succursale devient le client. Pour des réseaux en croissance, le routage dynamique, la redondance ou un pair tiers, IPsec route-based est généralement plus flexible ; pour une petite liaison entre deux Sophos Firewall, SSL Site-to-Site peut être plus simple.

Ce guide utilise un exemple concret :

  • Siège, serveur : vpn.example.com, réseau local 10.10.0.0/24
  • Succursale, client : IP publique dynamique, réseau local 10.20.0.0/24
  • Connexion : HQ-to-Branch
  • Port SSL VPN : 8443

vpn.example.com, les noms d’objets et les deux réseaux sont des valeurs d’exemple à remplacer par celles de l’environnement réel. 8443 est le port par défaut ; il reste inchangé uniquement si l’affectation des ports et le design de sécurité le permettent.

Le déroulement rapide est le suivant : attribuer les rôles et les réseaux, contrôler les réglages SSL VPN globaux, autoriser SSL VPN dans la zone WAN du serveur, créer la connexion serveur, exporter le fichier .apc, l’importer sur le pare-feu client, puis vérifier les routes, les règles et le trafic applicatif réel.

⚠️ Les réglages SSL VPN globaux sont également utilisés par Remote Access SSL VPN. Il ne faut donc pas modifier le port, le protocole, le certificat, la plage d’adresses ou les réglages cryptographiques uniquement pour ce tunnel. Évaluer d’abord les effets sur les connexions et profils utilisateurs existants.

Planifier les rôles, les réseaux et l’accès public

Le pare-feu serveur devrait être l’appliance la plus stable et, si les modèles diffèrent, la plus puissante. Si un seul côté possède une adresse IP publique statique, ce côté doit assumer le rôle de serveur. Le client peut se trouver derrière un NAT ou utiliser une connexion avec une adresse dynamique, tant qu’il peut joindre le serveur.

Les points suivants doivent être définis avant la configuration :

  • adresse IP publique ou FQDN du pare-feu serveur ;
  • protocole et port pour SSL VPN ;
  • réseau local du siège et réseau local de la succursale ;
  • plages d’adresses uniques et sans chevauchement ;
  • services nécessaires et sens de connexion autorisés ;
  • chemin de retour des deux côtés ;
  • accès administratif alternatif pour le changement ;
  • versions SFOS actuelles sur les deux pare-feu.

Si les réseaux se chevauchent, cette configuration standard ne suffit pas. Il faut alors un design de traduction et de routage délibéré ; dans la pratique, IPsec avec un NAT planifié est généralement plus approprié.

Vérifier la compatibilité avant le changement

Depuis SFOS 20.0 MR1, Sophos utilise un composant OpenVPN plus récent. Les tunnels SSL Site-to-Site de SFOS 20.0 MR1 ou version ultérieure ne se connectent ni à SFOS 18.5 ou version antérieure, ni à UTM 9. Dans une telle combinaison, il faut mettre à jour les deux Sophos Firewall ou utiliser plutôt IPsec ou un tunnel RED.

Contrôler les réglages SSL VPN globaux

Les réglages communs se trouvent sur le futur pare-feu serveur sous :

Remote access VPN > SSL VPN > SSL VPN global settings

Pour cet exemple, contrôler en particulier les valeurs suivantes :

  • Protocol: UDP est généralement le choix initial le plus efficace ; TCP peut aider dans les réseaux restrictifs.
  • SSL server certificate: doit être valide et importé avec sa clé privée et la chaîne de certificats complète. Lorsqu’un FQDN public est utilisé, le certificat devrait correspondre à ce nom.
  • Override hostname: vpn.example.com si les clients doivent utiliser précisément ce FQDN.
  • Port: 8443, sauf si un autre design de ports a été planifié délibérément.
  • Assign IPv4 addresses: ne doit chevaucher ni les deux réseaux des sites ni d’autres pools VPN.
  • Cryptographic settings: ne pas modifier les valeurs existantes sans test de compatibilité et d’exploitation.

Si le pare-feu serveur se trouve derrière un routeur en amont, celui-ci doit transférer le port et le protocole choisis vers le pare-feu. Le FQDN pointe alors vers l’adresse publique du routeur. WAF et SSL VPN ne doivent pas utiliser la même combinaison d’adresse IP WAN, de port et de protocole.

Si Port, Protocol, SSL server certificate ou Override hostname change ultérieurement, télécharger de nouveau la configuration serveur et la réimporter sur le pare-feu client. L’export .apc existant ne contient pas les nouvelles valeurs.

SSL VPN Remote Access sur Sophos Firewall explique toutes les dépendances des réglages globaux. Les changements doivent être planifiés en tenant compte des profils utilisateurs existants, des plages d’adresses, du DNS et des services accessibles publiquement.

Autoriser SSL VPN pour la zone WAN du serveur

Sur le pare-feu serveur, autoriser le service SSL VPN local pour la zone entrante :

Administration > Device access

Si le pare-feu client possède une adresse publique dynamique ou qui ne peut pas être limitée utilement, activer SSL VPN pour WAN sous VPN services. Cela autorise uniquement l’établissement du tunnel vers le pare-feu ; cette option ne remplace pas une règle de pare-feu pour le trafic applicatif entre les sites.

Si les réseaux sources publics du côté client sont stables et connus, laisser SSL VPN désactivé dans la matrice WAN. Créer plutôt une Local Service ACL Exception ciblée avec l’action Accept, Source zone WAN, les Source Networks/Hosts connues, l’adresse WAN du serveur comme Destination host et SSL VPN comme Service. Une exception Accept ne restreint pas une autorisation déjà active dans la matrice WAN. Configurer Device Access de manière sécurisée sur Sophos Firewall explique la planification.

Créer la connexion serveur au siège

Créer d’abord les deux réseaux comme objets IP host sur le pare-feu serveur :

Hosts and services > IP host
  • HQ-LAN: 10.10.0.0/24
  • Branch-LAN: 10.20.0.0/24

Créer ensuite la connexion serveur :

  1. Ouvrir Site-to-site VPN > SSL VPN.
  2. Dans la section Server, cliquer sur Add.
  3. Saisir HQ-to-Branch comme nom.
  4. Sous Local networks, sélectionner HQ-LAN.
  5. Sous Remote networks, sélectionner Branch-LAN.
  6. Activer Use static virtual IP address uniquement si un besoin le justifie et choisir une adresse libre en dehors des plages SSL VPN statiques et dynamiques globales.
  7. Enregistrer avec Save.

Du point de vue du pare-feu serveur, Local networks désigne les réseaux du siège. Remote networks désigne les réseaux situés derrière le pare-feu client. Cette perspective est importante : si les objets sont inversés, le tunnel peut devenir vert alors que les routes et les règles ne correspondent pas à la liaison souhaitée.

Exporter la configuration serveur de manière sécurisée

Dans la liste des serveurs, sélectionner Download pour HQ-to-Branch. L’export utilise le format .apc et contient les données de connexion destinées au pare-feu client.

Pour un transfert sécurisé, activer Encrypt configuration file et définir un mot de passe temporaire robuste. Transmettre le fichier et le mot de passe par des canaux séparés. Le fichier .apc ne doit pas être placé dans un ticket public, un chat non protégé ou un répertoire de téléchargement permanent.

Importer la configuration sur le pare-feu client

Importer la configuration sur le pare-feu de la succursale sous le même chemin de menu :

  1. Ouvrir Site-to-site VPN > SSL VPN.
  2. Dans la section Client, cliquer sur Add.
  3. Saisir Branch-to-HQ comme nom.
  4. Sous Configuration file, sélectionner le fichier .apc exporté.
  5. Si l’export est chiffré, saisir le mot de passe.
  6. Activer Use HTTP proxy server uniquement si la succursale joint réellement le serveur via un proxy HTTP explicite.
  7. Définir Override peer hostname uniquement si l’adresse du serveur contenue dans l’export n’est ni routable ni résoluble depuis le réseau client. Dans cet exemple, le champ reste vide, car vpn.example.com est déjà exporté par le réglage global.
  8. Enregistrer avec Save et activer la connexion.

Le statut devient vert dès que le pare-feu client joint le serveur et établit le tunnel. Un statut vert confirme uniquement le tunnel lui-même, pas l’accès aux serveurs, au DNS ou aux applications.

Contrôler les routes et les règles de pare-feu

Les réseaux sélectionnés sous Local networks et Remote networks sont utilisés pour le routage du tunnel. Ils appartiennent à la classe de routage static et doivent correspondre au reste de la configuration de routage. Une route statique, SD-WAN ou VPN plus spécifique peut sinon produire un chemin différent de celui attendu. Comprendre et adapter la priorité de routage sur Sophos Firewall explique l’ordre.

Créer délibérément les règles de pare-feu pour le trafic applicatif sur les deux pare-feu, ou vérifier les règles existantes adaptées. Dans cet exemple, où la succursale initie les connexions vers le siège, il faut au minimum :

  • sur le pare-feu de la succursale, une règle restrictive de LAN vers VPN pour Branch-LAN vers les destinations nécessaires dans HQ-LAN ;
  • sur le pare-feu serveur, une règle correspondante de VPN vers LAN pour Branch-LAN vers ces destinations ;
  • uniquement les services nécessaires, par exemple DNS, RDP et HTTPS ;
  • Log firewall traffic pendant les tests d’acceptation ;
  • aucune règle SNAT ou MASQ qui modifie le trafic intersite sans raison technique valable.

Si le siège doit également initier de nouvelles connexions vers la succursale, autoriser séparément les sens inverses. Une règle Any large ne constitue pas un design de sécurité terminé. Tester une règle de pare-feu explique comment la position de la règle, Rule ID et Packet Capture fonctionnent ensemble.

Valider le tunnel et le trafic applicatif

Commencer le test avec un client précis et une destination précise. Dans cet exemple, un appareil de 10.20.0.0/24 accède à un serveur autorisé dans 10.10.0.0/24.

  1. Sur les deux pare-feu, vérifier que le statut est vert et que les compteurs d’octets augmentent.
  2. Tester la destination d’abord par adresse IP, puis par hostname.
  3. Ouvrir un service réellement autorisé, tel que HTTPS ou RDP.
  4. Dans Log Viewer, vérifier la Firewall Rule ID attendue et les adresses source et destination inchangées.
  5. Tester un service ou une destination non autorisé et confirmer le drop.
  6. Tester séparément le sens inverse s’il doit être autorisé.
  7. Après un redémarrage ou un changement de WAN, vérifier que le pare-feu client rétablit le tunnel.

Un ping réussi ne suffit pas. Il ne prouve ni le fonctionnement du DNS ni celui du service applicatif requis. Pour une destination interne, la règle de pare-feu, le chemin de retour et le pare-feu de l’endpoint doivent autoriser le test ; Device Access n’est pertinent que lors d’un ping vers une adresse de Sophos Firewall elle-même.

Lire les logs en cas d’erreur

Ouvrir directement les logs SSL VPN sous Site-to-site VPN > SSL VPN > Logs. Pour une analyse plus approfondie, se connecter par SSH, sélectionner 5. Device Management > 3. Advanced Shell, puis lire le log de service actuel :

tail -n 200 /log/sslvpn.log

La commande ne modifie pas la configuration. Consigner ensemble l’heure, le nom de la connexion et le côté serveur/client. Selon le nombre de processus, des fichiers d’état OpenVPN supplémentaires peuvent exister sous les noms openvpn-status0.log, openvpn-status1.log et suivants ; les logs de service Sophos Firewall expliquent leur attribution.

Cibler les erreurs courantes

  • Le tunnel reste rouge : Vérifier le FQDN public, le DNS, la redirection de port, le protocole, le certificat et SSL VPN dans Device Access pour la zone WAN du serveur. Lire ensuite sslvpn.log pour la même heure.
  • Le tunnel ne s’établit plus après un changement global : Exporter de nouveau la configuration serveur et la réimporter sur le client. Le port, le protocole, le certificat et Override hostname, en particulier, dépendent de l’export.
  • Le tunnel est vert, mais aucun trafic ne passe : Vérifier le routage du tunnel, la priorité de routage, les règles sur les deux pare-feu, Rule ID, le chemin de retour, NAT et le pare-feu de l’endpoint. Suivre ensuite un flux unique avec Packet Capture.
  • Seuls les hostnames ne fonctionnent pas : Tester l’accès par IP, vérifier les serveurs DNS et le domaine de recherche, puis s’assurer que le serveur DNS est joignable et autorisé à travers le tunnel.
  • Un objet FQDN host pointe encore vers l’ancienne adresse : Les FQDN hosts et groups sont pris en charge comme réseaux locaux et distants. Après une modification DNS, déconnecter et reconnecter le tunnel de manière contrôlée, puis vérifier la route et le trafic applicatif vers la nouvelle adresse IP résolue. Un échec de résolution est d’abord un problème de trafic ou de routage, pas automatiquement un problème d’établissement du tunnel.
  • Le client ne peut joindre le serveur que via un proxy : Utiliser Use HTTP proxy server avec les valeurs de proxy approuvées ; ne pas saisir des paramètres de proxy arbitraires comme solution générique.
  • Un côté utilise SFOS 18.5 ou UTM 9 : Ne pas poursuivre les recherches sur le port ou le certificat. Cette combinaison est incompatible avec un pair actuel ; mettre à jour les deux côtés ou utiliser IPsec ou RED.

Si le tunnel reste difficile à interpréter après un test contrôlé, collecter la version et le build SFOS des deux pare-feu, l’heure avec le fuseau horaire, le nom de la connexion, sslvpn.log, les Rule IDs et un court Packet Capture. Ce n’est qu’ensuite qu’il faut modifier davantage les règles, les réseaux ou les réglages SSL VPN globaux.