Release date: 2002-04-22 [ISO]

The major new features of Clavister Firewall v7.02 from v7.00 are:

Firewall Manager

Firewall Core

• Cores/fwc_702.exe
  This is the v7.02.02 standard firewall core. Upload it to your existing (standard) firewall, or create new boot media with it. It will overwrite earlier 7.02.00 cores, if installed.
  Note: VPN firewalls should, as always, use the VPN core file, below.

• Cores/fwc_702v.exe
  This is the v7.02.02 VPN firewall core. Upload it to your existing (VPN) firewall, or create new boot media with it.
  Note: This file is not installed by the standard installation package, as only licensed users have access to it. Rather, it is available as a separate installation package (typically a Clavister Upgrader package).

• Cores/fwc_702h.exe
  This is the v7.02.02 HA firewall core. Upload it to your existing (HA) firewall, or create new boot media with it.
  Note: This file is not installed by the standard installation package, as only licensed users have access to it. Rather, it is available as a separate installation package (typically a Clavister Upgrader package).

• Docs/Changes-7.02.01-to-7.02.02.htm
  This document.

• FWMgr7.exe
  This is the v7.02.02 Firewall Manager. Earlier version 7 Firewall Managers will be overwritten. Version 6 Firewall Managers (if installed) will not be overwritten, as they are named "FWMgr6.exe".

Note: VPN firewalls should use the VPN core, "fwc_702v.exe". Uploading a standard core to a VPN firewall will, as always, disable VPN functionality and very likely render the firewall unable to operate, as it will not understand its configuration file.

• Statistics 'plot' menu gets truncated
  The "Plot" menu is capable of displaying several thousand statistics values. This is an order of magnitude more than what is required by a normal configuration. However, with several thousand VLAN interfaces and/or rules, the menu will become truncated. First, it will only display about a screenful of entries in each sub menu. Second, the total limit of statistics values may come into effect.
  This will be addressed in a future release by replacing the menu with something able to display more values efficiently.
  Affects: Firewall Manager v7.00.00 -- v7.02.02. Earlier versions have the same limit, but as they do not support VLANs, the problem is mitigated.
  Possible workaround: Setting the same name for two or more rules will make them use the same statistics value. This may reduce the number of statistics values somewhat.

• Added setting to allow a broadcast address of 255.255.255.255 in DHCP leases
  DHCP leases should contain the correct broadcast address on the local network.
  However, some DHCP servers apparently have been seen to hand out leases with a broadcast address of 255.255.255.255.
  We would like to point out that these servers should be fixed, as a broadcast address of 255.255.255.255 means "broadcast on all interfaces". However, as an intermediate fix, we have added the "DHCPAllowGlobalBcast" setting, which, if set to "Yes", will make the firewall accept such leases as valid.
  The default value of "DHCPAllowGlobalBcast" is "No", meaning that the firewall would reject such leases. This is how v7.02.00 and .01 cores behave.
  

• Errors in the configuration before the first interface would crash the firewall
  Issue: If a configuration error occured before the first interface was successfully attached, the firewall would crash and reboot rather than fall back to its previous configuration.
  Results: In cases where the bug was triggered by uploading a new configuration, the firewall would keep crashing and rebooting, every time finding the same broken configuration.
  Mitigating factors: First of all, there would have to be an error in the configuration.
  Second, only the "Settings", "Hosts" and "Nets" sections come before the "Interfaces" section in the configuration file. All other configuration sections come after it, so any error there would not cause this problem.
  Affects: Firewall cores v7.02.00 and v7.02.01.
  Does not affect HA cores, as they have no DHCP client code.
  Fixed: Fixed in v7.02.02.
  

• State engine is overly strict during TCP initial handshake
  Issue: The state engine currently requires strict conformance to the "SYN", "SYN/ACK", "ACK" initial TCP handshake pattern (possibly with resends). However, some operating systems will respond to resent SYNs with a plain "ACK", which the state engine will not accept.
  Affects: All Firewall Cores, from v5.1
  Results: This may lead to failed connections between certain operating systems, if packet loss occurs in the "right" place during the handshake. The firewall will also send "LogStateViolations" log events regarding "SYN ACK" flags at a later point in the handshake.
  Fix: This problem will be addressed in a future release.

• 'Memory' console command missing
  The 'memory' console command has been temporarily removed. It will be re-implemented in a future release.

• DHCP client works poorly on some VPN gateways
  Issue: In VPN gateways v7.02.00 and .01, configuring an interface through DHCP could work poorly on VPN gateways. In some cases, it would function properly. In others, not. The deciding factor is configuration related, although there are no simple instructions for working around the problem.
  Results: In affected gateways, the VPN gateway would aquire a lease, and then forget the lease information when it re-read its configuration with the new interface configuration data, leading to a slow never-ending loop.
  Affects: VPN cores 7.02.00 and 7.02.01 with one or more DHCP assigned interfaces.
  Fixed: Fixed in v7.02.02.
  

• Fragmented IKE packets are dropped
  Issue: If an IKE packet sent to the VPN gateway is fragmented, either during transport, or by the originator, it will be dropped.
  Mitigating factors: Typically, this is not a problem, as IKE packets tend to be only a few hundred bytes of length - well below the MTU of commonly used network types. One notable exception is the initial "discovery" mode of the Clavister VPN Client, during which it sends very long proposal lists.
  Workaround: If this behavior causes problems, you may try decreasing the size of your proposal lists, which will decrease the IKE UDP datagram size.
  Fix: This issue will be addressed in a future release.
  

• Altering the IP address of a gateway disrupts open tunnels
  Issue: When a gateway has its IP address changed, f.i. via DHCP, any open tunnels involving that IP address will cease to work. The remote tunnel end will be sending packets to the wrong (old) IP address, and it will refuse to listen to the packets from the new IP address, since it knows nothing about it.
  Results: The tunnels will become operational once the life time of the tunnel has expired and re-negotation is completed. Rebooting the firewall will also, of course, terminate the tunnel, leading to re-negotiation once the firewall is back up. However, this would also terminate all state-tracked connections.
  Mitigating factors: This will not affect most users, as the IP address is normally not altered very often. It should neither affect DHCP-enabled firewalls, as DHCP servers normally keep offering the same IP address as long as the machine (firewall) in question stays up.
  Fix: This issue will be addressed in a future release.