Having the opportunity to experiment with some Juniper security products at home has its (dis)advantages. Juniper offers a (limited) virtual appliance version for both the Unified Access Control appliance (aka the Infranet Controller or Pulse Access Control Gateway), and the SSL VPN solution (aka Secure Access or Pulse Secure Access Gateway).
The limited parts are:
- SSL is limited to 3 concurrent users
- UAC is limited to 5 concurrent users
- You cannot add additional licenses
- The UAC has no IF-MAP server capabilities, since that requires at least a 50 user license (and you cannot add additionel licenses).
So yes, it's crippled, but still very nice to play with in a lab or home/study environment.
Anyway, I have both the UAC and the SSL VPN running at home. Both running in VMWare Fusion on a MAC OSX server (Mac Mini).
A couple of months ago, Juniper released a new major version for the software (v5 for the UAC, and v8 for the SSL VPN), so I wanted to upgrade the VM's to the latstes software (also because of the Heartbleed bug in OpenSSL). This was no problem for the SSL VPN. The upgrade went smooth. However, the UAC was a different story. For some reason, the upgrade package was corrupt or invalid (even though it could be used to do a clean install), so upgrading was out of the question.
So I tried to do a clean install and see if I could import the old config of the existing UAC (v4.4) in the new version 5. Something that didn't work in the older versions of both the SSL VPN and UAC. Importing a software version meant that you needed the correct software version on the device first.
Anyway, importing the system config seemed to work, because all visible settings were correct. The XML import (other configuration settings regarding authentication servers, realms, user roles, etc.) also imported correctly (or so it seemed).
I compared the two configs side by side, and everything checked out. That was until I tried to authenticate on a switch with 802.1x. That didn't work as it should.
The logging of the UAC showed numerous 'No EAP Protocol Was Agreed On' errors. This was weird, because everything worked correctly on the older version.
Since the EAP protocol relies (for a part) on the SSL certificate on the device, I swapped that one for a new certificate from my personal PKI service.
After having checked, and double checked everything (I even tried authenticating against the older UAC version... which still worked), I decided to do a clean install (back to factory settings), and reconfigure the entire UAC by hand instead of the import.
Guess what, everything worked great after I had copied everything by hand.
So I guess that the import of a XML file belonging to a earlier software version still doesn't work. Only difference is that in the old days I got a warning/error.
So if you're getting the 'No EAP Protocol Was Agreed On' error in your events logging, and you did a recent upgrade, you might want to try a fresh install and configure things by hand.
I have no idea if this is applicable to the 'normal' hardware appliances with the software.