- Current openings

Upgrades

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

Release name:	Ingate Firewall® 4.5.1 Ingate SIParator® 4.5.1
Release date:	2007-01-16

This release supports a command language interface, a SIP Trunking module, ping and traceroute from the box and fixes two security problem 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

A SIP trunking module is now available. The SIP trunking module enables interoperability between an IP PBX located at an enterprise and a service provider offering PSTN termination. Moreover the SIP trunking module provides additional support for local call transfer handling. That means that the Ingate not only supports call transfers (which since long is a basic feature) but that it also can handle the SIP REFER method in place of other entities not capable of doing so. The SIP trunking module will be added for free on units that already have or installs the Advanced SIP Routing module. [Tracking IDs: 2416, 2826]
A new option that allows SIP clients behind the same far-end NAT box to no longer send media via the Ingate is available. This saves bandwidth in the Ingate, the far-end NAT device and on the Internet. [Tracking ID: 2437]
The Ingate SIParator can now be configured to use a NATed or private address which may be useful for SIParators running in DMZ or DMZ LAN mode. Using this feature a SIParator may be installed together with an existing non-SIP aware firewall without the need for an additional public IP address. [Tracking ID: 348]
The dial plan now supports forwarding of REGISTER messages. A configuration option defines if forwarding of REGISTER messages also rewrites the To Header. [Tracking ID: 2179]
Performance as well as robustness has been improved for TCP and TLS signaling. [Tracking IDs: 294, 2526, 2527, 2551]
The "Accepted SIP Transport" setting has been replaced with a "SIP Transport" setting. It now governs connections initated by the Ingate as well as connections received by the Ingate. This setting overrides all other SIP settings, so if this is set to "TLS", then the Ingate will never send or accept SIP messages over any other transport. (As before, this can also be set to "TCP or UDP" to forbid encrypted signaling, or "Any".) [Tracking ID: 2777]
The Ingate can now act as a limited master server in a VoIP survival environment and thus provide remote sites with survival information. [Tracking ID: 2783]
The maximum size of a SIP message packet is now configurable in the range between 1024 bytes and 64 Mbytes. (UDP packets can never be more than 64 Kbytes large.) In general higher value gives more performance but uses more memory. [Tracking ID: 2585]
The Remove Via headers function now logs when Via headers are removed. [Tracking ID: 2597]
The cause of the SIP module marking a SIP server as bad is now logged. [Tracking ID: 2614]
Messages that the SIP module sends to itself can now be filtered out by unchecking the option "Show Internal SIP Signaling" on the Display Log page in the web GUI. [Tracking ID: 2624]
The whole request URI, including parameters, is now used in the Dial Plan's regular expression matching. Previously only the user and host parts were used. [Tracking ID: 2782]
The internal B2BUA now conveys custom reason phrases in responses. [Tracking ID: 2590]
Selections of timeouts for voicemail and sequence User Routing has been extended with options for 5 and 10 seconds. [Tracking ID: 2778]
During call transfer, the B2BUA now also generates NOTIFYs to the referrer for provisional responses. Previously only a NOTIFY for the final response was sent. [Tracking ID: 2779]
Ingate MEDIAtor logging has been extended to include logging of complete messages to and from the Access Proxy, including original and rewritten SDP. [Tracking ID: 2792]
The reason for dropping late responses is now logged. [Tracking ID: 2930]
The valid range of values of the "Min Tail" column in the Matching Request URI table of the SIP Dial Plan has been limited to positive integers. [Tracking ID: 2889]

Other new functionality

