OpenVPN client now available on Apple iOS!

Great news for many pfSense users today, as OpenVPN Technologies in collaboration with Apple have released an OpenVPN client for iOS.

Within hours of its release, Jim Pingle updated our OpenVPN Client Export package’s inline export option to be compatible with iOS (and retaining its Android compatibility). The inline export is available for 2.0.x and 2.1 versions. Upgrade your package under System>Packages to the latest version and use the inline export option, which can be imported into the iOS client via iTunes amongst other methods. I had my iPhone connected to OpenVPN within 5 minutes, it’s a quick, easy process.

Our thanks to OpenVPN Technologies and Apple for making this happen!

Cool Tool – Video: Storage Explorer (Free Utility)

Storage Explorer assesses storage performance and capacity views across datastores and VMs that helps VM admins to get better visibility of their storage environment. Storage Explorer, a utility within the vOPS Server Explorer freeware suite, displays storage performance and capacity views across datastores and VMs with the following features:
  • Identify critical VM issues such as low available disk space, high latency and throughput.
  • Allows user to sort on any metric to find specific issues relevant to them.
  • Identify critical datastore issues such as overcommitment, low capacity, high latency, VMFS version mismatch.
vOPS Server Explorer

Facebook Messenger offers free calling for iPhone users

Facebook's Messenger app for iPhone has undergone a number of facelifts in the past year or so, but a new feature was added today that may completely change the way you use it: free calling over a data connection. The Verge reports that the new feature began rolling out to users today, and doesn't require you to update the app itself.

The new calling option is a rather streamlined affair: Simply open up a conversation with one of your Facebook friends from the app's menu, select the "i" icon in the corner and then hit the "Free Call" button. The recipient will get an alert window letting them know that you are calling.

The calls won't count against your phone's minutes, but it will eat up some mobile data if you're not connected to WiFi, so while the call may be free as far as Facebook is concerned, it's important to keep an eye on your data usage. The new feature is currently only available to US-based Facebook users, and no word on an international release is available at this time.



EMC ProSphere – Try, Learn & Download for Free

Social Share Toolbar

EMC ProSphere 1.7Following up on my recent post here which provides links to download your own free copy of the EMC VNX or Celerra Virtual Storage Appliance (VSA), here is another EMC product to download and try for free in your own lab environment.   EMC ProSphere is a Cloud storage management solution that monitors and analyzes storage services in a virtualization infrastructure.

Through using ProSphere you can gain a detailed insight into the following areas of your storage:

  • Capacity: Easily view capacity is being consumed on your storage.
  • Issue Detection: Identify conditions that require your attention.
  • Performance: View the performance trends of your storage.

EMC ProSphere Download

Sound Good? Where can you download my own free copy of  EMC ProSphere?

Before we move on to the download links I should point out that the only catch with this free downloadable version of EMC ProSphere is that it doesn’t come with any “Official” EMC support, although there is a healthy ProSphere community that can be found at this EMC ECN Community site where you’ll usually find someone who can assist you with any questions.

Download Link:  The latest EMC ProSphere download can always be found at the “EMC ProSphere: Play-Learn-Try” page here.

EMC ProSphere Free Download

Installing & Configuring EMC ProSphere

So once you’ve downloaded the relevant ProSphere files?  Well, the good news is that there are a couple of easy to follow  guides that will have you up and running with EMC ProSphere in no time.

Other Useful Links

  • Check out these other useful ProSphere related links:
  • Virtual Geek – EMC ProSphere 1.5 – Play, Learn,Try!
  • Official EMC ProSphere site

VN:F [1.9.22_1171]

Rating: 0.0/5 (0 votes cast)

VMware vCenter Server 5.x Install on W2K12 Fix: The following feature couldn’t be installed: .NET Framework 3.5

Social Share Toolbar

A pre-requisite of installing VMware vCenter Server 5.x is for the Microsoft .NET Framework (3.5). When recently installing VMware vCenter Server v5.1 on a new Microsoft Windows Server 2012 VM in my vSphere lab I had forgotten to install this pre-requisite and was presented with the following information box: “The following feature couldn’t be installed: .NET Framework 3.5 (includes .NET 2.0 and 3.0)”.

