Configurer Sophos Connect sur Sophos Firewall

Sophos Connect est le client standard pour le Remote Access avec Sophos Firewall dans de nombreux environnements. La qualité réelle de la solution ne se décide toutefois pas seulement sur Windows ou macOS, mais sur la firewall : autorisation des utilisateurs, pool IP, DNS, authentification, MFA, règles firewall et distribution ultérieure des profils doivent être cohérents.

Cet article décrit la planification et la configuration côté firewall pour Sophos Connect, surtout pour IPsec Remote Access et la mise à disposition des profils. Pour SSL VPN, la véritable policy Remote Access est décrite dans l’article Configurer Sophos Firewall SSL VPN Remote Access. Pour choisir entre IPsec, SSL VPN, clients mobiles et ZTNA, commencez par Sophos Connect ou SSL VPN : quelle solution Remote Access convient ?.

Quel article utiliser ?

Selon la tâche, un autre point d’entrée est plus adapté :

• Planifier Sophos Connect côté firewall pour IPsec: Cet article
• Configurer SSL VPN Remote Access sur la firewall: Configurer Sophos Firewall SSL VPN Remote Access
• Utiliser Microsoft Entra ID SSO pour Sophos Connect: Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal
• Installer Sophos Connect sur Windows ou macOS: Windows ou macOS
• Piloter les versions client et les changements de profil en exploitation: Vérifier et mettre à jour en sécurité la version du Sophos Connect Client
• Analyser les problèmes de connexion dans le tunnel: Troubleshooting Sophos Firewall IPsec VPN

Cette séparation est importante, car Sophos Connect touche plusieurs éléments : configuration IPsec, configuration SSL VPN, VPN Portal, provisioning, authentification, version client et règles firewall.

Prérequis

• Sophos Firewall avec une version SFOS prise en charge
• accès administrateur à l’interface WebAdmin
• utilisateurs ou groupes définis pour le Remote Access
• plage d’adresses IP libre pour les clients VPN
• serveurs DNS internes si des noms internes doivent être résolus
• concept MFA pour le Remote Access
• réseaux et services cibles clarifiés, qui doivent être joignables via VPN
• procédure claire pour la distribution des profils, les changements de profil et les mises à jour client

Si la firewall doit être mise à jour vers SFOS 22.0 MR1 ou une version plus récente, il faut d’abord vérifier si Legacy Remote Access IPsec existe encore. Cette ancienne configuration peut bloquer la mise à niveau. La procédure est décrite dans Migrer Legacy Remote Access IPsec avant SFOS 22 MR1.

Dans les versions SFOS actuelles, la configuration IPsec Remote Access se trouve sous Remote access VPN > IPsec. Dans les anciennes interfaces ou les anciens guides, on trouve encore des chemins comme VPN > Sophos Connect Client. Les captures existantes et les anciens environnements clients peuvent donc présenter des libellés différents.

Planifier avant la configuration

Avant l’activation, il est utile de documenter brièvement comment le Remote Access sera exploité. Cela évite des erreurs typiques comme des pools IP qui se chevauchent, des règles firewall trop larges ou des profils qui ne sont pas redistribués après une modification.

Questions de planification importantes :

• Utilisateurs: Utilisateurs locaux, groupe AD, RADIUS ou autre authentification
• MFA: OTP/MFA actif, testé et documenté pour les processus helpdesk
• Pool IP: pool dédié sans chevauchement avec LAN, WLAN, VLAN, Site-to-Site VPN ou réseaux domestiques
• DNS: serveurs DNS internes et domaines de recherche si des FQDN internes sont utilisés
• Accès: autoriser uniquement les serveurs, réseaux et services nécessaires
• Distribution client: .scx, .tgb, .ovpn, .pro, distribution logicielle, état de version et solution de repli
• Exploitation: Log Viewer, processus support, changements de profil et départs

Pour les bases MFA, voir Configurer Sophos Firewall MFA. Si le Remote Access passe plus tard par Microsoft Entra ID SSO, RADIUS ou AD, la chaîne d’authentification doit aussi être testée séparément.

Types de profils et mise à disposition

