Clavister Firewall Changes from v8.10.01 to v8.10.02

Clavister Firewall Changes from v8.10.01 to v8.10.02

Release date: 2003-10-10 [ISO]

Users upgrading from v7.0x and earlier versions should read changes-7.0x.xx-to-8.00.02.html first. It contains the list of major changes from v7.0x, and also instructions on how to upgrade; the upgrade procedure from v7 to v8 differs markedly from the normal procedure. Once the firewall is upgraded to 8.00.02, you can follow the procedures in this document.

Version 8.10.02 contains bug fixes to the Firewall Core and the Firewall Manager. This document outlines bug fixes as well as improvements for each component.

The upgrade procedures in this document refers to upgrades from earlier v8.0x installations.

New files installed by v8.10.02

How to upgrade earlier v8.0x firewalls to v8.10.02

How to upgrade v6.0x/v7.0x firewalls to v8.0x

HA upgrade procedure

Firewall Manager
[Bug Fixes]

Firewall Core
[Changes] [Bug Fixes]

Firewall Core - VPN specific
[Changes] [Bug Fixes] [Known Bugs / Problems]

Firewall Core - HA specific
[Known Bugs / Problems]

For future reference: This document is stored in the "Docs" sub-folder of your Firewall Manager install folder.

Change logs / release notes for earlier versions of Clavister Firewall are available in the release notes section of www.clavister.com/support.

Summary of changes and bug fixes

All changes and bug fixes affecting the standard firewall core also affect VPN and HA cores, unless explicitly stated otherwise.

Firewall Manager

  Bug fix: Netobject name changes do not propagate to comma-separated lists

  Bug fix: Copying service groups causes FWMgr to freeze

  Bug fix: Status icon of folders etc not updated when firewall status changes

  Bug fix: "Upload HTML Banner Files" ignores folder names with upper case letters

  Bug fix: Configuration download from HA cluster fails

Firewall Core

  Change: Log events now emitted for NetconBeforeRules/SNMPBeforeRules/IPsecBeforeRules

  Change: New TCP ECN "Nonce Sum" flag now handled the same way as other ECN flags

  Bug fix: Packet loss problems with VLANs and (primarily) Realtek r8139 NICs

  Bug fix: Intel e100 NIC driver IRQ sharing problems

  Change: IPsec NAT traversal made controllable

Firewall Core - VPN specific

Bug fix: Security Alert: Buffer overrun in IKE certificate ASN.1 parser

Known bug: Interoperability problem with 7.0x gateways (unstable tunnels)

Firewall Core - HA specific

Known bug: No state synchronization for FTP ALG

New files installed by v8.10.02

This is a list of the files that are new to the v8.10.02 release. All paths are relative to your Firewall Manager install folder.

»	Cores/fwc-8.10.02-full.cfx This is the v8.10.02 full firewall core. Upload it to your existing firewall, or create new boot media with it. It contains VPN as well as HA functionality.
»	Cores/fwc-8.10.02-novpn.cfx This is a version of the v8.10.02 core without VPN support. It is roughly half the size of the full version.
»	Cores/fwcoreup8.exe This is the core used to remotely upgrade v7.0x and earlier firewalls. It will install a "8.00.02-full" core.
»	Docs/Changes-8.10.01-to-8.10.02.html This document.
»	FWMgr8.exe This is the v8.10.02 Firewall Manager. Earlier version 8 Firewall Managers will be overwritten. Version 7 Firewall Managers (if installed) will not be overwritten, as they are named "FWMgr7.exe", and are also typically installed in a different directory.

How to upgrade earlier v8.0x firewalls to v8.10.02

Upgrading a previous v8.0x firewall to v8.10.02 is completely straightforward.
Simply upload the new core, "fwc-8.10.02-full.cfx", to your firewall and restart it.
(Alternatively, upload the "-novpn" version if you do not wish VPN functionality.)

HA upgrade procedure

Note: For upgrades from v7.x HA clusters, first follow the HA upgrade procedures outlined in changes-7.0x.xx-to-8.00.02.html.

There are no incompatibilities in the HA synchronization protocol between 8.10.02 HA cores and earlier v8.0x HA cores. No special procedures are required.

Simply upload the new firewall core file to the firewalls in your cluster and make sure that the first upload and restart is successful before uploading to the second firewall.

We recommend beginning with the firewall that is currently active, even though this will necessitate two failovers. The reason for this is that ALG sessions are not synchronized.

The "immediate availability" method

Upload the core to the currently active firewall ("firewall A") and restart it.
Issue a 'reconfigure' on the firewall B to rapidly fail back to the now upgraded firewall A. Make sure firewall A functions properly.
Upload the core to firewall B and restart it.
End result: Firewall A is now the active node, just as it was before the upgrade procedure.

