Clavister Firewall Changes from v8.30.00 to v8.30.01

Release date: 2004-01-21 [ISO]

Users upgrading from v7.0x and earlier versions should read changes-7.0x.xx-to-8.00.02.html first. It contains the list of major changes from v7.0x, and also instructions on how to upgrade; the upgrade procedure from v7 to v8 differs markedly from the normal procedure. Once the firewall is upgraded to 8.0, you can follow the procedures in this document.

Version 8.30.01 contains bug fixes to the Firewall Core and the Firewall Manager. This document outlines bug fixes as well as improvements for each component.

The upgrade procedures in this document refers to upgrades from earlier v8.0x installations.

  • New files installed by v8.30.01
  • How to upgrade earlier v8.0x firewalls to v8.30.01
  • How to upgrade v6.0x/v7.0x firewalls to v8.0x
  • HA upgrade procedure
  • Firewall Manager
  •      
  • Firewall Core
  • [Changes] [Bug Fixes]  
  • Firewall Core - VPN specific  
  •      
  • Firewall Core - HA specific
  •     [Known Bugs / Problems]

    For future reference: This document is stored in the "Docs" sub-folder of your Firewall Manager install folder.

    Change logs / release notes for earlier versions of Clavister Firewall are available in the release notes section of www.clavister.com/support.



     Summary of changes and bug fixes                
    All changes and bug fixes affecting the standard firewall core also affect VPN and HA cores, unless explicitly stated otherwise.

    Firewall Manager

    Firewall Core
      Change: FTP ALG logging now more verbose
      Change: DHCP relayer can now relay to built-in DHCP server
      Change: 'e1000' driver updated to support newer Intel Gigabit NICs
      Change: DHCP server will no longer hand out certain addresses
      Change: Better compatibility with various cluster systems
      Change: DHCP client can now be configured to not check for IP conflicts
      Change: Statistics for connections states added
      Change: 'DHCP Release' support in DHCP relayer
      Bug fix: PPPoE interfaces erronously count as physical interfaces
      Bug fix: Built-in DHCP server does not work with external DHCP relayers
      Bug fix: Proxy ARP clashes with DHCP Relayer
      Bug fix: Input Bytes not presented via SNMP for VPN tunnels
      Bug fix: 'ping -r' shows packet loss even though there is none
      Bug fix: Firewall hangs on startup if DHCP server pool contains a single IP
      Bug fix: Web auth server causes false positives in vulnerability scanners

    Firewall Core - VPN specific

    Firewall Core - HA specific
      Known bug: No state synchronization for FTP ALG



     New files installed by v8.30.01                
    This is a list of the files that are new to the v8.30.01 release. All paths are relative to your Firewall Manager install folder.
    » Cores/fwc-8.30.01-full.cfx
    This is the v8.30.01 full firewall core. Upload it to your existing firewall, or create new boot media with it. It contains VPN as well as HA functionality.
    » Cores/fwc-8.30.01-novpn.cfx
    This is a version of the v8.30.01 core without VPN support. It is roughly half the size of the full version.
    » Cores/fwcoreup8.exe
    This is the core used to remotely upgrade v7.0x and earlier firewalls. It will install a "8.00.02-full" core.
    » Docs/Changes-8.30.00-to-8.30.01.html
    This document.
    » FWMgr8.exe
    This is the v8.30.01 Firewall Manager. Earlier version 8 Firewall Managers will be overwritten. Version 7 Firewall Managers (if installed) will not be overwritten, as they are named "FWMgr7.exe", and are also typically installed in a different directory.


     How to upgrade earlier v8.0x firewalls to v8.30.01                
    Upgrading a previous v8.0x firewall to v8.30.01 is completely straightforward.
    Simply upload the new core, "fwc-8.30.01-full.cfx", to your firewall and restart it.
    (Alternatively, upload the "-novpn" version if you do not wish VPN functionality.)


     HA upgrade procedure                
    Note: For upgrades from v7.x HA clusters, first follow the HA upgrade procedures outlined in changes-7.0x.xx-to-8.00.02.html.

    There are no incompatibilities in the HA synchronization protocol between 8.30.01 HA cores and earlier v8.0x HA cores. No special procedures are required.

    Simply upload the new firewall core file to the firewalls in your cluster and make sure that the first upload and restart is successful before uploading to the second firewall.

    We recommend beginning with the firewall that is currently active, even though this will necessitate two failovers. The reason for this is that ALG sessions are not synchronized.

      The "immediate availability" method
    • Upload the core to the currently active firewall ("firewall A") and restart it.
    • Issue a 'reconfigure' on the firewall B to rapidly fail back to the now upgraded firewall A. Make sure firewall A functions properly.
    • Upload the core to firewall B and restart it.
    • End result: Firewall A is now the active node, just as it was before the upgrade procedure.

    Note that this leaves the second firewall untested, even though it most likely will work just as well as the first firewall. If you want to specifically test the second firewall, you can:
    1) cause two failovers manually,   or
    2) connect to it via e.g. the remote console just to make sure it's running,   or
    3) if ALG synchronization is not a concern, follow this procedure:

      The "long-term safe" procedure:
    • Upload the core to the currently inactive firewall ("firewall B") and restart it.
    • Issue a 'reconfigure' on firewall A. This causes failover to firewall B. Make sure firewall B functions properly.
    • Upload the core to firewall A and restart it.
    • Issue a 'reconfigure' on firewall B to fall back to firewall A. Make sure firewall A functions properly.
    • End result: Firewall A is now the active node, just as it was before the upgrade procedure.
    Again, note that the "availability" issues only affect ALGs. All other states are, as usual, fully synchronized and not affected in either procedure.


     Firewall Core Changes                
    FTP ALG logging now more verbose
        Issue: Some FTP ALG troubleshooting has been problematic due to inexact logging of certain events. For example: overly long lines were not logged as such, only that the connection was closed.
        Change: As of v8.10.03, v8.20.02 and v8.30.01, log events emitted by the FTP ALG are much more verbose.

    DHCP relayer can now relay to built-in DHCP server
        Issue: In some cases, it may be helpful to use the DHCP relayer to relay leases to the built-in DHCP server. The DHCP relayer can do several things that the DHCP server cannot, e.g. add dynamic routes for relayed leases, restrict the number of DHCP clients per interface (VLAN) and so forth.
        Change: As of v8.30.01, the DHCP relayer can be configured to relay to "127.0.0.1".

    'e1000' driver updated to support newer Intel Gigabit NICs
        Issue: Support for 19 new NICs based on Intel's Gigabit chips has been added, including Intel's new quad port gigabit NIC.
        Change: The updated 'e1000' driver is available as of v8.30.01.

    DHCP server will no longer hand out certain addresses
        Issue: In v8.30.00, the DHCP server would hand out any address it was configured to hand out.
        Change: As of v8.30.01, the DHCP server will never hand out the firewall's own interface addresses, nor addresses ending in .0 or .255.
        The latter is relevant even for networks with netmasks larger than /24. Reportedly, the Windows TCP/IP stack will refuse to communicate with any IP address ending in .0 or .255 regardless of it begin local or remote.

    Better compatibility with various cluster systems
        Issue: Some HA cluster systems (e.g. Linux 'Heartbeat' clusters) use a shared virtual IP address that changes MAC address as the active cluster role moves. However, some clusters announce this only through a single non-targeted ARP broadcast which surrounding equipment is supposed to pick up on and change their ARP caches.
        Change: As of v8.30.01, Clavister Firewall will listen to non-targeted ARP broadcasts for ARP cache update purposes, if it is configured to be RFC 826 compliant.
        See: See KB #10032 for more information.

    DHCP client can now be configured to not check for IP conflicts
        Issue: The DHCP client normally checks if the IP address in an offer is already taken on the local network by performing an ARP query for it. However, some routers may ARP publish IP addresses while the DHCP transaction is running and cause false positives. One such example is the Clavister Firewall DHCP relayer before v8.30.01, in certain configurations. There are also others.
        Change: As of v8.30.01, the DHCP client can be configured to not check for IP conflicts in offered leases via "Advanced Settings" -> "DHCP" -> "DHCP_DisableArpOnOffer".

    Statistics for connections states added
        Issue: When dimensioning the size of the firewall state table and/or modifying timeouts for various states, it may be useful to know the distribution of connections in various states.
        Change: As of v8.30.01, the firewall offers statics for connection states, e.g. how many connections are in TCP_SYN state, how many connections are in TCP_FIN state, etc..

    'DHCP Release' support in DHCP relayer
        Issue: Some operating systems (notably, newer Windows versions) send "RELEASE" DHCP notifications during shutdown to notify the DHCP server that it can now safely end the lease in case it needs to.
        Change: As of v8.30.01, the DHCP relayer will relay RELEASE notifications. Previously, it did not. It will also remove the lease from its relaying list, which may help in scenarios where the relayer is configured to only allow a single active lease per interface (VLAN), and a user is switching computers.



     Firewall Core Bug Fixes                
    PPPoE interfaces erronously count as physical interfaces
        Issue: Clavister Firewall licenses restrict the number of physical interfaces allowed on the firewall. For appliances, this restriction matches the number of ports actually installed.
        Problem: PPPoE interfaces erronously count as physical interfaces towards the license limit.
        Affects: FWCore v8.30.00.
        Fixed: Fixed in v8.30.01.

    Built-in DHCP server does not work with external DHCP relayers
        Problem: If there is an external DHCP relayer between the firewall and DHCP clients, the built-in DHCP server will only hand out a lease to the first client to request one on account of the DHCP server only looking at the DHCP relayer's MAC address.
        Affects: FWCore v8.30.00.
        Fixed: Fixed in v8.30.01.

    Proxy ARP clashes with DHCP Relayer
        Issue: In some situations, it is desirable to have the firewall proxy ARP all IP addresses of the local network on a given interface except those handed out to DHCP clients on that interface. This way, hosts configured via DHCP need not be aware of the router (firewall) hop between them and the rest of the network.
        Problem: Some DHCP clients use ARP requests to test whether or not the offered IP address is already taken. If the firewall is publishing all non-leased IP addresses, the client will erronously assume that it cannot use offered IP addresses.
    Not all clients use ARP for this task; many use ICMP pings and are unaffected. Unaffected DHCP clients include Windows (all versions).
        Results: Affected clients will not accept offered leases and claim that the offered IP address is already taken by a host on the local network.
        Affects: FWCore v8.00.00--.07, v8.10.00--.02, v8.20.00--.01, v8.30.00.
        Fixed: Fixed in v8.00.08, v8.10.03, v8.20.02 and v8.30.01. The firewall will not respond to ARP queries for IP addresses currently being offered through the DHCP relayer.

    Input Bytes not presented via SNMP for VPN tunnels
        Issue: The 'Input Bytes' counter is always presented as 0 via SNMP for VPN tunnels.
        Affects: FWCore v8.00.00--.07, v8.10.00--.02, v8.20.00--.01, v8.30.00.
        Fixed: Fixed in v8.00.08, v8.10.03, v8.20.02 and v8.30.01

    'ping -r' shows packet loss even though there is none
        Issue: The '-r' switch of the ping command causes the pings to go through the firewall ruleset(s) rather than just being sent straight to the destination. This allows for some rudimentary ruleset testing as well as following Policy Based Routing routes rather than only the main routing table.
        Problem: When using the '-r' switch, the generated ping packets (after the first packet) did not get their TTL explicitly set to 255. Often, the resulting packets would get very low TTLs.
        Results: The 'ping -r' command, if sending more than one packet, would often show packet loss even though there was none.
        Affects: FWCore v8.20.00--.01, v8.30.00.
        Fixed: Fixed in v8.20.02 and v8.30.01.

    Firewall hangs on startup if DHCP server pool contains a single IP
        Issue: The firewall would hang during configuration parsing if it encountered a DHCP server pool configured to contain only a single IP address, if that address equaled the first or last IP address of the network (as determined via the netmask).
        Results: The firewall would be rendered completely inoperable as a result. One would have to access the serial console CLI and delete "fwcore_n.cfg" in order to cause fallback to the previous configuration.
        Affects: FWCore v8.30.00.
        Fixed: Fixed in v8.30.01.

    Web auth server causes false positives in vulnerability scanners
        Issue: The web auth server would respond with "HTTP 200 OK" success codes for pages that did not exist.
        Results: There is no impact for ordinary use. However, vulnerability scanners would believe that dozens of vulnerable applications (from several different operating systems and web servers) were installed on the firewall and hence issue false positive alerts.
        Affects: FWCore v8.10.00--v8.30.00.
        Fixed: Fixed in v8.30.01.



     Firewall Core - HA Known Bugs / Problems                
    No state synchronization for FTP ALG
        Problem: No aspect of the FTP ALG is state synchronized
        Results: This means that control channels as well as data channel established through the FTP ALG will freeze when the cluster fails over to the other peer. If, however, the cluster fails back over to the original peer within approximately half a minute, frozen sessions (and associated transfers) should begin working again.
    Note that such failover occurs each time a new configuration is uploaded.