Clavister Firewall Changes from v8.10.00 to v8.10.01

Release date: 2003-05-16 [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.00.02, you can follow the procedures in this document.

The version 8.10 series is a new major version from the 8.00 series. It is available for all users holding a software subscription covering 2003-04-02. (Note that a 3-month subscription is included with all purchases.) The major new features are:

  • User authentication via HTTP and/or IKE XAUTH to RADIUS back-ends (includes Active Directory via MS Internet Authentication Services).
  • IPsec NAT traversal support. This support is already available in the Clavister VPN Client. Client-to-gateway and gateway-to-gateway VPN tunnels can now traverse any type of NAT transparently.

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

  • New files installed by v8.10.01
  • How to upgrade earlier v8.x firewalls to v8.10.01
  • How to upgrade v6.0x/v7.0x firewalls to v8.0x
  • HA upgrade procedure
  • Firewall Manager
    		•  [Changes]  [Bug Fixes]   
  • Firewall Core - VPN specific  
    		•   [Bug Fixes] [Known Bugs / Problems] 
  • Firewall Core - HA specific
    		•    [Bug Fixes]  [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
      Change: Default "ipsec-suite" service definition changed to include udp/4500
      Bug fix: User Auth "HTML Root Directory" couldn't be set for HA clusters

    Firewall Core

    Firewall Core - VPN specific
      Bug fix: Security alert: IPsec PSK authentication bug
      Bug fix: DNS resolution of remote gateways broken
      Known bug: Interoperability problem with 7.x gateways (unstable tunnels)

    Firewall Core - HA specific
      Bug fix: User authentication not designed for HA use
      Known bug: No state synchronization for FTP ALG



     New files installed by v8.10.01                
    This is a list of the files that are new to the v8.10.01 release. All paths are relative to your Firewall Manager install folder.
    » Cores/fwc-8.10.01-full.cfx
    This is the v8.10.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.10.01-novpn.cfx
    This is a version of the v8.10.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 v8.0x VPN core.
    » Docs/changes-8.10.00-to-8.10.01.html
    This document.
    » FWMgr8.exe
    This is the v8.10.01 Firewall Manager. Earlier version 8 Firewall Managers will be overwritten. The v8.10 manager is compatible with v8.0x firewalls. 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.x firewalls to v8.10.01                
    Upgrading a previous v8.x firewall to v8.10.01 is completely straightforward.
    Simply upload the new core, "fwc-8.10.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.10.01 HA cores and earlier v8.x 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 Manager Changes                
    Default "ipsec-suite" service definition changed to include udp/4500
        Change: With IPsec NAT traversal through udp/4500 implemented, it made sense to include udp/4500 in the default "ipsec-suite" service definition.
        Effect: This change does not affect existing firewalls or namespaces, only namespaces created after upgrading to 8.10.01.



     Firewall Manager Bug Fixes                
    User Auth "HTML Root Directory" couldn't be set for HA clusters
        Issue: When using user auth via HTTP, Clavister Firewall offers the possibility to customize the logon/result HTML pages. This was not possible for the "cluster" nodes, so customized pages could not be uploaded.
        Fix: Firewall Manager v8.10.01 allows the "HTML Root Directory" to be set for cluster nodes.
        Affects: Firewall Manager v8.10.00



     Firewall Core - VPN Specific Bug Fixes                
    Security alert: IPsec PSK authentication bug
        Issue: IPsec PSK authentication is short-circuited; users knowing the PSK of one VPN tunnel on a particular VPN gateway can gain access to all other PSK-using VPN tunnels on that gateway, under certain circumstances.
        Public: Public as of 2003-05-13. Fix available in two hours after discovery.
        Mitigating:
    » VPN gateways with only one PSK-using VPN tunnel are obviously not affected.
    » For gateways where all PSK-using VPN tunnels enjoy the same privileges, no additional exposure results.
    » VPN tunnels that require X.509 certificates are not affected
    » An attacker would already have to have access to the PSK of a legitimate tunnel, which limits the scope of the attack
    » An attacker would have to successfully spoof the IP address of the remote gateway whose tunnels it wants to take over. (One cannot have multiple PSK-using roaming-user tunnels, so spoofing is a necessity.)
        Affects: Clavister Firewall Core v8.10.00 only.
        Fix: Fixed in v8.10.01-pre001, previously available for download from
    http://www.clavister.com/support/prerelease/cfw_8_10_01_pre001.eup.
    This fix is included in this release.

    DNS resolution of remote gateways broken
        Issue: Clavister Firewall allows remote gateways to be specified by DNS name, which is helpful for gateways whose IP address frequently change; by registering with a dyndns service, one can connect to them after their IP address has changed.
        Problem: The IP address of the remote gateway was successfully resolved, but it also overrode the remote network with the same address.
        Result: The tunnel set-up would fail in phase 2; the IKE connection would be successfully created, but no IPsec SAs would be created, and no traffic could pass through the tunnel.
        Affects: Clavister Firewall Core v8.10.00 only.
        Fix: Fixed in v8.10.01.



     Firewall Core - VPN Specific Known Problems                
    Interoperability problem with 7.x gateways (unstable tunnels)
        Problem: We have received reports of tunnel instability problems between 7.x and 8.x VPN gateways. We are currently investigating these reports; it is possible, albeit not certain, that these problems are linked to IKE SAs having lifetimes over four hours.
        Action: Please report any such problems to support@clavister.com, and, if possible, the results of lowering the IKE lifetime to four hours or less.
        See: Please see changes-8.00.02-to-8.00.05.html for more information on this issue.



     Firewall Core - HA Bug Fixes                
    User authentication not designed for HA use
        Problem: Two issues made user authentication unfit for use in HA clusters:
    » Information about logged-on users was not synchronized
    » One could not authenticate via HTTP to the shared IP
        Fix: v8.10.01 synchronizes the state of logged-on users, and allows HTTP connectivity to the shared IP to be configured.
        Affects: Clavister Firewall v8.10.00 in HA setups.



     Firewall Core - HA Known Bugs / Problems                
    No state synchronization for FTP ALG
        Problem: No aspect of the FTP ALG is state synchronized.
    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 session (and associated transfers) should begin working again.
        Note: Note that failover occurs each time a new configuration is uploaded, and that the upload procedure leaves the "master" cluster node active.