- Current openings

Upgrades

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

Release name:	Ingate Firewall® 4.3.1 Ingate SIParator® 4.3.1
Release date:	2005-10-24

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

Security improvements

Improved stateful inspection to meet ICSA requirements.
- For each normal packet traversing the Ingate product only a single ICMP error packet is allowed back through the product. This prevents replay attacks.
- More thorough TCP packet inspection. Now the sequence numbers as well as the TCP window are properly tracked and verified. This prevents spoofed packets with invalid sequence numbers from traversing the Ingate or modifying the internal state of a TCP connection.
- Better resistance against SYN floods and attacks trying to fill up the internal state table with incomplete connections.
[Tracking ID: 2114]
An issue with terminating media sessions has been resolved. Previously media ports could remain open after a call had completed. [Tracking IDs: 742, 958]

New SIP functionality

Handling of media streams has been optimized offering higher performance i.e. increased number of simultaneous calls and improved call setup time, and minimizing the risk of dropping media packets in the beginning of a call. [Tracking ID: 57]
A SIP Advanced Routing module is now available. This module allows the SIP module to perform advanced SIP routing. The old Static Domain Modification table which provided similar but much simpler functionality has been removed. The SIP Advanced Routing module contains:
- Matching on From header (username and domain).
- Matching on Request-URI (username and domain).
- An option to rewrite the Request-URI when forwarding the message.
- Additional options to reject or allow SIP requests.
- The ability to perform ENUM lookup and forward messages.
- The ability to define various things per registered user:
  - Aliases.
  - Forwarding in sequence or parallel etc.
  - Forwarding to voice mail.
  - Limiting incoming calls to a common white list.
- And more.
[Tracking IDs: 390, 473, 1030, 1432, 1580]
SIP authentication is somewhat changed. The authentication Group table has been removed and authentication is now defined per method in the Method table. Additionally a new column is introduced which makes it possible to allow or disallow methods. Methods not included in the table are not handled by the SIP module. [Tracking ID: 1031]
Support for sending RADIUS accounting ticks.
The SIP module may now be configured to enable sending of start and stop ticks (see IETF RFC 2866) to an accounting server. These ticks can be used to construct CDRs. Currently ticks are only sent for sessions that have media which traverses the Ingate product. [Tracking ID: 560]
Support for terminating encrypted RTP media streams.
There is now support for terminating RTP media streams created by Microsoft Windows Messenger. The allowed type of media streams (encrypted or cleartext) can be configured per interface. [Tracking ID: 1036]
MIME multipart bodies are now supported. [Tracking IDs: 2023, 2119]
Matching users may now be done using both username and domain name. Previously only username was used. An interoperability setting has been added to enable full matching, but is disabled by default. [Tracking IDs: 86, 1172]
It is now possible to define a user "*" in the user table when authentication is active. [Tracking ID: 579]
An interoperability setting has been added to disable that IP addresses of the interfaces of the Ingate product are treated as locally handled domains. [Tracking ID: 1544]
More information about each active media stream is displayed in the SIP Active Sessions table in the GUI. [Tracking IDs: 14, 1651]
The port that SIP packets are sent to or received from is now logged. [Tracking ID: 1894]
An interoperability setting has been added to enable removal of Record-Route and Contact headers in 180 responses. This was previously always done. [Tracking ID: 2057]
An interoperability setting has been added that controls if large UDP packets should be sent as UDP packets (fragmented) or be sent using TCP. [Tracking ID: 1897]
An interoperability setting has been added to handle TLS accelerators. Enabling this allows the Ingate product to accept incoming TCP requests with a Via header indicating TLS. [Tracking ID: 2029]
A column for defining the order of SIP proxy rules has been added. [Tracking ID: 29]
An interoperability setting has been added to allow the Ingate to always add a Record-Route header to incoming SIP messages. [Tracking ID: 981]

Other new functionality

