Last Modified: Nov 07, 2022
Affected Product:
See more info
BIG-IP ASM
Known Affected Versions:
11.4.1, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5
Fixed In:
12.0.0, 11.6.0 HF6, 11.5.3 HF2
Opened: Apr 29, 2015
Severity: 3-Major
After changing the Application Language for a Security Policy and pushing the changes over a manual sync device group, the device group's status immediately returns to "Changes Pending". Additionally calls through the REST interface erroneously allowed a client to change the language for a policy where it was already set.
1) The change to encoding is not seen if looking at the result in tmsh. 2) In a manual sync group, after the change has been pushed to its peers, the change is correctly written to the MCP configuration when it is loaded. This appears as a new pending change from the peer device, and the device group appears out of sync again.
A Security Policy was set to "Auto-Detect" the Application Language, and then set to a specific encoding. Or an application language is already set and is changed through the REST API. Issue is seen most prominently in a device group when ASM sync is enabled on a Manual Sync Failover Group
Push another sync from the peer to the original device.
Changes to Language encoding are now validated and propagated correctly.
