Juniper SA NC does not work in FF4




8 years ago
2 years ago


(Reporter: ravi, Assigned: smichaud)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: JNPR Case 2011-0208-0766)


(3 attachments)



8 years ago
The Network Connect ("NC") of the SSL VPN ("SA") does not appear to function.  It does in the Win32 builds of FF4.


8 years ago
Whiteboard: JNPR Case 2011-0208-0766

Comment 1

8 years ago
Per an OOB thread I'm assigning this to you.

To gain access go to and login with your LDAP credentials.
Assignee: network-operations → blackconnect
Group: infra
Component: Server Operations: Netops → Java-Implemented Plugins
Product: → Core
QA Contact: mrz → blackconnect
Version: other → Trunk

Comment 2

8 years ago
Forgot to uncheck the Reset Assignee box...
Assignee: blackconnect → smichaud
> To gain access go to and login with your
> LDAP credentials.

I appear to have the necessary credentials, but I have no idea what
the problem is supposed to be.  Please give precise, detailed

I understand the problem only happens on OS X.  Does it only happen in
FF 4, or also in earlier FF versions (3.6.X and earlier)?  Does it
happen on both OS X 10.5.8 and 10.6.6, or just 10.5.8, or just 10.6.6?

I also understand that the problem doesn't happen in Safari.  But
Safari (unlike FF 4) doesn't (by default) use Oracle/Apple's Java
Plugin2.  To make Safari use Java Plugin2, choose "Run applets" "In
their own process" in Applications : Utilties : Java Preferences.
Then test again in Safari.
Component: Java-Implemented Plugins → Plug-ins
QA Contact: blackconnect → plugins

Comment 4

8 years ago
Juniper followed up with nothing really useful, but here for the record:

"Some of the items I have seen references to in the past, but again there is nothing definite noted that I am aware of, for the client components not launching are:
1)      JavaScript
2)      JRE interaction
One item that is not preventing the launch, but that I know has caused concern, is that Firefox uses its own proxy settings rather than the system-based proxy settings; that has been of concern when trying to configure the needed proxy details for the connection after launch."

To reproduce there should be a link for Network Connect toward the bottom which will launch the applet that acts as a VPN client.  It successfully worked in FF3.6.  I do not have a test OSX older than 10.6.6.

Comment 5

8 years ago
Curiously enough "Run applets" was already set to "In their own process".
Thanks for the info.  And for telling me that you're just a conduit
for information that, well, isn't very adequate.

But there's not much I can do if I don't know what the problem is.  At
this point, I think the only way forward is to have someone commenting
in this bug who has direct experience of the problem, and who
therefore can tell me what I need to know.  That may end up being
someone from Juniper.

> To reproduce there should be a link for Network Connect toward the
> bottom which will launch the applet that acts as a VPN client.

When I click on the Network Connect button, it launches *two* Java
applets, both signed (one after the other).  This happens in both FF 4
and FF 3.6.15.  I give both of them access to my computer.  Then I get
a dialog entitled "Setup Control - Warning", which asks me "Do you
want to download, install and/or execute software from the following
server?", and displays the following info:

  Product Name:  Network Connect
  Software Name:
  Server Name:

Here I say "no", because I'm not yet testing on a disposable

So far I've only tested on OS X 10.5.8.

Does the problem (whatever it is) happen after this point, or before?
I've now tested on a disposable partition running OS X 10.6.6, with FF
4.0 RC 1 and a recent Minefield nightly

I can't reproduce any problems with them.  As best I can tell, this
bug is invalid.

In these tests I answered "yes" whenever I was prompted to allow an
applet access to my computer, or to allow Java to install or run  In all tests except the very first one, I
eventually got what appeared to be a working connection to the VPN.

In my very first test, the browser appeared to stall (though not to
freeze) just before attempting to download the first signed Java
applet (just after I pressed the Start button to the right of Network
Connect).  This stall happened *before* the applet had finished
downloading, and therefore before Java was started (though I'd used
Java Preferences to turn on the Java Console, it didn't start up).

(By the way, when you visit, the browser
briefly displays the message "Loading applet ...".  Whatever this is,
it's *not* a Java applet -- the JVM doesn't start, and the Java
Console doesn't appear.)

In my second test I ran Minefield in 32-bit mode, thinking this might
be the problem.  However I've never been able to reproduce that
initial failure (in 64-bit mode or otherwise), even with a clean
profile, and after (as best I can tell) completely removing all the
Juniper stuff.  It's most likely my first failure was due to network
problems of some sort.  It certainly wasn't a Java problem.
Created attachment 518459 [details]
Changes made by Juniper installers

Juniper's installers make *extensive* changes to the system.  Here's a
list of those I was able to find.  I think it's complete, though it's
possible I missed something.

Comment 9

8 years ago
So the applet is able to successfully load then?  I'll attach some screenshots to illustrate the failure state and the expected state (that works in Safari).

Comment 10

8 years ago
Created attachment 518463 [details]
Failure screenshot

This is how it appears to fail initially while running RC1.  After I ack this dialogue I get a OS user authentication request which would permit the install.

Comment 11

8 years ago
Created attachment 518466 [details]
Successful launch of NC in Safari

Comment 12

8 years ago
So while I'm willing to admit my machine may be hosed the behavior happens on other sample hosts I've hijacked here in the office.
So it looks like your machine (and all the others you tested on) already had Network Connect installed -- probably an older version that needed to be uninstalled.

On a clean machine (to which Network Connect was never installed), you should have no problems.

Please try to identify the older version, and find a way for me to install it (and test with it).
Or it's conceivable that Juniper's installer (the one that displayed
the "failed to uninstall Network Connect" message) was being sneaky
and uninstalling one of its competitors' implementations (like Cisco's

In any case, you need to look for older VPN clients on the machines
where your tests failed.
Another thing to check:

Apple just released new Java updates for OS X 10.5 and 10.6.  Install the
appropriate one and test again, to see if this makes any difference.

All of my tests today have been with Java for Mac OS X 10.6 Update 4 (the
latest update for 10.6).
(Following up comment #14)

For what it's worth, I uninstalled Network Connect (by deleting the
items mentioned in attachment 518459 [details] from comment #8), installed
Cisco's WebEx (bug 622830 comment #0), and authenticated to

Network Connect left WebEx alone, and installed (and connected)
without any trouble.

So (to repeat what I've said in previous comments) you need to look
for older versions of Network Connect on the machines where you've
seen this bug, record their versions, and try to find how I can
install them (and test with them).

(To uninstall WebEx, you need to delete the items mentioned in bug
622830 comment #6.)
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.