Précisions sur les cas d'utilisation

VPN IPsec

VPN IPsec IKEv2

Lorsqu'un tunnel IPsec IKEv2 établi avec un correspondant nomade en mode CONFIG est interrompu brutalement par le client distant, l'adresse IP qui lui a été attribuée reste verrouillée et indisponible. Vous pouvez maintenant changer ce comportement en modifiant le paramètre UniqueIDs dans le fichier de configuration ~/ConfigFiles/VPN/0x (où x représente le numéro de la politique IPsec).

Par exemple, pour permettre à un utilisateur de retrouver sa précédente adresse IP, ajoutez le paramètre UniqueIDs=no dans la section du correspondant concerné, puis rechargez la configuration de la politique VPN avec la commande CLI / SSH envpn -u (interrompt les tunnels en cours).
Le protocole EAP (Extensible Authentication Protocol) ne peut pas être utilisé pour l’authentification de correspondants IPsec utilisant le protocole IKEv2.
Dans une configuration mettant en œuvre un tunnel IPsec basé sur le protocole IKEv2 et de la translation d’adresse, l’identifiant présenté par la machine source au correspondant distant pour établir le tunnel correspond à son adresse IP réelle et non à son adresse IP translatée. Il est donc conseillé de forcer l’identifiant local à présenter (champ Local ID dans la définition d’un correspondant IPsec IKEv2) en utilisant l’adresse translatée (si celle-ci est statique) ou un FQDN porté par le firewall source.
Il n’est pas possible de définir une configuration de secours pour les correspondants IPsec utilisant le protocole IKEv2. Pour mettre en œuvre une configuration IPsec IKEv2 redondante, il est conseillé d’utiliser des interfaces virtuelles IPsec et des objets routeurs dans les règles de filtrage (PBR).

Interruption de négociation d'une phase 2

Le moteur de gestion IPsec Charon, utilisé dans le cadre de politiques IKEv1, peut interrompre tous les tunnels avec le même correspondant si une seule phase 2 échoue. Cela est dû à l'absence de notification de la part du correspondant suite à un échec de négociation lié à une différence d'extrémités de trafic.

Le comportement du moteur de gestion IPsec Racoon a été modifié en version 3.11.1 afin que cela ne se produise pas dans le cadre d'un tunnel Racoon <=> Charon. Vous pouvez néanmoins être confronté à ce problème dans le cas où le moteur de gestion IPsec Charon négocie avec un équipement qui n'émet pas de notification d'échec.

Utilisation de correspondants de secours obsolète

L'utilisation de correspondants de secours (désigné en tant que "Configuration de secours") est obsolète et disparaîtra dans une future version de SNS. Un message d'avertissement est maintenant affiché pour encourager les administrateurs à modifier leur configuration.

Pour ce cas d'usage, privilégiez l'utilisation d'interfaces IPsec virtuelles avec des objets routeurs ou du routage dynamique.

IPsec - Politique mixte IKEv1 / IKEv2

L'utilisation de correspondants IKEv1 et IKEv2 au sein d'une même politique IPsec entraîne plusieurs restrictions ou obligations :

Le mode de négociation "agressif" n'est pas autorisé pour un correspondant IKEv1 avec authentification par clé pré-partagée. Un message d'erreur est affiché lors de la tentative d'activation de la politique IPsec.
La méthode d'authentification "Hybride" ne fonctionne pas pour un correspondant nomade IKEv1.
Les correspondants de secours sont ignorés. Un message d'avertissement est affiché lors de l'activation de la politique IPsec.
L'algorithme d'authentification "non_auth" n'est pas supporté pour un correspondant IKEv1. Dans un tel cas, la politique IPsec ne peux pas être activée.
Dans une configuration mettant en œuvre du NAT-T (NAT-Traversal - Passage du protocole IPsec au travers d'un réseau réalisant de la translation d'adresses dynamique), il est impératif de définir l'adresse IP translatée comme identifiant d'un correspondant utilisant l'authentification par clé pré-partagée et pour lequel un ID local sous la forme d'une adresse IP aurait été forcé.

Déchiffrement

La répartition du déchiffrement des données est réalisée par correspondant IPsec. Sur les firewalls multi-processeur, ce traitement est donc optimisé lorsque le nombre de correspondants est au moins égal au nombre de processeurs du boitier.

