TMS zl Module Release Notes ST.1.2.100916
Table Of Contents
- Release Notes: Version ST.1.2.100916 Software for the HP ProCurve Threat Management Services zl Module
- Contents
- Software Management
- Download Documentation from the Web
- Software Updates
- Special Considerations Prior to Updating
- Clarifications
- Enhancements
- Enhancements in ST.1.2.100916
- ST.1.1.100430
- ST.1.1.100226
- Command Line Interface (CLI) control of VPN functionality
- RADIUS authentication for management logins
- RADIUS authentication for L2TP users
- Renaming zones
- 256 VLANs now supported, increased from 19 VLANs
- Enhanced sort and filter capabilities for displaying log files
- Improved SNMP Monitoring for network traffic and key system resources
- Software Fixes in Releases ST.1.0.090213 - ST.1.2.100916
- Known Issues
43
Known Issues
Release ST.1.2.100916
■ PR_60478 — A VPN log message incorrectly shows up in monitor mode.
Example:
date: 2010-08-03 time: 09:55:05 msg: VPN global configuration
updated adminname: root severity: warning id: vpn_ipseccommon
src: 0.0.0.0 srcport: 0 dst: 0.0.0.0 dstport: 0 proto: 0 subfamid:
ipseccmnconfigurationinfo mtype: ipsecv4 mid: 6508
High Availability
■ PR_56632 — There is a difference in the output of the command show zones depending on
whether it was executed on the Master or Participant. When a network connection goes
through the GRE tunnel, TMS will treat the session as 2 sessions, one of which is the GRE
tunnel traffic. On the TMS with one GRE tunnel endpoint, the GRE tunnel will be considered
as the traffic directed to the TMS device. Thus it will not be synchronized to the participant.
As a result, there will be a difference in output depending on whether show zones is executed
on the participant or the master. This is true of any traffic in which the TMS Master is the
endpoint of the traffic (not synchronized with the participant) and is not the firewall in the
middle between two other endpoints (synchronized with the participant).
■ PR_61199 — Care must be taken when changing the Master's HA IP Address / Subnet Mask
when compared to the Participant's HA IP Address / Subnet Mask. If the Master HA new
IP/mask can reach the Participant's HA original IP/Mask AND the Participant HA original
IP/mask can NOT reach the Master's new HA IP/Mask , some period of time will go by before
either can be reached over the network.
An example:
The administrator logs into the management IP address of the Master. This management IP
address is synchronized between the Participant and Master. The administrator changes the HA
IP address of the master:
Original Master IP/mask: 192.168.251.5/30
==> gets changed to ==> new IP/mask: 192.168.251.1/24
Then the administrator reboots the Master. The Participant detects that the Master has disap-
peared and assumes the Master role and takes on the Management IP address. The administrator
logs into the new Master in order to change its HA IP address:
Original Participant IP/mask (now Master): 192.168.251.6/30
==> gets changed to ==> new IP/mask: 192.168.251.2/24