Release date: 2003-05-07 [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.00 is a new major version. It is available for all license holders with an "upgrades until" field of 2003-04-02 or later. The major new features are:

• User authentication via HTTP and/or IKE XAUTH to RADIUS back-ends (includes Active Directory via MS Internet Authentication Services).

• IPsec NAT traversal support. This support is already available in the Clavister VPN Client. Client-to-gateway and gateway-to-gateway VPN tunnels can now traverse any type of NAT transparently.

Firewall Manager

Firewall Core

• Cores/fwc-8.10.00-full.cfx
  This is the v8.10.00 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.00-novpn.cfx
  This is a version of the v8.10.00 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 v8.0x VPN core.

• Docs/Changes-8.00.06-to-8.10.00.htm
  This document.

• FWMgr8.exe
  This is the v8.10.00 Firewall Manager. Earlier version 8 Firewall Managers will be overwritten. The v8.10 manager is compatible with v8.0x firewalls. 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.10.00 HA cores and earlier v8.x 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.

Please see changes-8.00.05-to-8.00.06.html for the most recent bug fixes.

• User authentication via HTTP/XAUTH to RADIUS back-ends
  Users can now authenticate to the firewall; either via IKE XAUTH to authenticate VPN tunnels, or via HTTP to authenticate other traffic. This allows for much more fine-grained access controls. Authentication credentials are obtained via RADIUS, which includes Microsoft Active Directory via MS IAS, but also many other types of RADIUS servers.
  See e.g. KB articles #10011 and #10021 for more information.
  

• Changes to the initial setup procedure / boot menu
  

  • The initial setup procedure now provides the settings necessary to perform the setup procedure from a firewall manager not connected to the firewall's local network.
    

  • The initial setup procedure will now allow manual selection of what NIC driver to use when an unknown board is encountered.
    

  • Some menu options, e.g. exiting to a command line interface, and editing arbitrary files, have previously not been available on appliance firewalls. These options are now available.
  
  

• Tweakable NIC RX/TX ring sizes for performance tuning
  Several NIC drivers now allow fine tuning of their RX/TX ring sizes.
  While unnecessary for the vast majority of users, it provides a way to get the last ounce of performance out of a given unit through optimizing the settings for the given circumstances.
  Please see KB #10024 for more information.
  

• Changed FTP ALG "max line length" default from 128 to 256 characters
  It has become apparent that the default max line length of 128 is too short. This default has been changed to 256, and we recommend that existing ALG definitions be changed to reflect this; at least for outbound connections. If own servers are known to contain paths longer than ~120 characters, it should definitely also be applied to inbound connections.
  

• "StripDFOnSmall" default changed to 65535 to work around PMTUD problems
  Clavister Firewall does not (yet) pass ICMP error messages by default; doing so without further precautions introduces vulnerability to firewalk probes.
  In some cases, this introduces problems for Path MTU Discovery.
  Changing the "StripDFOnSmall" setting to 65535 results in the "Don't Fragment" bit being stripped from all packets passed through the firewall. This effectively disables the PMTUD scheme, and avoids all problems related to it.
  

• DHCP relayer: PXE booting using separate PXE and DHCP servers now possible
  PXE servers, when separate from the actual DHCP servers, send DHCP offers containing "0.0.0.0" IP addresses. Enabling the new option "Allow null offers" allows such DHCP replies through the DHCP relayer.
  

• Improved troubleshooting and low-level info
  Three new changes assist in troubleshooting:
  • The new fwloader will write more information to "shutdown.txt" and "crash.dmp" in the case of crashes. The one-line message in "shutdown.txt" is displayed on screen and sent to the log receiver on restart. The contents of "crash.dmp" can be displayed through the "crashdump" console command, or through the boot menu.
  • The "memory" console command is again available; it will show total/free RAM, as well as memory consumption of a number of individual modules.
  • The "sysmsgs" command will display low-level fwloader information which may assist in troubleshooting (primarily) disk problems.
  
  

Please see changes-8.00.05-to-8.00.06.html for the most recent bug fixes.

• IPsec NAT traversal over UDP implemented
  IPsec NAT traversal over UDP (port 500 or 4500) has now been implemented in the VPN gateway. This permits client-to-gateway as well as gateway-to-gateway IPsec tunnels over NATing gateways.
  Gateways will automatically make use of NAT traversal if they deem it necessary; it requires no further configuration to activate this support in gateways.
  NAT traversal support is already available in the Clavister VPN Client. It must, however, be explicitly told to use NAT traversal.
  
  

Please see changes-8.00.05-to-8.00.06.html for the most recent bug fixes.

• Interoperability problem with 7.0x gateways (unstable tunnels)
  We have received reports of tunnel instability problems between 7.0x and 8.00.0x 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.
  See changes-8.00.02-to-8.00.05.html for more information on this issue.
  

• No state synchronization for User Auth
  User Authentication (the fact that a user is logged on) is currently not state synchronized. State synchronization of User Auth will be implemented as soon as possible.

• 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, and that the upload procedure leaves the "master" cluster node active.