[7.004] HTTP Proxy doesn't work anymore in Standard Mode

https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32078

Let's just link ourselves up, shall we.

Good to know its not just me.

Hallo,

the same at my machine. Updated to 7.004. The proxy-port was the 8080. Then I have changed the port 3128. Now I can see notifications, that the proxy-server is not running and will be restarted. I can't connect to the web.

Whats wrong with 7.004 ?

Best regards from
Egbert

Price.  It is cheaper for me to run it on a small box internally. Since I am a commercial entity, I have to pay for the ASG.

Here is my response from Astaro Support:
"Apologies I had misread the original post and missed the generic proxy point.

We will send this as a report to our development team to address.  

The 7.003 up2date included a large number of http proxy changes which is what likely is affecting the 8080 port."

I have had to set up my proxy port on DNAT which I didn't have to do before.  I only had to specify my proxy in the Advanced Tab.
No big deal, but I cannot NAT port 8080.  I get denied every time.  3128 DNATs just fine.
So what IS the problem with port 8080.  Why can I not NAT it?


I am now having another problem.  Everytime traffic gets a little congested here (we only have a partial T1 - 512) https and smpt stop working for users.    A reboot clears it right up.  I am ready to re-install to 7.002 at this point.

Reelgaming,
I have noticed a similar problem with the hhtp proxy in standard mode under load. I have 1536/256 ADSL service, the load being a number of users 2 or 3 in my case with the link running about 1/3 utilisation I get DNS proxy failures.

What I am getting at, is I noticed and commented on it in V7.002.

Ian M

Well I did a clean install and configured manually the ASG-box. With V7.003 everything works ok. Then I updated it to V7.004. After 1,5 hour the HTTP Proxy doesn't work anymore, rebooted it and still it won't work. I did again a clean install and until now (V7.003) it still works properly. So I think it's a bug in V7.004.

I've run into this with ASG7.004. We are having the HTTP proxy just stop at various times during the day. I don't know whether is load related or otherwise. The squid daemon is still running, the squid logs don't indicate a crash or otherwise - the daemon just stop processing traffic. Restarting the HTTP proxy resolves the issue.

This only started occuring after we upgraded to 7.004.

Any ideas anyone?

PS. I'm running in transparent mode.

I have done a clean install.  I have gone to 7.002 as I am afraoid to proceed further.  Things seem to be running fine right now.
I hope that they can get this straightened out so I can upgrade.

Hi guys, 

its working as expected in my case.

Are you using anything special?

regards
gert

I am seeing the same problem. Random stops and out for a short to a long period of time - like I say it is random and there does not seem to be a pattern developing...

I am seeing this in transparent mode... I have not tested with standard mode...

--Ray

P4 1.3
1.5 GIG Ram
80 GIG Drive
Intel Pro100s Nics

Nope, nothing special. Same hardware as I used for V6.x, beta's V7.x and final releases of V7.x .

I'm running the HTTP proxy in standard mode, and it has stopped working on three occasions since I installed 7.004 two days ago. The first two times the proxy was re-started automatically, but on the last occasion I ended up rebooting the firewall to get it to work once more.

As other posters have mentioned, there seems to be no obvious reason why this happens.

No - nothing special. We had the proxy stop for a fourth time in four days ... so I decided to just change the port number from 8080 -> 3128. No everything seems to be OK. Been up for two days without a hitch.

No - nothing special. We had the proxy stop for a fourth time in four days ... so I decided to just change the port number from 8080 -> 3128. No everything seems to be OK. Been up for two days without a hitch.

The http proxy on my ASG usually stops at least twice a day and the socks proxy at least once a day.

Ian M

what is the cli-command to restart the proxy? /etc/init.d/squid restart?

If you review the Squid log (/etc/squid.log) from the CLI you will notice that there are configuration errors in it:

createRemovalPolicy_heap: Unknown key type "lfuda". Using LRU

This relates to these two directives:

cache_replacement_policy heap lfuda
memory_replacement_policy heap lfuda

This error is probably occuring due to the binary not being compiled with the --enable-removal-policies=heap directive.

Then:

WARNING: Very large maximum_object_size_in_memory settings can have negative impact on performance

maximum_object_size_in_memory 51395 KB

Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