Avant la configuration, il faut savoir clairement quel fichier sera utilisé sur quel client. Cela évite de nombreux cas de support.

• .scx: Sophos Connect pour IPsec Remote Access contient aussi les paramètres avancés de Sophos Connect
• .tgb: configuration IPsec pour anciens clients ou clients tiers ne contient pas les paramètres avancés de Sophos Connect
• .ovpn: SSL VPN pour Sophos Connect ou clients compatibles OpenVPN provient de la configuration SSL VPN ou du VPN Portal
• .pro: fichier de provisioning pour import automatique charge les configurations via le VPN Portal après connexion réussie

Pour les nouveaux déploiements Sophos Connect IPsec, .scx est généralement le meilleur standard, car il contient les paramètres avancés de la firewall. .tgb ne devrait être utilisé volontairement que lorsqu’un client tiers ou un ancien processus l’exige.

Le provisioning peut simplifier la distribution, mais augmente la dépendance au VPN Portal. Si des utilisateurs doivent utiliser le fichier de provisioning depuis Internet, le VPN Portal doit être joignable depuis la zone nécessaire. Cela se configure sous Administration > Device access et doit être durci consciemment dans la Local Service ACL, car un portail joignable depuis le WAN crée une surface d’attaque supplémentaire. Pour le durcissement, voir Device Access et Local Service ACL sur Sophos Firewall.

Activer Sophos Connect

Dans l’interface WebAdmin, ouvrir Remote access VPN > IPsec. Dans les anciennes interfaces, le chemin peut encore être VPN > Sophos Connect Client. L’affichage exact peut varier légèrement selon la version SFOS, mais les décisions de base restent similaires.

1. Activer Connect Client

Activer IPsec Remote Access. Régler ensuite les autres paramètres et ne pas déployer immédiatement en production.

2. Choisir l’interface externe

L’interface est généralement l’interface WAN par laquelle les connexions Remote Access atteignent la firewall. Avec plusieurs accès WAN, il faut décider consciemment quel accès est stable pour le VPN, documenté et joignable depuis Internet.

À vérifier :

• IP publique ou DynDNS/FQDN correct disponible
• redirections de ports et routeurs en amont adaptés
• comportement du WAN failover connu
• Device Access et ACLs de service locales n’autorisent que les services nécessaires
• VPN Portal joignable uniquement là où il est réellement nécessaire pour le téléchargement ou le provisioning

Remote Access est un point d’entrée joignable publiquement. Le simple fonctionnement ne suffit donc pas ; accès, MFA et logging doivent être pris en compte.

Pour le durcissement des services firewall joignables, voir Device Access et Local Service ACL sur Sophos Firewall.

3. Choisir l’authentification

Pour IPsec Remote Access, différents modèles d’authentification sont disponibles selon la version SFOS et la configuration. Preshared Key et certificat sont souvent les options pertinentes.

Classement pratique :

• Preshared Key est rapide à mettre en place, mais doit être forte, protégée et renouvelée en cas de soupçon.
• Certificat est plus propre pour les environnements contrôlés, mais nécessite une gestion des certificats et des processus clairs.
• MFA ne remplace ni PSK ni certificat, mais protège en plus la connexion utilisateur.

Si la Preshared Key a été distribuée dans plusieurs profils, un changement est plus lourd opérationnellement. La clé ne doit donc pas être traitée comme une valeur jetable.

Pour les certificats, il faut aussi vérifier si type de certificat, durée de validité, clés privées et client cible sont cohérents. Les certificats RSA sont particulièrement pertinents pour IPsec Remote Access. Un changement de certificat est toujours aussi un sujet de profil et de rollout.

4. Vérifier Local ID et Remote ID

Local ID et Remote ID sont facultatifs, mais peuvent être importants avec plusieurs tunnels ou des pairs particuliers. S’ils sont définis, ils doivent correspondre au profil utilisé et à la configuration client.

Valeurs typiques :

• nom DNS
• adresse IP
• email
• certificat