VMware vCenter .NET Framework 2.5 install

How to Resolve

The message given when installing VMware vCenter Server on a Windows Server 2012 (W2K12) OS isn’t to be unexpected as Microsoft also documents that this is an issue that can occur on W2K12 when the .NET Framework 3.5 tries to be installed from an installation wizard, see here for more details on what causes the problem.  Note:  I recommend that you install any pre-requisites ahead of starting the vCenter Server install.

I had tried installing it via the “Windows Server roles and features” GUI method although this unfortunately just didn’t take for some reason.

To get around this problem I simply performed a command-line installation, which worked successfully for me.

Note:  The “Source”  shown in the command below should be changed to the location of the Windows Server 2012  installation disc. As you can see my source was: d:sources

dism /online /enable-feature /featurename:NetFX3 /all /Source:d:sourcessxs /LimitAccess

VMware vSphere vCenter install .NET 3.5

VMware vCenter Server Install NET error

Useful Link:

Microsoft Support:  “Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012”

VN:F [1.9.22_1171]

Rating: 4.0/5 (1 vote cast)

VMware vCenter Server 5.x Install on W2K12 Fix: The following feature couldn’t be installed: .NET Framework 3.5, 4.0 out of 5 based on 1 rating

EMC Storage Analytics is now GA!

At VMworld 2012 in Oct we showed something we were working on called “EMC Storage Analytics” aka “ESA”.   This used to be called Storage Analytics Suite – but that could be confused with other stuff.

What is it?

  1. It provides rich analytics for everything from the VM down to the most basic storage element.
  2. VNX connectors for vCenter Operations.   These are more than just basic API goop – they contain the relationships between collected attributes – which is critical for the “analytics” part.
  3. A version of vCenter Operations targeted at the storage administrator developed by VMware and OEMed by EMC.

A neato background story: this project came from the team that runs the VNX business walking through the VMworld 2011 lab, where the VNX that was supporting big chunks was instrumented via vCOPS and a home-brewed connector.   They immediately saw the value and wanted to move to productize it.

Here’s the customer view – in Chad’s World Episode 16!

image

HINT: A ridonkulous video coming up soon :-)

A couple comments to help understand – after the break…

VMware vSphere Blog: Network Troubleshooting Using ESXCLI 5.1

When it comes to network troubleshooting in an ESXi host, there are various types of information that can be useful to a vSphere administrator such as basic information like a virtual machine’s IP Addresses, MAC Addresses, Uplink ports, Port ID, etc. to the network statistics view in the [r]esxtop command-line utility. However, all of this useful information today is spread across multiple tools and this can be challenging for a vSphere administrator when needing to quickly retrieve this data while troubleshooting an issue.

With the release of vSphere 5.1, the network namespace in ESXCLI has been enhanced to include a comprehensive set network statistics at various points in the virtual network. This enables a vSphere administrator to easily get an overall status of the vSphere network as well as provide the ability to drill down further for troubleshooting.

In ESXCLI 5.1, you can now retrieve additional network statistics at a physical NIC (vmnic), on a per VLAN (portgroup) which needs to be configured and on a per VM port (vNIC). Here is a quick diagram to help you visualize where you can retrieve network statistics:

Note: Network statistics are available on a per host basis and this is applicable to both a Distributed Virtual Switch as well as a regular Virtual Standard Switch.

Let’s start off by taking a looking at the physical NIC of the ESXi host or vmnic as it is commonly referred to. You will need to identify the vmnic you are interested in and you can list all available vmnics on your ESXi host by running the following command:

esxcli network nic list

We can see from the screenshot above that we have four vmnics (0-3) on this host and let’s say we are interesting in getting statistics for vmnic2. We can do so by using the new “stats” namespace by running the following command and specifying the vmnic of our choice:

esxcli network nic stats get -n vmnic2

