- Current openings

Upgrades

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

Release name:	Ingate Firewall® 4.5.2 Ingate SIParator® 4.5.2
Release date:	2007-05-29

This release supports NAT through IPsec tunnels, codec filtering for SIP calls, fixes some security problems and several issues related to SIP. Additionally it resolves a few other issues. We recommend that everybody upgrade.

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

When upgrading an Ingate SIParator running in MEDIAtor mode it is recommended that an updated Windows service is installed on the LCS Access Proxy server. Please contact support@ingate.com if you need to obtain this service.

New SIP functionality

It is now possible to specify which codecs are allowed in SIP calls and filter out all others. [Tracking ID: 502]
Support for RFC 3326 (The Reason Header Field) is added. When the SIP module initiates a CANCEL it includes a reason. [Tracking ID: 1042]
As an alternative to normal URI encryption which may produce long URIs, URIs can now be encoded so that username length in URIs is kept constant (17 characters). Note that this URI encoding type produces URIs which are only valid for 24 hours. [Tracking ID: 1870]
In case UAs don't implement ICE properly, it is now possible to remove ICE attributes so that those UAs can fall back on non-ICE behaviour which might have a better chance to work. [Tracking ID: 3013]
Local REFER handling now works even if a call isn't relayed by the Dial Plan. [Tracking ID: 3027]
The internal B2BUA (SIP accounts and REFER handling) now supports DTMF signaling in INFO requests. [Tracking ID: 3038]
An interoperability setting has been added for UAs which erroneously require space (coded as %20) to be unescaped when moved to a URI. [Tracking ID: 3086]
An interoperability setting has been added which allows the URI port to be ignored when there is an "maddr" parameter present in the URI. [Tracking ID: 3324]

New VPN functionality

It is now possible to NAT traffic going out through an IPsec tunnel. [Tracking id: 1711]
It is now possible to get a detailed log of the contents of IKE messages (used for IPsec tunnel negotiations), including among other things the proposals sent and received. [Tracking id: 811]
The subject names for X.509 certificates used in IPsec tunnel negotiations are now shown in the log. [Tracking id: 690]
Information about X.509 certificates and preshared keys for IPsec peers is now shown on the "Show Configuration" page, to help in finding misconfigurations. [Tracking id: 582]

Other new functionality

It is now possible to relay a range of ports in the Relays table. By entering a range in the "Listen to" port field and leaving the "Relay to" port field empty, these ports will be relayed unchanged to the server. This is limited to the port forwarding relay types. Be careful with large ranges, however, as these currently consume a significant amount of resources on the firewall. [Tracking ID: 329]

Fixed security problems

An OpenSSL vulnerability has been fixed. See http://www.openssl.org/news/secadv_20060928.txt [Tracking ID: 3216]
Downloading a Support Report now requires full privileges. [Tracking ID: 3260]
Authentication requirement for SIP could be bypassed by using an "maddr" parameter. This is no longer possible. [Tracking ID: 3265]

Fixed SIP-related problems

A problem with the internal B2BUA of the SIP module when double transfers were made and the INVITEs contain a Referred-By header has been fixed. [Tracking ID:3116]
Remote NAT Traversal in combination with the SIP module's internal B2BUA now works properly. [Tracking ID:3138]
SIP media timeout events now work properly. The timeout events indicating that a media stream has stopped working was accidently broken in 4.5.1. This has now been fixed. [Tracking ID: 3117]
When recursing on 3xx responses, CANCEL could fail. This has been fixed. [Tracking ID: 3099]
Load balancing using SRV records now works better with sequential Call-IDs. [Tracking ID: 2988]
Remote NAT Traversal now works with fragmented SIP packets. [Tracking ID: 3103]
The SIP module's internal B2BUA now avoids sending re-INVITEs while there is already a re-INVITE in progress. [Tracking ID:3199]
Registering a SIP account multiple times with the same username could cause calls to be misrouted. This has been fixed. [Tracking ID: 3126]
When SIP signaling over TCP is used, the SIP module could sometimes log the message "Bad event TimedOut in state TCPStateDead" and crash. This has now been fixed. [Tracking ID 3134]
TLS NAPTR entries were never used in 4.5.0 and 4.5.1, but are now once again used. [Tracking ID: 3142]
When SRTP transcoding is used and a call is made from an SRTP device to an RTP device that responds with early media, the SIP module would erroneously put in different keys in the early media SDP and the final SDP. This has been fixed; the SIP module now never changes the key that is used for media to a specific endpoint during the duration of a call. However, see also tracking ID 3213 under "Known problems". [Tracking ID: 3152]
Correct SRV queries are now performed when the destination URI has a "transport=tls" parameter. [Tracking ID: 3320]
Leading CRLF in TCP streams is now properly discarded. [Tracking ID: 3235]
If there were ongoing calls when applying a new configuration, new calls could interfere with the ongoing calls. This has been fixed. However, if the change in configuration includes changing the media port range, all existing calls will be torn down when the configuration is applied. [Tracking ID: 3252]

Fixed VPN-related problems

Firewall rules for IPsec tunnels were sometimes, especially in large configurations, not set up properly, causing loss of access for some peers. This has been fixed. [Tracking id: 3127]
Configurations which use very many networks in the private address ranges caused the IPsec subsystem to misbehave and drop random tunnels. This has been fixed. [Tracking id: 2708]
Added workaround for broken PPTP clients. Some PPTP clients incorrectly send too large packets through the tunnel. To fix this we explicitly force clients to limit the size of sent packets to 1400 bytes. [Tracking ID: 3203]
If two IPsec peers were accidentally configured to negotiate tunnels for the same network, they could "steal" the tunnels for each other. This could also cause the firewall to consume more and more resources, and eventually lock up. This has been fixed so that when a second peer tries to negotiate for a network that already has a tunnel up, this second peer is rejected. [Tracking id: 459]

Removed functionality

The combination of the SIP interoperability setting "Preserve username" and DMZ SIParator is no longer allowed. An error check is implemented to prohibit this setup. [Tracking ID: 3154]

Known problems

Known SIP-related problems

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

Transfer initiated by an internal IP-PBX client between two SIP Trunking (PSTN) clients fails in some scenarios. The Ingate firewall/SIParator does not offer the correct set of codecs in the offer in a REFER-initated INVITE. The problem may be worked around by selecting/configuring a codec common to all elements. This problem only appears if Local REFER handling is active. Ingate will shortly provide a patch that solves this issue. Contact Ingate support to obtain the patch. [Tracking ID: 2993]
Previous versions as well as 4.5.2 have several issues with SRTP support. Please contact support@ingate.com to obtain a patch to correct some of these issues if you are using SRTP. No support contract is necessary to obtain the patch.

Known VPN-related problems

These problems are only relevant if IPsec or the built-in PPTP server is used.

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]

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]