Limitations and explanations on usage

Authentication - TOTP

Support reference 84686

When advanced TOTP authentication settings are modified (Lifetime, Code size, Number of valid codes before and after current code or Hash algorithm), this authentication method would fail if it is used together with Google Authenticator or Microsoft Authenticator, which are code-generating applications.
A warning message has been added, asking the user to check whether the advanced settings are compatible with the code generator used.

Dynamic multicast routing

This is an early-access feature.

The dynamic multicast routing implemented has the following limitations:

  • IGMPv1 is not supported,
  • IGMP Snooping is not supported,
  • PIM Dense Mode is not supported,
  • PIM Sparse-Dense Mode is not supported,
  • PIM BiDir is not supported,
  • Multicast BGP Extension is not supported,
  • MSDP (Multicast Source Discovery protocol) is not supported,
  • AnycastRP is not supported,
  • IPv6 and the MLD (Multicast Listener Discovery) protocol are not supported,
  • Static multicast routing and dynamic multicast routing cannot be enabled at the same time,
  • Dynamic multicast routing tables are not synchronized in HA,
  • Bridges and bridged interfaces cannot be selected as interfaces participating in dynamic multicast routing,
  • The AutoRP protocol is not supported,
  • In HA configurations, interfaces that participate in dynamic multicast routing must have a static IP address,
  • The intrusion prevention engine does not analyze the PIM protocol,
  • The number of interfaces on the firewall that participates in dynamic multicast routing is restricted to 32.


This is an early-access feature.
Refer to the section on Known issues before enabling this feature.


This is an early-access feature.
Ensure that you have read the section on Known issues before enabling this feature or updating an existing QoS configuration to an SNS 4.7 version or higher.

The following limitations have been placed on the QoS implemented:

  • Maximum bandwidth supported: 1 Gbps,
  • Interfaces supported:
    • Ethernet,
    • IPsec,
    • GRETAP,
    • Virtual IPsec (VTI),
    • VLAN.
  • PRIQ and CBQ queues are not compatible with one another and must not be used on the same traffic shaper,
  • All thresholds set on queues must be expressed either in absolute values only or percentages only.
  • The amount of reserved bandwidth must not exceed the traffic shaper’s bandwidth.

Web services

If web services are used in the firewall's configuration, the DNS protocol analysis must be enabled.

Jumbo frames supported on SN160, SN210 and SN310 firewall models

Even though the size of jumbo frame MTUs can be set to a maximum of 9216 bytes on SN160, SN210 and SN310 firewalls, do note that due to the hardware limitations on these models, the software will verify the checksums of packets with MTUs higher than 1600 bytes. As a result, this may affect the overall performance of these firewall models.

TPM-equipped firewalls

Support reference 83580

The list of TPM-equipped firewall models is provided in the section Trusted Platform Module in the SNS User Guide.

After an update to SNS version 4.3 or higher, secrets stored in the TPM must be sealed with the new technical characteristics of the system, by using the CLI/Serverd command: SYSTEM TPM PCRSEAL tpmpassword=<TPMpassword> .

Do note that in clusters, this action must be applied to both members from the active firewall (by adding the parameter "serial=passive" from the active firewall to seal the secrets of the passive firewall).

For more information on this topic, refer to the Stormshield knowledge base.

PROFINET RT protocol

Support reference 70045

The network controller used on SNi40, SN2000, SN3000, SN6000, SN510, SN710, SN910, SN2100, SN3100 and SN6100 firewalls has been upgraded and allows VLANs with an ID value of 0. This measure is necessary for the industrial protocol PROFINET-RT.

However, IX network modules (fiber 2x10Gbps and 4x10Gbps equipped with INTEL 82599) and IXL modules (see the list of affected modules) were not upgraded and therefore cannot manage PROFINET-RT.


Optimized distribution of encryption/decryption operations

In a configuration containing a single IPsec tunnel through which several data streams pass through, enabling the mechanism that optimizes encryption/decryption operations may disrupt the sequence of packets and cause the recipient to reject encrypted packets based on the size of the anti-replay window configured.

Interruption of phase 2 negotiations

The Charon IPsec management engine, used in IKEv1 policies, may interrupt all tunnels with the same peer if a single phase 2 negotiation fails.

This occurs when the peer does not send notifications following a failed negotiation due to a difference in traffic endpoints.

As mentioned earlier, the behavior of the Racoon IPsec management engine was modified in version 4.1.0 so that this issue no longer occurs in Racoon <=> Charon tunnels.

However, you may still encounter this issue when the Charon IPsec management engine negotiates with an appliance that does not send failure notifications.

IPsec-related constraints