The admin menu can now be accessed using Secure Shell (SSH2). Previously, the admin menu could only be used from the console. Access control for SSH is similar to what has long been available for HTTP and HTTPS. [Tracking ID: 446]
A Command Line Interface (CLI) is now available to the administrator. The CLI which is available through the admin menu provides commands that can be used to inspect, alter and apply a new configuration. In order to describe the configuration a configuration language is provided. Command files can also be uploaded via the web GUI. Note also that while all configurations can be accessed from the CLI, there are many administrative tasks that still can only be done using the web GUI, e.g., searching the log, making a backup of the configuration, renegotiate IPsec tunnels, creating certificates, and so on. Some table names and columns will likely change in the next upcoming release (4.6), but after that it is Ingate's intention not to change existing tables. [Tracking IDs: 202, 203]
Prioritization of default gateways is now supported. This is useful when using multiple ISPs for improving availability. Setting the priority enables the administrator to select a primary ISP with e.g. best bandwidth in favour of other ISPs used as backup. [Tracking ID: 2544]
The Ingate can now be configured to return an ICMP response to traffic arriving from a currently inactive default gateway. This is useful e.g. when clients on the Internet tries to connect to services on the LAN. Recieving the ICMP response should help the client proceed to use the next DNS SRV entry and eventually find the service on the LAN. [Tracking ID: 2733]
Ping and traceroute are made available as commands in the CLI. These commands can be used for debugging network problems. [Tracking ID: 2885]
It is now possible to manually configure the speed and duplex settings for the individual network interfaces of the Ingate product (disable auto-negotiation). This applies to new models including Ingate Firewall 1180, 1450, 1600 and 1900 as well as Ingate SIParator 18, 45, 60 and 90. [Tracking ID:412]
A "Support Report" function has been added which saves status information as well as logs. This feature is intended to be used to collect information prior to contacting support. [Tracking IDs:1418, 2427]
The builtin DHCP client, server and relay now support VLAN. [Tracking IDs:2411, 2832]
The Show Configuration page in the GUI now indicates configuration differences between the preliminary and permanent configurations. [Tracking ID: 2761]
A watchdog guarding the health of the SIP module has been added. The watchdog may be enabled to periodically check that the SIP module is alive. If the SIP module is irresponsive the watchdog will restart the SIP module. [Tracking ID: 2554]
It is now possible to search the log, view load and capture packets in a broken failover team. It is also possible to do these things in upgrade test mode. Note that changing the parameters is not allowed. [Tracking ID: 2458]
Log categories for SIP license and media flow related log messages have been added. [Tracking ID: 2686]
An SNMP trap can now be generated to indicate that a new software version is available for the Ingate product. [Tracking ID: 2721]
Web GUI improvement: Rows with errors are now editable regardless of the edit column. [Tracking ID: 2799]
The default gateway can be used as a failover reference host even when assigned via a DHCP/PPPoE server [Tracking ID: 2806]
An error control has been added to verify that at least one computer or network can be used for accessing the Ingate product. [Tracking ID: 2755]
An error control has been added to verify that the same exact network is not used as both local and remote IPsec network in the IPsec network table. [Tracking ID: 2876]

Fixed security problems

A vulnerability for authentication replay attacks on the SIP module has been fixed. [Tracking ID: 2794]
The OpenSSL vulnerability to RSA Signature Forgery (CVE-2006-4339) has been removed in the 4.5.0 software: To be affected, you have to use an external CA and SIP over TLS. The IPsec implementation is not affected by this issue. It may be possible for an attacker to connect using SIP over TLS even if an X.509 client certificate is required. It may be possible for an attacker to intercept connections that the Ingate product initiates to TLS-secured servers. The vulnerability is only exploitable if an X.509 certificate uses an RSA key with exponent 3. The Ingate product has never created such keys by itself, but if an external CA is used, and if that CA uses exponent 3, the configuration may be vulnerable. SIP installations are vulnerable if any of the certificates in the "TLS CA Certificates" table on the "Signaling Encryption" page uses exponent 3. [Tracking ID:2829]
The security issue in GnuPG (CVE-2006-6235 et al) has been fixed. [Tracking ID:2997]

Fixed SIP-related problems