Référence support 37332

DPD (Dead Peer Detection)

La fonctionnalité VPN dite de DPD (Dead Peer Detection) permet de vérifier qu’un correspondant est toujours opérationnel en envoyant des messages ISAKMP.

Si un firewall est répondeur d'une négociation IPsec en mode principal, et a configuré le DPD en « Inactif », ce paramètre sera forcé en « passif » pour répondre aux sollicitations DPD du correspondant. En effet, pendant cette négociation IPsec, le DPD est annoncé avant d'avoir identifié le correspondant, et donc avant de connaître si les requêtes DPD peuvent être ignorées pour ce correspondant.

Ce paramètre n’est pas modifié en mode agressif, car dans ce cas le DPD est négocié lorsque le correspondant est déjà identifié, ou dans le cas où le firewall est initiateur de la négociation.

PKI

La présence d’une liste des certificats révoqués (CRL) n’est pas requise. Si aucune CRL n’est trouvée pour l’autorité de certification (CA), la négociation sera autorisée

Keepalive IPv6

Pour les tunnels IPsec site à site, l’option supplémentaire keepalive, permettant de maintenir ces tunnels montés de façon artificielle, n’est pas utilisable avec des extrémités de trafic adressées en IPv6. Dans le cas d’extrémités de trafic configurées en double pile (adressage IPv4 et IPv6), seul le trafic IPv4 bénéficiera de cette fonctionnalité.

Politique nomade

Dans une politique IPsec nomade contenant plusieurs correspondants et utilisant l'authentification par certificats :

Les correspondants doivent utiliser le même profil de chiffrement IKE,
Les certificats des différents correspondants doivent être issus d'une même CA.

Réseau

Modems 4G

La connectivité du firewall à un modem USB 4G nécessite l'utilisation d'un équipement de marque HUAWEI dans la liste suivante :

E3372h-153,
E8372h-153.

D'autres modèles de clés pourraient fonctionner, mais ils n'ont pas été testés.

Protocoles Spanning Tree (RSTP / MSTP)

Les firewalls Stormshield Network ne supportent pas les configurations multi-régions MSTP. Un firewall implémentant une configuration MSTP et positionné en interconnexion de plusieurs régions MSTP pourrait ainsi rencontrer des dysfonctionnements dans la gestion de sa propre région.

Un firewall ayant activé le protocole MSTP, et ne parvenant pas à dialoguer avec un équipement qui ne supporte pas ce protocole, ne bascule pas automatiquement sur le protocole RSTP.

Le fonctionnement des protocoles RSTP et MSTP nécessite que les interfaces sur lesquelles ils sont appliqués disposent d’une couche Ethernet. En conséquence :

Le protocole MSTP ne supporte pas les modems PPTP/PPPoE,
Le protocole RSTP ne supporte ni les Vlans, ni les modems PPTP/PPPoE.

Interfaces

Sur les firewalls modèle SN160(W) et SN210(W), la présence d’un switch interne non administrable entraîne l’affichage permanent des interfaces réseau du firewall en état « up », même lorsque celles-ci ne sont pas connectées physiquement au réseau.

Les interfaces du firewall (VLAN, interfaces PPTP, interfaces agrégées [LACP], etc.) sont désormais rassemblées dans un pool commun à l’ensemble des modules de configuration. Lorsqu’une interface précédemment utilisée dans un module est libérée, elle ne devient réellement réutilisable pour les autres modules qu’après un redémarrage du firewall.

La suppression d'une interface VLAN provoque un ré-ordonnancement de ce type d'interfaces au redémarrage suivant. Si ces interfaces sont référencées dans la configuration du routage dynamique ou supervisées via la MIB-II SNMP, ce comportement induit un décalage et peut potentiellement provoquer un arrêt de service. Il est donc fortement conseillé de désactiver une interface VLAN non utilisée plutôt que de la supprimer.

L'ajout d'interfaces Wi-Fi dans un bridge est en mode expérimental et ne peut pas s'effectuer via l'interface graphique. Sur les modèles SN160(W), une configuration comportant plusieurs VLAN inclus dans un bridge n’est pas supportée.

