Release date: 2002-06-24 [ISO]

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

Firewall Manager

• Cores/fwc_703.exe
  This is the v7.03.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_703v.exe
  This is the v7.03.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).

• Cores/fwc_703h.exe
  This is the v7.03.00 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.02-to-7.03.00.htm
  This document.

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

• DNS resolution of firewall addresses
  The Firewall Manager can now resolve host names of firewalls.
  This is helpful primarily for remotely managed firewalls with dynamic IP addresses (i.e. a DHCP assigned address), where a dynamic DNS client may be run behind the firewall to update its DNS entry when the firewall is assigned a new IP address.

  For this kind of use, we suggest that you take a look at dynamic DNS services like dyndns.org or cjb.net. There are many more; some free and some not. Clavister will be publishing examples of this kind of setup on the support web pages.
  

• 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.
  
  Affects: Firewall Manager v7.00.00 -- v7.03.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.
  Fix: This will likely not be fixed in the 7.0x tree. It will be fixed in the next major version.

• Changes to SNMP variables ifDescr/ifAlias
  The interface naming scheme in the variables "ifDescr" and "ifAlias" has been changed.
  

  Previous versions:
  	MIB-II ifDescr	hardware/driver information
  	ifMIB ifName	short name of interface, e.g. "int"
  	ifMIB ifAlias	not available
  As of 7.03.00, the default is:
  	MIB-II ifDescr	short name of interface, e.g. "int"
  	ifMIB ifName	short name of interface, e.g. "int"
  	ifMIB ifAlias	hardware/driver information

  The contents of ifDescr and ifAlias can be individually set to include either the short interface name, hardware/driver info, or the contents of the comment field, or any combination thereof, in any order, through the settings "SNMPifDescr" and "SNMPifAlias".
  

• Added Sundance "Alta" ST-201 NIC driver
  Version 7.03.00 adds support for the Sundance "Alta" ST-201 NIC.
  This chip is used in, among others:
  - The D-Link DFE580TX 4-port NIC, replacing the DFE570TX
  - The D-Link DFE550TX and FX NICs
  

• Rudimentary traceroute support added
  Version 7.03.00 adds rudimentary traceroute support. In other words: it may be configured to allow ICMP "unreachable" and "time exceeded" error messages on certain states.

  For outbound traceroute support, we'd suggest adding rules like:
  - NAT int:intnet ext:all-nets ICMP echo
  - NAT int:intnet ext:all-nets UDP 1024-65535 -> 33434-33499
  and checking the "Pass returned ICMP error messages from destination" checkbox for these rules.

  The first rule above will allow ICMP based traceroute, used by the Microsoft "tracert.exe" and unix traceroute implementations that support ICMP based traceroute.
  The second rule allows UDP based traceroute on the default ports, used by default by most unix traceroute implementations.

  The first two hops of the trace will time out. This is due to the firewalking protection of the firewall. Decreasing the timeout and/or number of queries sent using f.i. "tracert -w 500" or "traceroute -w 2 -q 2" will decrease the initial delays greatly.
  

• 'fwcore_n.cfg' was not removed on shutdown IMMEDIATE/PANIC
  Issue: If the firewall core encounters a "severe" error during the parsing of a newly uploaded configuration where it needs to re-start, it would not remove the newly uploaded file "fwcore_n.cfg".
  Results: If there were severe problems in a newly uploaded configuration, the firewall would keep encountering the same new configuration after each re-start, and keep re-starting. The administrator would have to reboot the firewall and manually remove the "fwcore_n.cfg" file.
  Mitigating factors: There aren't very many problems severe enough to require an immediate re-start. The vast majority of configuration related problems are solved by falling back to the previously used configuration.
  Basically the only problem severe enough is memory exhaustion, which can happen if memory-consuming settings such as state table size or number of packet buffers are set much too high.
  Affects: Firewall cores v7.00.00--v7.02.02.
  Fixed: Fixed in v7.03.00.
  

• Disallowed SNMP queries to the firewall were not logged
  Issue: The firewall should emit a log entry if it receives SNMP queries from the wrong source IP or with the wrong community string. It did not.
  Results: Disallowed SNMP traffic to the firewall itself that was not dropped by the ruleset would be silently dropped.
  Affects: Firewall cores v7.00.00--v7.02.02.
  Fixed: Fixed in v7.03.00.
  

• SYNRelay would leak RSTs during initial handshake
  Issue: The "SYNRelay" SYN flood protection will perform a three-way handshake with the client before doing the handshake with the server. This prevents plain SYN floods, or spoofing the client IP.
  During the relay phase, RSTs from the client would be permitted through the firewall to the server, even though the server had not seen anything, and hence would not benefit from seeing the RST.
  Results: Aside from the server seeing a RST for which it did not have a connection: none that we are aware of. This is a very common occurence on any type of TCP/IP network.
  Affects: Firewall cores v5.1--v7.02.02.
  Fixed: Fixed in v7.03.00.
  

• State engine was overly strict during TCP initial handshake
  Issue: If a SYN/ACK response is lost between the firewall and the client, the client will resend its SYN. Many TCP stacks will respond to this resent SYN with a plain ACK, which the state engine will dislike.
  Results: If said SYN/ACK response was lost between the firewall and the client, and the client resent its SYN before the the server resent its SYN/ACK, the connection would not be allowed to be properly opened, leading to a hung TCP connection.
  The firewall would also log "LogStateViolations" events regarding resent SYN/ACK packets at a later point in the handshake.
  Affects: Firewall cores v5.1--v7.02.02.
  Fixed: Fixed in v7.03.00.
  

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

• 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 the next major version.
  

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