Note that this leaves the second firewall untested, even though it most likely will work just as well as the first firewall. If you want to specifically test the second firewall, you can:
1) cause two failovers manually, or
2) connect to it via e.g. the remote console just to make sure it's running, or
3) if ALG synchronization is not a concern, follow this procedure:

The "long-term safe" procedure:

Upload the core to the currently inactive firewall ("firewall B") and restart it.
Issue a 'reconfigure' on firewall A. This causes failover to firewall B. Make sure firewall B functions properly.
Upload the core to firewall A and restart it.
Issue a 'reconfigure' on firewall B to fall back to firewall A. Make sure firewall A functions properly.
End result: Firewall A is now the active node, just as it was before the upgrade procedure.

Again, note that the "availability" issues only affect ALGs. All other states are, as usual, fully synchronized and not affected in either procedure.

Firewall Manager Bug Fixes

Netobject name changes do not propagate to comma-separated lists
Issue:	It is possible to use lists of netobject directly in the rules section and other places without creating a netobject group and then using this group.
Problem:	If a netobject is renamed, the name change would not propagate to such lists where it is used. A netobject could be deleted even though being in use.
Result:	The configuration would most likely fail to parse and could not be saved.
Affects:	FWMgr v8.00.00-8.00.06, v8.10.00-v8.10.01.
Fixed:	Fixed in v8.00.07, v8.10.02 and v8.20.00.

Copying service groups causes FWMgr to freeze
Problem:	Attempting to make a copy of a service group would cause FWMgr to freeze and consume 100% CPU.
Affects:	FWMgr v8.00.00-8.00.06, v8.10.00-v8.10.01.
Fixed:	Fixed in v8.00.07, v8.10.02 and v8.20.00.

Status icon of folders etc not updated when firewall status changes
Issue:	When the status of a firewall changes (e.g. from 'up and running' to 'unreachable'), the status of its parent folder / namespace / cluster should change with it.
Problem:	This change would not occur until the folder / namespace / cluster in question was clicked.
Affects:	FWMgr v8.00.00-8.00.06, v8.10.00-8.10.01.
Fixed:	Fixed in v8.00.07, v8.10.02 and v8.20.00.

"Upload HTML Banner Files" ignores folder names with upper case letters
Issue:	It is possible to customize the HTML pages displayed when doing user authentication via HTML forms. It is possible to customize the look of these pages on a per-rule basis by using separate directories.
Problem:	The upload procedure would ignore folder names containing upper case letters.
Result:	The firewall would display a warning about the designated folder missing, and revert to using the built-in page set.
Affects:	FWMgr v8.10.00-8.10.01.
Fixed:	Fixed in v8.10.02 and v8.20.00.

Configuration download from HA cluster fails
Problem:	Configuration download from HA cluster members will make erroneous changes to the downloaded configuration file before saving it.
Results:	The IP addresses of interfaces will be changed around. The configuration will still parse, but will not function properly if uploaded to the cluster members.
Affects:	FWMgr v8.10.00-8.10.01 and v8.20.00.
Fixed:	Fixed in v8.10.02, v8.20.01 and v8.30.00.

Firewall Core Changes

Log events now emitted for NetconBeforeRules/SNMPBeforeRules/IPsecBeforeRules
Issue:	As of v8.00.00, there are settings for allowing Netcon (firewall remote control), SNMP and IPsec directly to the firewall without examining the ruleset.
Change:	As of v8.00.06, v8.10.02 and v8.20.00, log events are now emitted for all connections permitted by these settings. If logging is not wanted, simply disable the settings and write own rules for the respective traffic types with logging disabled.

New TCP ECN "Nonce Sum" flag now handled the same way as other ECN flags

Issue:

The TCP Explicit Congestion Notification mechanism has previously only been using two TCP flags: ECE and CWR (previously known as the XMAS/YMAS flags). A new extension to the ECN mechanism will add a third flag, "NS". This flag must be handled the same way as the original two flags.

Change:

As of 8.00.07, 8.10.02 and 8.20.00, the following changes are made:

»	The "TCPECN" setting now works on three flags : the original two, plus the new "NS" flag.
»	The "TCPRF" setting, which previously worked on four unused flags in the TCP header now only works on three flags, as one of them was used by the new "NS" flag.
»	TCP flag dumps generated by the firewall (e.g. syslog events) will display the flag as "ns=1".
»	TCP flag dumps were also revised to show "ece=1" and "cwr=1" rather than "xmas=1" and "ymas=1".

Note:

As the "TCPECN" and "TCPRF" settings both default to "Strip", there is no difference for configurations where these values have been left unchanged.
However, for configurations where ECN has been allowed (TCPECN = Ignore), it will soon become necessary to upgrade, or make sure that TCPECN and TCPRF are set the same way. The former is more preferable.

Firewall Core Bug Fixes

