Clavister Firewall Changes from v8.40.01 to v8.40.04

Clavister Firewall Changes from v8.40.01 to v8.40.04

Release date: 2004-10-06 [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.0, you can follow the procedures in this document.

Version 8.40.04 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.40.04

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

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]

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: PPPoE interfaces could only assign IP/net information to automatically generated netobject names

Bug fix: Could not configure DHCP option 43 as binary in DHCP server

Firewall Core

  Change: HighBuffers setting now dynamic by default

  Change: DHCP server: improved handling of default gateway in leases

  Bug fix: HTTP ALG stability (crash) problem fixed

  Bug fix: PPPoE would not reconnect on link loss

  Bug fix: Only the first interface could be used in initial setup via serial console

  Bug fix: DHCP client would not accept leases with no default gateway set

  Bug fix: HTTP ALG may erroneously reject some pages served using "chunked encoding"

  Bug fix: HTTP ALG syslog format did not adhere to standard Clavister syslog format

Firewall Core - VPN specific

  Change: Workaround for Watchguard VPN client XAUTH interop problem

  Bug fix: AES, 3DES and DES ciphers would only work on accelerated crypto appliances

  Bug fix: AES, 3DES and DES problems on SG-31xx appliances

  Bug fix: Crash on config read with complex VPN network setups and keepalives enabled

Firewall Core - HA specific

Known bug: No state synchronization for ALGs

New files installed by v8.40.04

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

»	Cores/fwc-8.40.04-full.cfx This is the v8.40.04 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.40.04-novpn.cfx This is a version of the v8.40.04 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.40.01-to-8.40.04.html This document.
»	FWMgr8.exe This is the v8.40.04 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.40.04

Upgrading a previous v8.0x firewall to v8.40.04 is completely straightforward.
Simply upload the new core, "fwc-8.40.04-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.40.04 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

PPPoE interfaces could only assign IP/net information to automatically generated netobject names
Issue:	Configuration information received during run-time for interfaces capable of this (DHCP, PPPoE) has to be assigned to netobjects in order for the firewall to make use of them.
	The names to which this information gets assigned may be either automatically computed (e.g. "ip_<ifname>", "<ifname>net"), or specified by the user.
Problem:	Using automatically computed names would work. However, configuring manually specified names would not work - the changes were not properly written to the configuration.
Results:	The firewall would keep using automatically computed names.
Affects:	Affects FWMgr v8.30.00--.01 and v8.40.00--.01.
Fixed:	Fixed in FWMgr v8.30.02 and v8.40.02.

Could not configure DHCP option 43 as binary in DHCP server
Issue:	DHCP option 43 is "Vendor Specific" and should be treated as binary. The firewall manager, however, treated it as a string
Problem:	For many vendor extensions, it could not be set to values required by those vendors.
Affects:	Affects FWMgr v8.40.00--.01.
Fixed:	Fixed in FWMgr v8.40.02.

Firewall Core Changes

