Upgrades

Release notice for Ingate Firewall® 4.1.3 and Ingate SIParator® 4.1.3

The new version can be found here

   Release notice for Ingate Firewall(R) 4.1.3 and Ingate SIParator(R) 4.1.3

   +-------------------------------------------+
   | Release name: | Ingate Firewall(R) 4.1.3  |
   |               | Ingate SIParator(R) 4.1.3 |
   |---------------+---------------------------|
   | Release date: | 2004-10-08                |
   +-------------------------------------------+

   The new version and the user manual can be found at:
   [1]www.ingate.com/upgrades/

   Please read the separate upgrade instructions, available from the same
   place. You have to log on first to read them.

   New functionality

     * SIP users can now be administered with a specific authentication name
       different from the user name. A column named "Authentication name" has
       been added to the SIP users table. [Tracking ID: 50]
     * Support for NAPTR queries implemented (the replacement field). The
       regexp field is not supported yet and will be ignored. [Tracking ID:
       377]
     * A failover detection mechanism has been added to initiate a failover
       when an interface card breaks. [Tracking ID: 504]
     * More configuration options have been added to the built-in DHCP
       server. The DHCP server now supports handing out domain name to the
       clients. Moreover the lease time may be configured. [Tracking ID:
       1499]
     * It is now possible to use alias IP addresses on a SIParator. This
       enables use of the STUN server on a SIParator. [Tracking ID: 1501]

   Fixed SIP-related problems

     * The contact header will always be NATed if the SIP message comes from
       a NATed network. This even if the route headers will make sure the
       message would be passed on to the inside of the network again. This
       change applies to when SIP URL Encryption is turned on as well as when
       it is off. [Tracking IDs: 483, 1497]
     * A domain name in the contact header will no longer be looked up in the
       DNS to see if it needs to be NATed. [Tracking ID: 781]
     * The SIP proxy no longer sends 100 Trying responses to non-INVITE
       requests when acting as a stateful proxy. [Tracking ID: 975, 1472]
     * The transport parameter of a REGISTER sent to unregister a client is
       no longer lost. [Tracking ID: 985]
     * Support for NATing of the Refer-To header introduced. [Tracking ID:
       1293]
     * All IP addresses returned from a DNS A query will now be used.
       [Tracking ID: 1341]
     * SIP media DROP rules are now removed correctly in certain scenarios
       where a Call Control device is involved. This helps some one way media
       problems. [Tracking ID: 1453]
     * ACK requests are now proxied even if they don't match any existing
       transaction. [Tracking ID: 1475]
     * The contact header of a 3xx response is now NATed correctly. The
       previous behavior could for example affect scenarios with a 302
       Temporarily Moved response. [Tracking ID: 1480]
     * Expires parameter handling using Remote SIP Connectivity, RSC, has
       been corrected. [Tracking ID: 1484]
     * Contact header parameters using Remote SIP Connectivity have been
       corrected. [Tracking ID: 1485]
     * Problems with certain call transfer scenarios in configurations
       including Polycom phones and Broadsoft servers have been fixed.
       [Tracking ID: 1551]

   Other fixed problems

     * If two logical IP networks are connected to the same physical
       ethernet, and if the Ingate Firewall has an IP address on each of
       them, and a host on one of them sends something to another host on the
       other network via the Ingate Firewall, the Ingate Firewall will no
       longer issue an ICMP redirect. [Tracking ID: 1466]
     * Corrected bug that caused Internet Explorer to hang the webserver in
       some situations. [Tracking ID: 1504]
     * The DHCP server now hands out a correct default gateway in
       configurations with more than one directly connected network per
       interface. [Tracking ID: 1506]

   Known problems

   Known VPN-related problems

   These problems are only relevant if the optional VPN module is installed.

     * Packets with a destination address that belongs to either end of a
       tunnel will appear to be encrypted in the log, even when they should
       not be encrypted. This is a problem with the log only. [Tracking ID:
       46]
     * The local endpoint must be chosen so that it is the address closest to
       the next-hop router for that peer. This means that mobile clients must
       always connect via the same interface (typically the interface
       connected to the Internet). [Tracking ID: 508]
     * In order to properly remove an IPsec CA the firewall needs to be
       rebooted. [Tracking ID: 1178]

   Known SIP-related problems

   These problems are only relevant if the SIP module is enabled.

     * If you change the maximum number of users or registrations, the new
       settings won't be active until the SIP module has been restarted.
       [Tracking ID: 53]
     * If SIP over TLS is used, the SIP module may under some circumstances
       block while it waits for a response from the remote SIP client or SIP
       server. Until this is fixed, there is a risk that enabling TLS for SIP
       opens up the SIP module for a denial-of-service attack. [Tracking ID:
       665]
     * Windows Messenger 5.0 does not fully interoperate with Remote SIP
       Connectivity. Initiating a session to a WM 5.0 client located behind a
       none-SIP-aware NAT device will not work reliably. [Tracking ID: 1183]
     * Certain configurations with Microsoft LCS using TLS between firewall
       and LCS does not work. [Tracking ID: 1374]
     * The SIP module may block while it waits for RADIUS authentication.
       This effectively means that only RADIUS servers located on a LAN
       should be used. Additionally the RADIUS server should not enable any
       brute force attack prevention mechanism that delays the response in
       case of a faulty username-password combination. [Tracking ID: 1425]
     * Loop detection has been disabled in this release, due to errors in the
       implementation. A future release will re-enable loop detection. We
       fully support the Max-Forwards header, so this can not lead to
       infinite loops. Please note that loop detection is an optional feature
       that isn't required for SIP compliance. [Tracking ID: 1474]
     * Certain configurations with Remote SIP Connectivity and a SIP server
       on the local LAN does not work. [Tracking ID: 1566]

   Known Failover-related problems

   This problem is only relevant if failover is used.

     * Upgrading a failover team is a complex operation. To upgrade it, you
       must break the team and upgrade each machine in turn. This will
       require a number of reboots and network outages. See the separate
       failover upgrade document which is available on the upgrade web.
       [Tracking ID: 499]

References

   Visible links
   1. http://www.ingate.com/upgrades.php