Illumio Core What's New and Release Notes 22.5

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) might also ask for a maintenance token for CLI commands. CLI commands other than suspend will succeed if a valid maintenance token is provided. However, the suspend command 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 source (E-101229)

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

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

A firewall policy with a custom iptables rule might get dumped in 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. A workaround is to order the custom iptables rules the same way that the Linux kernel dumps them in.

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

Workaround: not available.

VEN 22.2.30 failure to restart at boot was holding up critical processes (E-100416)

In some cases, when Solaris cluster nodes were restarted due to a storage issue with the underlying hardware devices, Illumio Core processes appeared to block the rest of the node processes from starting. The reboot did not work. Workaround: Place the VEN into suspend mode and then reboot the hardware again,

Compatibility report (problem 2) - nftables /RHEL8 (E-91481)

The customer installs the missing packages and reruns the compatibility report from the Web Console but is unable to run the report.

Workaround: Either restart the VEN (sudo /opt/illumio_ven/illumio-ven-ctl restart) or rerun the script that manually generates the report (sudo /opt/illumio_ven/bin/.agent_qualify.sh).

Works as designed.

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

A process-based rule was defined but was shown as "no rule" in Explorer. The workaround is to not specify the service name in the process-based rules.

On CentOS 8, VEN can't load the FTP and 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.

No workaround is available.

[CentOS8] 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.