Amaranten Firewall Changes from v8.20.00 to v8.20.01

Release date: 2003-10-10 [ISO]

Version 8.20.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.20.01

·  How to upgrade earlier v8.0x firewalls to v8.20.01

·  HA upgrade procedure

·  Firewall Manager

[Changes]

[Bug Fixes

[Known Bugs / Problems]

·  Firewall Core

[Changes]

[Bug Fixes]

[Known Bugs / Problems]

·  Firewall Core - VPN specific  

[Changes]

[Bug Fixes]

[Known Bugs / Problems

·  Firewall Core - HA specific

[Changes]

[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 Amaranten Firewall are available in the release notes section of www.Amaranten.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

  Bug fix: 

Configuration download from HA cluster fails

Firewall Core

  Change: 

DHCP relayer leases can now be ended from console

  Bug fix: 

HTTPPoster does not work with dyndns.org DynDNS services

Firewall Core - VPN specific

  Bug fix: 

Security Alert: Buffer overrun in IKE certificate ASN.1 parser

Firewall Core - HA specific

  Known bug: 

No state synchronization for FTP ALG

 

 New files installed by v8.20.01

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This is a list of the files that are new to the v8.20.01 release. All paths are relative to your Firewall Manager install folder.

» 

Cores/fwc-8.20.01-full.cfx
This is the v8.20.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.20.01-novpn.cfx
This is a version of the v8.20.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.20.00-to-8.20.01.html
This document.

» 

FWMgr8.exe
This is the v
8.20.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.20.01

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 HA upgrade procedure

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

There are no incompatibilities in the HA synchronization protocol between 8.20.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 Manager Bug Fixes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuration download from HA cluster fails

   Problem:

Configuration download from HA cluster members will make erroneous changes to the downloaded configuration file before saving it.

   Results:

The IP addresses of interfaces will be changed around. The configuration will still parse, but will not function properly if uploaded to the cluster members.

   Affects:

FWMgr v8.10.00-8.10.01 and v8.20.00.

    Fixed:

Fixed in v8.10.02, v8.20.01 and v8.30.00.



 

 Firewall Core Changes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DHCP relayer leases can now be ended from console

  Change:

The "dhcprelay" console command now has "-release <ipaddr>" switch, which forcefully makes the relayer forget about a relayed lease, including removing automatically added routes, if any.



 

 Firewall Core Bug Fixes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HTTPPoster does not work with dyndns.org DynDNS services

   Problem:

The HTTPPoster would not send a "User-Agent" string in its requests. Dyndns.org does not accept such HTTP requests.

   Results:

Dyndns.org would not obey changes posted via the HTTPPoster.

   Affects:

v8.20.00.

    Fixed:

The HTTPPoster now sets the "User-Agent" to
"
CFW-HTTPPoster/1.0 support@Amarantenaisa.com".
Fixed in v
8.20.01 and v8.30.00.



 

 Firewall Core - VPN Specific Bug Fixes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Security Alert: Buffer overrun in IKE certificate ASN.1 parser

    Issue:

All VPN enabled firewalls that support certificate-based authentication are vulnerable to a buffer overrun in the ASN.1 parser in the IKE code.

    Impact:

If an IKE connection can be established to a VPN enabled firewall, the firewall can be crashed. This normally leads to an automatic restart.
The full extent of the buffer overrun is not yet fully understood; for the time being, Amaranten assumes that it may be possible to take control of the firewall itself. Initial observations however suggest that this may be difficult.

  Workaround:

» 

For firewalls that do not require VPN functionality: upload a firewall core that does not support IPsec VPNs ("-novpn" cores).

» 

For VPN gateways: disable the "IPsecBeforeRules" advanced setting and add rules that allow IKE and IPsec (e.g. the "ipsec-suite" service) only from known IP addresses.
This reduces the window of exposure until a patch can be installed.
It may indeed be a good idea to
always restrict who may speak IPsec to your VPN gateways, if possible.

    Affects:

v8.00.00-8.00.06, v8.10.00-8.10.01 and v8.20.00.

    Fixed:

Fixed in v8.00.07, v8.10.02, v8.20.01 and v8.30.00.



 

 

 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.