Dans les configurations simples, ces champs restent souvent vides. Si des erreurs comme no IKE config found ou des problèmes de proposal/ID apparaissent plus tard, cette zone doit être contrôlée. Pour une analyse plus poussée, Troubleshooting Sophos Firewall IPsec VPN est l’article de suite approprié.

5. Affecter utilisateurs et groupes

Sélectionner uniquement les utilisateurs ou groupes qui ont réellement besoin de Remote Access. En production, un groupe VPN dédié est généralement préférable à un large groupe standard.

À vérifier :

• Le groupe ne contient que des utilisateurs autorisés.
• Les utilisateurs sortants sont supprimés.
• MFA est actif et testé pour ces utilisateurs.
• Le helpdesk sait comment bloquer, débloquer ou reprovisionner des utilisateurs.

Les guest users n’ont pas leur place dans Remote Access. Pour les environnements productifs, un groupe VPN dédié est meilleur qu’un large groupe standard issu du service d’annuaire.

Configurer les données client

6. Attribuer un nom

Le nom de connexion doit être compréhensible pour les utilisateurs et le support. Des noms comme homeoffice, remote-access-ipsec ou un nom de site sont plus utiles que des abréviations internes.

Si plusieurs profils sont distribués, le nommage doit rester cohérent. Cela réduit les confusions dans le Sophos Connect Client.

7. Définir le pool IP

La firewall attribue aux clients VPN une adresse issue du pool défini. Cette plage ne doit pas se chevaucher avec les réseaux internes, d’autres pools VPN, les réseaux Site-to-Site ou des plages domestiques courantes.

Bonnes pratiques :

• plage d’adresses séparée uniquement pour Remote Access
• taille suffisante pour les utilisateurs simultanés
• pas de chevauchement avec 192.168.0.0/24, 192.168.1.0/24 ou les plages domestiques fréquentes si cela est évitable
• documentation claire dans l’IPAM ou la documentation réseau

Si le pool est modifié plus tard, profils et tests doivent être revérifiés.

Pour IPsec Remote Access, le pool doit au moins être planifié proprement comme sous-réseau dédié. Il ne doit pas non plus se chevaucher avec d’autres pools Remote Access comme SSL VPN, L2TP ou PPTP.

8. Saisir les serveurs DNS

Si les utilisateurs doivent accéder aux systèmes internes par nom, des serveurs DNS adaptés et, le cas échéant, des domaines de recherche doivent être distribués. Dans beaucoup d’environnements, il s’agit d’un Domain Controller interne ou d’un serveur DNS dédié.

Des résolveurs externes comme Cloudflare, Google, Quad9 ou OpenDNS ne résolvent pas les zones internes. Ils ne sont utiles que si aucun nom interne n’est nécessaire via le tunnel VPN ou si le DNS est volontairement résolu autrement.

Exemples de résolveurs externes :

• Cloudflare: 1.1.1.1 et 1.0.0.1
• Google: 8.8.8.8 et 8.8.4.4
• Quad9: 9.9.9.9 et 149.112.112.112
• OpenDNS: 208.67.222.222 et 208.67.220.220

Pour le Remote Access productif, il est généralement plus important que les FQDN internes fonctionnent de manière fiable. Si le DNS n’est pas planifié proprement, le tunnel semble “connecté” pour les utilisateurs alors que les applications ne sont pas utilisables.

Vérifier les paramètres avancés

9. Définir le Session Timeout

Un Session Timeout empêche les connexions VPN inutilisées de rester ouvertes indéfiniment. Des valeurs trop agressives peuvent toutefois créer des cas de support, car les utilisateurs doivent se reconnecter après de courtes interruptions.

Une valeur utile correspond au modèle de travail :

• timeouts courts pour des accès administrateur sporadiques
• timeouts plus longs pour des sessions de travail stables
• communication claire si les utilisateurs doivent se reconnecter après inactivité

Si OTP/MFA est utilisé, l’effet sur les reconnexions doit aussi être testé.

Si la firewall déconnecte un client idle, le Sophos Connect Client peut reconstruire la connexion en arrière-plan. Si cela échoue, l’utilisateur doit déconnecter consciemment la connexion dans le client puis se reconnecter. Ce comportement doit être connu dans le processus helpdesk.

