New features in version 4.2.1


ANSSI Diffusion Restreinte (DR) mode

SNS firewalls offer the implementation of a strengthened IPsec mode calledDiffusion Restreinte (DR) mode that complies with the recommendations of the French Network and Information Security Agency (ANSSI).

In SNS version 4.2, many strengthening measures were added to DR mode, in particular:  

  • IPsec tunnels are now exclusively negotiated over UDP port 4500, making NAT-T (NAT traversal) detection unnecessary,
  • IPsec VPN tunnels can now be only IKEv2-based,
  • ESN support for ESP anti-replay is implemented,
  • Creating an IPsec VPN policy enables the CRLRequired configuration token,
  • Restrictions regarding the authentication and encryption algorithms allowed,
  • Two specific “DR mode” encryption profiles (one for IKE, one for IPsec) were added to existing profiles (StrongEncryption, GoodEncryption and Mobile).

DR mode in SNS version 4.2 is not compatible with DR mode in earlier SNS versions, and the firewall does not allow updates of firewalls with DR mode enabled to SNS version 4.2.0 or higher. DR mode must be disabled before updating the firewall.

Find out more

Modifying logs enabled by default

The possibility of storing some logs, including connections, on disk is now disabled by default on firewalls in SNS version 4.2 in factory configuration. The only logs enabled and stored by default are the following in their respective log files:

  • Administration (l_server),
  • Authentication (l_auth),
  • System events (l_system),
  • Alarms (l_alarm),
  • Filter policies (l_filter),
  • IKE/IPsec negotiation (l_vpn),
  • IPsec VPN (l_vpn),
  • SSL VPN (l_xvpn),
  • Filter statistics and IPsec statistics (l_monitor),
  • Sandboxing (l_sandboxing).

The storage of other logs on disk can be manually enabled in Logs - Syslog - IPFIX.

Find out more


The daemon that manages IKEv1 IPsec VPN tunnels is now the same as the one that manages IKEv2 IPsec VPN tunnels (strongSwan charon).

The configurations listed below are no longer allowed in version 4.2:

  • IKEv1 rules based on pre-shared key authentication in aggressive mode (mobile and site-to-site tunnels),
  • IKEv1 rules based on hybrid mode authentication (mobile tunnels),
  • IKEv1 backup peers.

You must therefore ensure the compliance of the active IPsec policy, and that it meets the restrictions for a combined IKEv1/IKEv2 policy, before updating the firewall to version 4.2.

Find out more


encryption/decryption operations in the IPsec module are distributed more efficiently, leading to improved IPsec throughput in configurations that contain a single IPsec tunnel.

This optimization mechanism can be enabled or disabled manually using the CLI/serverd command:

CONFIG IPSEC UPDATE slot=<x> CryptoLoadBalance=<0|1>

where <x> is the number of the active IPsec policy.

These commands are explained in detail in the CLI SERVERD Commands Reference Guide.

Find out more

A new CLI/Serverd command PKI CA CHECKOCSP was added so that the URL of an OCSP server can be loaded into certificates used in the negotiation of IPsec tunnels.

Find out more

Logs - IPsec VPN rule type

A field specifying the type of VPN rule (mobile tunnel or site-to-site tunnel) was added to IPsec VPN logs.

Find out more

Logs - IPsec VPN rule name

In the IPsec VPN configuration module, it is now possible to look for the name of a rule directly in IPsec VPN logs to display matching logs.

SNMP agent

In IKEv2 or IKEv1 + IKEv2 IPsec policies, an SNMP trap is now raised whenever an IPsec VPN peer cannot be reached.

A new MIB (STORMSHIELD-OVPNTABLE-MIB) makes it possible to monitor via SNMP users who connected through SSL VPN.

STORMSHIELD-VPNSA-MIB offers additional IPsec statistics. Two new IPsec MIBs were added to it:

  • STORMSHIELD-VPNIKESA-MIB: provides information on negotiated IKE SAs,
  • STORMSHIELD-VPNSP-MIB: provides information on SPs (Security Policies).

