Check Point R75.45 released

Last week, Check Point released the first major update to the Gaia-introducing R75.40 version. The release of R75.45  mainly brings enhancements and fixes for the new Gaia platform:
R75.45 Release Notes
R75.45 Resolved Issues
R75.45 Known Limitations

R75.45 includes this R75.40 hotfix.
Among the new features provided, support for 6in4 tunneling, policy-based routing appear to be the most intriguing (at least to me).
The long list of fixes addresses important issues such as long policy install time, kernel memory leaks or IPS not exiting bypass mode again after returning to normal CPU utilization.
Only direct upgrades from R75.40 are supported, no earlier versions.

I haven’t tried this new release yet, but given the list of fixes and potential first prematureness of the still young Gaia platform, I’ll check it out rather sooner than later.

Running Check Point ClusterXL member interfaces on different subnets than the virtual interfaces

We have a couple of 802.11q VLAN interfaces on our Check Point Firewalls for a number of small public DMZ networks, providing full layer 2 isolation for usually only one or two related servers in those networks. Using a /29 subnet for each VLAN means minus broadcast and network address, we can assign 6 (public) IP addresses in those networks. We also need an IP for the virtual ClusterXL interface to be used as a gateway by the servers. Up until recently, we also used 2 more IPs of each subnet for the members VLAN interfaces, so they can communicate via Check Points Cluster Control Protocol or CCP. This left us with merely 3 public IPv4 addresses per /29 subnet for actual servers inside those VLANs.
Wasting IPs like this on interfaces transparent for your actual services is not really practical in times of scarce IPv4 address space though. So what we did was getting rid of using IP addresses of the public subnet for the VLAN interfaces of each cluster member during our upgrade to R75.40 and Gaia on new systems.  This configuration is fully supported (actually since long ago) as per ClusterXL Admin Guide:

Configuring Cluster Addresses on Different Subnets
Only one routable IP address is required in a ClusterXL cluster, for the virtual cluster interface that faces the Internet. All cluster member physical IP addresses can be non-routable.Configuring different subnets for the cluster IP addresses and the member addresses is useful in order to:
– Enable a multi-machine cluster to replace a single-machine gateway in a pre-configured network, without the need to allocate new addresses to the cluster members.
– Allow organizations to use only one routable address for the ClusterXL Gateway Cluster. This saves routable addresses.

Continue reading

July 2012 ESXi and vCenter updates

Yesterday and today VMware released an unusual Update for vCenter (and VCSA) titled “5.0 Update 1a” as well as couple regular bug fixes and security patches for ESXi 5 hosts.
Update Aug 20 2012: VMware recently released vCenter 5.0 Update 1b, which replaces 1a due to some issues with Oracle databases. Apart from that, there seem no other new fixes that weren’t present in 1a already. So if you’re on 1a already with a non-oracle database, there is no real need to upgrade to 1b.

VMware vCenter Server 5.0 Update 1a – a as in accident? Update 1b – b as in bummer

Grab the official release notes here:
https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u1a_rel_notes.html
https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u1b_rel_notes.html

It’s the first time VMware officially released such an official out-of-band update for vCenter with a small set of fixes and enhancements, I was quite surprised too. As expected of such a minor update, it doesn’t provide any significant new features. Adding support for using vCenter with some very specific Oracle version, or switching from DB2 to PostgreSQL for the VCSA? Ok, next please.
Much more interesting and probably the reason why they made this move in the first place, are a couple of bugs this update fixes. One of them is the infamous Storage vMotion dvSwitch issue for which until now the workaround meant some manual labor or running scripts after each Storage vMotion (including SDRS).
The other fixes don’t seem particulary interesting, but I’m glad VMware finally fixed the Storage vMotion issue.

Oh joy, installing another complete vSphere Client of a whooping 350MB for just a few vCenter-side fixes! Not speaking of the actual vCenter “update” process which is essentially a whole reinstall of the new version every time.
Will VMware ever offer a proper patching method for this? Praying seems to be the only hope left.

New set of ESXi 5 patches – (a as in) adhering to a patchday policy?

Note: You do not need the above mentioned 5.0 U1a vCenter for these ESXi patches.
Less unusual appears to be the release of a series of new ESXi 5 patches for both, security and bug fixing reasons. It’s been almost exactly a month (hello patchday) since the last security patch, which was a really important one, but luckily these two new security patches for a libxml 3rd party component and a stability issue in the VMware Tools don’t seem that critical to require your immediate attention (rated important by VMware).
I will highlight a few fixes and points from the patch notes I personally deem important:

Security patches:
VMware ESXi 5.0, Patch ESXi500-201207101-SG: Updates esx-base
>This patch updates the esx-base VIB to incorporate an important libxml2 security update.
VMware ESXi 5.0, Patch ESXi500-201207102-SG: Updates tools-light
   >This patch updates the tools-light VIB to resolve a stability issue in VMware Tools.
The full advisory that came with the first patch is available here: http://www.vmware.com/security/advisories/VMSA-2012-0012.html