10. Régler consciemment les Advanced settings

Les paramètres avancés déterminent le comportement quotidien du client. Pour IPsec Remote Access, ils sont repris dans le fichier .scx, pas dans le fichier .tgb.

Points importants :

• Use as default gateway: Tout le trafic Internet doit-il passer par la firewall ou seulement les ressources internes ?
• Permitted network resources: Quels réseaux internes peuvent réellement être atteints via le tunnel ?
• Send Security Heartbeat through tunnel: Sophos Endpoint/Synchronized Security est-il utilisé et Heartbeat doit-il passer par VPN ?
• Allow users to save username and password: La connexion enregistrée est-elle compatible avec le concept MFA et sécurité ?
• Prompt users for 2FA token: OTP doit-il apparaître dans un champ séparé ou être combiné dans le champ du mot de passe ?
• Run AD logon script after connecting: Les logon scripts comme les mappages de lecteurs sont-ils réellement nécessaires et testés ?
• Connect tunnel automatically: Le tunnel doit-il être établi automatiquement à la connexion utilisateur ?

Avec Full Tunnel via Use as default gateway, il faut en plus une règle firewall de VPN vers WAN et une conception consciente NAT/Security Policy. Avec Split Tunnel, les ressources internes autorisées doivent être documentées proprement.

Si Prompt users for 2FA token est actif, l’utilisation est souvent plus claire pour les utilisateurs. En même temps, il faut vérifier si les outils ou automatisations utilisés fonctionnent avec ce paramètre.

11. Enregistrer et exporter la configuration

Après l’enregistrement, la configuration de connexion est exportée. Selon le client et la version SFOS, des fichiers .scx, .tgb ou de provisioning peuvent être pertinents. Le fichier ne doit pas être stocké ouvertement ni transmis à des personnes non autorisées.

Après des changements de groupe utilisateur, pool, DNS, profil, gateway, port, certificat ou Advanced Settings, les clients concernés doivent recevoir la configuration actualisée. Les anciens profils sont une cause fréquente de problèmes VPN difficiles à comprendre.

Si le provisioning est utilisé, il faut aussi vérifier si le client recharge automatiquement les changements ou si les utilisateurs doivent actualiser la policy dans Sophos Connect Client ou se reconnecter. Les changements de port SSL VPN, gateway, certificat serveur ou protocole sont des cas typiques où une nouvelle connexion ou une étape de mise à jour consciente peut être nécessaire.

Configurer les règles firewall

Sophos Connect établit seulement le tunnel. L’accès aux systèmes internes reste contrôlé par les règles firewall. Sans règles adaptées, la connexion peut être verte sans qu’un accès productif fonctionne.

Pour l’accès des clients VPN aux systèmes internes, on crée typiquement une règle de VPN vers LAN ou vers une zone cible spécifique.

• Source Zone: VPN
• Destination Zone: LAN

Une règle limitée aux réseaux ou services réellement nécessaires est généralement meilleure qu’une autorisation large vers tout le LAN. Le logging doit être activé pendant la phase d’introduction afin que les erreurs soient visibles dans le Log Viewer.

Si le client fonctionne en Full Tunnel et que le trafic Internet doit aussi passer par la firewall, il faut en plus une règle de VPN vers WAN et une conception consciente NAT/Security Policy.

• Source Zone: VPN
• Destination Zone: WAN

Pour la recherche d’erreurs dans les règles, Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture est utile.

Les règles firewall ne doivent pas seulement “fonctionner”, elles doivent être vérifiables. Pour la phase d’introduction, le logging sur les règles Remote Access est utile. Plus tard, il est possible de décider quelles règles seront loggées durablement et quels événements doivent aussi être envoyés à Sophos Central ou Syslog.

Tester après le rollout

Un statut Sophos Connect vert ne suffit pas comme test d’acceptation. Au minimum, les points suivants doivent être vérifiés avec un utilisateur de test :

