Upgrades

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

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

• PPTP tunnels for inactivated users are now terminated.
  When a PPTP user who has an active tunnel is disabled or removed, the tunnel is now terminated when the configuration is applied. [Tracking ID: 1826]
• A problem related to the use of the SIP STUN server opening more IP:port combinations than configured has been fixed. [Tracking ID: 2033]

• The Static Forwarding and Static Domain Modification tables now allow configuration of multiple redundant outbound SIP servers without using DNS. [Tracking ID: 1828]
• The Static Domain Modification table now contains row numbers. [Tracking ID: 1853]
• When a SIP request times out the destination is remembered as faulty and no requests will be sent to this host for a certain amount of time. A configuration parameter has been added, which allows an administrator to specify for how long a SIP endpoint should be remembered as bad. [Tracking ID: 1856]
• The following predefined content types for LCS 2005 have been added: "application/adrl+xml" and "application/rmli+xml". [Tracking ID: 1695] This only applies to the factory database for new installations; upgrading your firewall/SIParator will not change your configuration into contain these.

• Support for RFC 3947 NAT-T added.
  NAT-T was recently specified in two Standards Track RFCs:
  RFC 3947 - Negotiation of NAT-Traversal in the IKE
  RFC 3948 - UDP Encapsulation of IPsec ESP Packets
  In addition to still supporting the older NAT-T drafts we now also support the NAT-T negotiation defined in RFC 3947. [Tracking ID: 1845]
• PPTP GRE packets received out of order are now better handled. PPTP GRE packets received in incorrect order must normally be discarded by the PPTP server, however RFC 2890 specifies an optional buffering scheme where such packets are queued and re-ordered by the server. Such a queing scheme has now been implemented, increasing PPTP throughput in cases when packet re-ordering occurs between the client and server. [Tracking ID: 1858]
• A PPTP status page has been added. [Tracking ID 2021]

• Changes of the registrar limits "Allowed number of users" and "Maximum number of registrations per user" now takes effect without restarting the SIP module. [Tracking ID: 53]
• The Expires header is now modified according to the value of bindings added to the request. [Tracking ID: 1752]
• Responses with a host name in the Via header's sent-by value are now decrypted correctly. [Tracking ID: 1852]
• Under some rare circumstances the SIP module could restart itself when the survival module was used and a new configuration was applied. This has been fixed. [Tracking ID: 1941]
• A problem related to supporting an SDP offer in a response has been fixed. [Tracking ID: 1942]
• The SIP module no longer restarts itself when exceeding the maximum number of allowed media streams. [Tracking ID: 1974]

• IPsec tunnels using dynamic DNS lookup visible only once on status page. Sometimes such IPsec tunnels occured twice on the status page. This has now been fixed. [Tracking ID: 1972]

• After upgrading to 4.2.2, it is no longer possible to perform an upgrade using floppy. All upgrades must now be performed using the web interface. It is still possible to save and load configurations via floppy.

• 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]
  Workaround:
  Disable all IPsec peers and apply the configuration. This will clear all previous IPsec state. Then enable the peers and apply the configuration again.

• Active Sessions may under some circumstances not be directly removed. The session is in such a case not removed at the instant when the call ends. Instead the session is removed at the configurable session timeout. This will lead to temporary unnecessary allocations of memory and in some cases temporary unnecessary media-stream (firewall rules for media) allocations. [Tracking ID: 1202]
• 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 preferably not enable any brute force attack prevention mechanism that delays the response in case of a faulty username/password combination. [Tracking ID: 1425]
• The combination of Remote NAT traversal and static registrations does not work. Typically this problem may show up calling a SIP user that sits remotely behind a none-SIP-aware NATing firewall from PSTN. [Tracking ID: 1859]

• 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]