Une configuration avec un bridge incluant plusieurs interfaces non protégées et une route statique sortant de l'une de ces interfaces (autre que la première) n'est pas supportée.

Routage dynamique Bird

Le moteur de routage dynamique Bird ayant été mis à jour en version 1.6, il est nécessaire, dans les configurations implémentant le protocole BGP avec de l'authentification, d'utiliser l'option "setkey no". Pour de plus amples informations sur la configuration de Bird, veuillez consulter la Note Technique "Routage dynamique Bird".

Lorsque le fichier de configuration de Bird est édité depuis l’interface d’administration Web, l’action « Appliquer » envoie effectivement cette configuration au firewall. En cas d’erreur de syntaxe, un message d’avertissement indiquant le numéro de ligne en erreur informe de la nécessité de corriger la configuration.

En revanche, une configuration erronée envoyée au firewall sera prise en compte au prochain redémarrage du service Bird ou du firewall.

Système

Référence support 80692

Accès aux modules de configuration

Après la mise à jour d'un firewall, l'accès à certains modules de configuration peut être impossible et générer une erreur si les préférences d'affichage des modules ont été grandement modifiées (colonnes affichées, ordre, etc.) ou si une préférence d'affichage enregistrée n'existe plus dans la nouvelle version.

Pour rétablir l'accès aux modules de configuration concernés, il est nécessaire de restaurer les paramètres par défaut des préférences utilisateur depuis le module Préférences.
En savoir plus

Référence support 78677

Cookies générés pour l’authentification multi-utilisateurs

Suite à l’implémentation d'une nouvelle politique de sécurité sur les navigateurs Web du marché, l’authentification multi-utilisateurs SNS n’est plus fonctionnelle dans le cas où un site non sécurisé (via HTTP) est consulté.

Ce comportement aboutit à l'affichage d’un message d'erreur ou d'un avertissement selon le navigateur Web utilisé, et est lié au fait que les cookies d’authentification du proxy ne peuvent pas utiliser l'attribut "Secure" conjointement à l’attribut “SameSite” dans le cadre d'une connexion non sécurisée HTTP.

Pour rétablir la navigation sur ces sites, une opération manuelle doit être effectuée dans la configuration du navigateur Web.
En savoir plus

Référence support 51251

Serveur DHCP

Lors de la réception d'une requête DHCP de type INFORM émise par un client Microsoft, le firewall envoie au client son propre serveur DNS primaire accompagné du serveur DNS secondaire paramétré dans le service DHCP. Il est conseillé de désactiver le protocole Web Proxy Auto-Discovery Protocol (WPAD) sur les clients Microsoft afin d'éviter ce type de requêtes.

Migration

La mise à jour vers une version majeure de firmware provoque une réinitialisation des préférences de l’interface Web d’administration (exemple : filtres personnalisés).

Mises à jour vers une version antérieure

Les firewalls livrés en version 3 de firmware ne sont pas compatibles avec les versions majeures antérieures.

Le retour à une version majeure de firmware antérieure à la version courante du firewall nécessite préalablement une remise en configuration d’usine du firewall (defaultconfig). Ainsi par exemple, cette opération est nécessaire pour la migration d’un firewall d’une version 3.0.1 vers une version 2.x.

Référence support 3120

Configuration

Le client NTP des firewalls ne supporte la synchronisation qu’avec les serveurs utilisant la version 4 du protocole.

Restauration de sauvegarde

Si une sauvegarde de la configuration a été réalisée sur un firewall dont la version du système est postérieure à la version courante, il ne sera alors pas possible de restaurer cette configuration. Ainsi par exemple, il n'est pas possible de restaurer une configuration sauvegardée en 3.0.0, si la version courante du firewall est la 2.5.1.

Objets dynamiques

Les objets réseau en résolution DNS automatique (dynamic), pour lesquels le serveur DNS propose un type de répartition de charge round-robin, provoquent le rechargement de la configuration des modules uniquement si l'adresse actuelle n'est plus présente dans les réponses.

Objets de type Nom DNS (FQDN)

Les objets de type Nom DNS ne peuvent pas être membres d'un groupe d'objets.

Une règle de filtrage ne peut s'appliquer qu'à un unique objet de type Nom DNS. Il n'est donc pas possible d'y ajouter un second objet de type FQDN ou un autre type d'objet réseau.

