Release date: 2002-01-29 [ISO]

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

• Cores/fwc_702.exe
  This is the v7.02.00 standard firewall core. Upload it to your existing (standard) firewall, or create new boot media with it.
  Note: VPN firewalls should, as always, use the VPN core file, below.

• Cores/fwc_702v.exe
  This is the v7.02.00 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).

• Docs/Changes-7.01.01-to-7.02.00.htm
  This document.

• FWMgr7.exe
  This is the v7.02.00 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.

• Fixed crashes due to GDI object leaks under Windows 9x/ME
  Issue: The Firewall Manager would crash after several hours' of continous use under Windows 9x/ME, resulting in an "out of resources" error message.
  Problem: The configuration grid was allocating GDI objects that were never released. Under Windows NT/2000/XP this was not much of a problem, as the GDI resource pool is fairly large. However, under Windows 9x/ME, the resource pool is very limited, which is why the problem was only seen under 9x/ME.
  Affects: All versions up to v7.01.01.
  Fix: Fixed in v7.02.00.

• Comments in the VLAN tab no longer disappear
  Issue: Comments written in the Comment column of the VLAN tab were not displayed properly in the configuration grid when the configuration was (re-)opened. Comment (separator) lines, however, were properly displayed.
  Affects: Firewall Manager v7.00.00 -- v7.01.01
  Fix: Fixed in v7.02.00.

• 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.00. 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.

• Firewall interfaces may now be configured via DHCP
  As of version 7.02, one or more interfaces may be configured via the DHCP protocol. Security checks are in place to stop a rogue DHCP server from assigning IP and network addresses that could otherwise lead to security compromises, f.i. packets destined for the internal network being routed to the external network.

  The DHCP functionality is switched off by default. You enable it on a per-interface basis in the Interfaces configuration tab.

• DEC/Intel Tulip driver may fail to attach during high traffic
  Issue: This was previously described as a "known bug". However, the problem only existed in version 6 firewall cores, never in version 7 cores.
  Affects: v6.00--v6.02 cores
  Fix: Fixed in v7.00.00

• 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.

• IKE "Local ID" was set incorrectly when initiating sessions
  Issue: The "Local ID" field in IKE wasn't set correctly when initiating VPN connections. It was set to the source address of the packet triggering the exchange, rather than the IP address of the VPN gateway.
  Result: The VPN gateway was not able to initiate tunnels to VPN implementations that expect the local ID to be set to the tunnel endpoint's IP address. One such implementation is Linux FreeS/WAN.
  Affects: All previous VPN gateways.
  Fix: Fixed in v7.02.00. The Local ID field is now set to the IP address of the interface closest to the remote gateway / client.

• 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.
  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.