Several constraints are imposed when IKEv1 and IKEv2 peers are used in the same IPsec policy:

  • "Aggressive" negotiation mode is not allowed for IKEv1 peers using pre-shared key authentication. An error message appears when there is an attempt to enable the IPsec policy.
  • The hybrid authentication method does not function for IKEv1 mobile peers.
  • Backup peers are ignored. A warning message appears when the IPsec policy is enabled.
  • The "non_auth" authentication algorithm is not supported for IKEv1 peers. In such cases, the IPsec policy cannot be enabled.
  • In configurations that implement NAT-T (NAT-Traversal - transporting the IPsec protocol through a network that performs dynamic address translation), the translated IP address must be defined as the ID of a peer that uses pre-shared key authentication and for which a local ID in the form of an IP address had been forced.


A Certificate Revocation List (CRL) is not required. Even if no CRLs are found for the certification authority (CA), negotiation will be allowed.

A CRL can be made mandatory with the use of the "CRLRequired=1" parameter in the CLI command "CONFIG IPSEC UPDATE". When this parameter is enabled, you must have all the CRLs in the certification chain.

Support reference 37332

DPD (Dead Peer Detection)

The VPN feature DPD (Dead Peer Detection) makes it possible to check whether a peer is still up by sending ISAKMP messages.

If a firewall is the responder in an IPsec negotiation in main mode, and DPD has been set to "inactive", this parameter will be forced to "passive" in order to respond to the peer's DPD queries. During this IPsec negotiation, DPD will be announced even before the peer is identified, so before even knowing whether DPD queries can be ignored for this peer.

This parameter has not been modified in aggressive mode, as in this case DPD would be negotiated when the peer has already been identified, or when the firewall is the initiator of the negotiation.


The EAP (Extensible Authentication Protocol) protocol cannot be used for the authentication of IPsec peers using the IKEv2 protocol.

In configurations that implement NAT-T (NAT-Traversal - transporting the IPsec protocol through a network that performs dynamic address translation), the translated IP address must be defined as the ID of a peer that uses pre-shared key authentication and for which a local ID in the form of an IP address had been forced.

Backup peers

A backup configuration can no longer be defined for IPsec peers. In order to implement a redundant IPsec configuration, you are advised to use virtual IPsec interfaces and router objects in filter rules (PBR).


4G modems

In order to ensure a firewall's connectivity with a 4G USB modem, HUAWEI equipment in the following list must be used:

  • E3372h-153,

  • E8372h-153,

  • E3372h-320.

Other key models may work, but they have not been tested.

Routing - Network directly connected to an interface on the firewall

Support reference 79503

Whenever a network is directly connected to an interface on the firewall, the firewall creates an implicit route to access this network. This route is applied prior to PBR rules (Policy Based Routing): PBR is therefore ignored for such networks.

Spanning Tree protocols (RSTP / MSTP)

Stormshield Network firewalls do not support multi-region MSTP configurations. A firewall implementing an MSTP configuration and interconnecting several MSTP regions may therefore malfunction when managing its own region.

If MSTP has been enabled on a firewall and it is unable to communicate with equipment that does not support this protocol, it would not automatically switch to RSTP.

Due to the way they operate, RSTP and MSTP cannot be enabled on VLAN interfaces and PPTP/PPPoE modems.


On SN160(W) and SN210(W) firewall models, the presence of unmanaged switches would cause the status of the firewall's network interfaces to stay permanently "up", even when they are not physically connected to the network.

The firewall's interfaces (VLAN, PPTP interfaces, aggregated interfaces [LACP], etc.) are grouped together in a common pool for all configuration modules. When an interface previously used in a module is released, it becomes reusable for other modules only after the firewall is rebooted.

Deleting a VLAN interface will change the order of such interfaces the next time the firewall starts. If such interfaces are listed in the dynamic routing configuration or monitored via SNMP MIB-II, this behavior would cause a lag and may potentially cause the service to shut down. You are therefore strongly advised to disable any unused VLAN interfaces instead of deleting them.

The possibility of adding WiFi interfaces in a bridge is currently in experimental mode and cannot be done via the web administration interface.

On SN160(W) models, configurations that contain several VLANs included in a bridge will not be supported.

Configurations containing a bridge that includes several unprotected interfaces, and a static route leaving one of such interfaces (other than the first), are not supported.

Bird dynamic routing

In configurations using BGP with authentication, the "source address <ip>;" directive must be used. For further information on Bird configuration, refer to the Bird Dynamic Routing Technical Note.

When a Bird configuration file is edited from the web administration interface, the Apply action will send this configuration to the firewall. If there are syntax errors, the configuration will not be applied. A warning message indicating the row numbers that contain errors will prompt the user to correct the configuration. However, if a configuration containing errors is sent to the firewall, it will be applied the next time Bird or the firewall is restarted, preventing Bird from loading correctly.

Policy-based routing

