Hi all,
We have recently started trialing webroot for some business clients.
Webroot works fine if the client device has full access to the internet. However we come across problems when the clinet PC is behind a corporate firewall that blocks all direct outside internet connectivity - webroot installes but does not do an initial scan so does not work.
I found a list of IP's that need to be allowed for Webroot, and opened all these but it still doesn't work. I ran a packet sniff and I find that webroot is trying to connect to another IP address that is not on the list!:
g76.p4.webrootcloudav.com
C:Windowssystem32>ping g76.p4.webrootcloudav.com Pinging rona5-1483468263.eu-west-1.elb.amazonaws.com [176.34.235.43] with 32 bytes of data: Request timed out.
Some of our clients have a proxy server to permit devices to connect to the internet. If IE has the settings for the proxy server configured webroot always tries to connect via the proxy even if I have selected "no proxy" in the webroot settings. So even if I am on a network with full internet access, and have a proxy set Webroot does not work.
Am happy to be corrected if possible but Webroot does not seem to be a suitable product to deploy in a secure environment.
Webroot on clients behind firewall
+6Contact Webroot Support for the latest list of domains to allow through the firewall. These are the ones listed in the administrator guide, but there will be a new version out in the next few weeks so I wouldn't trust it to be 100% correct. Not really sure why they're asking for *.compute to be whitelisted since it's not Webroot specific, I'm sure they can shed some light or get you something more exact... PrevX is a legacy domain owned by Webroot.
*.webrootcloudav.com
*.*.webrootcloudav.com
*.p4.webrootcloudav.com
*.compute.amazonaws.com
*.webroot.com
*.webrootanywhere.com
*.prevx.com
Not to sound like an absolute shill, but Webroot support isn't like other companies. You call, you get connected direct to the same enterprise support team in Colorado every time, and they'll ask a developer if they don't know an answer. (They also have support in Australia and Dublin for other timezones if I remember correctly) A surprisingly big factor in us staying with them through the bumps.
*.webrootcloudav.com
*.*.webrootcloudav.com
*.p4.webrootcloudav.com
*.compute.amazonaws.com
*.webroot.com
*.webrootanywhere.com
*.prevx.com
Not to sound like an absolute shill, but Webroot support isn't like other companies. You call, you get connected direct to the same enterprise support team in Colorado every time, and they'll ask a developer if they don't know an answer. (They also have support in Australia and Dublin for other timezones if I remember correctly) A surprisingly big factor in us staying with them through the bumps.
Thanks for your response.
Hopefully there is someone from webroot reading this, but I don't really feel that its an acceptable solution. It sounds like if you run webroot in an enterprise you need to open your firewall to every site or service that is hosted on Amazon.
Another issue is that most firewalls do not work with URL's only IP addresses.
Hopefully there is someone from webroot reading this, but I don't really feel that its an acceptable solution. It sounds like if you run webroot in an enterprise you need to open your firewall to every site or service that is hosted on Amazon.
Another issue is that most firewalls do not work with URL's only IP addresses.
+6I know exactly where you're coming from and I agree, just giving wildcard domain names for firewall access is not a solution for many businesses. I still encourage you to contact Webroot support directly, but I've raised the flag with one of my contacts to get this responded to as soon as possible. They may be sending you a private message.
I think I'm going to be running into this in the near future for a subset of our users and I am interested in their response like you.
I think I'm going to be running into this in the near future for a subset of our users and I am interested in their response like you.
Hi explanoit and sossie07
The Webroot Intelligence Network (WIN) is hosted on the Amazon Web Services Elastic Compute Cloud (AWS EC2). AWS EC2 uses Public (IPV4) internet addresses which are a scarce resource. There is only a limited amount of public IP space available, and Amazon EC2 is committed to helping use that space efficiently, so Amazon uses the URL *.compute.amazonaws.com and therefor our IP addresses change very freaquently. Even if we were able to use a static IP address or addresses due to the elastic nature of AWS EC2 our customers would have to constantly update their IPs to bypass or use an IP range which would not always be occupied by Webroot.
Regarding proxy detection, our 2014 refresh is much better at automatically detecting the presence of a proxy. That being said, if a proxy is present we recommend deployment that includes proxy credentials. Please see our video on deployment for the best practices.
As for prevx.com explanoit is correct that it is a legacy domain however we may use the domain for some time. If this changes and the bypass of *.prevx.com is no longer required we will inform you guys :D
If your firewall does not accept URLs or URLS with an asterix (*) the other option is a proxy bypass on g*.p4.webrootcloudav.com
Jack
The Webroot Intelligence Network (WIN) is hosted on the Amazon Web Services Elastic Compute Cloud (AWS EC2). AWS EC2 uses Public (IPV4) internet addresses which are a scarce resource. There is only a limited amount of public IP space available, and Amazon EC2 is committed to helping use that space efficiently, so Amazon uses the URL *.compute.amazonaws.com and therefor our IP addresses change very freaquently. Even if we were able to use a static IP address or addresses due to the elastic nature of AWS EC2 our customers would have to constantly update their IPs to bypass or use an IP range which would not always be occupied by Webroot.
Regarding proxy detection, our 2014 refresh is much better at automatically detecting the presence of a proxy. That being said, if a proxy is present we recommend deployment that includes proxy credentials. Please see our video on deployment for the best practices.
As for prevx.com explanoit is correct that it is a legacy domain however we may use the domain for some time. If this changes and the bypass of *.prevx.com is no longer required we will inform you guys :D
If your firewall does not accept URLs or URLS with an asterix (*) the other option is a proxy bypass on g*.p4.webrootcloudav.com
Jack
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.