An issue which could cause the SIP module to block while waiting for RADIUS authentication has been fixed. [Tracking ID: 1425]
A problem running application sharing in an LCS environment using a MEDIAtor which in some situations could cause the MEDIAtor to hang has been fixed. [Tracking ID: 2858]
The offer/answer handling has been improved to support negotiation in PRACK and UPDATE transactions. [Tracking ID: 2548]
An issue causing the Ingate to consume two licenses per call for calls using specific SIP account types has been fixed. [Tracking ID: 2781]
A bug in the MEDIAtor causing re-INVITEs to a clients being located behind a far-end NAT device to fail (no media) has been fixed. [Tracking ID:2936]
Not receiving a response to a SIP request will no longer mark the destination as bad. Now only network failures and failed server monitoring (configured in the GUI) by OPTIONS requests will mark the destination as bad. [Tracking ID: 1638]
The DNS cache of the SIP module is now flushed when the DNS server is changed to a different one. [Tracking ID: 650]
When an authentication attempt failed because the user did not exist, 403 Forbidden used to be returned. Now 401/407 is returned. This only affects local authentication and not RADIUS authentication where 401/407 has always been returned. [Tracking ID: 1623]
OPTIONS requests directed to the SIP proxy are now responded to properly with 200 OK. The response will contain Accepted and Supported headers specifying the proxy's capabilities. [Tracking ID: 1760]
A bug causing the Ingate to not properly recognize a preloaded Route header with its own domain (causing a loop) has been fixed. [Tracking ID: 2269]
A bug causing the Via header value to change in responses to clients behind a far end NAT has been fixed. [Tracking ID: 2606]
A bug causing the Dial Plan not to proceed to the next possible host in the Forward To table after receiving a 408 Request Timeout has been fixed. [Tracking ID: 2612]
A SIP module crash when a recvonly/sendonly call moves to inactive has been fixed. [Tracking ID: 2857]
A one way media problem has been fixed. The problem occured when two remote clients were behind the same NAT box and the server was on the LAN behind a DMZ SIParator. [Tracking ID: 2741]
A bug causing the weight column of the DNS override table not to be properly used, causing SIP requests to be forked to all addresses or subrows has been fixed. [Tracking ID: 2986]
A problem causing media not to flow for incoming calls through the B2BUA has been fixed. [Tracking ID: 2702]
A bug causing 100 Trying and 180 Ringing messages to be marked as resent in the log even when that is not the case has been fixed. [Tracking ID: 2694]
When the Ingate sent error responses to INVITE transactions, the ACKs following were not absorbed by the Ingate. The ACKs are now properly absorbed and logged. [Tracking ID: 2760]
A bug occurring when the stream timeout feature is used in combination with the SIP module being heavily loaded causing the SIP module to hang or crash has been fixed. [Tracking ID: 2776]
An issue causing an end point to keep ringing even though the caller has hung up has been fixed. The issue showed up when calling through the Ingate B2BUA and there was no answer. The caller-B2BUA call terminated after 32 seconds. The B2BUA-callee call, however, continued to live for "Default timeout for INVITE requests" seconds. [Tracking ID: 2861]
The SIP module has been updated to use the recommended RFC 3261 branch calculation. [Tracking ID: 2788]
A bug causing some SIP packets not to be shown in the SIP packet category in the log has been fixed. [Tracking ID: 2802]
A bug causing Remote NAT Traversal to fail in certain situations using the "Preserve username for all requests" interoperability setting has been fixed. [Tracking ID: 2804]
A bug causing tel URI requests to always be sent to the outbound proxy has been fixed. [Tracking ID: 2813]
A bug causing an ACK to be sent using UDP as transport when TCP is indicated as transport by the Route header has been fixed. [Tracking ID: 2827]
The error control that verifies the "SIP blacklist interval" has been updated to check against the correct transaction interval. [Tracking ID: 2875]
A bug causing Record-Route handling to fail when using the interoperability setting "Preserve username for all requests" has been fixed. [Tracking ID: 2963]
A bug causing the Ingate to consume traversal licenses for any forwarded request where the Ingate is stateful has been fixed. The Ingate only consumes traversal licenses when media traverses the unit. [Tracking ID 2989]
A bug causing large file transfers using Windows Messenger to fail has been fixed. [Tracking ID: 2992]
An error control has been added to limit the number of DNS override targets to 10. [Tracking ID: 3010]
A bug causing the B2BUA to send two Server headers (one of them incorrect) has been fixed. [Tracking ID: 3024]

Fixed VPN-related problems

Receiving an IPsec IKE phase two proposal without PFS (Perfect Forward Secrecy) enabled no longer causes the IPsec module to restart. [Tracking ID: 2848]
An issue causing IPsec tunnels to stop working after some days or weeks, depending on how often tunnels are renegotiated, has been fixed. This issue is identified by the log message "Errno 28: No space left on device". [Tracking ID: 2854]
In some cases firewall rules were not destroyed properly when IPsec tunnels were brought down. This could cause available memory as well as performance to degrade over time. [Tracking ID: 3014]

Removed functionality

Support for Vonage user accounts has been removed. [Tracking ID: 2801]
The SIP setting "Local IP Addresses Are SIP Domains" has been removed. All domains that are to be used as local domains by the SIP proxy must be listed in the "Local SIP Domains" table. [Tracking ID: 2784]

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]

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]