If the firewall has been reset to its factory settings (defaultconfig) after a migration from version 2 to version 3 then to version 4, the order in which routing will be evaluated changes and policy-based routing [PBR] will take over priority (policy-based routing > static routing > dynamic routing >…> default route). However, if the firewall has not been reset, the order of evaluation stays the same as in version 1 (static routing > dynamic routing > policy-based routing [PBR] > routing by interface > routing by load balancing > default route).


Support reference 78677

Cookies generated for multi-user authentication

After a new security policy is implemented on mainstream web browsers, SNS multi-user authentication no longer functions when users visit unsecured websites via HTTP.

When this occurs, an error message or a warning appears, depending on the web browser used, and is due to the fact that the authentication cookies on the proxy cannot use the "Secure" attribute together with the “SameSite” attribute in an unsecured HTTP connection.

The web browser must be manually configured to enable browsing on these websites again.
Find out more

Support reference 51251

DHCP server

Whenever the firewall receives INFORM DHCP requests from a Microsoft client, it will send its own primary DNS server to the client together with the secondary DNS server configured in the DHCP service. You are advised to disable the Web Proxy Auto-Discovery Protocol (WPAD) on Microsoft clients in order to avoid such requests.

Support reference 3120


The NTP client on firewalls only supports synchronization with servers using version 4 of the protocol.

Restoring backups

If a configuration backup is in a version higher than the current version of the firewall, it cannot be restored. For example, a configuration backed up in 4.0.1 cannot be restored if the firewall's current version is 3.9.2.

Dynamic objects

Network objects with automatic DNS resolution (dynamic objects), for which the DNS server offers round-robin load balancing, cause the configuration of modules to be reloaded only when the current address is no longer found in responses.

DNS (FQDN) name objects

DNS name objects cannot be members of object groups.

Filter rules can only be applied to a single DNS name object. A second FQDN object or any other type of network object cannot be added as such.

DNS name objects (FQDN) cannot be used in a NAT rule. Do note that no warnings will be displayed when such configurations are created.

When a DNS server is not available, the DNS name object will only contain the IPv4 and/or IPv6 address entered when it was created.

If a large number of DNS servers is entered on the firewall, or if new IP addresses relating to DNS name objects are added to the DNS server(s), several requests from the firewall may be required in order to learn all of the IP addresses associated with the object (requests at 5-minute intervals).

If the DNS servers entered on client workstations and on the firewall differ, the IP addresses received for a DNS name object may not be the same. This may cause, for example, anomalies in filtering if the DNS object is used in the filter policy.

Filter logs

When a filter rule uses load balancing (use of a router object), the destination interface listed in the filter logs may not necessarily be correct. Since filter logs are written as soon as a network packet matches the criteria of a rule, the outgoing interface will not yet be known. As such, the main gateway is systematically reported in filter logs instead.

High availability


When the passive member of a cluster is migrated from SNS v3 to SNS v4, established IPsec tunnels will be renegotiated; this is normal.

HA interaction in bridge mode and switches

In a firewall cluster configured in bridge mode, the average duration of a traffic switch was observed to be around 10 seconds. This duration is linked to the failover time of 1 second, in addition to the time that switches connected directly to the firewalls take to learn MAC addresses.

Policy-based routing

A session routed by the filter policy may be lost when a cluster is switched over.


High availability based on a cluster of firewalls of differing models is not supported.

VLAN in an aggregate and HA link

Support reference 59620

VLANs belonging to an aggregate (LACP) cannot be selected as high availability links. This configuration would prevent the high availability mechanism from running on this link — the MAC address assigned to this VLAN on each firewall will therefore be 00:00:00:00:00:00.

IPv6 support

In SNS version 4, the following are the main features that are unavailable for IPv6 traffic:

  • IPv6 traffic through IPsec tunnels based on virtual IPsec interfaces (VTI),
  • IPv6 address translation (NATv6),
  • Application inspections (Antivirus, Antispam, URL filtering, SMTP filtering, FTP filtering and SSL filtering),
  • Use of the explicit proxy,
  • DNS cache,
  • SSL VPN portal tunnels,
  • SSL VPN tunnels,
  • Kerberos authentication,
  • Vulnerability management,
  • Modem interfaces (especially PPPoE modems).

High availability

In cases where the firewall is in high availability and IPv6 has been enabled on it, the MAC addresses of interfaces using IPv6 (other than those in the HA link) must be defined in the advanced properties. Since IPv6 local link addresses are derived from the MAC address, these addresses will be different, causing routing problems in the event of a switch.



Events sent via the IPFIX protocol do not include either the proxy's connections or traffic sent by the firewall itself (e.g., ESP traffic for the operation of IPsec tunnels).

Activity reports

Reports are generated based on logs recorded by the firewall, which are written when connections end. As a result, connections that are always active (e.g., IPsec tunnel with translation) will not be displayed in the statistics shown in activity reports.

