Amaranten Firewall Changes from v8.30.00 to v8.30.01

Release date: 2004-01-21 [ISO]

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
· 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

Firewall Core

Change:	FTP ALG logging now more verbose
Change:	DHCP relayer can now relay to built-in DHCP server
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

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

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, Amaranten Firewall will listen to non-targeted ARP broadcasts for ARP cache update purposes, if it is configured to be RFC 826 compliant.

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 Amaranten 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