Other bug fixing patches:
VMware ESXi 5.0, Patch ESXi500-201207401-BG: Updates esx-base
   >PR 831801: The default value of FIN_WAIT_2 timer was erroneosly set to TCPTV_KEEPINTVL * TCP_KEEPCNT = 75* 0x400. This discrepancy results in the socket at FIN_WAIT_2 state to exist for a much longer time and if multiple such sockets are accumulated, they might impact new socket creation.
    >PR 835040: An ESXi host might not respond or get disconnected due to the esx.conf file being locked. This might happen because when updating the ESX configuration (esx.conf configuration file) a lock file /etc/vmware/esx.conf.LOCK is created and it is linked to the process attempting to lock the file. If the link (known as a symlink) is not valid then it prevents the esx.conf from being unlocked.
    >PR 838922: An ESXi host might not restart UDP logging after a temporary interruption that might be caused by target server reboot or network UDP package being lost.
    >PR 838946: During the installation of Windows Server 2012 or Windows 8 64-bits virtual machine, the virtual machine displays a black screen with a loading icon and stops responding during the start-up process.
    >PR 848382: An ESXi host might become unresponsive with a purple diagnostic screen (PSOD) that displays messages similar to the following if any changes are made to BufferCache.HardMaxDirty.
    >PR 866810: On Dvportgroup, a promiscuous port might not work in promiscuous mode if the DVMirror sessions are reconfigured.
    >PR 855177: If you configure the loghost of syslogd incorrectly via esxcli or edit the /etc/vmsyslog.conf file directly followed by syslog reload, syslogd might terminate abruptly. You might notice the following symptoms with this issue:
VMware ESXi 5.0, Patch ESXi500-201207402-BG: Updates tools-light
 >PR 751508: Windows Vista and later versions of Windows do not recommend allowing services to be interactive; however, VMware Tools Service is installed as an interactive service.
VMware ESXi 5.0, Patch ESXi500-201207403-BG: Updates scsi-mptsas
VMware ESXi 5.0, Patch ESXi500-201207405-BG: Updates misc-drivers
VMware ESXi 5.0, Patch ESXi500-201207406-BG: Updates net-e1000
Just your usual driver updates with no detailed info of the last 3 here.

You can install VMware Tools updates without maintenance mode or reboots btw. since it effectively only overwrites the Tools ISO images in /vmimages/tools-isoimages. Note that ESX(i)4 patches are also pending to be released. As per VMware support for a case we have open, I also expect a real vCenter and ESXi  5.0U2 to be released soon-ish. Maybe around VMworld 2012 and with the potential release of vSphere 5.1?

New ESXi security patch VMSA-2012-0011 released on June 14th

Today VMware released a new security update for ESX(i), from version 3.5 to 5.0, as well as other hosted virtualization platforms like Workstation/Player, and updated several older security advisories.
If you’re not signed up on the VMware security mailing list, you should do so at http://lists.vmware.com/mailman/listinfo/security-announce in order to get all the latest information on updates and advisories.

The new advisory is available here. The new patch VMware ESXi 5.0, Patch ESXi500-201206401-SG: Updates esx-base fixes two critical security issues:

VMware Host Checkpoint File Memory Corruption
Certain input data is not properly validated when loading checkpoint files. This might allow an attacker with the ability to load a specially crafted checkpoint file to execute arbitrary code on the host.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2012-3288 to this issue.
The following workarounds and mitigating controls might be available to remove the potential for exploiting the issue and to reduce the exposure that the issue poses.

Workaround: None identified.

Mitigation: Do not import virtual machines from untrusted sources.

VMware Virtual Machine Remote Device Denial of Service
A device (for example CD-ROM or keyboard) that is available to a virtual machine while physically connected to a system that does not run the virtual machine is referred to as a remote device. Traffic coming from remote virtual devices is incorrectly handled. This might allow an attacker who is capable of manipulating the traffic from a remote virtual device to crash the virtual machine.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2012-3289 to this issue.
The following workarounds and mitigating controls might be available to remove the potential for exploiting the issue and to reduce the exposure that the issue poses.

Workaround: None identified.

Mitigation:
Users need administrative privileges on the virtual machine in order to attach remote devices.
Do not attach untrusted remote devices to a virtual machine.

This is already the 2nd critical security-related patch after VMware ESXi 5.0, Patch ESXi500-201205401-SG which was released a month ago following a leak of VMware source code which raised some public attention. I really hope we’re done with this soon.

Here are the updated advisories based on older patches:
– http://www.vmware.com/security/advisories/VMSA-2012-0005.html

– http://www.vmware.com/security/advisories/VMSA-2012-0006.html

– http://www.vmware.com/security/advisories/VMSA-2012-0007.html

– http://www.vmware.com/security/advisories/VMSA-2012-0009.html

The actual changes of these advisories can be found in section 6. Change log. There doesn’t seem to be any really important information though.

And last but not least, if you’re running ESX on HP, while you’re installing this you might as well update your HP-Extensions while you’re at it.