Yesterday i was deploying the new clients to laptops we use in the company.
The laptops are used on units that we have which basicly dont come back to the office to hook up on the network.
Therefor we make use of the JUNIPER SA 2500 SSL VPN connection.
It works like this:
We have a website for the employees and units to login to. If they make use of a token (which the units do) then you get several options that we publish. One of hte options is NETWORK CONNECT (the name that Juniper gives to VPN)
The SA 2500 installs via activex and java several files to check if hte computer validates to our demands. One of the demands is that the laptop is part of our domain. When this is the case the NETWORK CONNECT option becomes available after login.
I have installed the SBC client on the laptop and i dont see the NETWORK CONNECT.
So i started testing on a VM because i thought at first it was the java version.
This is my testing trajectory:
installed a completely clean Win7 32bit with all the updates in the company
installed java 6 update 26
the 4.8 client gets installed automatically, so the sbc is an upgrade of 4.8 at deployment
no other software installed
make a snapshot of the machine is this “clean” state
then i tested the JUNIPER SA login.
result: VPN CONNECT available
then i reverted my snapshot
installed the sbc client with all the shields that are standard in default group
result: NO VPN CONNECT available
then i reverted my snapshot
configured all the shields except file shield in the default group to be turned off
installed the sbc client
result: NO VPN CONNECT available
Right now im installed a clean machine again, but i will not have 4.8 installed.
then i will deploy sbc clean and test the NETWORK CONNECT
Although i have little hope that a clean install of SBC is the sollution, i will try.
I guess tho that a part of the juniper software is blocked, so please check this out.
the SBC and client are on the latest released versions
all client machines: win7 32bit using IE9
Have the same problem since have purchase and Install Avast 4.8 (managed).
Have open support request 6 month ago, but Avast is too busy to cash my check that solved that problem.
I called Juniper (I’m not even client) and I work with them on this issue.
But now, all our tests confirm that the problem is due to AVAST.
Currently my solution that i found works 1/5. I generate a setup file (MSI file) and I use Avast to install locally on the PC with the user’s account.
On Juniper Side the admin need to activate a check box to bypass client error.
With this… My users can work 30 minutes before to be kicked out.
well my clients with the 4.8 client have no problem at all with this
it gets validated perfectly
so either its in the up-to-date notification detection or the avast name that gets detected… i do not believe anymore that the avast client is blocking things, i believe juniper has validation issues
Previously i wasnt responsible for managing the network part that deep, now i am so im still figuring out how some of the devices work.
The hostchecker software from the Juniper SA2500 has been configured to check WHICH anti-virus software is installed, not if windows is reporting if the AV is still up to date or working properly. So truly only the name is checked.
I have found the list of AV products that the hostcheckers checks for, and there is an Avast 5.x line in there, it is not the 6.x or business client
so right now im figuring out how to edit that list and which string is reported by avast as the installed package so that the hostchecker recognizes it.
I found this out by my vm deployment testing mentioned above when a completely configure domain machine (with av 4.8) past the test and the exact same machine but without 4.8 or with the new sbc client didnt pas the test i saw that hte host check failed (in a split second it showed it)
So in this case i jumped to conclusion too early, but on the other hand it is good to know this for your technical support to have a possible reason with this kind of problems with other customers
I have to update the list that the SA2500 appliance can recognise. Unfortunately i cant do this manually, i have to download some software from Juniper site for this.
BUT, i am afraid that definition file does not contain the latest namings of the Avast company or the product.
I believe the technique used by the SA2500 comes from OPSWAT.
I went to their site and they offer a free appremover tool, so i used that tool to see if i could remove the avast! Business Plus software, unfortunately the appremover does not recognize the NEWEST avast software.
I reported this to the company, but i have to conclude that because the appremover (fresh downloaded) doesnt recognise the newest avast software, an updated definition file for the SA2500 will still not recognise the installed antivirus and thus fail the hostcheck and thus wont allow connections, the only temp sollution would be disabling the av check which means im opening my network for potential mass infections.
Is there contact between Avast and OPSWAT by any chance?
The list used by the SA2500 (and others devices from the SA serie) use the OPSWAT list to identify the antivirus.
This list is updated once a month and of course with my luck this update happened 3 days ago and there is no new avast (avast! Business Protection Plus) in the supported list
therefor i opened a support case at Juniper to put the new naming from the avast software and the company name too.
In the last 2 days i have exchanged about 10 emails with questions and answers (both sides) now it is escalated to a third or forth line engineer to see how to add the new avast name to the list.
I used a diagnostic tool they send me that gather details but that tool didnt recognize the new avast client by more than the name (therefor its escalated to the high level engineer now).
I suggested that instead of depending on me for their diagnostics, they should contact Avast and get prime intel on this.
If the engineer asks eventually if i have a contact person at Avast for him, is it possible i refer him to someone?
in the meantime we were able gain access to and do some tests with one of the Juniper boxes. The VPN connect with Avast was blocked immediately by the Juniper host checker, so the VPN connection was not even started.
I guess the best person to address for the diagnostics required from Juniper (if needed from your bug ticket) would be our Q/A manager Lukas Hasik (hasik (at) avast.com) but of course you can mail any one here (e.g. me) and I’ll forward to whom it concerns.
Im running ESAP 1.8.0 in the complete list there is no avast 6 (any version) as supported AV.
Juniper has classified this as a bug and its run up to a third line engineer i believe.
On my question when this is resolved i received the answer that they are expecting the support for this now maybe in the release of end of December.
Tomorow i will add another reply to my ticket with the info you gave me, maybe they can hurry it up. I dont like to tell my management that i have to wait for at least another one and a half month for MAYBE support.
I have just checked it with the collegue who has tried to run Avast with Juniper for you. They were succefull in configuring Juniper SA2500 + ESAP 1.7.6 to work with avast. The security template for Host checker can be edited manually and maybe you have to do some tweaks at your side. Tomorrow we’ll have the XML files with the running configuration available, so we can post it here for you to compare with your setup.
Hi wpn,
I still don’t have the packages / examples for you. We were trying to obtain the ESAP 1.8 for reference today via the official Juniper support, but since we currently don’t have a support contract with them they didn’t agree to cooperate with us. There are still other ways, so please wait for more info.
The problem is indeed caused by the fact that the Juniper Host Checker doesn’t know about the Avast client.
We’re in the process of talking to Juniper (or, more specifically, another company that’s building this for Juniper), aiming to solve the problem on their end.
BTW similar thing will happen with Cisco NAC, for example.
Thanks for bringing up this important topic though.
Hope to get it solved faster then the projected end of December though. At this moment my clients cant make VPN connection which they need for their updates and policies and quality management control
been busy with Juniper Support for a couple days now. Today even had conference call for about an hour with them (luckily they called me ;)).
OPSWAT is a thirdparty tool that Juniper is using for their so called HOST CHECKER.
This host checker checks for different rules that I configure.
My rule is that there should be a valid AV product installed that is running realtime protection.
OPSWAT added support for detecting Avast Business Protection (Plus). KUDOS!
So far so good.
Now, what me and the engineer concluded out of our session today is the following:
The host checker (OPSWAT basicly) DOES detect Avast is installed.
BUT
The host checker needs elevated rights to be able to detect if avast has the realtime protection turned on.
-When i logged in as a regular user on the computer, host checker FAILED the check (and thus not giving the option to make VPN connection)
-When i logged in as a domain administrator (which is part of the local administrators group), host checker FAILED the check (and thus not giving the option to make VPN connection)
-When i logged in as the local administrator of the machine, host checker PASSED the check and showed the option to make VPN connection.
-When i disabled UAC and logged in as a domain administrator, host checker PASSED the check and showed the option to make VPN connection.
-When i disabled UAC and logged in as a regular user, host checker FAILED the check (and thus not giving the option to make VPN connection)
The Juniper Engineer is in contact with Avast about this and im in the middle of all this of course.
Either OPSWAT has to change how the host checker checks, or Avast has to change the admin rights to check for realtime protection being turned on or not. Right now the shot is at the last option.
Avast is correctly bein detected by the OPSWAT tool, so the ticket for adding it is closed.
The engineer from juniper opened another ticket tho, to get the tool to detect avast propperly now.
explanation:
The hostchecker tool requires admin rights to detect the real-time protection status from avast business protection.
Not only that, but it only works out of the box with a local administrator account when UAC is turned on.
When UAC is turned on and you use an domain admin account which is a member of the local admin group on the machine, then the detection still fails.
When UAC is turned completely off, using that domain admin account with local admin rights, it is possible to detect the real-time protection status.
Now this is never going to happen in a business environment:
Turning off UAC
Giving normal users local admin rights
Points 1 and 2 together…
Therefor the engineer opened another ticket for this issue. And now it is waiting for the solution for this new ticket.
