Juniper SA SSL VPN – Migration to JUNOS Pulse

With version 7 (see previous post) of code having been released for Juniper SA, I have been busy testing all the new features in our lab and in some cases, deploying them for clients. One of the most interesting features has been Junos Pulse, which Juniper’s marketing team describe below.

"Junos Pulse is an integrated multi service network client that supports integrated connectivity, location-aware network access, acceleration, and security. Junos Pulse simplifies the user experience by letting the network administrator configure, deploy, and control the Junos Pulse client software and the Junos Pulse connection configurations that reside on the endpoint."

Junos Pulse is a replacement for Network Connect; it adds new functionality and interoperability with other Juniper Networks appliances (IC Series UAC Gateway Release 4.0, Secure Access Series Gateway Release 7.0, WXC Series JWOS Release 6.1, SRX Series Release 10.0). The following key features have been added in Junos Pulse:

• Credential saving – Ability to save credentials on the client machine.
• Host checker consolidated to Pulse client rather than a separate installer.
• WAN acceleration.
• Certificate trust and storage.
• Dynamic connections – Allows connections through newly discovered supported gateways through the web browser.
• Wireless suppression – Disables a wireless adaptor (if feature enabled) when a wired connection is available.
• Scan list – Allows a white list of SSIDs for wireless networks to be added.
  
• Location awareness – Allows conditional connection depending on where the endpoint is located.



• Enhanced Endpoint Security – Extra licence for endpoint security on the box, now present on the client.

Migration

Knowing the Juniper SA pretty well, in the first instance I decided to have a ‘tinker’ and see if I could work out how Pulse worked and how it could be activated for a small sub-set of users in the lab environment. This proved difficult, partially due to the labyrinthine depth of some of the menus and partially because of non-standard logic derived from hundreds of configurations I have done on the SA. After an hour or so of tenacious (mis)configuration, I decided to look for the admin guide on the Juniper website, which is well written and simple. It’s definitely worth reading it in its entirety (or at least pages 31-47 which are relevant to the SA) and the migration guide, located on the same web page. The admin guide contains a step-by-step for configuration on the SA (and for all the other appliances) and the migration guide provides information about which features are new and which are missing. A key point to note is that Network Connect and Pulse cannot function for the same role, even though they share the same split tunnelling policy and the documentation is very misleading on this point! What this will mean, is that once you have deployed Junos Pulse and users have installed it, they will no longer be able to connect to the same SA (or cluster) using Network Connect. Whilst discussing the solution, it’s worth mentioning the principle reason for this being an issue. Junos Pulse will ONLY work with Windows at present (Windows Mobile Included!) and this is an issue with the proliferation of Macs and desktop Linux distributions such Ubuntu and Fedora Core (especially in IT Security where pen’ testing rigs are almost always Linux based using Back|Track or a custom build). This means that it is no longer possible or logical to group all users of Network Connect together in one role as it previously was.

Advice on Testing

During a ‘live’ testing period with end users it’s advisable to provision both access methods in case there are any issues and to give an environment where you can easily test the same action with the other application. The optimal method (IMHO) is to create an additional role for Junos Pulse. I would advise copying an existing role that includes Network Connect as this will contain all the IP address pools and settings that will duplicate the user experience. I would recommend that you name these logically as “<role> Junos Pulse” and “<role> Network Connect” as this will help greatly with troubleshooting.

In order to correctly assign the roles to users I recommend either a regular expression to recognise the useragent (e.g. userAgent = '*Safari*' OR userAgent = '*Linux*') in the realm level role mapping or to update your OUs in Active directory (i.e. split the users into Mac / Linux / Windows). From experience, I’d advise the ‘regular expression’ method at the realm level role mapping and moving it to the top of the processing order and adding a stop rule. The next group, which should be your Windows users that have not hit the first rule, should then be mapped to both the Network Connect role and the new Junos role and the option “User must select from among assigned roles” selected. This will give the users the option of selecting the role they require upon login to the portal. Once this is set up, you will need to add the roles to the Network Connect resource policy. It doesn’t explain or tell you how to do this in the step-by-step guide, which means it can often be a gotcha! Simply add the role to the Access, NC Connection Profiles and Split Tunnelling settings (Users > Resource Policies > Network Connect).

SSL VPN - What’s new in Version 7?