Find out more

Calculation of entropy - TPM (Trusted Platform Module)

Firewalls equipped with a TPM now use it as a source of entropy in cryptographic functions, therefore improving their entropy.

Calculation of entropy - Password policy

Entropy, which is calculated based on the unpredictability of a password and the number of characters it contains, has been included in the definition of the password policy to guarantee that these passwords are robust.

A minimum entropy value can now be imposed on passwords defined on the firewall (service accounts, administration accounts, automatic backup passwords, etc.).

Find out more

High availability

In a high availability configuration, when an interface on a node in the cluster fails, the time it takes for a passive node to switch to active mode has been significantly shortened on SN500, SN510, SN700, SN710, SN900, SN910, SN2000, SN2100, SN3000, SN3100, SN6000 and SN6100 models, therefore minimizing interruption to network traffic.

Find out more

SPNEGO authentication

Support reference 73844

The firmware in version 4.2 introduces Windows Server 2019 support for the SPNEGO authentication method. Version 1.7 of the spnego.bat script, available in Mystormshield, must be used in this version of Windows Server.
This version of the script is also compatible with Windows Server 2016, 2012 and 2012 R2.

Authentication - Internal LDAP directory

For better security, passwords contained in the internal LDAP directory can now be hashed using SHA2 or PBKDF2.

Find out more

Authentication - Captive portal

On firewalls configured in strict HTTPS mode (using the CLI/Serverd command CONFIG AUTH HTTPS sslparanoiac=1), the configuration of the captive portal no longer allows the selection of certificates other than server certificates containing the ExtendedKeyUsage ServerAuth.

Before updating firewalls to version 4.2, a captive portal certificate that complies with this requirement must therefore be selected.

Authentication – SSO Agent

SSO agents now connect to the firewall's authentication service over TLS v1.2 instead of SSLv3. The SSO agent v3.0 or higher must therefore be used with SNS firewalls in version 4.2.

Logs - Location of verbose.* files

Log files created when verbose mode is enabled on firewall services are now placed in a dedicated folder /log/verbose and no longer directly in the /log folder. Existing files will automatically be moved to this new folder when the firewall is updated to version 4.2.

CLI/serverd commands

CLI/Serverd commands are now given versions to allow changes to be tracked. A section setting out the CLI/Serverd commands that were changed, added or deleted between the last SNS version and the previous SNS LTSB version has been added to the first part of the CLI/Serverd commands reference guide.

The CLI/serverd commands relating to IPsec VPN (CONFIG IPSEC PROFILE PHASE1 and CONFIG IPSEC PROFILE PHASE2) were modified to enable the verification of the configuration before it is applied to the firewall.
Service disruptions can therefore be prevented if there are anomalies in the configuration.

Find out more

Restoring configurations

A mechanism that monitors the integrity of the network configuration now makes it possible to prevent configuration errors on firewalls when they are deployed via SMC or when backups are restored.

A consistency analysis is conducted before a configuration is partially restored.
When the analysis mechanism detects an anomaly, it will display a warning message. The administrator can however proceed with the restoration, but changes must be made to the configuration to ensure that the modules that will be restored are operational.


As part of the process of hardening the SNS operating system, the configuration file meant for the Stormshield SSL VPN client includes the parameter auth-nocache to force the client not to cache the user's password (except for SSL VPN clients configured in Manual mode).

Firewall's SSH key

As part of the process of hardening the SNS operating system, the firewall's SSH keys (firewall key for SSH connections to the firewall, keys created for high availability and admin account key) are now encrypted by default with ECDSA instead of RSA, which was used in versions prior to SNS 4.2.

The firewall's SSH key is now generated when the firewall’s SSHD service is enabled (not when the firewall starts) to enhace its entropy (key robustness). The key can also be generated again using the CLI/Serverd command CONFIG SSH REGENHOSTKEY.