Les objets de type Nom DNS ne peuvent pas être utilisés dans une règle de NAT. Notez qu'aucun avertissement n'est affiché lorsqu'une telle configuration est réalisée.

Lorsque aucun serveur DNS n'est disponible, l'objet de type Nom DNS ne contiendra que l'adresse IPv4 et/ou IPv6 renseignée lors de sa création.

Si un nombre important de serveurs DNS est renseigné dans le firewall, ou si de nouvelles adresses IP concernant un objet de type Nom DNS sont ajoutées au(x) serveur(s) DNS, l'apprentissage de l'ensemble des adresses IP de l'objet peut nécessiter plusieurs requêtes DNS de la part du firewall (requêtes espacées de 5 minutes).

Si les serveurs DNS renseignés sur les postes clients et sur le firewall diffèrent, les adresses IP reçues pour un objet de type Nom DNS peuvent ne pas être identiques. Ceci peut, par exemple, engendrer des anomalies de filtrage si l'objet de type DNS est utilisé dans la politique de filtrage.

Journaux de filtrage

Lorsqu’une règle de filtrage fait appel au partage de charge (utilisation d’un objet routeur), l’interface de destination référencée dans les journaux de filtrage n’est pas forcément correcte. En effet, les traces de filtrage étant écrites dès qu’un paquet réseau correspond aux critères de cette règle, l’interface de sortie n’est alors pas encore connue. C’est donc la passerelle principale qui est systématiquement reportée dans les journaux de filtrage.

Qualité de service

Les flux réseaux auxquels sont appliquées des files d’attente de qualité de service (QoS) ne tirent pas entièrement bénéfice des améliorations de performances liées au mode « fastpath ».

Antivirus avancé

L'option Activer l'analyse heuristique n'est pas supportée sur les modèles SN160(W), SN210(W) et SN310.

Agrégation de liens (LACP)

Référence support 76432

L'agrégation de liens (LACP) n'est pas compatible avec le module réseau SFP+ 40G LM4 (référence NA-TRANS-QSFP40-SR).

Certificats et PKI

Protocole SCEP

L'implémentation du protocole SCEP sur les firewalls SNS présente les caractéristiques et limitations suivantes :

Le message **SCEP CertPoll**, destiné à simplifier les requêtes de polling en envoyant uniquement l'identifiant de transaction n'est pas implémenté. Sur le firewall, cet identifiant de requête est utilisé pour retrouver localement la requête initialement envoyée et la soumettre à nouveau au serveur. Cette adaptation n'impacte aucunement le fonctionnement des échanges SCEP.
L'opération **GetCACaps** permettant de récupérer la liste des fonctionnalités SCEP implémentées sur le serveur n'est pas disponible. Cela n'impacte aucunement la gestion des certificats au travers du protocole SCEP.
L'opération **GetNextCACert** permettant de récupérer le futur certificat de la CA avant expiration du certificat courant n'est pas implémentée. Le nouveau certificat de la CA peut en effet être récupéré à l'aide de l'opération SCEP **GetCACert** lorsque le certificat utilisé jusqu' alors est expiré.
L'opération **GetCRL** destinée à récupérer la dernière mise à jour de la CRL lié à la CA du serveur SCEP n'est pas implémentée. Cette opération génère en effet une surcharge d'activité inutile sur le serveur et le firewall dispose de sa propre option "Activer la récupération régulière des listes de révocation de certificats (CRL)" (module Système > Configuration > onglet Configuration Générale).
L’ébauche de spécification impose la restriction de la méthode POST aux seules opérations SCEP de type **PKIOperation**. Sur les firewalls SNS, cette méthode est utilisée par défaut pour l'ensemble des requêtes. La méthode GET peut cependant être imposée à l'aide de l'option "post=off" pour les différentes commandes SCEP disponibles en ligne de commande.
Les algorithmes de chiffrement et d'authentification utilisés par défaut sur le firewall sont 3DES et SHA-1.

VPN SSL

Suite à la mise à jour d'OpenVPN en 2.4.4 :

Vous ne devez plus utiliser des plages d'adresses IP plus étendues qu'un réseau de classe B (masque /16),
Certains algorithmes TLS ont disparu.

