Release date: 2003-02-19 [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.00.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.

Note that there was no 8.00.03 public release. It mainly solved driver problems for the realtek NIC, used in R33 appliances. All R33 appliances have been delivered with 8.00.03 (or later) cores. Version 8.00.04 was also very limited due to early discovery of a newly introduced bug in the DHCP client. This has been fixed in v8.00.05.

New files installed by v8.00.05
How to upgrade earlier v8.0x firewalls to v8.00.05
How to upgrade v6.0x/v7.0x firewalls to v8.0x
HA upgrade procedure
Firewall Manager		[Bug Fixes]
Firewall Core	[Changes]	[Bug Fixes]	[Known Bugs / Problems]
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.

Firewall Manager

• Cores/fwc-8.00.05-full.cfx
  This is the v8.00.05 full firewall core. Upload it to your existing (standard) firewall, or create new boot media with it. It contains VPN as well as HA functionality.
  

• Cores/fwc-8.00.05-novpn.cfx
  This is a version of the v8.00.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.00.02-to-8.00.05.htm
  This document.

• FWMgr8.exe
  This is the v8.00.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.

There are no incompatibilities in the HA synchronization protocol between 8.00.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 now 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.

• Lifetimes of locally defined IPsec/IKE proposals could not be changed
  Issue: Lifetimes for IPsec/IKE proposals may be stored both in the global namespace (the recommended location; as these values need to be shared between gateways) as well as locally for a specific firewall.
  Problem: The lifetimes of locally defined proposals sometimes could not be changed.
  Fixed: Fixed in v8.00.04.
  Affects: v8.00.00 - v8.00.03.
  

• FWMgr would not allow PBR rules with Fwd=<main> and Ret=<main>
  Issue: It is often useful to make exceptions in the policy-based routing ruleset by placing rules earlier in the ruleset that specify <main> as the routing table to use in both the forward and return direction.
  Problem: The firewall manager would not allow PBR rules with <main> used in both directions
  Workaround: Create an empty dummy routing table to use instead of <main>; the lookup will fall back to using the main table if the lookup in the PBR tables fails to find a matching route.
  Fixed: Fixed in v8.00.04.
  Affects: v8.00.00 - v8.00.03.
  

• Identical proposals could not be used in multiple proposal lists
  Issue: The firewall manager would name identical proposals the same way, which caused name collisions (errors) if identical proposals were used in more than one proposal list.
  Results: One would have to work around the problem by altering one proposal slightly.
  Fixed: Fixed in v8.00.03.
  Affects: v8.00.00 - v8.00.02.
  

• Old "stage2.bin" files were uploaded by "upgrade firmware" - firewalls could stop booting
  Issue: As of 8.00.03, firewalls are shipped with a new "stage2.bin" (second-stage boot loader). This file is tightly tied to the boot sector, which also changed. Old "stage2.bin" files are so far distributed with the firewall manager.
  Problem: The firewall manager uploaded the old "stage2.bin" file on "upgrade firmware".
  Results: Appliances delivered with new "stage2.bin" files could no longer boot after the erronous upload. Affected appliances would have to have their boot media reconstructed.
  Fixed: Fixed in v8.00.03. "stage2.bin" is no longer uploaded.
  Affects: FWMgr v8.00.00 - v8.00.02 in combination with firewall appliances that came preinstalled with v8.00.03+ cores. Older appliances and software firewalls were never affected.
  

• Better error reporting and media forcing in Realtek NIC driver
  The Realtek R8129/8139 NIC driver now has much more detailed reporting of link status and speed, and whether or not this information comes from autonegotiation, autosensing or if the values are simply forced.
  Speed and duplex forcing also work better against units that violate the autonegotiation protocol (or simply do not speak it at all).
  Changed in: v8.00.04
  
  

• New arguments to the "time" command: "-set" and "-sync"
  The local firewall time can now be set from the command prompt through the new "time -set YYYY-MM-DD HH:MM:SS" command.
  Time synchronization can also be initiated on demand through the new "time -sync" command, if time servers are configured in the Settings section. If clock drift is too high, "time -sync -force" may be used to override the Timesync_MaxAdjust limit.
  Manual time setting was previously only possible through the boot menu, which requires either physical access to the firewall or modem access to the serial port.
  Changed in: v8.00.04
  

• DHCP client can now be configured to start with 0.0.0.0
  The DHCP client normally picks a link-local (169.254.x.x) IP address while waiting for a lease to arrive. Using link-local IP addresses is a relatively new addition to the DHCP standard, so to avoid as-yet unseen compatibility problems, the DHCP client can now be configured to adhere to the old BOOTP/DHCP specifications and use 0.0.0.0 until a lease is received.
  This behavior is controlled through the new "DHCP_UseLinkLocalIP" setting, which defaults to on (i.e. no change from previous versions by default).
  Changed in: v8.00.05
  

• DHCP client less restrictive
  Because of the prevalence of non-standards-compliant and/or misconfigured DHCP servers and relayers, several sanity checks have been removed from the DHCP client:
  - The DHCP client previously rejected leases with the gateway equal to the proposed IP address. This is now allowed, and treated as if there is no gateway at all.
  - The DHCP client also did basic sanity verification on the renew/rebind timers by rejecting leases with these timers set lower than five and seven seconds, respectively. Apparently, there are badly broken DHCP servers out there that hand out even lower times. Such times are now simply rewritten to 50% and 90% of the total lease time, respectively.
  - To support "quirky" setups, the DHCP client will now also allow the IP and/or gateway address to equal the lowest and/or highest address of the assigned network, for network sizes /29--/32.
  Changed in: v8.00.05
  

• SAT SETDEST rules with destnet=0.0.0.0/0 now become redirects
  SAT rules normally transpose IP ranges. E.g. a rule like:
    SAT   ext all-nets   any 1.2.3.0-1.2.3.4   SETDEST 5.6.7.10
  will map 1.2.3.0 to 5.6.7.10, 1.2.3.1 to 5.6.7.11, etc.
  This behavior is not useful if the destination network in a SAT SETDEST rule is 0.0.0.0/0, so this special case has been changed: when the destination network is 0.0.0.0/0, all addresses will map to the single "new address" set in the rule.
  This is useful for e.g. building a transparent HTTP proxy using the Squid Cache, which requires that all traffic to be transparently proxied be redirected to its own IP address.
  Changed in: v8.00.05
  

• FTP ALG freeze/reboot problems resolved
  Issue: On some firewalls, the FTP ALG is very unstable, and causes freezes and/or reboots.
  Affects: Firewall cores v8.00.00-.04.
  Fixed: Fixed in v8.00.05.
  

• FTP ALG: Active mode connections would fail through some remote firewalls
  Issue: The FTP ALG would fail to form data connections on the client end if the client was behind e.g. Checkpoint Firewall-1. The reason is that the FTP ALG originated the data channel on a dynamic port. FW-1 expects the data connection to originate from port 20.
  Affects: Affects FTP clients connecting through such firewalls to an FTP server protected by the Clavister Firewall FTP ALG, v8.00.00 - v8.00.03.
  Fixed: Fixed in v8.00.04. The FTP ALG will now originate its data connection from the port below the command port. For FTP servers listening on port 21, this translates to port 20.
  

• DHCP relayer would (correctly) refuse too short DHCP packets
  Issue: According to the BOOTP and DHCP RFCs, all BOOTP/DHCP packets must be at least 300 bytes in size, and use padding to reach this size if the actual data is shorter. The DHCP relayer used to verify this size and drop packets
  Problem: Some DHCP clients/servers (notably, the Windows 2000 DHCP server) violate the RFCs and send packets shorter than 300 bytes.
  Results: Misbehaving clients would be unable to aquire DHCP leases through the DHCP relayer. Misbehaving servers would be unable to hand out DHCP leases through the DHCP relayer.
  Workaround: For servers: add more options to the leases so that the packets sent by the server are longer than 300 bytes.   For clients: none known.
  Affects: Firewall cores v8.00.00 - v8.00.03.
  Fixed: Fixed in v8.00.04. The DHCP relayer now only verifies that the packet contains all the data it should. It no longer enforces the 300-byte minimum.
  

• DHCP client problems in multi-DHCP-server networks
  Issue: In networks with more than one DHCP server, especially one than hands out leases that are somehow disallowed (e.g. too short lease time), the DHCP client would behave poorly.
  Problem: The DHCP client would pick the first lease offer to arrive, and then request it. At this point, it would discover if the lease was indeed invalid, and, if so, return to the "DHCP discover" phase and request a new list of offers.
  Results: If a rogue DHCP server hands out leases that the firewall is configured to reject, and this server is faster than the legitimate server, the firewall would fail to aquire a lease until the legitimate server is faster than the rogue one.
  Workaround: Locate and disable the misbehaving DHCP server. Some cable/ADSL modems with built-in DHCP servers have been seen to have extremely short lease times (e.g. 20 seconds).
  Affects: All firewall cores up to and including v8.00.03.
  Fixed: Fixed in v8.00.04. The offered leases are now also verified before they are actually picked and requested from the server.
  

• Realtek network cards could stop receiving packets
  Issue: A documented misfeature of the Realtek R8129/8139 NICs is that they freeze if they fail to upload received packets to RAM. This may happen during high local load, e.g. during disk activity.
  The workaround suggested by Realtek is to reset the NIC when this happens.
  Problem: The suggested workaround was not implemented. When this error occured, the NIC stayed frozen until the configuration was re-read or the firewall rebooted.
  Affects: Software firewalls with realtek NICs, using cores v8.00.00 - v8.00.02.
  Fixed: Fixed in v8.00.03.
  

• Time synchronizer would not update the computer RTC
  Issue: The remote time synchronizer would not update the computer hardware Real-Time Clock.
  Results: After a reboot, the firewall would trust the (possibly incorrect) RTC until it could contact a time server and retreive the correct time.
  If the RTC clock drift was high enough (higher than what the Timesync_MaxAdjust setting allows), time synchronization would fail completely.
  Affects: Firewall cores v8.00.00 - v8.00.03, but is really only important in VPN gateways where certificates are used.
  Fixed: Fixed in v8.00.04. The RTC is now updated when the firewall receives time synchronization data, or when the "time -set" command is executed.
  

• DHCP client goes into a reconfigure loop (8.00.04 only)
  Issue: The DHCP client erronously checks for IP and network collisions after receiving and accepting a lease and reconfiguring to activate it.
  Results: As long as IP and network collision is activated (it is, by default), the firewall will think that its own IP collides with its own IP, and reconfigure again to drop the lease. At this point, it will acquire a new lease, reconfigure to activate it, and the loop has begun.
  Workaround: (Temporarily) disable "Don't allow IP collisions with static routes" until the firewall can be upgraded to v8.00.05.
  Affects: Firewall core v8.00.04.
  Fixed: Fixed in v8.00.05.
  

• DHCP relayer fails to add dynamic routes unless configured to do proxy ARP for the route (8.00.04 only)
  Issue: As of v8.00.04, the DHCP relayer will not add dynamic routes according to the leases it relays, unless explicitly told to do so in the configuration. Unfortunately, firewall managers v8.00.00-.04 only do so if proxy ARP settings are configured for the dynamically added route.
  Workaround: Configure all DHCP relayer rules to use proxy ARP on the routes that you want it to dynamically add.
  Affects: Firewall cores v8.00.04 and up, if FWMgr v8.00.00-.04 is used.
  Fixed: This was fixed in Firewall Manager v8.00.05.
  

• DHCP client fails to receive unchecksummed leases (8.00.04 only)
  Issue: DHCP uses the UDP protocol. A provision of UDP is to set the checksum to zero for "don't care". It makes no real sense for DHCP servers to disable UDP checksumming, but some do.
  Problem: The DHCP client failed to recognize zero checksums. Leases received from servers that disable UDP checksums would be silently dropped.
  Affects: Firewall core v8.00.04.
  Fixed: Fixed in v8.00.05.
  

• VPN tunnels unstable with IKE lifetimes over 4 hours
  Issue: RFC2408 recommends use of "time variant" material in creating IKE "cookies" (loosely: session IDs) to protect against overload attacks. Clavister Firewall has followed this recommendation up to v8.00.03, with a period of four hours.
  Problem: An IKE SA that lives past the "time variant" period is considered "illegal", and is dropped.
  Results: If IKE SAs used lifetimes over four hours, they would eventually be invalidated, and new IPsec SAs could not be negotiated over them. Tunnels would function for a number of hours and then cease to function as the IPsec SA timed out and could not be renegotiated.
  Workaround: Select IKE lifetimes of four hours (14400s) or less.
  Affects: All firewall cores up to v8.00.03.
  Fixed: Fixed in v8.00.04, by removing this time variant keying material completely. In our implementation, it did not actually add any resistance to overload attacks; the underlying algorithms handle it equally well without this added layer.
  

• Continuous phase-2 retries could crash the firewall
  Issue: If phase-1 negotiation and authentication succeeded, but phase-2 negotiation failed due to misconfiguration, and the remote gateway aggressively retried the phase-2 negotiation, it could trigger a timing race bug and crash the firewall.
  Results: Triggering this bug normally leads to a reboot.
  Workaround: Configure the tunnel endpoints correctly so that phase-2 negotiation succeeds.
  Affects: All firewall cores up to v8.00.03. Units known to aggressively retry the phase-2 negotiation include the Intel Netstructure VPN Gateway family.
  Fixed: Fixed in v8.00.04.
  

• Crash when fetching (some) LDAP CRLs
  Issue: VPN gateways set to retreive their CRLs via LDAP, where the CDP (CRL Distribution Point) location ends with a "?", could crash.
  Affects: v8.00.00-v8.00.03.
  Fixed: Fixed in v8.00.04.
  

• Certificates using non-ASCII encodings would not work
  Issue: Certificates using non-ASCII character encoding schemes would not work; they would never match configured ID lists.
  Affects: v8.00.00-v8.00.03.
  Fixed: Fixed in v8.00.04.
  

• Interoperability problem with 7.0x gateways (unstable tunnels)
  We have received reports of tunnel instability problems between 7.0x and 8.00.04(-pre) 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.
  Please report any such problems to support@clavister.com, and, if possible, the results of lowering the IKE lifetime to four hours or less.

• No state synchronization for FTP ALG
  No aspect of the FTP ALG is state synchronized.
  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 session (and associated transfers) should begin working again.
  Note that such failover occurs each time a new configuration is uploaded.