The SSH key of the admin account is always generated every time the password to this account is changed. This password should therefore be changed after the firewall is updated to version 4.2.

Find out more

TLS v1.3 protocol

SNS version 4.2 introduces TLS v1.3 support for services on the firewall (captive portal, LDAPS, Syslog TLS, Autoupdate, etc.).

Clients going in the direction of the firewall can now use only 1.2 and 1.3 of the TLS protocol. The usable version of the TLS protocol can be configured with the CLI Serverd command:

CONFIG CRYPTO ClientTLSv12=<0|1> ClientTLSv13=<0|1>

For more details on this command, refer to the CLI SERVERD Commands Reference Guide.

Do note that the server hosting an external LDAP directory must support and use a compatible encryption suite in the implementation of the LDAPS protocol based on TLS1.2 or TLS 1.3.
The list of such encryption suites is provided in the SNS v4 User Configuration Manual.


SHA256 is now the algorithm used in the NSRPC library to calculate password hashes.

Updates - Logs

Support reference 79529

Logs regarding operations performed before the firewall was restarted have been added to the update.log files to identify the causes of firmware update failures.

Intrusion prevention

TLS v1.3 protocol

The intrusion prevention engine now detects and analyzes decrypted frames from TLS v1.3, which secures communications. In particular, this makes it possible to:

  • Allow 0-RTT mode,
  • Decide which values/extensions to adopt (GREASE extensions [Generate Random Extensions And Sustain Extensibility], extensions defined in RFC on TLS v1.3 or unknown extensions can be configured).
  • Define a blacklist of TLS extensions.

Do note that related traffic can now be analyzed by protocol alarms.

Find out more

RDP over UDP protocol

The intrusion prevention engine now detects and analyzes UDP-based RDP traffic in addition to TCP-based RDP traffic.

Do note that related traffic can now be analyzed by protocol alarms.

IPv6 protocol

In version 4.2, IPv6 packets containing non-compliant RDNSS (Recursive DNS Server) options are detected and blocked (cf. RFC 8106).

Web administration interface

IPsec VPN monitoring

The IPsec VPN monitoring module now includes two tables that present the characteristics of the selected IPsec VPN tunnel’s Security Associations (SAs):

  • Table of IKE SAs:
    • Name of the IPsec rule,
    • IKE version of the tunnel,
    • Local gateway,
    • IP address of the local gateway,
    • Remote gateway,
    • IP address of the remote gateway,
    • SA state,
    • Role (responder/initiator),
    • Initiator cookie,
    • Responder cookie,
    • Local ID,
    • Peer ID,
    • Whether NAT-T is enabled,
    • Authentication algorithm used,
    • Encryption algorithm used,
    • PseudoRandom Function (PRF) algorithm used,
    • Perfect Forward Secrecy (PFS) used,
    • Lifetime lapsed.
  • Table of IPsec SAs:

    • SA state,
    • Local gateway,
    • Remote gateway,
    • Bytes in,
    • Bytes out,
    • Lifetime lapsed,
    • Authentication algorithm used,
    • Encryption algorithm used,
    • Whether there is an ESN,
    • Whether UDP encapsulation of ESP packets is enabled.


The dashboard includes a new Messages widget that displays system notifications and warnings. Messages appear if:

  • IPv6 is enabled on the firewall,
  • DR mode is enabled on the firewall,
  • The authentication engine uses the firewall's default certificates.

Interface monitoring

The interface monitoring module can now show real-time and historical curves of throughput and the number of packets exchanged for VLANs defined on the firewall.

Curves showing the history of throughput and packets exchanged are now also available for interface aggregates.

Protocols - NTP

Clicking on the link to Protection against Time Poisoning attacks (Configuration > Application protection > Protocols > NTP > IPS tab) now allows direct access to the configuration of the firewall clock.

Find out more

Certificates and PKI

The web administration interface now makes it possible to create certificates in which the FQDN contains the special character "*" (e.g., *