ASG tweaking

The licenses count, as tracked by ASG, is only based on the number IP Addresses connecting through the ASG.  The number of users, user accounts, or email addresses is immaterial.

Thank you Scott. 
I really think I have to change my reseller.... [:@] [:@]

Eclipse, in all fairness to your reseller, if an Astaro is only used to protect a mailserver, the license agreement requires a license for the number of email addresses.  In your case, that would be 50.

Given your other issues about RAM use and responsiveness, I agree that you might want to transition to your own server with a 50-IP license to get better performance and lower your costs.  The easiest time to start that process is about three months before your current subscriptions expire.

Cheers - Bob

Eclipse, I bet a 100-IP license would work for you.  As root, try:

count_active_ip.plx --showcount –debug 

Cheers - Bob

Reading the query performed by this command I have seen that it excludes all ASG ip addresses, APxx too... nice!

Hardware:
DNS forwarder:
I sometimes have seen, that some people are using their internal domain DNS servers as forwarders for ASG. This is a possible bottleneck, because ASG is very DNS dependent. Better use public DNS servers as forwarder. I also do not recommend to simply put the single DNS servers into the dns forwarder field, because ASG seems to distribute it's requests via round robin across these DNS servers. If one of these servers fail, you may experience very strange behaviour. I usually create a availability group containing my public DNS servers I want to use, and use this availability group as forwarder. Requests to special domains (e.g. you internal AD DNS) should be created via DNS request route.

Quality of Service (QoS):
Ok. This one is to handle carefully. QoS can be a nice thing, but you also can mess up your ASGs performance, depending on you mainly traffic usage. In many cases I can live very good with the automatic tuning options, and the rare usage of manual bandwidth pools / traffic selectors (for S2S VPNs or RED traffic for example). I personally found these settingbehave very well in most scenarios:
==> First check the QoS Interface speeds for standard Ethernet interfaces. Sometimes ASG seems not to use the right bandwidth for 1Gig Interfaces (102400 kbit/s instead of 1024000 kbit/s).
==> Then check the other interfaces speeds (as internet uplinks, RED interfaces, separate zone WIFI interfaces) and set them to appropriate values (do not forget to check the "limit uplink" setting)
==> For the different Interface usage types I found following settings working well, and keeping the reactivity for all connected systems fairly well distributed:
==> Internet Uplinks (Interfaces connected to Internet) - Only use the "Uplink Optimizer" setting
==> Locally connected Ethernet Interfaces as LAN or DMZ - I found the usage of the "Download Equalizer" setting behaving nicely here. This feature seems to lower you maximum throughput for a single user by ~20%, if he is able to saturate the interface bandwidth, but also keeps other connected workstations pretty reactive, if they for example are surfing at the same time.
==> separate zone WIFI interfaces: I personally found here the same settings as for local ethernet interfaces (only "download equalizer") behave nicely. I've set interface speed for AP30 to 144MBit. Maybe lower values would be more realistic, but it work well this way
==> RED interfaces - This depends heavily on RED usage / traffic type. Mostly I use "upload optimizer", because this helps with VOIP and websurfing...But for some scenarios no QoS at all, or the "download equalizer" may be a better setting.
=> The from ASG used technologies as RED, SFQ etc. are mentioned in the ASG online help. Google ist dein Freund or Wikipedia is you friend to find more detailed informations to these techniques (very interesting stuff to read).

Webproxy (Ok, 8.201 has obviously some flaws, where tweaking may not help at the moment, but I still find these settings helping me to keep the surfing pleasure quite nice):
==> I use webcaching. BUT - I personally believe, that some content makes no sense to be cached (as pics, flash banners etc.) because most websites are dynamic, and the content changes a lot, which will lead to a low cache hit rate. Furthermore it may lower your disk I/O - especially on a heavily used webproxy. I will list below a list of content in perl regex notation, from which I belive this helps me to keep the diskcache small. Furthermore in my eyes small content as pics as 3-4KB GIFs or a favicon.ico will be delivered faster via Internet from the webservers memory cache compared to the local diskcache ;o)

Under Web Security / Webfilter / Advanced I have caching activated, and all checkboxes marked (HTTP, HTTPS and content from sites with cookies)