Two of the major players in SSL VPN appliances, F5 (Edge, Firepass) and Juniper (SA) have just released new versions (both version 7) of code. There are some notable (and not so notable) new features included in the new releases which may well whet the appetite of Information Security managers and administrators across the industry – or so the vendors hope.

Firstly, and at a slight tangent, I think it's worth mentioning a bit about F5 and how they have been refocusing their approach to SSL VPNs with the release of their Edge Gateway appliance. The Edge focuses on throughput and download speeds with the consolidation of their existing modules; WAN acceleration (WOM), Web Acceleration (WBA) and Access policy management (APM) into one 'Edge' Package (For datasheet on Edge click here). F5 are continuing development of Firepass, however, conversations I've had with several SEs from F5 allude to it be phased out over the next few years. The Edge itself is essentially the three existing F5 modules mentioned above on Big-IP running on F5's standard hardware. This is sold as a bundle and held together by pretty impressive client-side software specific to Edge.

F5 Firepass

The new version of code for the Firepass contains a few updates for Endpoint functionality, including support for Mac OSX and Linux Antivirus inspectors (something the Juniper SA doesn't do), Endpoint Hardware inspectors which enables access to be locked down by Mac address or HDD ID and the addition of CAPTCHA field to the login page to thwart brute force attacks. Additionally, a major new feature is the ability to run the software as Virtual appliance. The Firepass VE (Virtual Edition) runs on VMware ESX4 and can be licenced for up to 2000 users. F5 seem to be positioning this as a DR option if capacity needs to be boosted during a failure, rather than an SME or scalable option. F5 have also added a java applet for RDP giving the end user the ability to connect to windows machines remotely from any platform, this essentially a feature to catch up with Juniper (although it's quite difficult to configure on Firepass).

Overall, I think that the changes to Firepass in version 7 bring it in-line with other offerings within this space (notably Juniper – rated as the best appliance on the market by Gartner (and my personal preference)) and features such as support for Mac AV checking and java-based RDP on the Endpoint will tip a few decisions with the growing prevalence of the 'business-Mac-user'.

Juniper SA

Version 7 of the Juniper software doesn't add as many features as F5, but focuses on enhancement and transition to the JUNOS platform. One of the 'stand-out' features of the release is the JUNOS Pulse client, which improves upon network connect and is (as the name suggests) JUNOS compatible. As the java RDP client that was used in version 6.x was quite difficult to configure and customers often reported back a poor user experience (normally based around resolution and window sizing, especially on Macs), Juniper have included third-party software from Hobsoft. Hob RDP is now included with 2 concurrent user licences, requirements exceeding this need to be purchased through Juniper or a reseller. I have only just started testing this myself as I may recommend this to a customer who's unhappy with the standard script. However, looking at comments in general on the J-Net forum, the feedback seems to be pretty positive. Although, it appears that it's not possible to force the use of Hob RDP for windows users, it defaults to the older platform-specific version for windows, meaning the end user experience is still different on Mac and Linux. Like F5, Juniper has also invested in creating a virtual appliance. Their focus for this lies in scalability and there is no limit on user licences unlike with F5.

Another feature that Juniper has added is the ability to open multiple user session. This feature is very handy if you use multiple machines at the same time and wish to complete two tasks on the VPN concurrently, although, I am struggling to think of too many scenarios where this would be useful. One situation that springs to mind is when logged into the VPN and wanting to initiate a secure meeting. This was not possible previous (and still isn't from a single machine) to version 7 as it was strictly one session per-user. After picking the brains of my colleagues as to a circumstance when this could be useful, we decided that the preclusion of multiple sessions could restrict use from smart phones or disparate devices (or iPads / iPhones when the JUNOS Pulse app is released in July). Two more minor features that caught my eye on the release notes were RDP7 support (which is fairly self-explanatory) and the ability to present legal disclaimers or MOTD to users through the portal. In large estates this feature could be very useful, as we all know that people don't read emails or SharePoint messages boards religiously.

Summary

To conclude, I believe that both vendors are making steps in the right direction to improving the user experience. Although, in this release I feel that Firepass is playing catch-up and Juniper is smoothing the cracks that appear when you create a product with such granularity of control. It's disappointing also, that F5 have not updated a horrible Windows 95'esque GUI, but I believe a complete re-write isn't going to be imminent as the Edge Gateway moves closer into focus.