SurfProtection temporarily blocking all websites?

I've seen a similar problem with 5.207 (and previous) where once in a while a known good site will get blocked as Spyware. If I retry, it will work on the second or third time, and be fine after that. Only things blocked are Virus and Spyware. Doesn't happen often enough to be a big concern, but it is somewhat annoying.

Hello Friends,

I faced your problem but it was solved by installing the 6.100 and upgrading to new patch. Frankly speaking, they release this patch for me  

You will have a good performance for the url filtering.

But to remind you that your external NIC should have a public IP.

Enjoy ASTARO

Our ASL-support-company has taken a look at this a couple of weeks ago, and they also contacted Astaro. Seems like our ASL (v5.208) sometimes cannot reach one of the Cobion database-servers. Then it seems to assume the requested URL belongs to ALL taboo-categories and blocks it, showing a message like this one:

URL: http://www.iss.net/products_services/webfilter/send_test_site.php
Unallowed category Sects(11)
Unallowed category Gambles(17)
Unallowed category Computer Games(18)
Unallowed category Toys(19)
Unallowed category Alcohol(39)
Unallowed category Tabacco(40)
Unallowed category Self Help/Addiction(41)
Unallowed category Dating/Relationships(42)
Unallowed category Sports(46)
Unallowed category Weapons(55)
Unallowed category Spyware(60)

 In this case, Cobion (now ISS) block it's own website! That would be funny, if it wasn't so annoying. Our ASL-support told me, none of their other ASL-5.x-customer has experienced this problem and ASL 6.x would solve it. (but if we upgrade, maybe we're only going to be the first customer experiencing this problem with ASL 6.x?)  [;)]

Desperately waiting for v5.209 ...

I'm a reseller, and 6.x may solve your problems, but maybe not.  We have seen issues with timeouts contacting various Cobion servers (in our case, specifically one that is located in Spain!) ... they can't explain why it is happening.  Other sites we have setup work OK.. I think it's some issues with the ISPs involved.  Unfortunately, there is no way in WebAdmin to disabling selected Cobion servers.  This is a feature request I've put in for inclusion hopefully in a future version.  There is a way to manually change the http.xsl file in /var/chroot-http/etc/  to remove the offending server(s).  This fixes it in all the cases we've dealt with.  Your reseller should contact Astaro to get authorization to do this, as any unauthorized changes via SSH may void your warranty / support contracts with Astaro.  It just takes 3 minutes with VI to fix it.

Thanks a lot for the tip! I'll contact our reseller immediately. I'll report back if it helped.

Thanks a lot for the tip! I'll contact our reseller immediately. I'll report back if it helped.

Incidentally, they should be able to see what servers are timing out via the Content Filter logs.

I don't know what is going on with the Cobion Protection.

It was supposed that the new patch 6.101 will solve the problems of cobion protection.

For my case, still facing the problem. My Astaro is not filtering, the log file shows "Query Failed" while connecting to Proventia Mail Filter.

I feedup from this issue, I am not going to filter. Open Policy

Bye

Hello BrucekConvergent,

our reseller says they did a tcpdump on our astaro, which showed them, which server was causing trouble, and that more than one cobion-server was unreacheable or anwsering with "reset"-commands. Is there no log-file, where I can look up which Cobion-server was unreacheable?

Hello Friends,

Please, take note that I am able to use Kerio Winroute which has the orange filter (it looks like cobion) successfully.

I guess it is not a matter of my ISP, it is a matter of Astaro.

Please, let me know (eng_ali1979@yahoo.com, wee_aliismail@hotmail.com) if this problem is solved.

Regards,

The Content-Filter Logfile (at least on 6.x) shows which server is timing out... just run it in live log mode, and let people browse until you get a timeout.. if your problem is intermittent contact with the troublesome server(s), it may take a while.  In our case it was definitely the servers in spain that were giving us issues.. we just took all of them out, although only 1 was really giving us a problem.  tcpdump may be able to show this... but I just used the content-filter logs, made it real simple.