Local Content Filter Database:
==> This is a nice feature, but makes in my eyes only sense in a few scenarios, where heavy web usage makes categorization noticeable slower. I personally know 2-3 such sites, where the local CFDB helped to solve this issue under 8.1x ;o) But there was ~3500 concurrent Users surfing...
==> My opinion here is to test first without local CFDB, after applying all these mentioned tweaks in this thread. Especially on lower memory boxes no local CFDB performs way better than a local CFDB which may swap as hell...
==> Local CFDB in MEM may make sense starting from a 4GB+ Appliance, where without local CFDB maybe 50-60% of the mem already are in use
==> Local CFDB on DISK may make sense on boxes from 2...4GB memory, if there are fast disks installed. For VM Appliances in my eyes also not always recommended (test for your own). For Appliances with 1GB not recommended too - it works, but the heavy usage of swap makes it in my eyes not recommendable for those small appliances...in best case useable, if a 1GB Appliance is solely used as webproxy.
==> Local CFDB Howto can be found here

==> Caching Exceptions: Creating a exception in the webproxy to skip chaching for following URLs:
[EDIT 17-10-2011: New Regex for exceptions. using now the "$" to read the string from the end backwards, instead as before from start of the string using the caret "^". Seems to be faster / using less ressources]

^https?://[A-Za-z0-9.-]*google\.[A-Za-z]

\.ico$

\.pdf$

\.smil$

\.mp3$

\.wav$

\.mp4$

\.gp$

\.divx$

\.mpg$

\.mpeg$

\.avi$

\.wmv$

\.wmf$

\.mjpeg$

\.mov$

\.png$

\.jpg$

\.jpeg$

\.gif$

\.bmp$

\.xml$

\.html$

More Informations to regular expressions can be found here

Hope these tweaking settings may be helpful to anyone giving it a try. Please comment your personal findings, if using any of these tweaks.

I'm only going to address the things i do not agree with in detail.  Everything else i personally have no problems with..[[:)]]  

using public dns is only good if you are NOT using anti-spam.  Every major spam list service will reject your dns queries if you route them though public dns.  Use your isp's dns servers.  If you ahve your own dns server feel free to use it as long as your internal dns dows NOT route its external dns queries though a public dns...then you are in the same boat as above.  

Astaro is DNS dependent but if you configure it right it is a sinch.  For internal networks(aD, Novel..etc etc) do NOT use the Astaro as your external DNS.  Use the dns routing to route all internal requests to the internal dns server so internal dns works correctly.  From the SSO server have it use the isp assigned dns servers as it's forwarder..not the Astaro machine.

For other networks that do NOT have any kind of SSO you can then use the astaro as the forwarder provided you are using ISP dns as the forwarding servers not public dns.

if you are purely a home network with no internal dns then using public dns as astaro's forwarding destination and having the machines use astaro as their dns server works fine.

as for proxy caching...with how many sites are dynamic(aka generated upon request) and not static caching really isn't going to help much.  Combine that with the fact that http cache won't cache anything larger than 100K it's not really that useful.  It takes up disk space and really doesn't make the pages render faster.  Combine all of this with the smart/dynamic caching of modern browsers which do a much better job at caching than astaro's http proxy I would just leave the http proxy cache off.

Local Content http database:  put it on the disk if you have less than 2 gigs of ram..use ram if you have 3 gigs or more.  The difference may not be apparent..until the cff database servers(which are "cloudy" have issues of some kind..and they do often.  If you use a local cff cache you are effectively immune to inet connectivity issues slowing you up..here's how the cff works:
1. you head to CNN.com International - Breaking, World, Business, Sports, Entertainment and Video News
2. http proxy has to send that url to cff cloud...this is an automatic minimum 50 ms of delay(the average i see form three installs is 100 ms) to the request
3. if cff cloud isn't overloaded you get responses reasonably quickly..if not you wait for the response..then it travels back to you(at least another 50 ms)
4. If you pass cff muster you can finally go start fetching your content.
5.  client start seeing content.

let's keep one thing in mind..this process is not done per page..but is done PER LINK in every page.  These delays stack up nicely.  cff does some minor caching to help hide the delays...sometimes..[[:)]]

If you do it locally you only have 10ms delay(to search disk) or 20 NANOseconds(in the case of ram lookup).  You have already cut down cff resonse by a minimum of 10x.  There's no real reason(other than Astaro still has NOT made this a webadmin feature despite over a YEAR's worth of promises).  Of course this could void support so you may have to do this at your own risk.  