Si vous êtes concerné par ces limitations, les tunnels VPN SSL ne monteront plus. Des messages d'erreur explicites s'afficheront pour vous aider à corriger votre configuration.

Support IPv6

En version 3, voici les principales fonctionnalités non disponibles pour le trafic IPv6 :

Le trafic IPv6 au travers de tunnels IPsec basés sur des interfaces IPsec virtuelles (VTI),
La translation d'adresses IPv6 (NATv6),
Inspections applicatives (Antivirus, Antispam, Filtrage URL, Filtrage SMTP, Filtrage FTP, Filtrage SSL),
L’utilisation du proxy explicite,
Le cache DNS,
Les tunnels VPN SSL portail,
Les tunnels VPN SSL,
L’authentification via Radius ou Kerberos,
Le Management de Vulnérabilités,
Les interfaces modems (en particulier les modems PPPoE).

Haute Disponibilité

Dans le cas où un firewall est en Haute Disponibilité et a activé la fonctionnalité IPv6, les adresses MAC des interfaces portant de l'IPv6 (autres que celles du lien HA) doivent impérativement être définies en configuration avancée. En effet, les adresses de lien local IPv6 étant dérivées de l'adresse MAC, ces adresses seront différentes, entraînant des problèmes de routage en cas de bascule.

Logs - Journaux d'audit

Référence support 60085

Sandboxing

Après le redémarrage du firewall, une alarme "System error Sandboxing licence unavailable" vous informera que la licence Sandboxing est indisponible. Cette alarme apparaît même si vous ne disposez pas d'une licence Sandboxing et que vous n'utilisez pas son analyse dans vos règles de filtrage.

Notifications

IPFIX

Les événements envoyés via le protocole IPFIX n'incluent ni les connexions du proxy, ni les flux émis par le firewall lui-même (exemple : flux ESP pour le fonctionnement des tunnels IPsec).

Rapports d’activités

La génération des rapports se base sur les traces (logs) enregistrées par le firewall et celles-ci sont générées à la clôture des connexions. En conséquence, les connexions toujours actives (exemple : tunnel IPsec avec translation) ne seront pas affichées dans les statistiques affichées par les Rapports d’activités.

Les traces générées par le firewall dépendant du type de trafic qui ne nomme pas forcément de la même façon les objets (srcname et dstname). Pour éviter de multiples représentations d’un même objet dans les rapports, il est conseillé de donner à l’objet créé dans la base du firewall, le même nom que celui associé via la résolution DNS.

Prévention d’intrusion

Protocole GRE et tunnels IPsec

Le déchiffrement de flux GRE encapsulés dans un tunnel IPsec génère à tort l’alarme « Usurpation d’adresse IP sur l’interface IPsec ». Il est donc nécessaire de configurer l’action à passer sur cette alarme pour faire fonctionner ce type de configuration.

Analyse HTML

Le code HTML réécrit n’est pas compatible avec tous les services web (apt-get, Active Update) parce que l’en-tête HTTP « Content-Length » a été supprimé.

Messagerie instantanée

Le NAT sur les protocoles de messagerie instantanée n’est pas supporté.

Référence support 35960

Préserver le routage initial

L’option permettant de préserver le routage initial sur une interface n'est pas compatible avec les fonctionnalités pour lesquelles le moteur de prévention d’intrusion doit créer des paquets :

La réinitialisation des connexions lors de la détection d'une alarme bloquante (envoi de paquet RESET),
La protection SYN Proxy,
La détection du protocole par les plugins (règles de filtrage sans protocole spécifié),
La réécriture des données par certains plugins tels que les protections web 2.0, FTP avec NAT, SIP avec NAT et SMTP.

NAT

Référence support 29286

La gestion d'état pour le protocole GRE est basée sur les adresses source et destination. Il n'est donc possible de discerner deux connexions en même temps avec le même serveur, soit du même client soit partageant une adresse source commune (cas du "map").

Support H323

Le support des opérations de translation d'adresses du protocole H323 est rudimentaire, en particulier : il ne supporte pas les cas de contournement du NAT par les gatekeeper (annonce de l'adresse autre que source ou destination de la connexion).

Proxies

Référence support 35328

Proxy FTP

