Release date: 2002-03-15 [ISO]

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

• Cores/fwc_702.exe
  This is the v7.02.01 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.01 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.02.00-to-7.02.01.htm
  This document.

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

• Entering duplicate names in some tabs caused crashes
  Issue: The Firewall Manager should show an error dialog when duplicate names are entered in the following configuration tabs: Hosts, Nets, Pipes, Ifaces, VLANs and VPN Connections.
  Problem: Instead of displaying the error box, the Firewall Manager crashed.
  Affects: Version 7.02.00 only.
  Fix: Fixed in v7.02.01.

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

• Excessive 'TTLOnLow' logging of locally heard broadcasts
  Issue: Most local broadcasts are sent with an IP Time-To-Live of 1. By default, the firewall core will not accept packets with a TTL lower than 3, to protect against firewalking and IDS avoidance attempts.
  Problem: In v7.02.00, the "drop all local broadcasts" code was moved after the IP TTL check.
  Results: Packets that were previously silently dropped as locally heard broadcasts were instead being caught by the TTL check, and hence logged. From a functionality standpoint, nothing changed, as the packets were still being dropped. The negative impact was the unnecessary logging.
  Affects: v7.02.00 cores.
  Fix: In v7.02.01, the TTL check is disabled for locally heard broadcasts, that is, packets sent to the layer 2 broadcast address. Instead, such packets are silently dropped later on simply because they are local broadcasts.

• Inaccurate status bar readings for ODI interfaces
  Issue: All previous 7.0x cores have been displaying only sent packets and bytes in the console status bar for interfaces using ODI drivers. The status bar should display the total throughput of interfaces, i.e. sent and received packets and bytes.
  Affects: All cores v7.00.00 -- v7.02.00.
  Not affected: 'Usage' log entries and statistics were not affected. Interfaces using built-in drivers displayed correct readings in the status bar.
  Fix: As of v7.02.01, the console status bar displays the total throughput of interfaces using ODI drivers.

• DHCP server responses being silently dropped
  Issue: In set-ups where a DHCP gateway communicates through the firewall to a DHCP server, the firewall should simply forward queries as well as responses using normal rule base lookups and state tracking.
  Problem: Support for DHCP configured interfaces was added in v7.02.00. It picks up DHCP responses, provided that the "transaction ID" (XID) in the packet matches the XID chosen by the firewall.
  When an interface is not configured via DHCP, i.e. most interfaces, the firewall's XID was left as "0", but the code for picking up DHCP responses was still enabled.
  Results: If the remote DHCP client/gateway selected XID 0, the firewall would pick up the response from the server, and then silently drop it, as the firewall's own DHCP client was disabled.
  Some DHCP client implementations always set XID to 0, even though the DHCP specification recommends that XIDs be selected randomly. Such clients would never receive responses from the server.
  Affects: Version 7.02.00.
  Not affected: HA firewalls have no DHCP client code, as the DHCP protocol does not support the concept of "shared IP address". Hence, they never pick up DHCP server repsonses.
  Fix: Fixed in 7.02.01. If an interface is not configured via DHCP, it will never pick up DHCP server responses, regardless of the transaction ID.

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

• Old VPN gateway instability problem fixed
  Issue: For a long time, some VPN gateways have been exhibiting unstable behavior; usually freezing completely on irregular intervals.
  This bug has been identified and fixed. Its internal workings are not easily coupled with real-world factors; loosely translated, it depends on timing issues, SA lifetimes, number of tunnels, tunnels being run across lossy networks, and whether or not the gateway acts as originator or responder.
  Affects: All VPN cores up to and including v7.02.00.
  Fixed: Fixed in v7.02.01.
  

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

• HA firewalls sometimes sent ARP queries using unique MAC addresses
  Issue: When sending an ARP query from a shared IP address, such as the 'Local IP' in the Routes configuration section, a HA firewall should send it using the shared MAC address rather than its unique MAC address.
  Problem: Queries sent from IP addresses specified in the 'Local IP' column of the Routes configuration section were erronously sent using the unique MAC address. This caused hosts attached to the HA cluster to associate such IP addresses with the unique MAC address rather than the shared MAC address.
  Affects: HA cores v7.01.00 -- v7.02.00.
  Mitigating factors: This bug only affected ARP queries sent from 'Local IP' IP addresses. It never affected ARP responses, and never affected the 'Shared IP' specified in the Ifaces configuration section.
  During normal operation, this bug would cause no problems. The only situation where it would cause temporary problems, is when failover occurs, and one or more hosts learned the unique MAC address from an ARP query, rather than the shared MAC address from an ARP response.
  Affected hosts would again be able to communicate through the HA cluster after issuing an ARP query for said IP address(es).
  Fix: Fixed in v7.02.01. All queries sent from shared IP addresses are now sent using the shared MAC address.

• VLAN interfaces of HA slave firewalls used the IP addresses of the master
  Issue: The same way that the physical interfaces of HA slave firewalls have unique IP addresses, VLAN interfaces should also have unique IP addresses.
  Problem: HA slaves would use the IP address of the master firewall on its VLAN interfaces rather than their own unique IP addresses. However, if the IP address settings of the VLAN interface were left blank, everything would work as expected.
  Results: ARP queries for the master IP of the VLAN interface would be replied to by both the master and the slave, each using their own IP addresses. Neither would respond to ARP queries for the slave IP of the VLAN interface. This resulted in a 50% chance that the master firewall was reachable for administration through the VLAN interface IP address. The slave firewall could not be administered through the VLAN interface IP address.
  Affects: HA cores v7.01.00 -- v7.02.00.
  Mitigating factors: The unique IP addresses are only used for administration; the shared IP address was reachable, and failover would continue to work. Administering the firewalls through the IP addresses of the physical interface was never affected.
  Fix: Fixed in v7.02.01. The slave firewall will now correctly use the configured "Slave IP" for VLAN interfaces.