TMS zl Module Release Notes ST.1.1.100430

Known Issues

Release ST.1.1.100430

Firewall

■ PR_42671 — A log message is generated for a TCP sequence number but shows ICMP as

the protocol.

time="2009-07-08 19:39:33" severity=warning pri=5

fw=ProCurve-TMS-zl-Module id=fw_access_control ruleid=10 msg="FW: tcp

sequence number translation failed, packets dropped" srczone=INTERNAL

src=192.168.80.2 dstzone=INTERNAL dst=192.168.70.2 proto=ICMP rcvd=0

rcvdsc=0 sent=36 sentsc=0 srcnatport=0 destnatport=0 destnati-

paddr=0.0.0.0 subfamid=accessdeny mtype=access_control mid=617 srcna-

tipaddr=0.0.0.0

■ PR_53000 — TMS does not prevent a manager from adding the same access-policy multiple

times for the same zones.

■ PR_53666 — When using TMS Access Policies that specify the TCP MSS, the user can

specify a TCP MSS lower than 88. However, the actual minimum TCP MSS used is 88,

regardless if a value lower than 88 is entered.

■ PR_54234 — The TMS allows a local or RADIUS user to be authenticated more than once

on different hosts, which can cause access policies based upon groups to be left open.

When logging in with the same user on Host1 and Host2, the policies for the group applied

correctly. Then, when logging out from Host1, the policies for the group stop working. Then,

when logging out from Host2 the policies remained working.

Steps:

1. Create a user group, such as "Group1"

2. Firewall/XAUTH add user "User1" to Group1

3. Add access policies for Group1

4. Login with User1 on two different hosts, Host1 and Host2

5. Verify that the access policies for Group1 are applied

6. User1 logs out from Host1

7. Verified the policies don't apply after logout

8. User 1 logs out from Host2

The policies remain working after User1 logs out from host2

■ PR_55370 — There have been extremely rare occurrences where, after a reboot, a VLAN

configured for TMS results in it being 'untagged' rather than 'tagged' in the switch

configuration. This could be immediately seen if DHCP is enabled, as DHCP traffic is not