Clavister Firewall Changes from v8.40.04 to v8.40.05

Clavister Firewall Changes from v8.40.04 to v8.40.05

Release date: 2004-02-22 [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.05 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.05

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

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
[Bug Fixes]

Firewall Core - HA specific
[Bug Fixes] [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: Firewalls set as DNS names could not revert back to numeric IP address

Firewall Core

  Change: FTP ALG list of known and disallowed commands updated

  Change: DHCP client will now include options 12, 60 and 61 in requests

  Bug fix: HTTP ALG problems with Microsoft Windows Update and some other sites

  Bug fix: Intel e1000 NIC link problems (gigabit ports in all Clavister appliances)

  Bug fix: FTP ALG problems with PBR

  Bug fix: User authentication timeouts not reset by traffic passing through FwdFast rules

  Bug fix: Crash if DNS client was making a query during a config re-read

  Bug fix: Deselecting an ALG from a service would require a reboot

Firewall Core - VPN specific

  Bug fix: DES/3DES/AES performance problem on SG31xx appliances

  Bug fix: Automatic IPsec keepalives would not work with 0.0.0.0/0 as local or remote net

  Bug fix: Auto-adding routes would fail intermittently

  Bug fix: IPsec data lifetimes higher than 4194304KB (4GB) would be misinterpreted

  Bug fix: DSA certificates would not work in IPsec

Firewall Core - HA specific

Bug fix: Incorrect behavior of Route Local IPs on inactive node

Known problem: No state synchronization for ALGs

New files installed by v8.40.05

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

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

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

Firewalls set as DNS names could not revert back to numeric IP address
Issue:	In order to facilitate remote management of firewalls without fixed IP addresses, the Firewall Manager may be told to connect to the firewall using a DNS hostname.
Problem:	Reverting to using a numeric IP address would not work. The firewall manager would keep trying to resolve the previously given DNS name.
Results:	If the DNS name would not resolve, or would resolve to the wrong IP address, remote management of the firewall would be impossible.
Affects:	Firewall Manager v8.00.00 and up.
Fix:	Fixed in v8.40.05 and v8.50.00.

Firewall Core Changes

FTP ALG list of known and disallowed commands updated
Issue:	The FTP ALG keeps a list of commands that are "known" and hence allowed through it. By default, everything else is disallowed. However, it is possible to tell it to "Allow Unknown Commands", in which case there is a list of explicitly disallowed commands that is still used. The reason for the latter list is that they won't work through the ALG anyway.
Change:	As of v8.40.05 and v8.50.00, the following commands have been added to the "known commands" list: "XMKD", "XRMD", "XPWD", "XCUP" and "XCWD".
	Two commands have been added to the "disallowed commands" list: "MLST" and "MLSD". The reason is that MLSD uses data channels that would not work without explicit support in the FTP ALG anyway. Support for this may be added in a future release.

DHCP client will now include options 12, 60 and 61 in requests
Issue:	Some DHCP servers require options 12 (Host Name), 60 (Class Identifier) and 61 (Client Identifier) to be set in DHCP requests. Although requiring optional data in this manner could be considered a violation of the DHCP RFC, measures have been taken in the DHCP client in Clavister Firewall.
Change:	As of v8.40.05 and v8.50.00, the above options are included in all DHCP requests. The host name is constructed from the MAC address of the interface in question.

Firewall Core Bug Fixes

HTTP ALG problems with Microsoft Windows Update and some other sites
Issue:	In some cases, the HTTP ALG would believe that a HTTP response was invalid and refuse to pass it to the client.
Results:	The connection would be closed to the client, leading to an empty page being displayed. Or, in the case of Windows Update, the update process stalling before downloads begin.
Affects:	Clavister Firewall v8.40.00--.04.
Fix:	Fixed in v8.40.05 and v8.50.00.
Note:	Preliminary reports indicate that some problems may remain for a few sites. This is being investigated. Please report problem URLs to support@clavister.com after verifying that using plain state tracked http (port 80) makes the URL work again.

Intel e1000 NIC link problems (gigabit ports in all Clavister appliances)
Issue:	Some Intel e1000 series chips would have link problems establishing or maintaining link with some equipment.
Affects:	Clavister Firewall v7.00 and up.
Fix:	Fixed in v8.40.05 and v8.50.01.

FTP ALG problems with PBR
Issue:	There was a problem in the FTP ALG related to policy-based routing.
Results:	The command channel would work, but one of the transfer modes (passive or active FTP) would not work, depending on the routing scenario.
Affects:	Clavister Firewall v8.40.01--.04. FTP sessions using the main routing table only were not affected.
Fix:	Fixed in v8.40.05 and v8.50.00.

User authentication timeouts not reset by traffic passing through FwdFast rules
Issue:	When a user authenticated to the firewall has an "idle timeout" configured, it should be reset by traffic passing through the firewall.
Problem:	The idle timeout was only reset by traffic being permitted by "Allow" and "NAT" rules - state-tracked connections. Not by statelessly permitted traffic via "FwdFast" rules.
Result:	If all traffic for a logged-on user was permitted by FwdFast rules, they would be logged out when the "idle timeout" period expired regardless of sending traffic through the firewall or not.
Affects:	Clavister Firewall v8.10.00 and up.
Fix:	Fixed in v8.40.05 and v8.50.01.

Crash if DNS client was making a query during a config re-read
Issue:	If the DNS client was making a query during the time of a configuration re-read, it could lead to a crash and subsequent re-start.
Results:	The configuration re-read would, in the end, result in a restart instead. The configuration would be successfully re-read.
Affects:	Clavister Firewall v8.40.00--.04.
Fix:	Fixed in v8.40.05 and v8.50.00.

Deselecting an ALG from a service would require a reboot
Issue:	If an Application Layer Gateway previously had been selected for a service, and then was deselected from the service, the change would not be picked up by the firewall.
Results:	The ALG would remain active on the service until the firewall was rebooted, or the service deleted or renamed.
Affects:	Clavister Firewall v8.00.00 and up.
Fix:	Fixed in v8.40.05 and v8.50.00.

Firewall Core - VPN Specific Bug Fixes

DES/3DES/AES performance problem on SG31xx appliances
Problem:	The SG31xx appliance series would perform below spec for DES, 3DES and AES encrypted tunnels.
Affects:	Clavister SG31xx appliances running v8.40.00--.04
Fix:	Fixed in v8.40.05 and v8.50.00.

Automatic IPsec keepalives would not work with 0.0.0.0/0 as local or remote net
Problem:	The ICMP echo packets used inside the tunnel would be sent from 0.0.0.1, and be dropped by the Block0Net setting at the receiving end.
Results:	The packets would still be enough to trigger the tunnel to activate, but the keepalive logic would never see any responses. This would lead it to (correctly) assuming that there is something wrong with the keepalives, and it would never tear down the tunnel, regardless of whether it worked properly or not.
Affects:	Clavister Firewall v8.20.00--.01, v8.30.00--.01 and v8.40.00--.04.
Fix:	As of v8.20.02, v8.30.02, v8.40.05 and v8.50.00, the "Auto" mode will stay away from the 0.0.0.0/8 net and pick 1.0.0.1 or .2 instead.

Auto-adding routes would fail intermittently
Issue:	IPsec tunnels have the capability of auto-adding routes to IP addresses of incoming clients. This is useful in roaming user scenarios where DHCP over IPsec is not used (in which case the route would be added by the DHCP relayer).
Problem:	In some configurations, the automatic route addition would sometimes fail.
Results:	Connections back to the client would be impossible. Connections from the client could also be denied, depending on source IP validation policy. If however connections from the client were allowed, they would work due to the fact that connections originated from an IPsec tunnel would always send return traffic back through the same tunnel.
Affects:	Clavister Firewall v8.20.00 and up.
Fix:	Fixed in v8.40.05 and v8.50.00.

IPsec data lifetimes higher than 4194304KB (4GB) would be misinterpreted
Issue:	Due to an internal conversion error, data lifetimes higher than 4GB could not be handled.
Results:	Bit masking would occur, translating values just above 4GB to very low values, 5GB to 1GB, 6GB to 2GB, and so forth until wrapping occurs again.
Affects:	Clavister Firewall v5.1 and up.
Fix:	As of v8.40.05 and v8.50.00, values up to 4 terabytes are handled correctly, which is the upper limit supported by IPsec.

DSA certificates would not work in IPsec
Issue:	IPsec can use RSA and DSA certificates for authentication. RSA is by far and large the more common of the two.
Problem:	Attempting to upload a configuration using DSA certificates to the firewall would result in an error message: "Error: Failed to decode private key for name-of-your-cert"
Affects:	Clavister Firewall v8.10.00 -- .02, v8.20.00 -- .01, v8.30.00 -- .01, v8.40.00 -- .04, v8.50.00.
Fix:	Fixed in v8.10.03, v8.20.02, v8.30.02, v8.40.05 and v8.50.01.

Firewall Core - HA Bug Fixes

Incorrect behavior of Route Local IPs on inactive node

Problem:

If a route had a "Local IP" configured, the inactive node would use it, along with the shared MAC address, as source address when sending ARP queries for IP addresses in that route.

Results:

Depending on the switches in the network, two things could happen:

»	The inactive node would get no reply at all to queries for addresses covered by that route
»	OR communications through the active node would be disrupted for a short period of time until the switches re-learn that the shared MAC address actually belongs to the active node.

Affects:

Clavister Firewall v8.00.00 and up

Fix:

As of v8.00.08, v8.10.03, v8.20.02, v8.30.02, v8.40.05 and v8.50.00, the inactive node will ignore "Local IP" settings in routes and always use its unique interface address in ARP queries.

Note:

The fix may result in problems communicating with the inactive node, given that the "Local IP" setting was likely configured for a good reason. However, due to the way that the ARP protocol works, having the inactive node source ARP queries from an IP address currently "owned" by the active node would always result in disruptions of one sort or another.

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.