We’re experiencing a strange problem with remote assistance not working for some clients - see attached for the error message we are receiving. We are running client version 8.0.1603.
As stated above, the problem only affects some clients. After Wiresharking clients that are working and ones that aren’t, we’ve been able to narrow down the difference to a resolved IP address for rh.ara.avast.com. The clients that aren’t working are resolving to 77.234.41.84, while the clients that do work resolve to 77.234.44.84. I’m not certain if this has anything to do with it, but it was the only difference we saw. We also connected a few machines that weren’t working to an open offsite internet connection to eliminate any content filtering/local network issues, but the problem remained. I have the Wireshark files available by request - thank you.
Unless you have a support contract with Avast! or whoever provides the paid support, I’m going to suggest you implement a workaround until the problem is resolved. More than likely, one group of remote help servers is having issues with it’s configuration or is unreachable.
In your DNS, create a new zone file named rh.ara.avast.com and create a new host record, same as parent domain, and have it resolve to the working IP address. Flush your DNS cache, check you are getting the working IP when trying to connect to the rh.ara.avast.com
Thanks for the suggestion. Unfortunately (or fortunately?), it appears the IP address difference doesn’t matter. I forced a working computer to resolve to the “not working” IP address via the hosts file and it connected just fine. I also tried the same by adding the “working” IP address into a machine’s host file that wasn’t working and was met with the same error - so we’re back to square one.
Do you use a proxy or content filter that requires authentication? Can you check the logs there to see if one of the non-working hosts is getting denied for some reason?
As a side note: I thought the remote help feature used the local server to perform its function. I could be wrong, but I don’t understand why it would going out to one of avasts servers to remote help someone on the local LAN.
According to our content filter logs, there isn’t anything being blocked. That was our first thought as well, so we took a few machines offsite and hooked them up to an open internet connection but had the same issue.
I’m purely speculating, but I think it uses the remote Avast server to generate the remote code.
No to the proxy/SSL decryption question - our content filter resides inline and doesn’t use any proxy settings (in other words, once you’re off network, you get free reign), and yes to the time being correct on the client machines that aren’t working. We’re grasping at straws too! We use this feature in our helpdesk extensively for remote support and its inaccessibility is crippling us. Thank you for the suggestions thus far!
At this point, I would start looking for similarities between the machines that aren’t working.
*Are they in the same container in AD?
*Same security group?
*Maybe based on the same version of an image file or operating system service pack level?
*Do you have WSUS or other patch management in place? Are they in the same group in that system?
*Are they in the same group in Avast! for getting their policy file?
*Did some update, patch, or configuration recently get applied to the computers in the non-working group that didn’t get applied to the working group?[/li][/list]
How are they different from the ones that do work? Other than resolving to the other IP address?
At this point, I would just have to sleuth it out step by step, comparing and contrasting until I pinned it down.
In an attempt at further troubleshooting, we removed Avast EPS from a machine that didn’t work and installed the free version. We confirmed that the remote assistance in the “free” version of Avast works without fail! The URL of the remote server is slightly different (free.ara.avast.com rather than rh.ara.avast.com), but the resolved IP address was the same in both cases. After removing the free version and re-installing the full version, remote assistance stopped working again (though the resolved IP was the same).
Needless to say we are stumped and slightly frustrated.
Can you expound a bit on how we can do this? Our subscription file states that we have an active subscription with 65 days remaining if this is what you mean.
Backing up a bit, since certificates are complex. Did you make sure the date, time, and time zone settings on the machines are correct? Still having to do with certificates, but not diving into the deep end yet.
Any chance the problem clients have some kind of firewall or filter turn on locally? Windows firewall or maybe even Avast! shield that the working clients do not have?
By default, Windows Firewall is turned off on our machines and I verified that it is off on the machines we’re using. I disabled all of the Avast shields while testing to no avail. I’ve confirmed that the issue is happening on both our Windows 7 and XP machines.
Have you tried uninstalling and reinstalling the Avast! client? I know it may not be a final solution, but it might help determine the underlying problem.
Yep, we did. Uninstalling and reinstalling the EPS client resulted in the same error. It was only when we uninstalled the EPS client and installed the free version did we get it to work. Sadly, after uninstalling the free client and installing EPS again, we’re back to the error.
Interestingly, some of our machines that were working a week ago are now starting to throw the same error. It’s rare that we find a machine in our environment that is working now.
I’m not sure if Avast! logs to the event logs of the system, so check their also. Maybe another even being thrown around the time you try and fail to remote assistance.
You might be on to something here. Here’s the output of that log file right when I tried a remote assistance session. It seems your thoughts on the certificate might be on point. Now - what to do to fix? ;D
2015-03-02 10:43:19,553: [ARA_DLL] INFO - Wks: WKSServer ARAWksBase::ThreadProcedure - entry point
2015-03-02 10:43:19,678: [ARA_DLL] ERROR - ARASSLSocket::VerifyPeerCertificate - Verification of the peer certificate failed,
2015-03-02 10:43:19,678: [ARA_DLL] ERROR - Wks: WKSServer - ARAWksBase::DoError - Local error 0x1000e occurs
2015-03-02 10:43:19,678: [ARA_DLL] INFO - Wks: WKSServer - The session has been teminated
2015-03-02 10:43:19,678: [ARA_DLL] INFO - External Abort of Current Session is requested
2015-03-02 10:43:19,678: [ARA_DLL] WARN - StopStandaloneServer: Server is already stopped
2015-03-02 10:43:19,679: [ARA_DLL] INFO - External Abort of Current Session is requested
2015-03-02 10:43:19,679: [ARA_DLL] WARN - StopStandaloneServer: Server is already stopped