Si l’option « conserver l'adresse IP source originale » est activée sur le proxy FTP, le rechargement de la politique de filtrage entraîne l’interruption des transferts FTP en cours (en upload ou download).

Filtrage

Filtrage Multi-utilisateur

Il est possible de permettre l’authentification Multi-utilisateur à un objet réseau (plusieurs utilisateurs authentifiés sur une même adresse IP) en renseignant l’objet dans la liste des Objets Multi-utilisateurs (Authentification > Politique d’authentification).

Les règles de filtrage avec une source de type user@objet (sauf any ou unknow@object), avec un protocole autre qu’HTTP, ne s’appliquent pas à cette catégorie d’objet. Ce comportement est inhérent au mécanisme de traitement des paquets effectué par le moteur de prévention d’intrusion. Le message explicite avertissant l’administrateur de cette limitation est le suivant : « Cette règle ne peut identifier un utilisateur connecté sur un objet multi-utilisateur ».

Géolocalisation et réputation des adresses IP publiques

Lorsqu'une règle de filtrage précise des conditions de géolocalisation et de réputation d'adresses publiques, il est nécessaire que ces deux conditions soient remplies pour que la règle soit appliquée.

Réputation des machines

Si les adresses IP des machines sont distribuées via un serveur DHCP, la réputation d'une machine dont l'adresse aurait été reprise par une autre machine sera également attribuée à celle-ci. Dans ce cas, la réputation de la machine peut être réinitialisée à l'aide de la commande en ligne monitor flush hostrep ip = host_ip_address.

Interface de sortie

Une règle de filtrage précisant une interface de sortie incluse dans un bridge, et qui ne serait pas la première interface de ce bridge, n’est pas exécutée.

Référence support 31715

Filtrage URL

Le filtrage par utilisateur authentifié n’est pas possible au sein d’une même politique de filtrage URL. Il est toutefois possible d’appliquer des règles de filtrage particulières (Inspection applicative) selon les utilisateurs.

Authentification

Portail captif - Page de déconnexion

La page de déconnexion du portail captif ne fonctionne que pour les méthodes d'authentification basées sur des mots de passe.

SSO Agent

La méthode d’authentification Agent SSO se base sur les évènements d’authentification collectés par les contrôleurs de domaine Windows. Ceux-ci n’indiquant pas l’origine du trafic, la politique d’authentification ne peut être spécifiée avec des interfaces.

Référence support 47378

Les noms d’utilisateurs contenant les caractères spéciaux suivants : " <tab> & ~ | = * < > ! ( ) \ $ % ? ' ` @ <espace> ne sont pas pris en charge par le SN SSO Agent. Le firewall ne recevra donc pas les notifications de connexions et déconnexions relatives à ces utilisateurs.

Domaines Active Directory multiples

Dans le cadre de domaines Active Directory multiples liés par une relation d'approbation, il est nécessaire de définir dans la configuration du firewall un annuaire Active Directory et un SN SSO Agent pour chacun de ces domaines.

Les méthodes SPNEGO et Kerberos ne peuvent pas être utilisées sur plusieurs domaines Active Directory.

La phase 1 de négociation IPsec n'est pas compatible avec les annuaires Active Directory multiples pour l'authentification des clients mobiles.

Le protocole IKEv1 nécessite l'emploi de l'authentification étendue (XAUTH).

Annuaire LDAP - Microsoft Active Directory

Les utilisateurs sont absents de la liste des membres de leur groupe primaire.
Ce comportement est dû au fonctionnement de Microsoft Active Directory : en effet, l'attribut memberof de l'utilisateur ne contient pas son groupe primaire. De même, l'utilisateur n'est pas inclus dans l'attribut member de son groupe primaire.

Les firewalls Stormshield utilisant l'attribut member pour obtenir la liste des utilisateurs d'un groupe, les utilisateurs n'apparaissent donc pas dans la liste des membres de leur groupe primaire.

Annuaires multiples

Les utilisateurs définis comme administrateurs du firewall doivent obligatoirement être issus de l'annuaire par défaut.

Les utilisateurs ne peuvent s'authentifier que sur l'annuaire par défaut via les méthodes certificat SSL et Radius.

Méthode CONNECT

