Illumio Core What's New and Release Notes 23.2

RHEL5 and Solaris VENs fail to apply policy containing virtual services with FQDNs (E-110016) This failure occurs if a RHEL5 or Solaris VEN is associated with a rule that allows communication to a virtual service with FQDNs defined or the virtual service's labels. Workaround: none currently.

VEN IPSec policy tampering detection not supported with RHEL5 (E-110015)

In Illumio Core 23.2.20-GA, VEN IPSec policy tampering detection and recovery doesn't work with VENs running on RHEL5 workloads. On all other supported Linux distributions, tampering detection works as designed.

Upgrade for AIX 6.x and 7.x VEN triggered from PCE failed (E-109282)

VEN upgrade for AIX 6.x and 7.x failed when upgrading from the PCE.

Workaround: None.

VEN should not ask for maintenance token on unsupported OSes for tampering protection (E-101470)

When VEN tampering protection is enabled, Solaris and macOS workloads (where VEN tampering protection is not yet supported) also ask for a maintenance token for CLI commands. CLI commands other than suspend will succeed if a valid maintenance token is provided. Suspend does not work even if a valid token is provided.

There is no workaround. If you will enable the VEN tampering protection feature, do not upgrade Solaris or macOS workloads to 22.5.10.

SecureConnect only logs the "E" on the provider (E-101229)

Works as designed. There is no way to tell whether SecureConnect is in the egress path.

Workload keeps emitting agent.tamper error events after configured custom iptables rule (E-101029)

A firewall policy with a custom iptables rule might get vvin a different format than the one it was in when ingested. When using -key value arguments to iptables such as --k2 v2 --k1 v1, it does not matter which order you add them in for correctness in the system. However, if the Linux kernel dumps the arguments back to the VEN in a different order, the VEN falsely considers it a tamper. For example, if the kernel always dumps "-k1 v1 --k2 v2" even if you give "-k2 v2 --k1 v1", then the VEN will think somebody has changed the firewall.

Workaround: Order the custom iptables rules the same way that the Linux kernel dumps them in.

Windows 11 shows as Windows 10 on the workload/VEN page (E-100844)

Workaround: None

Process-based rule not showing properly in Explorer (E-89749)

A process-based rule was defined but was shown as "no rule" in Explorer.

Workaround: Do not specify the service name in the process-based rules.

On CentOS 8, VEN can't load the FTP or TFTP modules (E-85127)

On CentOS 8, the VEN can't load the nf_conntrack_ftp and nf_conntrack_tftp modules, which blocked the workload from uploading and managing files. Due to this issue, customers can't upgrade the VEN on CentOS 8 workloads.

Workaround: None

[CentOS 8] Custom IPtables rule does not work with -j REDIRECT (E-80818)

After creating a custom rule on the PCE with -j REDIRECT in the nat table, the CentOS 8 VEN enters an error state because the VEN could not correctly handle the -j REDIRECT part of the rule. The custom rule performs a NAT operation that requires a different chain type therefore, nftables does not allow the VEN to perform the redirect in our chains.

Workaround: Remove the custom Iptables rule and restart the VEN. This brings the VEN back to a healthy state.

Established connections are not removed when the VEN is restarted (E-63072)

After the VEN is paired and restarts using the Illumio-ven-ctl options, it dumps suspicious log entries into vtap.log twice per minute. The log type is INFO and they appear to be caused by an error related to the restart of the VEN. This issue is observed in the global zone and the exclusive IP zone.

Workaround: Not available; however, this issue has no major impact except for vtap.log receiving these log entries.