Amaranten Firewall Changes from v8.00.02 to v8.00.05

Release date: 2003-02-19 [ISO]

Version 8.00.05 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.

Note that there was no 8.00.03 public release. It mainly solved driver problems for the realtek NIC, used in R33 appliances. All R33 appliances have been delivered with 8.00.03 (or later) cores. Version 8.00.04 was also very limited due to early discovery of a newly introduced bug in the DHCP client. This has been fixed in v8.00.05.

·  New files installed by v8.00.05

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

·  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

 

[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: Lifetimes of locally defined IPsec/IKE proposals could not be changed

·  Bug fix: FWMgr would not allow PBR rules with Fwd=<main> and Ret=<main>

·  Bug fix: Identical proposals could not be used in multiple proposal lists

Firewall Core

·  Change: New arguments to the "time" command: "-set" and "-sync"

·  Change: DHCP client can now be configured to start with 0.0.0.0

·  Change: DHCP client less restrictive

·  Change: SAT SETDEST rules with destnet=0.0.0.0/0 now become redirects

·  Bug fix: FTP ALG freeze/reboot problems resolved

·  Bug fix: FTP ALG: Active mode connections would fail through some remote firewalls

·  Bug fix: DHCP relayer would (correctly) refuse too short DHCP packets

·  Bug fix: DHCP client problems in multi-DHCP-server networks

·  Bug fix: Time synchronizer would not update the computer RTC

·  Bug fix: DHCP client goes into a reconfigure loop (8.00.04 only)

·  Bug fix: DHCP relayer fails to add dynamic routes unless configured to do proxy ARP for the route (8.00.04 only)

·  Bug fix: DHCP client fails to receive unchecksummed leases (8.00.04 only)

Firewall Core - VPN specific

·  Change: Resolved remote gateway DNS names are now cached locally in case of DNS failure

·  Bug fix: VPN tunnels unstable with IKE lifetimes over 4 hours

·  Bug fix: Continuous phase-2 retries could crash the firewall

·  Bug fix: Crash when fetching (some) LDAP CRLs

·  Bug fix: Certificates using non-ASCII encodings would not work

Firewall Core - HA specific

·  Known bug: No state synchronization for FTP ALG

 

 

 

 New files installed by v8.00.05

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


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

  • Cores/fwc-8.00.05-full.cfx
    This is the v8.00.05 full firewall core. Upload it to your existing (standard) firewall, or create new boot media with it. It contains VPN as well as HA functionality.
  • Cores/fwc-8.00.05-novpn.cfx
    This is a version of the v8.00.05 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.00.02-to-8.00.05.htm
    This document.
  • FWMgr8.exe
    This is the v    8.00.05 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.00.05

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Upgrading a previous v8.0x firewall to v8.00.05 is completely straightforward.
Simply upload the new core, "fwc-8.00.05-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.00.05 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 now 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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Lifetimes of locally defined IPsec/IKE proposals could not be changed
    Issue: Lifetimes for IPsec/IKE proposals may be stored both in the global namespace (the recommended location; as these values need to be shared between gateways) as well as locally for a specific firewall.
    Problem: The lifetimes of locally defined proposals sometimes could not be changed.
    Fixed: Fixed in v    8.00.04.
    Affects: v8.00.00 - v8.00.03.

  • FWMgr would not allow PBR rules with Fwd=<main> and Ret=<main>
    Issue: It is often useful to make exceptions in the policy-based routing ruleset by placing rules earlier in the ruleset that specify <main> as the routing table to use in both the forward and return direction.
    Problem: The firewall manager would not allow PBR rules with <main> used in both directions
    Workaround: Create an empty dummy routing table to use instead of <main>; the lookup will fall back to using the main table if the lookup in the PBR tables fails to find a matching route.
    Fixed: Fixed in v    8.00.04.
    Affects: v8.00.00 - v8.00.03.

  • Identical proposals could not be used in multiple proposal lists
    Issue: The firewall manager would name identical proposals the same way, which caused name collisions (errors) if identical proposals were used in more than one proposal list.
    Results: One would have to work around the problem by altering one proposal slightly.
    Fixed: Fixed in v    8.00.03.
    Affects: v8.00.00 - v8.00.02.
     

 

 

 Firewall Core Changes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



  • New arguments to the "time" command: "-set" and "-sync"
    The local firewall time can now be set from the command prompt through the new     "time -set YYYY-MM-DD HH:MM:SS" command.
    Time synchronization can also be initiated on demand through the new     "time -sync" command, if time servers are configured in the Settings section. If clock drift is too high, "time -sync -force" may be used to override the Timesync_MaxAdjust limit.
    Manual time setting was previously only possible through the boot menu, which requires either physical access to the firewall or modem access to the serial port.
    Changed in: v    8.00.04

  • DHCP client can now be configured to start with 0.0.0.0
    The DHCP client normally picks a link-local (169.254.x.x) IP address while waiting for a lease to arrive. Using link-local IP addresses is a relatively new addition to the DHCP standard, so to avoid as-yet unseen compatibility problems, the DHCP client can now be configured to adhere to the old BOOTP/DHCP specifications and use 0.0.0.0 until a lease is received.
    This behavior is controlled through the new "DHCP_UseLinkLocalIP" setting, which defaults to     on (i.e. no change from previous versions by default).
    Changed in: v8.00.05

  • DHCP client less restrictive
    Because of the prevalence of non-standards-compliant and/or misconfigured DHCP servers and relayers, several sanity checks have been removed from the DHCP client:
    - The DHCP client previously rejected leases with the gateway equal to the proposed IP address. This is now allowed, and treated as if there is no gateway at all.
    - The DHCP client also did basic sanity verification on the renew/rebind timers by rejecting leases with these timers set lower than five and seven seconds, respectively. Apparently, there are badly broken DHCP servers out there that hand out even lower times. Such times are now simply rewritten to 50% and 90% of the total lease time, respectively.
    - To support "quirky" setups, the DHCP client will now also allow the IP and/or gateway address to equal the lowest and/or highest address of the assigned network, for network sizes /29--/32.
    Changed in: v    8.00.05

  • SAT SETDEST rules with destnet=0.0.0.0/0 now become redirects
    SAT rules normally     transpose IP ranges. E.g. a rule like:
      SAT   ext all-nets   any 1.2.3.0-1.2.3.4   SETDEST 5.6.7.10
    will map 1.2.3.0 to 5.6.7.10, 1.2.3.1 to 5.6.7.11, etc.
    This behavior is not useful if the destination network in a SAT SETDEST rule is 0.0.0.0/0, so this special case has been changed: when the destination network is 0.0.0.0/0,     all addresses will map to the single "new address" set in the rule.
    This is useful for e.g. building a transparent HTTP proxy using the Squid Cache, which requires that all traffic to be transparently proxied be redirected to its own IP address.
    Changed in: v8.00.05

 

 

 

 Firewall Core Bug Fixes