• Le client importe la configuration sans erreur.
• La connexion fonctionne avec mot de passe et MFA.
• Le client reçoit une adresse du pool VPN attendu.
• Les noms DNS internes sont résolus correctement.
• Les systèmes internes centraux sont joignables.
• Log Viewer affiche la règle firewall attendue.
• Split Tunnel ou Full Tunnel se comporte comme prévu.
• La reconnexion après changement de réseau fonctionne.
• Les anciens profils n’ont pas été réutilisés.
• Avec Full Tunnel, l’accès Internet via la firewall fonctionne comme prévu.
• Avec Split Tunnel, les destinations non autorisées restent bloquées.
• Log Viewer affiche des hits sur les règles attendues.
• Avec le provisioning, les changements de profil sont mis à jour de manière traçable.

Ensuite, les guides d’installation pour Windows et macOS peuvent être utilisés.

Checklist d’exploitation

Après le rollout technique, l’exploitation ne doit pas rester ouverte :

• Groupe VPN responsable documenté.
• Le processus de départ supprime les utilisateurs des groupes Remote Access.
• Le processus de réinitialisation MFA est connu.
• Version du profil ou date de modification documentée.
• Le helpdesk sait quels profils sont actuels.
• Log Viewer et journaux de service pertinents sont connus.
• Les changements de pool IP, DNS, gateway, certificat et Advanced Settings déclenchent une vérification du profil.
• Avant les mises à niveau SFOS, Legacy Remote Access IPsec et les profils client sont vérifiés.

Troubleshooting

La connexion s’établit, mais aucun trafic ne passe

La cause n’est souvent pas le tunnel, mais les règles firewall, le NAT, le routage, le DNS ou le chemin de retour. Vérifier d’abord dans le Log Viewer si le trafic depuis la zone VPN touche la règle attendue. Ensuite, affiner avec Packet Capture ou Policy Test.

L’utilisateur ne peut pas se connecter

Vérifier le groupe utilisateur, le serveur d’authentification, MFA, l’utilisateur bloqué et l’état du mot de passe. Si AD, RADIUS ou Microsoft Entra ID SSO est impliqué, l’authentification doit être testée séparément du VPN.

Le client utilise une ancienne configuration

Après des changements de pool IP, DNS, groupe utilisateur, profil, gateway, certificat ou Advanced Settings, la configuration doit être redistribuée ou réimportée. Les anciens fichiers .tgb, .scx, .ovpn ou de provisioning ne doivent pas rester en circulation en parallèle.

Le provisioning ne fonctionne pas

Vérifier d’abord si le VPN Portal est joignable depuis la zone nécessaire et si Device Access a été défini consciemment. Contrôler ensuite la valeur gateway, le port du portail, le certificat, la connexion utilisateur, MFA et, avec Entra SSO, l’affectation sous Authentication > Services.

SSO ne fonctionne que partiellement

Avec Microsoft Entra ID SSO, VPN Portal, IPsec et SSL VPN doivent correspondre au bon serveur Entra ID selon le workflow. Avec le provisioning, la valeur gateway doit correspondre à la Redirect URI de la configuration Entra. Si seuls certains utilisateurs sont concernés, vérifier aussi UPN, adresse e-mail, mapping de groupes et groupes utilisateurs importés.

La connexion est établie, mais les gros transferts se bloquent

Si login, DNS et petits accès fonctionnent, mais que de plus grands transferts de fichiers ou certaines applications se bloquent, MTU/MSS doit être vérifié. Le symptôme correspond souvent à une fragmentation, PPPoE, des connexions tunnelisées ou un chemin asymétrique. La procédure est décrite dans Vérifier MTU et MSS sur Sophos Firewall en cas de problèmes VPN.

IPsec se coupe dans des réseaux tiers

IPsec peut être bloqué dans les hôtels, WLAN invités, réseaux mobiles ou réseaux d’entreprise très filtrés. Dans ces cas, il faut vérifier si SSL VPN Remote Access, ZTNA ou une autre conception Remote Access convient mieux.

Full Tunnel n’a pas d’accès Internet

Si Use as default gateway est actif, le trafic de VPN vers WAN doit être autorisé et traité avec un NAT adapté. Web Protection, Application Control, DNS et logging doivent aussi être planifiés consciemment comme pour les autres réseaux clients.

FAQ