Your content exceptions:
Considering the amount of malware being transported by pdf's excluding that is leaving yourself open to malware.  Don't depend on desktop a/v..these have been defeated many many times by this stuff.  excluding html and xml is the same thing.  you WANT to scan the html and xml pages/feeds as well as their contents.  also don't skip flash/java/or any other embedded content type as they are the primary malware carriers right now.  I have actually raised my scanning size to 30 megs to make sure all pdf's get scanned..after something go by due to having the limit lower(5 megs) i'm not taking chances now.  Everything is also subject to dual scanning as well.

using public dns is only good if you are NOT using anti-spam.  Every major spam list service will reject your dns queries if you route them though public dns.  Use your isp's dns servers.  If you ahve your own dns server feel free to use it as long as your internal dns dows NOT route its external dns queries though a public dns...then you are in the same boat as above. 

==> Never seen this issue. But may be with some ISP's. I also learn every day new things. But with all Installations I have seen using Google, OpenDNS or similar public DNS I never had RBL issues.

Astaro is DNS dependent but if you configure it right it is a sinch.  For internal networks(aD, Novel..etc etc) do NOT use the Astaro as your external DNS.  Use the dns routing to route all internal requests to the internal dns server so internal dns works correctly.  From the SSO server have it use the isp assigned dns servers as it's forwarder..not the Astaro machine.

==> That's how my recommendation was intended. Clients use internal DNS servers, those use ASG as forwarder...

For other networks that do NOT have any kind of SSO you can then use the astaro as the forwarder provided you are using ISP dns as the forwarding servers not public dns.

==> Non domain networks...as guest networks or smb networks without internal domain / DNS...

if you are purely a home network with no internal dns then using public dns as astaro's forwarding destination and having the machines use astaro as their dns server works fine.

==> Yup

as for proxy caching...with how many sites are dynamic(aka generated upon request) and not static caching really isn't going to help much.  Combine that with the fact that http cache won't cache anything larger than 100K it's not really that useful.  It takes up disk space and really doesn't make the pages render faster.  Combine all of this with the smart/dynamic caching of modern browsers which do a much better job at caching than astaro's http proxy I would just leave the http proxy cache off.

==> "http cache won't cache anything larger than 100K " - Where did you hear that ? There was once a bug in a 7.*** where it cached only such small sizes. But since years it's working fine. My .deb packets from my Ubuntu updates are cached nicely...also with MB sizes [[;)]]

Local Content http database:  put it on the disk if you have less than 2 gigs of ram..use ram if you have 3 gigs or more.  The difference may not be apparent..until the cff database servers(which are "cloudy" have issues of some kind..and they do often.  If you use a local cff cache you are effectively immune to inet connectivity issues slowing you up..here's how the cff works:
1. you head to CNN.com International - Breaking, World, Business, Sports, Entertainment and Video News
2. http proxy has to send that url to cff cloud...this is an automatic minimum 50 ms of delay(the average i see form three installs is 100 ms) to the request
3. if cff cloud isn't overloaded you get responses reasonably quickly..if not you wait for the response..then it travels back to you(at least another 50 ms)
4. If you pass cff muster you can finally go start fetching your content.
5.  client start seeing content.

let's keep one thing in mind..this process is not done per page..but is done PER LINK in every page.  These delays stack up nicely.  cff does some minor caching to help hide the delays...sometimes..[:)]

If you do it locally you only have 10ms delay(to search disk) or 20 NANOseconds(in the case of ram lookup).  You have already cut down cff resonse by a minimum of 10x.  There's no real reason(other than Astaro still has NOT made this a webadmin feature despite over a YEAR's worth of promises).  Of course this could void support so you may have to do this at your own risk. 

 

==> Didn't say local caching is bad. Indeed it's a nice thing [:D] But a low memory appliance swapping as hell performs crappy overall. Local CFDB will then make things even worse.

Your content exceptions:
Considering the amount of malware being transported by pdf's excluding that is leaving yourself open to malware.  Don't depend on desktop a/v..these have been defeated many many times by this stuff.  excluding html and xml is the same thing.  you WANT to scan the html and xml pages/feeds as well as their contents.  also don't skip flash/java/or any other embedded content type as they are the primary malware carriers right now.  I have actually raised my scanning size to 30 megs to make sure all pdf's get scanned..after something go by due to having the limit lower(5 megs) i'm not taking chances now.  Everything is also subject to dual scanning as well.