L’authentification multi-utilisateur sur une même machine en mode Cookie, ne supporte la méthode CONNECT (protocole HTTP). Cette méthode est généralement utilisée avec un proxy explicite pour les connexions HTTPS. Pour ce type d’authentification, il est recommandé d’utiliser le mode « transparent ». Pour plus d’informations, consultez l’aide en ligne à l’adresse documentation.stormshield.eu, section Authentification.

Conditions d'utilisation

L’affichage des Conditions d'utilisation d'accès à Internet sur le portail captif peut avoir un rendu incorrect sous Internet Explorer v9 avec le mode compatibilité IE Explorer 7.

Utilisateurs

La gestion d'annuaires LDAP multiples impose une authentification précisant le domaine d'authentification : user@domain.

Le caractère spécial « espace » dans les identifiants (« login ») des utilisateurs n’est pas supporté.

Déconnexion

La déconnexion d’une authentification ne peut se faire que par la méthode utilisée lors de l’authentification. Par exemple, un utilisateur authentifié avec la méthode Agent SSO ne pourra pas se déconnecter via le portail d'authentification, car l'utilisateur doit fournir pour la déconnexion, un cookie n’existant pas dans ce cas.

Comptes temporaires

Lors de la création d'un compte temporaire, le firewall génère automatiquement un mot de passe d'une longueur de 8 caractères. Dans le cas d'une politique globale de mots de passe imposant une longueur supérieure à 8 caractères, la création d'un compte temporaire génère alors une erreur et le compte ne peut pas être utilisé pour s'authentifier.

L'utilisation des comptes temporaires nécessite donc une politique de mots de passe limités à 8 caractères maximum.

Haute Disponibilité

Interaction H.A en mode bridge et switches

Dans un environnement avec un cluster de firewall configuré en mode bridge, le temps de bascule du trafic constaté est de l’ordre des 10 secondes. Ce délai est lié au temps de bascule d’1 seconde auquel vient s’ajouter le temps de réapprentissage des adresses MAC par les switches qui sont directement connectés aux firewalls.

Routage par politique

Une session routée par la politique de filtrage peut être perdue en cas de bascule du cluster.

Modèles

La Haute disponibilité basée sur un groupe (cluster) de firewalls de modèles différents n’est pas supportée. D’autre part, un groupe avec un firewall utilisant un firmware en 32 bits et l’autre en 64 bits n’est pas autorisé.

VLAN dans un agrégat d'interfaces et lien HA

Référence support 59620

Le choix d'un VLAN appartenant à un agrégat d'interfaces (LACP) comme lien de haute disponibilité n'est pas autorisé. En effet, cette configuration rend le mécanisme de haute disponibilité inopérant sur ce lien : l'adresse MAC attribuée à ce VLAN sur chacun des firewalls est alors 00:00:00:00:00:00.

Management des vulnérabilités

Référence support 28665

L'inventaire d'applications réalisé par le Management des vulnérabilités se base sur l'adresse IP de la machine initiant le trafic pour indexer les applications.

Le cas de machines ayant une adresse IP partagée par plusieurs utilisateurs, par exemple un proxy HTTP, un serveur TSE ou encore un routeur réalisant du NAT dynamique de la source, peuvent entraîner une charge importante sur le module. Il est donc conseillé de mettre les adresses de ces machines dans la liste d'exclusion (éléments non supervisés).

Suite d'administration Stormshield Network

SN Real-Time Monitor

Les commandes de transfert de fichiers (envoi et réception) depuis la console CLI de SN Real-Time Monitor ne fonctionnent plus en versions 2 et supérieures.

Référence support 28665

La commande CLI MONITOR FLUSH SA ALL est initialement dédiée à désactiver les tunnels IPsec en cours, en supprimant leur association de sécurité (SA - security association). Cependant, le routage dynamique Bird utilisant également ce type d’association de sécurité (SA), cette commande dégrade la configuration de Bird, empêchant toute connexion. Ce problème se pose également avec la fonction « Réinitialiser tous les tunnels » proposée dans l’interface de Real Time Monitor.

Pour résoudre ce problème, il est nécessaire de redémarrer le service Bird.

SN Event Reporter

SN Event Reporter n'est plus inclus dans la suite d'administration en version 3 ou supérieure, et les connexions depuis SN Event Reporter sur les firewalls en version 3 ou supérieure ne sont pas supportées.