You will get some basic stats such as packet transmit/received and bytes transmit/received but in addition you will also get new stats pertaining to length, over, CRC, frame, FIFO and missed transmit/received.

Next, let’s take a look at statistics on a per portgroup or more specifically on a per VLAN basis using the new “vlan” namespace. By default VLAN statistics is disabled and you will need to enable this on each vmnic that you wish to pull statistics from. We will go ahead and enable VLAN stats collection on vmnic2 by running the following command (replace with the vmnic of choice):

esxcli network nic vlan stats set -e true -n vmnic2

and then run the following command to retrieve all VLAN stats for that given vmnic interface (replace with the vmnic of choice):

esxcli network nic vlan stats get -n vmnic2

For VLAN statistics, you will see packets received and sent for each VLAN ID for that given vmnic interface.

Finally, let’s take a look at the network details and statistics for our virtual machines. There is new “vm” namespace that allows you to easily list all virtual machines including the number of ports (configured vNIC) as well as the networks they are connected to. You will need to run the following command:

esxcli network vm list

Included in the output is also the VM’s World ID which can be thought of as the process ID for that given VM. Next, we will take this World ID and run the following command to get more details about the VM’s network configuration which includes the Port ID, VSS/VDS, Portgroup, DVPort Group, MAC Address, IP Address, vmnic Uplink, Uplink ID and any active filters (replace with the World ID of choice):

esxcli network vm port list -w 10930

As you can see, just from a single command, you can now easily retrieve all the networking details about your VM where-as before this would require the use of multiple tools to get the same info versus having a single location for quick ease of access.

Note: The IP Address information is made available by ARP packet inspection and this is disabled by default. If you wish to see the IP Address information, you will need to enable this by running the following command: esxcli system settings advanced set -o /Net/GuestIPHack -i 1

From here, we can drill down one additional level and retrieve network statistics on a per VM port (vNIC) level which is available through the new “port” namespace. You will need to identify the Port ID from the last step and then run the following command (replace with the Port ID of choice):

esxcli network port stats get -p 50331660

Hopefully with these new enhancements to ESXCLI, gathering networking details and statistics for your virtual machines will be much easier to perform as well as easier to consume without having to use multiple tools. To get more details, you can refer to the ESXCLI documentation.

Note: All these statistics are available via SNMP and can be monitored remotely. For details on configuring SNMP traps for your ESXi host, please refer to this article.

Get notification of new blog postings and more by following VMware Automation on Twitter:  @VMWAutomation

VMware ESXi: Angriffe auf den Hypervisor

Mit der Software CANape lässt sich der Netzwerkverkehr zwischen VMwares Hypervisor ESXi und den Clients nicht nur überwachen, sondern auch manipulieren. Für die Kommunikation nutzt VMwares Verwaltungssoftware beispielsweise HTTPS aber auch binäre Protokolle.

Auf dem 29. Chaos Communication Congress (29C3) hat Sicherheitsexperte James Forshaw die Software CANape vorgestellt, mit der sich auch binäre Protokolle im Netz überwachen lassen. Der Entwickler demonstrierte am Beispiel des ESXi-Hypervisors von VMware, wie der Datenverkehr zwischen Hypervisor und Client nicht nur abgegriffen und aufgezeichnet werden kann, sondern auch so manipuliert werden kann, dass er beispielsweise Tastatureingaben an Clients versendet. Mit der CANape deckte er zahlreiche Fehler auf, die VMware reparieren will oder bereits korrigiert hat.

CANape klinkt sich als Socks-Proxy in die Kommunikation zwischen Clients und dem ESXi-Hypervisor ein. Mit zahlreichen Plugins kann die Software die verschiedenen Protokolle interpretieren, die VMwares Verwaltungssoftware für die Kommunikation mit dem Hypervisor nutzt, darunter VMwares Network-File-Copy- (NFC) oder RD-Protokoll. Anders als Wireshark beschränkt sich CANape auf weniger gängige oder kaum dokumentierte Protokolle. Mit CANape lässt sich der Datenverkehr in virtuellen Umgebungen von Citrix auslesen.