Whether logs are generated by the firewall depends on the type of traffic, which may not necessarily name objects the same way (srcname and dstname). In order to prevent multiple representations of the same object in reports, you are advised to give objects created in the firewall's database the same name as the one given through DNS resolution.

Intrusion prevention

GRE protocol and IPsec tunnels

Decrypting GRE traffic encapsulated in an IPsec tunnel would wrongly generate the alarm "IP address spoofing on the IPsec interface". This alarm must therefore be set to Pass for such configurations to function.

HTML analysis

Rewritten HTML code is not compatible with all web services (apt-get, Active Update) because the "Content-Length" HTTP header has been deleted.

Support reference 35960

Keep initial routing

The option that makes it possible to keep the initial routing on an interface is not compatible with features for which the intrusion prevention engine must create packets:

  • reinitialization of connections when a block alarm is detected (RESET packet sent),
  • SYN Proxy protection,
  • protocol detection by plugins (filter rules without any protocol specified),
  • rewriting of data by certain plugins such as web 2.0, FTP with NAT, SIP with NAT and SMTP protections.


H323 support

Support for address translation operations on the H323 protocol is basic, namely because it does not support NAT bypasses by gatekeepers (announcement of an address other than the connection's source or destination).

Instant messaging

NAT is not supported on instant messaging protocols


Support reference 35328

FTP proxy

If the "Keep original source IP address" option has been enabled on the FTP proxy, reloading the filter policy would disrupt ongoing FTP transfers (uploads or downloads).

Support reference 31715

URL filtering

Separate filters cannot be used to filter users within the same URL filter policy. However, special filter rules may be applied (application inspection), with a different URL filter profile assigned to each rule.


Outgoing interface

Filter rules that specify an out interface included in a bridge without being the first interface of such a bridge will not be applied.

Multi-user filtering

Network objects may be allowed to use multi-user authentication (several users authenticated on the same IP address) by entering the object in the list of multi-user objects (Authentication > Authentication policy).

Filter rules with a 'user@object' source (except 'any' or 'unknown@object'), with a protocol other than HTTP, do not apply to this object category. This behavior is inherent in the packet processing mechanism that the intrusion prevention engine runs. The message warning the administrator of this restriction is as follows: "This rule cannot identify a user logged on to a multi-user object."

Geolocation and public IP address reputation

Whenever a filter rule specifies geolocation conditions and public address reputation, both of these conditions must be met in order for the rule to apply.

Host reputation

If IP addresses of hosts are distributed via a DHCP server, the reputation of a host whose address may have been used by another host will be assigned to both hosts. In this case, the host's reputation may be reinitialized using the CLI command monitor flush hostrep ip = host_ip_address.


Captive portal - Logout page

The captive portal's logout page works only for password-based authentication methods.

SSO Agent

The SSO agent authentication method is based on authentication events collected by Windows domain controllers. Since these events do not indicate the source of the traffic, interfaces cannot be specified in the authentication policy.

Support reference 47378

The SSO agent does not support user names containing the following special characters: " <tab> & ~ | = * < > ! ( ) \ $ % ? ' ` @ <space>. As such, the firewall will not receive connection and disconnection notifications relating to such users.

Multiple Microsoft Active Directory domains

In the context of multiple Microsoft Active Directory domains linked by an approval relationship, an Active Directory and SSO agent need to be defined in the firewall's configuration for each of these domains.

SPNEGO and Kerberos cannot be used on several Active Directory domains.

The IKEv1 protocol requires extended authentication (XAUTH).

Multiple directories

Users can only authenticate on the default directory via SSL certificate and Radius.

CONNECT method

Multi-user authentication on the same machine in cookie mode does not support the CONNECT method (HTTP). This method is generally used with an explicit proxy for HTTPS connections. For this type of authentication, you are advised to use "transparent" mode. For further information, please refer to our online help at, under the section "Authentication".


The management of multiple LDAP directories requires authentication that specifies the authentication domain: user@domain.

The <space> character is not supported in user logins.

Logging out

Users may only log out from an authentication session using the same method used during authentication. For example, a user authenticated with the SSO agent method will not be able to log off via the authentication portal as the user would need to provide a cookie to log off, which does not exist in this case.

Temporary accounts

Whenever a temporary account is created, the firewall will automatically generate an 8-character long password. If there are global password policies that impose passwords longer than 8 characters, the creation of a temporary account would then generate an error and the account cannot be used for authentication.

In order to use temporary accounts, you will therefore need a password policy restricted to a maximum of 8 characters.

Vulnerability management

Support reference 28665

The application inventory carried out by the Vulnerability manager is based on the IP address of the machine initiating the traffic in order to index applications.

For hosts with an IP address shared among several users, for example an HTTP proxy, a TSE server or a router that dynamically translates the source, may greatly increase the load on the module. You are therefore advised to place the addresses of these machines in an exclusion list (unsupervised elements).