I'm not sure whether this has anything to do with the cache halting but Astaro should definitely revisit their cache tuning configuration.

If you review the Squid log (/etc/squid.log) from the CLI you will notice that there are configuration errors in it:

createRemovalPolicy_heap: Unknown key type "lfuda". Using LRU

Yep, I see this, too.

WARNING: Very large maximum_object_size_in_memory settings can have negative impact on performance

maximum_object_size_in_memory 51395 KB

Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

I agree that even on big hardware values larger than a couple megabytes or so should not significantly improve performance. The default is 8KB!

On my system w/512MB, the maximum_object_size_in_memory is 25762KB and the cache_mem size is 51526KB. I think a more reasonable size for squid would be to set cache_mem to 1/20th the total memory size and the max object size to 1/200th of the cache_mem size.

In addition, the cache_swap_low/high settings could be tweaked as well.

Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

BTW, a quick google search reveals this set of benchmarks:

http://lynx.fnal.gov/ntier-wiki/Squid_20performance_20for_20big_20objects

They found that keeping the max object size in memory setting small tends to work much better regardless of  the cache_mem setting.

I was advised by Astaro Tech Support of this today. It would _appear_ Astaro is aware of the problem.

Anyone have the contents of /var/storage/chroot-squid/etc/squid.conf from 7.003 handy???? Would love to see what the old settings were.

> James,
>
> Thank you we'll check into this.  The last major change to the 7.004 was
> the increasing of the cache size to accommodate more objects in the proxy
> cache.  The next update should include a change to move cached objects out
> of memory and into the HD cache more efficiently to address performance
> problems locking up the proxy.
>
> Best regards,
>
> Cameron Byers  |  Support Engineer
> Astaro Corporation
> supportus@astaro.com
> https://my.astaro.com/support/cases.php  | Support Form
> www.astaro.com/kb  |  Astaro Knowledgebase

I was advised by Astaro Tech Support of this today. It would _appear_ Astaro is aware of the problem.

It looks like they may be, reducing the memory utilization of squid and letting the OS handle more of the caching duties should improve the performance of the system over a wider variety of system loads.

Anyone have the contents of /var/storage/chroot-squid/etc/squid.conf from 7.003 handy???? Would love to see what the old settings were.

Well, my 6.304 system has the same ratio of disk space, max object sizes and cache_mem settings allocated to it based on the size of the /var/storage system and amount of memory in the systems, so I doubt that those have changed unless they reduced one of those settings early in V7 for some reason.

This is hot off the press from Cameron:

James,

We can certainly try setting these to a lower value, however it may be overwritten with the new 7.005, which really shouldn't be an issue as it should do this to help correct the storage issue.

The settings to modify this cache are:
joe /var/storage/chroot-squid/etc/squid.conf

Under the Cache tuning section:

maximum_object_size_in_memory 25711 KB
maximum_object_size 108 MB

Change these to a 5 MB max memory file and only a 20 MB object size:

maximum_object_size_in_memory 5120 KB
maximum_object_size 20 MB

Too bad they are reducing the maximum_object_size. [:(]

That value should be proportioned related to the amount of disk space used for the cache, where the maximum_object_size_in_memory should be proportioned slightly according to the cache_mem setting.

All IMO and IME, of course. [;)]

Upgraded 2 firewalls here yesterday to 7.004.  Had no issues prior, but now the HTTP proxy stops serving requests every few hours on each of them.  No config changes were made other than the update.

Disable and re-enable HTTP proxy will make it work for a while.. and then it stops again.  

I do not think the problem is actually the HTTP proxy but rather the AUTO_INPUT packet filter table that the middleware manages.  For some reason, the firewalls just start dropping packets to its own http proxy after a while.

We also have other strange things due to packets being dropped by the middleware managed INPUT filter, such as we sometimes cannot access the Webmin interface from external networks.

We also are getting trouble tickets on PPTP VPN problems, their sessions seem to stop passing traffic after several minutes, not sure if its related.  Using L2TP seems to help with or resolve these.

This is not good for us, and rolling back to 7.003 is going to be a real PITA, with management types upset.   Thank god its a three day weekend.. at least for everyone else [[[:(]]] [[[:(]]] [[[:(]]]