Datenverkehr entschlüsselt

VMwares ESXi nutzt seine eigenen CA-Zertifikate für das SSL-Protokoll, die es auch weitergibt. Zwar können eigene Zertifikate genutzt werden, dann stürzt der Client hin und wieder ab. ESXi aber gültige und funktionierende Zertifikate mitzugeben, sei jedoch mit wenig Aufwand möglich, sagte Forshaw. Zwar weise der Hypervisor einmalig darauf hin, dass es sich möglicherweise um ein gefälschtes Zertifikat handelt, die Meldung lässt sich mit einem Klick aber übergehen. Nach dem Import des Zertifikats konnte Forshaw den mit SSL verschlüsselten Datenverkehr offenlegen.

Danach ließ sich schnell herausfinden, wie Tastatureingaben an virtuelle Maschinen übergeben werden können. Forshaw las dazu über VNC abgegebene Pakete an den Hypervisor aus und entdeckte die übermittelten Tastaturbefehle. Er zeichnete sie auf und sandte sie später erneut an ESXi, startete beispielsweise eine Linux-Distribution am Bootprompt einer virtuellen Maschine.

Fuzzing und Speicherüberläufe

Außerdem demonstrierte Forshaw Fuzzing-Angriffe und das Versenden von manipulierten Dateien über VMwares NFC-Protokoll, die unter anderem einen Absturz des Hypervisors zur Folge hatten. Insgesamt habe er mit CANape fünf Speicherüberläufe in den Protokollen entdeckt. Außerdem konnte er zwei unbehandelte Ausnahmen, zwei uninitialisierte Zeiger und eine Schwachstelle bei freigegebenem Speicher nachweisen. Er habe seine Befunde bereits an VMware geschickt.

CANape ist modular aufgebaut, wurde in .NET umgesetzt und bietet Schnittstellen zu Ironpython und Ironruby oder C#. Das besondere an CANape sei seine Benutzerschnittstelle, sagte Forshaw. Bestimmte Angriffsszenarien lassen sich per Drag-and-Drop schnell zusammenstellen und konfigurieren. Gegenwärtig ist Version 1.1 von CANape vom Frühjahr 2012 kostenlos erhältlich. In wenigen Tagen soll eine neue Version von der Webseite des Sicherheitsunternehmens zum Download bereitstehen.

A possible explanation for the iOS New Year’s Do Not Disturb bug

If you've been living under a blissfully silent rock for the last couple of days, it may have escaped your notice that an annoying bug in iOS means scheduled Do Not Disturb periods don't automatically end. Apple's response was a rather weak KB article that amounts to a shrug and a claim that the problem will "resume normal functionality after January 7, 2013."

