VMware VCNS/NSX Edge Gateway SSLVPN and El Capitan 10.11.1

It is sad that most of my blog posts are related to an SSLVPN client and not my area of expertise, storage.  The previous SSLVPN client post is by far the most popular post on my blog, so here is to another post that will hopefully help someone.  My previous post on the SSLVPN client can be found here.

I had previously been running the NAclient from Edge version 6.1.3 on OS X 10.11 without issue, however the installation will no longer work due to security controls put into place by Apple.  There is a trend here, the previous problem with getting the NAclient installed onto OS X 10.10 (Yosemite) was also due to failure to meet Apple security guidelines, they didn’t implement code signing (amongst using deprecated methods of configuring/starting services).

If you attempt to install the NAclient on a current version of Apple OS X 10.11.1 you will see a lovely error like this one:  “This package is incompatible with this version of OS X and may fail to install.”
Install_VMware_SSL_VPN-Plus_Client_Installer

 

And if you select to Install Anyway it will just fail with the error: “The installation failed.  The installer encountered an error that cause the installation to fail.  Contact the software manufacturer for assistance.”Install_VMware_SSL_VPN-Plus_Client_Installer

It took some digging to figure out what is going on, and I used one of my favorite tools (Pacifist) to open the actual installer package to see where the installation files are written.

Archive_bom

I also remember reading about Apple’s System Integrity Protection locking down access to secure system file locations, including /usr, /System, and others.

In researching this I found Apple’s developer guidelines for System Integrity Protection, and it clearly states that /usr is off limits.

https___developer_apple_com_library_prerelease_ios_documentation_Security_Conceptual_System_Integrity_Protection_Guide_System_Integrity_Protection_Guide_pdf

Source: Apple System Integrity Protection Guide

Now that the root problem is found, I sought a work around.  Previously we had to disable the check for kext signing, though that didn’t permanently solve the issue because the dependent services wouldn’t work after reboot due to use of deprecated methods.  This time I was able to find that you can manage the System Integrity Protection using the command csrutil:

OS_X_10_11_-_Clean_install

In order to manage System Integrity Protection you must reboot your system into Recovery Mode, you can do this by holding down Command+R on system startup.  You should boot to a OS X Utilities menu.  Click Utilities and select to open Terminal.
OS_X_10_11_-_Clean_install_and_untitled_2

Within terminal you simply need to run ‘csrutil disable’ and then reboot the system, the easiest way to do this is with a single command line of ‘csrutil disable; reboot’.
OS_X_10_11_-_Clean_install_and_untitled_2

 

Once the system is booted up you can  now successfully install the NAclient, test that it works.  At this point you can repeat the process and run ‘csrutil enable; reboot’ to turn System Integrity Protection back on…which I strongly encourage.  It is disappointing that we have to disable security controls to install a security tool, however at least we only have to have it disabled upon install.  Any actual package upgrades would require you to repeat this process, but lets face it…VMware hasn’t released an update to this client since the last time I reported a bug in it 😉

Happy VPN’ing.

—– Follow up 11/24/2015 —-

It is becoming obvious that VMware doesn’t take client support for SSLVPN seriously, I will be investigating options to migrate our environments off of SSLVPN within the Edge Gateway.  It is entirely idiotic that you must deploy an entire new version (that isn’t even released yet) in order to fix a simple client installer bug.  That means you have to wait for the new version of the NSX stack to be qualified and supported by GSS with any of your other software components (e.g. vCloud Director), which isn’t an immediate process.  This leaves customers exposed for a long period of time, it increases operational burden for support teams and in general is a horrible way of delivering client software.

Client software should be released and maintained independently of the entire NSX Manager/Edge Gateway bundle.  Requiring every customer to do a massive upgrade of their entire environment just to fix a bug (that they should have known about months ago and should have been included in a 6.1.x release!) in client software is not acceptable.

— Edit 11/30/2015 —

An additional challenge here is if you disable the work around (have System Integrity Protection enabled), as you should, it will result in the client breaking if you run an installer again (say to add another VPN profile).  If you need to add another VPN destination you really should just edit the config file /opt/sslvpn-plus/naclient/naclient.conf directly with the editor of your choice.

— Update 12/16/2015 —

The work around allows the naclient to function on OS X 10.11.2 as well.  If you have the client installed prior to installing 10.11.2 update it will remain working, the work around will also preserve the ability to install after 10.11.2.

Advertisements

5 thoughts on “VMware VCNS/NSX Edge Gateway SSLVPN and El Capitan 10.11.1

  1. […] Rather than keep adding content to this post, I created  new blog post with the work around for OS … […]

  2. william says:

    Hi,
    I did all you tell, but it still don’t work.
    Do i have to modify the files like Mountain Lyon ?

    Thanks for your answer.

    Regards,

    William

    • effndc says:

      What version of Edge Gateway are you downloading the installer from? It must be 6.1.3 or newer in order for you to have a chance of it working on Yosemite or El Capitan, but I would encourage the use of 6.1.5. If you upgraded your NSX Manager you need to make sure you also upgrade the deployed Edges themselves.

  3. Tommy says:

    i’m getting this error on El Capitan 10.11.2 with naclient downloaded from 6.2.0 Edge.

    • effndc says:

      I do not currently have any 6.2.0 deployments to test with, and I don’t have the ability to upgrade one of my environments to it as I must stay on the 6.1.x release path.

Contribute to the discussion

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: