SNS 4.6.11 bug fixes

System

Proxies

Support references 85428 - 85495 - 85491

Issues regarding proxies that were unexpectedly blocked when configurations were reloaded have been corrected.

Network captures with tcpdump on a usbus interface

Support references 85083 - 85313

Launching a network capture with tcpdump on a usbus interface no longer causes the firewall to unexpectedly restart.

Elastic Virtual Appliances (EVA)

Support reference 85273

On an EVA virtual firewall, limiting the number of CPUs when hyperthreading is enabled no longer causes the firewall to restart unexpectedly.

QoS

Support reference 85019

Due to an issue that occurs when a CBQ queue used as an acknowledgment queue (ACK) in a filter rule is deleted, the firewall may sometimes unexpectedly restart. This issue has been fixed.

SD-WAN

Inconsistencies in the measurement unit used for calculations and the display of gateway unavailability rate have been fixed.

Support reference 85253

For SD-WAN configurations that use SLA thresholds and in which the main gateways of a router object present very close SLA scores, enhancements now make it possible to prevent excessively frequent changes to the priorities of these gateways.

Switching to a lower SNS version

Support reference 85247

When a firewall switches to a lower SNS version without being reset to its factory configuration (defaultconfig), attempts to display the list of available alarms no longer cause the intrusion prevention engine and the command-based configuration server (serverd) to unexpectedly restart.

NAT

Support reference 84819

An issue has been fixed in the NAT manager. This issue would wrongly fill the table of translated ports used for traffic that requires child connections (e.g. FTP, RTSP and others). As a result, this would prevent child connections from being created, and disrupt the traffic in question.

Filter - NAT

Support references 85357 - 85376

In filter rules that use a set of network objects, one of which is linked to a disabled DHCP-configured interface, restarting the firewall will no longer wrongly enable the "(1) Block all" filter rule. This regression appeared in SNS version 4.6.8.

Support reference 85239

In a situation such as the following:

  • The firewall has a bridge that groups several interfaces. On this bridge:
    • Traffic from one of the bridge interfaces to an interface outside the bridge is allowed by a filter rule in Firewall mode,
    • Traffic from another bridge interface to the same interface outside the bridge is blocked by another filter rule.
  • A connection has been established between a client host and the server through the first rule,
  • An infected host or an intrusion probe located on the same interface as the server sent a reset packet with the same references as the established connection (source/destination addresses and source/destination ports).

Although the packet from the infected host or intrusion probe was rightly blocked, the source interface of the client host was wrongly modified and its established connection with the server was shut down. This issue has been fixed.

Connection to the web administration interface with the admin account

Support references 85266 - 85309 - 85349 - 85437 - 85494

Under certain circumstances, attempts to connect to the web administration interface with the admin account would fail and cause the command-based configuration server (serverd) to unexpectedly restart. This issue has been fixed.

High availability (HA)

Support references 77890 - 83274

On a high availability firewall that has switched roles several times in the cluster, some packets would take the wrong return route while presenting the IP address of the right return route. This issue, which caused the shutdown of the traffic in question, has been fixed.

Intrusion prevention engine

IPS analysis - Alarms

Support reference 85210

Packets that raise one of the alarms occurring before the filter inspection would still pass through the firewall despite the presence of a filter rule configured to block the corresponding network traffic. This issue has been fixed.

Refer to the list of alarms occurring before the filter inspection in the Stormshield knowledge base (authentication required).

LDAP protocol

Support reference 84561

The LDAP protocol analysis engine now correctly manages GSSAPI authentication packets, which no longer wrongly generate "Bad LDAP protocol" (ldap_tcp:427 error) alarms.