VLAN IEEE 802.1Q is now supported.
In the Ingate product GUI, virtual LANs are defined by a physical interface and a VLAN tag. These virtual interfaces may then be used or selected in addition to physical interfaces. [Tracking ID: 368]
Support for redundant default routes. In order to improve availability, redundant service providers may be connected and multiple default routes may be specified. A working route will be selected and monitored. If that route goes down the Ingate product will be updated to use a another default route. [Tracking ID: 360]
Support for recording PCAP logs is introduced. These logs can be downloaded from the Ingate and may be analyzed in e.g. the Ethereal program. [Tracking ID: 1794]
The Ingate SNMP MIB has been extended with:
- Unit serial number.
- Fan speeds (where applicable).
- SIP registrations.
- SIP media sessions.
The following SNMP traps have been added:
- Failed sending logs via email.
- Fan speed goes below the minimum allowed speed (where applicable).
- Malfunctioning power supply (in a machine with multiple PSUs).
- Malfunctioning log disk (in a machine with both hard disk and compact flash).
- The number of concurrent SIP sessions rises above an admin-configurable limit.
- The number of concurrently registered SIP users rises above an admin- configurable limit.
- The CPU load rises above an admin-configurable limit.
- The memory utilization rises above an admin-configurable limit.
[Tracking IDs: 1446, 1668]
A new administrator user type, "VPN Renegotiator", is introduced. This is a user that is only allowed to renegotiate VPN tunnels. [Tracking ID: 1774]
The functionality of the LCD display (only available on some models) has been augmented. It is possible to assign an initial IP address to the machine using the LCD display. The user can enter an interface, IP address and netmask. (Configuration (using web interface) will be allowed from the whole given network, the password will be cleared, and all other interfaces disabled.) It is also possible to become a failover slave, and to exit a failover team, using the LCD display. The default view of the display now includes current CPU usage and current time. [Tracking ID: 1682]
Ethernet port status (link/speed/duplex) is now displayed in the GUI. [Tracking ID: 400]
Ethernet MAC addresses are now displayed in the GUI. [Tracking ID: 1657]
Log time stamps now have millisecond resolution. [Tracking ID: 439]
The Ingate GUI now displays all optional modules. The ones lacking a proper installed license will not be enabled. [Tracking ID: 1704]

Fixed SIP-related problems

The first UDP media packet is no longer dropped. [Tracking ID: 1118]
A problem with terminated SIP sessions that under some circumstances remained active in the SIP session output in the GUI has been fixed. [Tracking ID: 1202]
A problem with rewriting the Request-URI in handling of 302 (Moved temporarily) messages has been fixed. [Tracking ID: 1664]
A problem handling domain names in the Via header has been fixed. [Tracking ID: 1852]
A problem with Remote SIP Connectivity has been fixed. When Remote SIP Connectivity was disabled while NATed clients were registered, the Ingate accidentaly flooded the clients with OPTIONS requests. [Tracking ID: 1966]
Avoid encryption of contact header in some redirection situations. [Tracking ID: 2041]
A problem causing one way media related to receiving 183 and 200 responses with differing port allocations in their SDPs has been fixed. [Tracking ID: 2118]
A problem related to a missing Content-Length header in REGISTER messages to local domains/IP addresses has been fixed. [Tracking ID: 2184]
The SIP module is now fully interoperable with the 3Com VCX server versions 6 and 7. [Tracking ID: 2247]

Known problems

Known security problems

A vulnerability for XSS exploits have been found.
The security cookie used for accessing the web interface of the product may be stolen and used for logging in to the product from a host or network configured to be accepted for configuration.
The attack requires knowledge about the IP address of the Ingate product in use. The administrator must be tricked to follow a link on a malicious web site using the same client and browser he or she uses for accessing the Ingate product. This may enable the malicious site to steal the cookie without the administrators notice.
The timing of the theft is critical, since the security token has a limited lifetime of 10 minutes. The administrator must follow a link on the malicious site within 10 minutes after accessing the Ingate product, or the attack will fail. [Tracking ID: 2174]
Workaround:
To minimize the risk of this happening Ingate recommends that access control setup in the Ingate product is kept as tight as possible. Only internal networks, trusted VPN tunnels or specific IP addresses should be allowed to configure the Ingate product. Additionally it is important to always log out before accessing other sites.

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

Known SIP-related problems

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

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]
Selecting transport '-' in Static Forwarding should mean that standard procedures are followed to determine transport but currently means same as selecting 'UDP'. [Tracking ID: 2043]
SIP accounts available with the Advanced SIP Routing module do not handle media correctly in cases where media passes the Ingate. [Tracking ID: 2334]

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]

« BACK