HTTP Proxy broken

Hi Joe,

Try checking whether you have dual AV scan enabled.  If you are running on dual scan if one of the scanners is missing an up2date you will be blocked.  Running on single mode have never had a problem.

Quite a few people experienced this issue today. In my case, the issue was that the Clam AV database was empty. Astaro Support had to SSH into my Astaro box to reload the ClamAV definitions, but some may be having the same issue with Avira defs as well.

Quite a few people experienced this issue today. In my case, the issue was that the Clam AV database was empty. Astaro Support had to SSH into my Astaro box to reload the ClamAV definitions, but some may be having the same issue with Avira defs as well.

I have experienced this issue at home on my private ASG.

Every time I make a HTTP POST request on a webpage, I get the ASG-Error page with Error message: No AV Database. Even now on replaying this posting. This happens on every web page. Only workaround: Turn off antivirus with an exception.

Updated yesterday from 7.306 to 7.400 without any problems, pattern update is on and has find/installed new pattern.

UPDATE: Solved the problem. Switch Dual-AV off to Single-AV, wait a day and switch back to Dual-AV-Scan. Problem is gone.

Regards,
Manuel

Hmm, if its a pattern directory missing on the http proxy try the following from ssh to confirm your 2 AV engines are present.  

cd /var/storage/chroot-http/var/pattern

ls -l should show 2 directorys: avira and clamav

If clamav for example is missing:

mkdir clamav
patterndist clam

cd /var/storage/chroot-http/var/pattern/clamav
ls -l
Inside this directory should now be pattern files.

Can run the same thing if avira is missing:

cd /var/storage/chroot-http/var/pattern

mkdir avira
patterndist avira
cd /var/storage/chroot-http/var/pattern/avira
ls -l

Hope this helps out!

That's great information, Cath, thanks!

Scott, Was the amount of time spent by Astaro support consistent with the straightforward steps recommended by Cath?

Thanks - Bob

That's great information, Cath, thanks!

Scott, Was the amount of time spent by Astaro support consistent with the straightforward steps recommended by Cath?

Thanks - Bob

That information on the pattern def directories I had is actually from Astaro Support so I'll have to give them the credit [:)]

Cath, you brought us the knowledge!  That you were smart enough to get someone else to figure it out is just another plus! [;)]

Cheers - Bob

Yep, patterndist clam is what support ran on my system to fix the problem.  It took about 10x as long for me to get support access to my system than it did to run the fix itself with temporary acl changes.

Thanks Scott, Cath and Bob.

It seems that was the issue but it was resolved over time.
I checked just now and had both directories with files in them. I was also able to logon here and to https sites with out issues, weeee.

But.... The second part of my problem still exists. 
Users STILL cannot access the internet.

I have Astaro HTTP proxy running in transparent mode.
The Astaro is blocking all traffic to port 80 on its internal IP.
He is a bit from the packet filter love log:
10:22:03 Default DROP TCP 192.168.10.36 : 1202  → 192.168.10.25 : 80 
 [SYN] len=48 ttl=128 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:0d:60:f5:46[:D]6 
10:22:05 Default DROP TCP 192.168.10.36 : 1202  → 192.168.10.25 : 80 
 [SYN] len=48 ttl=128 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:0d:60:f5:46[:D]6 
10:22:11 Default DROP TCP 192.168.10.36 : 1202  → 192.168.10.25 : 80 
 [SYN] len=48 ttl=128 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:0d:60:f5:46[:D]6 

All users have (and have had) internet explorer proxy settings set to use port 80 for http/https (for the last 6 months with out a problem).

Whywould it suddenly stop. The only reason I am able to access the internet and this site is:
1) I remove or uncheck the proxy box.
2) Or change the http/https port to 8080

If "transparent mode" was working, it seems to me that it would pickup all http traffic no matter what port the users proxy settings were.

Thanks,
joe