==> I did not recommend to exclude these filetypes from AV scanning, the recommendation was to skip caching[[;)]]

However. Any Feedback is welcome. As I also already mentioned these tweaks are not perfect for any scenario. They often help, but there may also be constellations, where these tweaked settings may do the opposite as expected.

==> Never seen this issue. But may be with some ISP's. I also learn every day new things. But with all Installations I have seen using Google, OpenDNS or similar public DNS I never had RBL issues.



==> That's how my recommendation was intended. Clients use internal DNS servers, those use ASG as forwarder...



==> Non domain networks...as guest networks or smb networks without internal domain / DNS...



==> Yup



==> "http cache won't cache anything larger than 100K " - Where did you hear that ? There was once a bug in a 7.*** where it cached only such small sizes. But since years it's working fine. My .deb packets from my Ubuntu updates are cached nicely...also with MB sizes
 

==> Didn't say local caching is bad. Indeed it's a nice thing [[:D]] But a low memory appliance swapping as hell performs crappy overall. Local CFDB will then make things even worse.



==> I did not recommend to exclude these filetypes from AV scanning, the recommendation was to skip caching

However. Any Feedback is welcome. As I also already mentioned these tweaks are not perfect for any scenario. They often help, but there may also be constellations, where these tweaked settings may do the opposite as expected.

==> Never seen this issue. But may be with some ISP's. I also learn every day new things. But with all Installations I have seen using Google, OpenDNS or similar public DNS I never had RBL issues.

Read the TOS of spamhaus and other RBL's it is very clearly stated they actively reject these queries.  If the queries continue they blacklist the public dns provider altogether..then your spam filters go nearly to zero..[[:)]]

==> That's how my recommendation was intended. Clients use internal DNS servers, those use ASG as forwarder..
nopers.  if they have internal DNS they need to use the isp dns as the forwarder not the ASG.  The asg should only use isp dns in the above scenario.  Avoid using the Astaro as a dns forwarder.  it is usually busy enough without additional work to do.  

==> "http cache won't cache anything larger than 100K " - Where did you hear that ? There was once a bug in a 7.*** where it cached only such small sizes. But since years it's working fine. My .deb packets from my Ubuntu updates are cached nicely...also with MB sizes
That's not been my experience..but i have not used their cache since it went to something proprietary.  I sit corrected.  I still don't reccomend it especially for .deb's or something that updates frequently.  if you want a cache setup a local mirror..[[:)]]  It's folks choice though.

==> Didn't say local caching is bad. Indeed it's a nice thing [[:D]] But a low memory appliance swapping as hell performs crappy overall. Local CFDB will then make things even worse.
That's why i said under 2 gigs use disk.  It is still at least 10x faster than cloudy.  Disk mode won't force a 1 gig appliance to swap.  If the disk i/o becomes a problem you need a faster disk or a faster appliance/server.

Interesting discussion you guys have there, however I didn't see anything in the spamhaus TOS that would suggest

... it is very clearly stated they actively reject these queries.  If the queries continue they blacklist the public dns provider altogether..then your spam filters go nearly to zero..[:)]

I don't understand the correlation. What does your dns forwarder have to do with spamhaus or any other RBL for that matter and how would spamhaus or any other website know what you are using as a DNS forwarder. All they ever see is your IP not your DNS forwarder[:S] They have restrictions against the amount of queries against their system but at 300,000 that is more than adequate for even a typical small business.

no..they will NOT see your ip....they will see the ip of hte dns server from which the anti-spam engine is using for dns based lookups..which will be the public dns.  When you do an rbl anti-spam check it is a dns query.  If you are using public dns what happens is the Astaro(or internal server) sends a dns query to the public dns...inside that query is the request for an rbl check.  That request is forwarded form the public dns to the rbl vendor..who will reject that check..rendering the rbl check moot for that mail.  That is going to significantly reduce the effectiveness of the astaro anti-spam engine.  In essence as i noted in another post in greater detail..if youa re using Astaro anti-spam do NOT use public dns on the forwarders of the Astaro itself.

http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage

specifically:
Check what DNS resolvers you are using: If you are using a free "open DNS resolver" service such as Google Public DNS or Level3's public DNS servers to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. Please use your own DNS servers when doing DNSBL queries to Spamhaus.

IOW: Don't use public dns with anti-spam products.