UpgradesRelease notice for Ingate Firewall® 4.4.1 and Ingate SIParator® 4.4.1
| Release name: |
Ingate Firewall® 4.4.1
Ingate SIParator® 4.4.1 |
The new version can be found here
Security improvements
* A Denial of Service attack against SSL/TLS has been fixed. A remote
attacker could perform a carefully crafted SSL/TLS handshake against
the SIP module, causing it to crash and restart. This is only possible
if TLS is enabled for the SIP module. The attack could also be
performed against the webserver if SSL/TLS was enabled. [Tracking ID:
2605]
* A vulnerability for XSS exploits has been fixed. The security cookie
used for accessing the GUI 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
administrator's 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]
New SIP functionality
* The SIParator can now be configured in a MEDIAtor mode. The MEDIAtor
mode enables a Microsoft Live Communication Server Access Proxy to
support media traversal for Federated and Remote users. The Ingate
SIParator must in this mode be connected in parallel with the LCS AP.
Currently this mode requires a specific license file to be loaded on
the SIParator. A software plug-in (windows service) needs to be loaded
on the LCS AP. Contact [1]sales@ingate.com if you would like to obtain
license and plug-in. [Tracking ID: 2274]
* SRTP transcoding using sdescriptions as key exchange method is now
supported. This enables the Ingate product to encrypt and decrypt
media using SRTP. [Tracking ID: 2169, 2230]
* Support for mutual TLS authentication for SIP (X.509 TLS client
certificates) has been added. [Tracking ID: 1882]
* Call Admission Control is now supported by the QoS module. The
administrator can reserve bandwidth for SIP media in the QoS module.
If the remaining part of the reserved bandwidth is less than what is
needed to initiate a new call, the call is not set up, and the
response "486 Busy here" is returned to the initiator. [Tracking ID:
1256]
* Sessions with media failures such as one-way media or an ended media
session can now be detected, logged and terminated by the SIP module.
[Tracking IDs: 1649, 1650]
* The performance of the SIP registrar has been improved. [Tracking ID:
294]
* Several improvements have been made to enable more effective log
search for SIP. SIP messages can now be filtered on:
* Call-ID
* Method
* IP address
* From header URI
* To header URI
Messages that are being resent are marked to indicate that. [Tracking
ID: 242, 328, 2405]
* The SIP module can now be configured to listen to other ports in
addition to the standard ports 5060 and 5061. [Tracking ID: 1539]
* Handling of media streams related to SIP servers that are implemented
as B2BUAs has been redesigned for the purpose of improved
interoperability. [Tracking ID: 2062, 2183, 2200, 2334, 2410]
* Messages using the tel URI scheme can be routed to the outbound proxy.
[Tracking ID: 1615]
* The SIP module may now be forced to lock on sender IP address for
media streams (based on the SIP signaling), ensuring that media
arrives from the same endpoint adress that media is sent to. [Tracking
ID: 1864]
* Intermediate CA certificates are now supported by the SIP module and
for HTTPS login to the GUI. [Tracking ID: 2604]
* The order of some SIP routing related features are now configurable.
The order of DNS override, Dial plan and the registrar can be
configured. [Tracking ID: 2435]
* RADIUS Accounting may now be done with the SIP module acting as a
B2BUA, which enforces SIP signaling not to by-pass the SIP module.
[Tracking ID: 2319]
* The P-Asserted-Identity Header (RFC 3325) is now supported. [Tracking
ID: 2337]
* When the SIP module connects to a SIP server using TLS, it requires
that the remote certificate is signed by a configured CA certificate.
A configurable option is introduced to allow for checking that the
domain specified in the certificate matches the domain that the SIP
module tries to connect to. [Tracking ID: 2451]
* The status of SIP servers being monitored is now displayed on the SIP
Status page in the GUI. [Tracking ID: 2430]
* Wildcard matching in the User Routing table is now supported. This
enables users authenticated with a RADIUS server to have incoming
calls forwarded to voicemail. [Tracking ID: 2256]
* SIP messages that lack Content-Type or Contact headers when such
headers should be included are now blocked and logged. [Tracking ID:
2181]
* The fact that the SDP of the response includes fewer media sessions
than the SDP of the INVITE is now logged. [Tracking ID: 2431]
* A restriction of DNS domain length in the SIP module to 86 characters
has been removed. The limit is now 255 characters which is the maximum
length of a domain name. [Tracking ID: 666]
* Multiple media sources are now supported if media destination expects
multiple streams. [Tracking ID: 2039]
* Support for the BENOTIFY method has been added. [Tracking ID: 1694]
* The SIP version number is now checked for all received requests and
responses. [Tracking ID: 1114]
* Absolute URIs are now supported in the Refer-To header. [Tracking ID:
1829]
* SSLv2 acceptance and usage by the SIP module is now configurable.
[Tracking ID: 1771, 1773]
* Multiple media sections in the SDP header using the same port are now
supported. [Tracking ID: 1862]
* An error control has been added to ensure that a voice mail server is
configured when being refered to in the User Routing table. [Tracking
ID: 2542]
* An error control has been added to avoid a configuration with the SIP
module enabled, Default Policy set to "local only" and no local SIP
domain entered. This configuration causes an error message to be shown
in the GUI as the combination prohibits all SIP traffic. [Tracking ID:
2561]
* An error control has been added to prohibit more than 10 media streams
per session. [Tracking ID: 2600]
* Usage of SIP registrations and SIP traversal licenses are now logged.
[Tracking ID: 2713]
Other new functionality
* A reminder that the preliminary configuration is changed but not
applied is now shown in the GUI as soon as a change is made to the
preliminary configuration. [Tracking ID: 369]
* The DHCP client can now be configured to obtain DNS, syslog and NTP
server information. [Tracking ID: 264, 265, 266]
* Active DHCP leases of the internal DHCP server are now displayed in
the GUI. [Tracking ID: 444]
* The builtin DHCP server can now be made to pass on info, like DNS
servers, from the DHCP client. [Tracking ID: 1034]
* The load log has been augmented with information on CPU load and
memory usage. [Tracking ID: 2420]
* IPsec tunnel information and status can now be obtained via an SNMP
query. [Tracking ID: 2233]
* SNMP traps are now sent when IPsec tunnel status changes. [Tracking
ID: 2107]
* The administrator may now configure certain conntrack timeouts.
* timeout for ICMP connections
* timeout for established TCP connections
* timeout for one-way UDP connections
* timeout for two-way UDP connections
These settings are found on the Advanced page under Basic
Configuration. [Tracking ID: 703]
* The software modules Advanced SIP Routing, VoIP Survival, Remote SIP
Connectivity and QoS can now be made available for limited time for
evaluation purposes. Contact [2]sales@ingate.com to obtain evaluation
licenses. [Tracking ID: 1467]
* The Dynamic FTP Management service may now be used for other server
ports than 21. [Tracking ID: 757]
* The name of the unit (defined by the administrator on the Basic
Configuration page) is now displayed on the LCD at run time (models
45/1450, 60/1600 and 90/1900). [Tracking ID: 2421]
* Firewall rules may now be enabled or disabled in the GUI. Each rule
may also be given a free text comment. [Tracking ID: 405, 766]
* Syslog messages can now be sent to multiple syslog servers. [Tracking
ID: 2707]
* A SIParator may now obtain dynamic IP addresses using DHCP or PPPoE.
[Tracking ID: 1125]
* A SIParator can now use all its interfaces when working in DMZ/LAN or
Standalone mode. [Tracking ID: 2549]
* It is from now on possible to downgrade to an older version even
though patches have been installed. [Tracking ID: 1240]
* A special log category for broadcast packets has been added. [Tracking
ID: 76]
* A limit for the time that can be spent on a log search has been
implemented on the Logview page. [Tracking ID: 1849]
* The default status for a new PPTP user is now "On" instead of "Off".
[Tracking ID: 2332]
* The new firewall types "Dynamic RTSP management" and "Dynamic TFTP
management" have been added on the Services page. [Tracking IDs: 2398,
2456]
* When a new row is created in the IPsec peers table new default values
are used for the Status, RADIUS and ISAKMP lifetime fields. The new
default values are On, Off and 3600 respectively. [Tracking ID: 2574]
* Web pages (in the Ingate GUI) are now positioned at the table in
question when adding rows to a table. The Logview page is positioned
at the top log row when a log search has been performed. [Tracking ID:
649, 1703]
Fixed SIP-related problems
* The source address used for SIP signaling is now more deterministic.
Responses are always sent back from the same interface/port as the
request was received on. All communication with a specific UA (within
a certain time frame) will use the same source address. For new
connections, the address specified in the Directly Connected Network
table and port 5060/5061 will be used. [Tracking ID: 1440]
* A bug that caused the SIP module not to add an Expires header when
configured to do so and not being the registrar has been fixed.
[Tracking ID: 1879]
* An issue where the SIP module absorbed resent 2xx responses after a
lost ACK message has been fixed. [Tracking ID: 2271]
* A parameter (fent) for internal usage is no longer added to the
Request-URI of SIP messages being sent from the firewall/SIParator.
[Tracking ID: 2340]
* An issue related to the SIP module not recognizing a CANCEL to an
existing transaction has been fixed. [Tracking ID: 2395]
* An issue with the Contact header being rewritten differently in
re-INVITE than in the original INVITE is now fixed. [Tracking ID:
2403]
* The option '-' in the DNS Override table has been removed. In
configurations where '-' is selected, this will be converted to 'UDP'.
[Tracking ID: 2043]
* An issue with host names in Via or Contact headers has been fixed.
[Tracking ID: 1852]
* An issue with failed TLS connection attempts causing the SIP module to
restart has been fixed. [Tracking ID: 2525]
* An issue with SIP clients behind a far-end NAT trying to make a call
using an XF/Register account has been fixed. [Tracking ID: 2568]
* An issue with the From Domain field in the SIP outbound proxy table
has been fixed. [Tracking ID: 2569]
* Various issues with the Vonage user account have been fixed. [Tracking
ID: 2594, 2621, 2625]
* An issue with bodies containing a NULL '\0' byte has been fixed.
[Tracking ID: 1163]
* A problem causing one-way media in a far-end NAT scenario after a HOLD
has been fixed. [Tracking ID: 2426]
* An issue where traversal licenses are consumed even though media does
not traverse the Ingate unit has been fixed. [Tracking ID: 2725]
Other fixed problems
* An issue that required that the firewall was rebooted to properly
remove an IPsec CA has been fixed. IPSec CAs can now be removed
without rebooting. [Tracking ID: 1178]
* An issue with the DynDNS client not being able to update the
configured account has been fixed. [Tracking ID: 2638]
* Packets belonging to a port forwarding relay were always put into the
default QoS class, even if the matched a specific class. This has now
been fixed. [Tracking ID: 585]
* The DHCP server now uses persistent storage for the lease file. This
increases the possibility of clients retaining their IP address after
a reboot of the Ingate unit. This applies to models with hard disk.
[Tracking ID: 1422]
* A VPN issue related to using many private addresses in e.g. IPsec
tunneled networks limiting the number of possible IPsec peers has been
fixed. [Tracking ID: 2708]
* In some cases IPsec would not work when PPPoE and/or PPTP was also
enabled. This could prevent IPsec tunnels from being negotiated. This
has now been fixed. [Tracking ID: 2428]
* You could get a traceback when viewing the IPsec Status page in the
GUI if all peers were located on an interface that use dynamic IP and
that interface had not yet acquired an IP address. This has been
fixed. [Tracking ID: 2433]
* When the PPTP server was enabled, TCP port 1723 would be reserved for
it on all interface. This has been fixed so that the port is only
bound on the configured PPTP server IP address. [Tracking ID: 2464]
* If the same X.509 certificate was used for both HTTPS and IPsec RADIUS
authentication, configuration of the product via HTTPS would not work.
This is now fixed. [Tracking ID: 2529]
* An issue with load log overflow has been fixed. [Tracking ID: 2543]
Removed functionality
* The IPsec implementation no longer supports Diffie-Hellman group 1
(MODP768).
Known problems
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 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]
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. mailto:sales@ingate.com
2. mailto:sales@ingate.com
|