Packet loss problems with VLANs and (primarily) Realtek r8139 NICs
Problem:	The transmit queue of r8193 NICs is extraordinarily small. When packets were sent on VLANs, the transmit queue was not despooled quickly enough.
Results:	The transmit queue could become full, with packet loss as a result. This would be especially noticeable when the firewall itself is generating traffic, which is the case with remote administration traffic such as statistics polling and file transfers. Other NICs have transmit queue sizes 10 to 50 times larger; we believe that the effects were negligible for VLAN operation over non-r8193 NICs.
Affects:	v8.00.00-8.00.06 and v8.10.00-8.10.01.
Fixed:	Fixed in v8.00.07, v8.10.02 and v8.20.00.

Intel e100 NIC driver IRQ sharing problems
Problem:	The Intel e100 driver may cause problems if it shares IRQs with other NIC cards.
Results:	The firewall would freeze during startup or during only a short time of operation.
Affects:	v8.00.00-8.00.06, v8.10.00-8.10.01 and v8.20.00. Clavister Firewall appliances not affected.
Fixed:	Fixed in v8.00.07, v8.10.02, v8.20.01 and v8.30.00.

Firewall Core - VPN Specific Changes

IPsec NAT traversal made controllable

Issue:

When NAT traversal was implemented, we assumed that automatic sensing of whether or not it was needed (and supported by the other end) would be enough. This has not not been the case.

Many broadband routers and other NATing gateways implement special "IPsec passthrough" NAT code which assumes that only plain ESP encapsulation is used, and will misbehave fatally when UDP encapsulation is actually used. This is ironic, seeing as how IPsec UDP encapsulation is specifically designed to traverse NATing gateways without requiring the gateway to have specific knowledge of IPsec.
This scenario is solved by disabling NAT-T for such tunnels.

Some IPsec gateways become confused when they see a peer that advertises NAT traversal support, but deems its use unnecessary, and does not request NAT-T. Sonicwall gateways reportedly have this problem.
This scenario is solved by either disabling NAT-T, or forcing it to on.

Change:

As of v8.10.02 and v8.20.00, there is a setting in the VPN tunnel properties dialog, which allows NAT traversal to be configured as follows:

»	Always off, even if a NAT is detected.
»	On, if a NAT is detected, and the peer supports it (this is the default).
»	On, regardless of the presence of a NAT, as long as the peer supports it.

Firewall Core - VPN Specific Bug Fixes

Security Alert: Buffer overrun in IKE certificate ASN.1 parser

Issue:

All VPN enabled firewalls that support certificate-based authentication are vulnerable to a buffer overrun in the ASN.1 parser in the IKE code.

Impact:

If an IKE connection can be established to a VPN enabled firewall, the firewall can be crashed. This normally leads to an automatic restart.
The full extent of the buffer overrun is not yet fully understood; for the time being, Clavister assumes that it may be possible to take control of the firewall itself. Initial observations however suggest that this may be difficult.

Workaround:

»	For firewalls that do not require VPN functionality: upload a firewall core that does not support IPsec VPNs ("-novpn" cores).
»	For VPN gateways: disable the "IPsecBeforeRules" advanced setting and add rules that allow IKE and IPsec (e.g. the "ipsec-suite" service) only from known IP addresses. This reduces the window of exposure until a patch can be installed. It may indeed be a good idea to always restrict who may speak IPsec to your VPN gateways, if possible.

Affects:

v8.00.00-8.00.06, v8.10.00-8.10.01 and v8.20.00.

Fixed:

Fixed in v8.00.07, v8.10.02, v8.20.01 and v8.30.00

Firewall Core - VPN Specific Known Problems

Interoperability problem with 7.0x gateways (unstable tunnels)
Problem:	We have received reports of tunnel instability problems between 7.0x and 8.x VPN gateways. We are currently investigating these reports; it is possible, albeit not certain, that these problems are linked to IKE SAs having lifetimes over four hours.
Action:	Please report any such problems to support@clavister.com, and, if possible, the results of lowering the IKE lifetime to four hours or less.
Workaround:	Use the "VPN Keepalive" functionality in v8.2+ gateways to monitor and quickly reestablish tunnels that cease working. Using manual configuration of the monitoring settings, this will work even though the remote gateway is not a v8.2 (or, indeed, Clavister) gateway.
Note:	If we do not receive new information on this issue, it will be closed without further action and this note not included in subsequent release notes.

Firewall Core - HA Known Bugs / Problems

No state synchronization for FTP ALG
Problem:	No aspect of the FTP ALG is state synchronized
Results:	This means that control channels as well as data channel established through the FTP ALG will freeze when the cluster fails over to the other peer. If, however, the cluster fails back over to the original peer within approximately half a minute, frozen sessions (and associated transfers) should begin working again. Note that such failover occurs each time a new configuration is uploaded.