Release date: 2002-11-14 [ISO]

Clavister Firewall 8.0 contains a large set of changes from 7.0x. This document will not list all small changes, but rather concentrate on the most notable ones, and describe the upgrade procedures involved in moving from 7.0x to 8.00 firewalls and managers.

This document is primarily meant for users of previous version of Clavister Firewall; new users are referred to the User's Guide.

• Firewall Manager
  The Firewall Manager has gotten a complete overhaul.
  Among the foremost changes is the ability to share common settings / network objects between related firewalls through inheritance from a shared parent.
  All configuration may now be dialog driven, which eases use for new users. However, "in-cell editing" may also be enabled for a mode of operation closer to previous managers.
  

• Up to five million simultaneous connections
  The state engine has been improved to support up to five million simultaneous connections. Each state consumes about 200 bytes, so 256 MB RAM supports over a million connections.
  The connection replace algorithm (used if/when the state table becomes full) has been vastly improved; it is now able to replace tens of thousands connections per second even on modest hardware.
  

• X.509 certificate support for VPN tunnels
  The IPsec engine now supports authentication through X.509 certificates, as well as simultaneous use of multiple Certificate Authorities.
  Since certificate use requires correct date and time, a time synchronizer has also been implemented.

• Grouping support for interfaces, hosts/networks and protocols
  Interfaces, host/networks and protocols may now be grouped together in logical groups for easier management and reduced ruleset sizes.

• Policy Based Routing
  A new and flexible policy based routing implementation allows, among other things:
  

  • Vectoring certain protocols to transparent proxies or inspection devices, allowing in-stream anti-virus protection and transparent web caching.

  • Use of multiple ISPs for a single organization, while still guaranteeing that requests arriving through one ISP will send their answers back the same way.

  • Fully operator independent metropolitan area networks with active backbones, where users share a common backbone while still being able to choose from a selection of ISPs and other services.
• High Availability for VPN firewalls
  VPN gateways may now be configured in HA setups with full stateful failover for individual connections and instant re-key for the VPN tunnels when the cluster fails over.
  Fail-over time depends on the number of active tunnels; a dozen tunnels typically take about three seconds to re-establish from the time of failure.
• Full FTP Application Layer Gateway
  A full FTP ALG has been implemented, meaning that explicit rules for data channels no longer need to be added.
  Among its notable features is its ability to convert passive mode connections to active mode connections on the fly, thereby letting both the client and the server run in its most secure mode.
• Stateful rule-based DHCP relayer
  A stateful rule-based DHCP relayer was added, with the ability to dynamically add routes and proxy ARP entries according to relayed leases.
  This supports a scenario with a single DHCP server handing out leases to thousands of clients behind dozens of firewalls, e.g. a metropolitan area network with individually firewalled end-user connections.
• Support for two new encryption algorithms; AES and Twofish
  VPN tunnels may now use two new encryption algorithms: the new AES standard (Rijndael) and Twofish, which also was a candidate for the AES standard.
  Twofish is an excellent algorithm for use in modern computers, including VPN scenarios; however, the AES selection process also weighed in factors such as ease of implementation in embedded equipment and smart cards, where Rijndael was a better choice.
• Password protection on the physical console
  The physical console of the firewall may now be password protected.
  However, note that firewalls should never be placed where unauthorized people can access them; even if the firewall itself cannot be tampered with, someone with physical access to the network rack can always re-wire the network to effectively bypass the firewall.
• Combined firewall cores
  Firewall cores are now normally distributed with VPN as well as HA functionality compiled in. Use of such functionality is now controlled through the licensing system.
  For those booting from small and slow boot media, such as floppies, non-VPN cores are still available for reduced size and loading time.
• Support for roaming VPN gateways
  Roaming VPN gateways are now supported through dynamic DNS.
  Either one, or both ends of a VPN tunnel may now be roaming gateways, e.g. ones that receive their IP address through DHCP. By using a dynamic DNS service, such as www.dyndns.org, and gateways will learn of address changes in a matter of minutes.
  

We do not recommend that you attempt to connect to old datasources with the new manager. Rather, firewalls should be moved, one by one as they are upgraded, from the old datasource to a v8 datasource.
Moving the firewalls between datasources is best done through the v7 manager, or by simply moving/copying the related files from the old datasource directory to the new one.

Note that even though v8 managers can read v7 firewall configurations, they cannot be used to manage v7 firewalls, as they generate configuration files with new configuration directives that old firewalls will not understand.

