Juniper Unified Access Control With Junos Pulse

This blog post hold the key ingredients for successfully authenticating on layer 2 (802.1x or dot1x) and layer 3 with:

General Information

The setup consists of four networks (VLAN's) and Internet access. Inter-VLAN communication is handled by a Juniper SRX210. The four VLAN's are:

Untrust (VLAN 20)
The Internet
Trust (VLAN 10 - 192.168.1.0/24)
This VLAN hosts the UAC, Active Directory, DNS and DHCP services
Production (VLAN 100 - 192.168.100.0/24)
Network where the normal workstations are placed
Quarantine (VLAN 200 - 192.168.200.0/24)
This is where the naughty people/PC's are dropped

When a PC is placed in Quarantine, it looses all access to the Internet, but can still resolve domain names, access minimal internal services like the DHCP server and the UAC.

The components on the network are:

Domain Controller + DNS Server - 192.168.1.10
DHCP Server - 192.168.1.1
UAC - 192.168.1.11
Gateway(s) - .254

No EAP Protocol Was Agreed On

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.

Posted on April 13, 2014 by Willem and filed under Security, Software, Tips'n Tricks and tagged UAC IC Pulse SA Juniper EAP Error Protocol sslvpn.

Using EX Firewall Filters With UAC

Network Access Control (NAC) is hot in Enterprise environments. NAC offers an excellent mechanism to (safely) allow various devices network connectivity and staying in control as a network administrator. There are numerous ways to allow iOS devices, BYOD, CYOD, Corporate laptops onto your network without compromising valuable corporate resources.

In my line of work I deal with several vendors / solutions to create these NAC protected environments. The most popular at the moment are;

Identity Service Engine (ISE) from Cisco
Junos Pulse Access Control (UAC) Service from Juniper

Both solutions have their pro's and cons. Juniper has an excellent client for the desktop to safely connect to the network, and an integration with their SRX firewalls to (dynamically) enforce firewall policies on a per user basis. Cisco on the other hand has a more flexible way of creating access policies, and the use of so-called downloadable Access Lists (dACL).

Junos Pulse, Apple iOS, and Split-Tunneling

When you create (SSL)VPN access for you employees, you might enable split-tunneling to save corporate bandwidth. No split-tunneling means that all traffic is forwarded into the VPN tunnel. So if you browse the internet with an active VPN, the traffic goes through the VPN, and accesses the Internet through the corporate Internet connection. This isn't a big problem with a couple of employees, but with hundreds on the road or working from home, this might frustrate the employees in the building.