HighBuffers setting now dynamic by default
Issue:	The HighBuffers setting previously defaulted to 1024 packet buffers. This is barely enough for high-end gateways with 8+ gigabit NICs; their RX rings alone consume 512 buffers at start-up. (See KB #10024 for more information.)
Change:	As of v8.40.02, the HighBuffers setting may be set to "dynamic" (this is also the new default), which means that 3% of available RAM is used for packet buffers. For a high-end gateway with 1GB RAM, this means over 10000 buffers. For smaller gateways, where 3% would mean fewer than 1024 buffers, the algorithm will simply pick 1024 as a resonable default.

DHCP server: improved handling of default gateway in leases

Issue:

Some network topologies have no explicitly configured default router and rely on proxy ARPing all non-local addresses. A DHCP server should be able to hand out leases to clients saying that their default gateway is their own IP addresses to force this behavior. It should also be able to exclude default gateway information from the lease altogether.

Change:

As of v8.30.02 / v8.40.01, the default gateway can be configured in two new ways:

»	Configuring the default gateway as "0.0.0.0", which causes the DHCP server to hand out the clients' own IP addresses to them as default gateway.
»	Leaving the default gateway field blank, which causes the DHCP server to not send default gateway information to clients at all.

Firewall Core Bug Fixes

HTTP ALG stability (crash) problem fixed
Issue:	Certain URLs would trigger a crash in the HTTP ALG, bringing the whole firewall down along with it.
Affects:	Clavister Firewall v8.40.00 -- .01.
Fixed:	Fixed in v8.40.02.

PPPoE would not reconnect on link loss
Problem:	PPPoE interfaces would not automatically reconnect if they lost link to the PPPoE server.
Results:	The interface would remain down until the firewall was restarted. For PPPoE connections to some ISPs, this problem was aggravated, since they routinely tear down all PPPoE sessions once a day - supposedly to prevent always-on machines from retaining the same IP address for extended times.
Affects:	Clavister Firewall v8.30.00 -- v8.40.01.
Fixed:	Fixed in v8.40.02.

Only the first interface could be used in initial setup via serial console
Issue:	During setup via the serial console, one should be able to set up any of the available interfaces for initial administrative use.
Problem:	Due to a bug, only the first interface ("if1") could be used during setup via the serial console. Setup via the front panel however was not affected.
Affects:	Boot menu shipping with Clavister Firewall v8.40.00 -- .01.
Fixed:	Fixed in boot menu shipping with v8.40.02.

DHCP client would not accept leases with no default gateway set
Issue:	Normally, DHCP servers hand out leases with the default gateway set. However, in some scenarios, it is desirable to make DHCP clients behave as if every address is local by handing out leases with no default gateway set.
Problem:	Clavister Firewall would not accept leases with no default gateway set.
Affects:	All versions prior to v8.30.02, and v8.40.00 -- .01.
Fixed:	Fixed in v8.30.02 and v8.40.02.
Note:	The "DHCPClient"->"DHCP_AllowGlobalBcast" advanced setting must be set to "Yes" in order for this to work.

HTTP ALG may erroneously reject some pages served using "chunked encoding"
Issue:	When web servers do not know the length of the output page beforehand, and want to keep the HTTP connection alive when the page is done, they may use "chunked encoding" to send content in separate chunks. This is normally never the case for static HTML or images, but may be the case for dynamic content.
Problem:	If a chunk header arrives but no actual data follows in the same TCP segment, the HTTP ALG will erroneously reject the stream. Note that this is not the norm; normally, there will be data immediately following the chunk header. However, a few sites deviate from this norm.
Results:	The page download may abort at any point during the download, or before any content is received, depending on when this condition occurs.
Affects:	Clavister Firewall v8.40.00 -- .01.
Fixed:	Fixed in v8.40.02 and v8.50.00.

HTTP ALG syslog format did not adhere to standard Clavister syslog format
Issue:	All syslog data output by Clavister Firewall follows a "name=value" format. This was not true for the HTTP ALG syslog output.
Affects:	Clavister Firewall v8.40.00 -- .01.
Fixed:	Fixed in v8.40.02.

Firewall Core - VPN Specific Changes

Workaround for Watchguard VPN client XAUTH interop problem
Issue:	When Watchguard VPN clients use XAUTH to authenticate themselves, the IKE negotiation completes successfully, and Clavister Firewall registers the user in question as logged on. However, when the negotiation is done, the client immediately sends an "invalid SPI" notification, which causes the IKE SA to close, and the user to immediately become logged out.
Change:	As of v8.30.02, v8.40.02 and v8.50.00, the user authentication subsystem will also track IPsec SAs and consider the user logged on as long as there are either IPsec or IKE SAs. The problem with the IKE SAs being immediately closed due to the unusual notification message remains, but does not affect the operation of the VPN tunnel.

Firewall Core - VPN Specific Bug Fixes

AES, 3DES and DES ciphers would only work on accelerated crypto appliances
Problem:	In v8.40.02, changes were made for accelerated crypto appliances for the AES, 3DES and DES ciphers. These changes caused these ciphers to cease working in un-accelerated modes.
Results:	IPsec tunnels using these ciphers would establish correctly and then fail to forward any packets. Tunnels using other ciphers would function correctly.
Affects:	Clavister Firewall v8.40.02.
Fixed:	Fixed in v8.40.03.

AES, 3DES and DES problems on SG-31xx appliances
Problem:	As of 8.40.02, AES, 3DES and DES acceleration was highly unstable on SG-31xx appliances.
Affects:	SG-31xx appliances running Clavister Firewall v8.40.02 -- .03.
Fixed:	Fixed in v8.40.04

Crash on config read with complex VPN network setups and keepalives enabled
Problem:	A VPN connection configured with a list of ranges for one end and a single range (or IP address) for the other end, while having keepalives enabled, would cause a bad memory read.
Results:	The firewall would crash and reload while reading the configuration file.
Affects:	Clavister Firewall v8.20.00--.01, v8.30.00--.01 and v8.40.00--.01.
Fixed:	Fixed in v8.20.02, v8.30.02 and v8.40.02.
Note:	Note that a VPN tunnel configured with only single ranges in both ends, or with lists of ranges in both ends would not trigger the bug. Neither would any sort of tunnel with keepalives disabled.

Firewall Core - HA Known Bugs / Problems

No state synchronization for ALGs
Problem:	No aspect of the FTP or HTTP ALGs are state synchronized
Results:	This means that all traffic handled by ALGs 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 (and consequent fallback) occurs each time a new configuration is uploaded.