For the most reliable remote upgrade path, we recommend copying the firewall entry from the old management datasource to the new one.

1. Install Firewall Manager v8 if you have not already done so.
2. In the windows file explorer, locate your old datasource. This is typically
   "C:\Program Files\Clavister\Firewall Manager\Default\".
   It may also be a good idea to make a back up copy of this directory.
   
3. Select all files related to the firewall you are upgrading. Assuming your firewall is named "gw-myorganization", these files are named:
     "gw-myorganization.efw"
     "gw-myorganization.00001.efc"
     "gw-myorganization.00002.efc"
     etc...
   Hit "Ctrl+C" to begin copying the files.
4. Locate your new datasource. This is typically
   "C:\Program Files\Clavister\Firewall Manager 8\Default\".
   Hit "Ctrl+V" to paste the files.

Getting a license file for the firewall to use:

1. Start the new firewall manager. Even though it cannot be used to configure the old firewall, it can communicate with it.
2. Open a console window to your firewall and run the "ifstat" command.
3. Decide which interface to bind your license to. Write down its MAC (hardware) address.
4. Go to https://clientweb.clavister.com
5. Either register as a new user, or log on as an existing user if you have previously registered as a client web user.
6. Register your license. You need the license number on your Certificate of Authenticity, and the MAC address from above.
   Note that MAC address display like "0123:4567:89ab" in the "ifstat" command, but must be entered like "01-23-45-67-89-ab" in the client web.
7. The new license should appear in your list of available licenses.
   Click "Download license" and save the ".lic" file somewhere; on your desktop, for instance.
8. From the "Tools" menu, select "Licenses". This brings up a list of your licenses.
   Import the license you downloaded above by selecting "Import" from the "File" menu.
9. At this point, you may wish to verify that the MAC address of the license matches the MAC address of the interface in your firewall.
   
10. Right-click the license. Select "Advanced"->"Bind". In the following dialog, uncheck the "Upload License" check box, select the firewall being upgraded, and click "Finish".
11. Close the license list window.

Upgrading the firewall itself:

1. In the Security Editor, select the newly transferred firewall.
2. From the "Action" menu, select "Boot Media"->"Create Boot Media".
   
3. At this point you have three choices:

   • You can create the new boot image directly onto the boot media you will be using, move it to the firewall, and boot from it.

   • You can create a floppy that may be used to install the new software on the firewall through the "System" -> "Transfer System" command in the boot menu. Then remove the floppy and boot from the fixed media.

   • You can also run directly from the floppy, although we do not encourage this past the initial testing phase, as floppies are not very durable.
4. If this is a High Availability Slave, you need to abort the startup sequence and select "System" -> "Set Firewall type to High Availability Slave" in the boot menu system.
   Then return to the main menu and execute the firewall core.

After booting, the running firewall is a v8.00.00 firewall, but it has not been activated with a license. It will be running in 2-hour evaluation mode.

Uploading the license file to the upgraded firewall:

1. Return to the new firewall manager
2. Select the newly upgraded firewall.
3. From the "Action" menu, select "License"->"Upload License".
4. Open a console window to the firewall. Execute "license" to view your current licensing options. There should be no error or warning messages.

The remote upgrade procedure will work for all Clavister appliances.
It should also work for non-appliance installations, if:

Follow either one of the above upgrade procedures, but with the following changes:

1. In the "Preparations before upgrading" section, copy both of your cluster members from the old datasource to new one.
2. Perform the "Getting a license file for the firewall to use" section twice; once for each member. Do "Properties" on the installed licenses, and make sure that the "Maximum allowed cluster members" property is listed, and states "2".
3. Perform the "Upgrading the firewall itself" section on the currently inactive firewall.
4. Perform the "Uploading the license file to the upgraded firewall" section on the same firewall. Again, the "license" command on the console should say "PROP_MAXCLUSTER 2".
5. If the upgrade is done remotely: Open a real-time statistics view for the new firewall. Graph at least "Forwarded Bits/s" and "Conns". This can be done from the old manager as well as the new manager.
6. Cause the cluster to fail over by issuing a "reconfigure" command on the v7 member. In a short time (about ten seconds on a busy network), you should see new connections forming on the new firewall and traffic increasing. If not, issue a "reconfigure" command on the new firewall to fall back to the old one and begin troubleshooting. The state table on the old firewall should still contain all old connections and allow a fairly smooth fallback.
7. When the new firewall is seen to be working, perform the "Upgrading the firewall itself" and "Uploading the license file to the upgraded firewall" sections on the other firewall.