[UPDATE: as pointed out by Liam Gladdy in a comment written an embarrassingly short period of time after this story going live, there's something wrong with the reasoning below. The period of January 1st-6th is actually the first ISO week of 2013, not the last week of 2012, so (at least as written here) the explanation cannot be correct. The bug could be related to the ISO week calculation, or it might not; however the working out in this article is definitely flawed in several ways. The blogger responsible has been taken out the back and shot.]

Digging into the problem

I did some manual testing by winding my iPhone's clock forward several years and setting different times to turn DND on and off again. You can replicate this easily by scheduling one minute of DND, changing your iPhone's date and time, and watching to see if DND correctly switches on and then off again. If you try this too, note that you'll get some scary-looking warnings about mail server SSL certificates, not having backed your iPhone up for several years, and some nagging about app updates. It should be safe to click through those.

To me, it seemed that in the years I tested (2013, 2014 and 2015), as long as the "Enable from..." time set in the Do Not Disturb schedule settings fell after midnight on the first Monday of each year, then it would work correctly. Conversely, I would see wonky behaviour (a technical term, there) until that first Monday. A similar pattern was recorded by MacRumors forum poster "stevem1981," who tested all the way up to 2024. Note that he talks about the "fix date" being Sunday, rather than Monday, because he's scheduling the DND after midnight, as he says in the last sentence.

But stevem1981 recorded some weirdness, too; like in 2016, when the bug doesn't occur even though the week starts on a Friday. Or 2017, when the bug happens through as far as January 8 even though the year starts on a Sunday. So it's not as simple as "it doesn't work until the first Monday of the year." More on that in a moment.

This is enough information that we can theorise how DND works, and what is going wrong.

A possible explanation

Firstly, note that the bug is related to DND switching off, not on. The device always moves into DND mode successfully, but never comes back out of it. Secondly, note that the bug occurs when the "Enable from..." time is before the first Monday in the year. That suggests that the way DND works, under the hood, is that when it switches on through a schedule, a timer is kicked off (in some background daemon) in iOS; that timer is responsible for turning DND back off again at the appropriate time. The timer has problems during something a bit like, but not exactly, the first calendar week of the year.

Now, to programmers who've done a lot of work with date and time handling (like me; I write airline flight systems for a living, which require a lot of heavy timezone math) "it's broken during something like the first week of the year" immediately suggests a moderately obscure problem related to the ISO week date. This is a slightly weird definition of the year that you get from many date manipulation libraries by specifying that you want the year as "YYYY", as opposed to the more common "yyyy".

It's derived from an ISO standard that defines the first week of the year as starting on "the Monday that contains the first Thursday in January". Under this definition, the first few days of the year that we write as "2013" are actually counted as being part of 2012 instead; 2013 doesn't begin until Monday, January 7. It's the sort of thing accountants like to use to keep things neat and tidy. Interestingly, January 7 is exactly when Apple says the problem will go away. Ah hah!

So, for 2013, the 1st-6th of January will show as being part of 2012 if the developer specifies "YYYY" in his or her date string, rather than being part of 2013. This means that when DND automatically switches on, it will have a calculated switch off date of sometime in 2012, which is now in the past so it will never turn off. I once made this mistake in my own code, as it's very easy to type "YYYY" instead of "yyyy"; it seems some nameless Apple engineer has done the same in iOS's Do Not Disturb function, but only in the automatic switch off time, not the switch on time part. In my case, the problem was caught in automated testing and never went live. The Apple engineer has been less fortunate.

I'm not the only one who is thinking along these lines. iOS dev Patrick McCarron mooted it on Twitter, and MacRumors forum poster "akac" had the same theory. Charles Arthur wrote the story up for the Guardian and linked to a code sample by Chris Cieslak that clearly reproduces the issue using Apple's NSCalendar and NSDateFormatter libraries.

Apple's response

On the one hand, I feel sorry for Apple. Presumably this issue had gone completely unnoticed until January 1, and even if the fix is merely changing "YYYY" to "yyyy" there's no way it can get a patch written for iOS, run through internal testing to ensure nothing else was accidentally broken, then released to the world before January 7. So all Apple can really do here is say "sorry, but the problem will go away by itself"... whilst also putting a permanent fix into some future iOS release, of course.

On the other hand, Apple's response is rubbish. Coming on the heels of high-profile problems with Daylight Savings in 2010, 2011 and 2012 (plus some oddity with Siri), and most recently Calendar.app crashes if you have an all-day appointment on April 1 2013 (link via Charles Arthur), it wouldn't be unfair to describe Apple's reputation for date and time handling as "rather poor." Seeing as how Apple has basically all the money in the world, and seeing as how bugs like this are quite easily caught with thorough unit testing, you'd hope that this isn't the sort of thing that Apple would put in a shipping release of iOS.

Having allowed this rather silly bug to slip through anyway, I think the least Apple could offer us was some crumb of embarrassment or apology. I'm not expecting or demanding it prostrate itself with wailing and gnashing of teeth; just suggesting a little bit of humility might not have gone amiss here. Instead we get a Gallic shrug of a KB article that blandly says, in essence, "scheduled DND is broken. Stop scheduling it that way." I think that's a poor show, and an example of how Apple's minimal attitude to corporation communication will end up making this a bigger story than it should have been because it simply irritates people.