This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG tweaking

NOTE: the newest version of this guide is UTM Tweaking Guide 2.0.

I have listed here my very personal tweaking tipps for ASGs, which I'm using successfully since a long time, and which gave me in my very personal tests in different (mostly home user ASGs, but also some customer ASGs) good results. Measurements werde not done lab based, they are very subjective "how working through ASG feels", but maybe you like to give them a try...

This is not a official Astaro statement, these are my very personal opinions.

There are a few basic rules, which may help you keeping your ASG reactive and smooth from user view.

Hardware:
As Astaro declares 1GB memory as minimum requirement for ASG since version 7.4, i personally think, that starting from 2GB memory upwards working is fun - at least, if you are using all memory intensive features as IDS/IPS, webproxy, Mailproxy, Reporting. 1GB is ok for partial usage of ASG features.
Do I have to mention, that multicore also helps (Hyperthreading or "real" multicores) ? [:D]
==> minimum hardware requirement is not == recommended hardware [;)]

Basic networking settings:
Basically I recommend to make sure, that the "TCP Window Scaling" feature under "Network Security / Packetfilter / Advanced" is checked. For most scenarios this setting is a good tweak, unless your traffic mainly consists from small packets (serving a public DNS, VOIP etc.), or your ISP or networking infrastructure does not support "TCP Window Scaling" (only seen a few times in the last years). In V8 this setting is checked by default, in V7 not. So if you migrated from V7 to V8 this setting may still be disabled...
==> TCP window scale option - Wikipedia, the free encyclopedia

MTU on interfaces
Usually Ethernet Networks use a MTU of 1500. Make sure if you're using PPPoE/PPPoA (xDSL) for your Internet Uplink, that the MTU value is set lower (usually 1492 for PPPoE, but provider dependent I also already heard from other values as 1454 etc.). This should be done on the PPPoE Interface on the ASG if a xDSL bridge is used, but also on the according standard ethernet interface, if a xDSL router sits before the ASG, which makes the PPPoE connection.

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. Please use your ISP's public DNS servers instead of "open" servers as Google DNS or similar, if you're using ASG mailproxy / spamfiltering. Some RBL Providers seems to respond "not listed" for all requests - see for example Spamhaus FAQ (Thanks to William for this hint...)
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 (advanced settings: Test for UDP53 every 15s, fail after 3 missed tests). Requests to special domains (e.g. you internal AD DNS) should be created via DNS request route. Recommended DNS Setup is Clients use internal DNS/DC as DNS Server, Internal DNS/DC uses UTM as forwarder, UTM uses Public DNS Servers as forwarders).
DO NO MIX INTERNAL AND EXTERNAL DNS IN THE UTM DNS FORWARDER !!! THIS LEADS SOMETIMES TO STRANGE (MIS)BEHAVIOUR !!!

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 settings behave 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 "Download Equalizer" setting (against my earlier recommendation using "upload optimizer", the "download equalizer" setting seems to behave better with actual UTM versions)
==> Locally connected Ethernet Interfaces as LAN or DMZ - I found the usage of the "Download Equalizer" setting behaving nicely here. This feature seems to little lower your maximum throughput for a single user, 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. Especially in conjuction with the webproxy surfing fells somehow snappier with this setting.
==> 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. Simply try, whic setting behaves best for you.
=> 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 
==> I use webcaching. BUT - I personally believe, that some content makes no sense to be cached (as most graphics, flash banners etc.) as most todays 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 avoid unnecessary disk caching. Furthermore in my eyes small content as pics as 3-4KB GIFs or a favicon.ico will usually 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]

Edit 13-4-2012: minimized the exception list - seems to behave better (lower cpu usage for regex pattern matching ?)


^https?\://.*\.google\.[a-z|A-Z]
\.smil$
\.xml$
\.html$
\.htm$
\.swf$



Manual URL blocklists
Edit 13-09-2012: I used since long time manual blocklist entries to block some widespread ad/tracker and other sites. Seems, that this was a bad idea performancewise. I had only those 14 listed URL's (Regex'es) in the blocklist, but removing them completely greatly improved website loading times. Seems somehow to be logic, as every Regex has to be checked against EVERY item loaded within a website.

So my new recommendation is "DO NOT USE MANUAL BLOCKLISTS", at least as far as possible. Every manual URL / regex will slow down website loading. Probably using URL's instead of regex with wildcards may behave better (not tested...)

Edit 29.01-2014: changed regex from 
^https?://.*\.
to 
^https?://([A-Za-z0-9.-]*\.)?
as second version uses nearly 2/3 less iterations for longer URL's than the previous one. And since changes in the UTM 9.2 regex handling the previous regex also may lead to PCRE errors.

Valid up to UTM 9.1


^https?://([A-Za-z0-9.-]*\.)?econda-monitor.de
^https?://([A-Za-z0-9.-]*\.)?hurra.com
^https?://([A-Za-z0-9.-]*\.)?adtech.de
^https?://([A-Za-z0-9.-]*\.)?wemfbox.ch
^https?://([A-Za-z0-9.-]*\.)?econda.de
^https?://([A-Za-z0-9.-]*\.)?eloqua.com
^https?://([A-Za-z0-9.-]*\.)?twitter.com
^https?://([A-Za-z0-9.-]*\.)?webtrekk.net
^https?://([A-Za-z0-9.-]*\.)?chartbeat.com
^https?://([A-Za-z0-9.-]*\.)?google-analytics.com
^https?://([A-Za-z0-9.-]*\.)?addthis.com
^https?://([A-Za-z0-9.-]*\.)?sharethis.com



Since UTM9.2 you can choose to enter own regex, or only domains with the option to include subdomains, which is since UTM9.2 the recommended simple version.


IPS (Intrusion Prevention System):
Network Security>>Intrusion Prevention>>Advanced Tab>>Performance Tuning. Add the applicable servers within your network to this section to avoid unnecessary false positives and blocked connections. Will also help to lower load from IPS. (Thanks to Scott Klassen to remind this one...)

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



This thread was automatically locked due to age.
Parents
  • 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.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

Reply
  • 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.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

Children

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

    Interesting, but in the preceding FAQ they make mention of problems when your ISP redirects failed DNS lookups to a default page, i.e. prevents the "not found" result from being returned. That was the case with my ISP last time I checked, which is why I use OpenDNS instead. 

    Would it be possible to define a Request Routing rule to send spamhaus.org requests directly to Spamhaus?

    Sent from my iPhone using Forum Runner
  • Interesting, but in the preceding FAQ they make mention of problems when your ISP redirects failed DNS lookups to a default page, i.e. prevents the "not found" result from being returned. That was the case with my ISP last time I checked, which is why I use OpenDNS instead. 

    Would it be possible to define a Request Routing rule to send spamhaus.org requests directly to Spamhaus?

    Sent from my iPhone using Forum Runner


    maybe..give it a whirl..i would try opting out first.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow



  • maybe..give it a whirl..i would try opting out first.


    I would welcome suggestions how to implement this. I know how to set up a redirect, but how would I go about creating a network definition for the Spamhaus DNS servers - is is possible to create a network group definition based on NS records?

    Sent from my iPhone using Forum Runner
  • I would welcome suggestions how to implement this. I know how to set up a redirect, but how would I go about creating a network definition for the Spamhaus DNS servers - is is possible to create a network group definition based on NS records?

    Sent from my iPhone using Forum Runner


    dunno...i've never used anything but isp servers even if i had to opt-out.  In theory it should work...but that's all i can tell you there.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Thanks William for pointing out this shortcoming of spamhaus. I researched it a little more and when you query spamhaus using a forwarder lets say 4.2.2.1 for my dynamic IP 207.119.1.1, its queried something like this. 
    gatekeeper:/var/log # dig @4.2.2.1 1.1.119.207.zen.spamhaus.org
    

    ; <>> DiG 9.5.0-P2 <>> @4.2.2.1 1.1.119.207.zen.spamhaus.org
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER

    Notice the answer need to know only

    However when queried with a regular dns server you get 127.0.0.10
    gatekeeper:/var/log # dig @70.85.0.142 1.1.119.207.zen.spamhaus.org
    

    ; <>> DiG 9.5.0-P2 <>> @70.85.0.142 1.1.119.207.zen.spamhaus.org
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER

    The answer this time is 127.0.0.10 indicating that its in the end user IP range and shouldn't be sending mail.

    Thanks again for keeping us up to date on this.
    Regards
    Bill
  • dunno...i've never used anything but isp servers even if i had to opt-out.  In theory it should work...but that's all i can tell you there.
    I guess I'll let it slide for now, since I have no idea how to - or even if you can - define a network group that will dynamically reflect the current nameservers for spamhaus.org.  It appears that Request Routing target servers must be spcified by IP address (which makes sense to avoid potential lookup loops).

    However, after trying the dig commands suggested by Billybob, it appears that Spamhaus is happily returning results via both OpenDNS and my ISP's DNS relay, so I guess the point is moot for now, but it would be nice if there was a way to define a request route - or specify different forwarders - for RBL lookups.
  • I usually don't use google or opendns name servers with astaro and use GRC's*|*DNS Nameserver Performance Benchmark** dns benchmark tool to find the closest servers (other than my ISP or other non redirecting servers) and most of them work fine with spamhaus.

    I did some more tests on spamhaus and the results are mixed. If you read the notes from spamhaus, http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage they suggest don't use google or Level3 but recommend using your own DNS server. Well astaro is using its own DNS server using 4.2.2.1 as a forwarder in my test configuration. Remember in my previous tests, 4.2.2.1 fails with spamhaus.

    So if you define 4.2.2.1 as your forwarder in astaro and then run the same query as before

    gatekeeper:/var/log # dig 1.1.119.207.zen.spamhaus.org

    ; <>> DiG 9.5.0-P2 <>> 1.1.119.207.zen.spamhaus.org
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER
     you get an answer.... AHA!!! how could that be??? So I tested again with my windows machine. Use 4.2.2.1 as your dns server in windows network configuration

    C:\>nslookup 1.1.119.207.zen.spamhaus.org
    Server:  vnsc-pri.sys.gtei.net
    Address:  4.2.2.1

    *** vnsc-pri.sys.gtei.net can't find 1.1.119.207.zen.spamhaus.org: Non-existent
    domain
    and then tested again with astaro as dns server (remember astaro is using 4.2.2.1 as a forwarder)

    C:\>nslookup 1.1.119.207.zen.spamhaus.org
    Server:  gatekeeper.local
    Address:  192.168.0.1

    Non-authoritative answer:
    Name:    1.1.119.207.zen.spamhaus.org
    Address:  127.0.0.10
     and it works[;)] 

    Remember, William has had problems with the above setup so its up to you to decide if you want to run a setup like that. That way you will have no one to blame but yourself if you go that route and get unexpected results[:D]

    Regards
    Bill
  • I usually don't use google or opendns name servers with astaro and use GRC's*|*DNS Nameserver Performance Benchmark** dns benchmark tool to find the closest servers (other than my ISP or other redirecting servers) and most of them work fine with spamhaus.

    I did some more tests on spamhaus and the results are mixed. If you read the notes from spamhaus, http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage they suggest don't use google or Level3 but recommend using your own DNS server. Well astaro is using its own DNS server using 4.2.2.1 as a forwarder in my test configuration. Remember in my previous tests, 4.2.2.1 fails with spamhaus.

    So if you define 4.2.2.1 as your forwarder in astaro and then run the same query as before

    gatekeeper:/var/log # dig 1.1.119.207.zen.spamhaus.org

    ; <>> DiG 9.5.0-P2 <>> 1.1.119.207.zen.spamhaus.org
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER
     you get an answer.... AHA!!! how could that be??? So I tested again with my windows machine. Use 4.2.2.1 as your dns server in windows network configuration

    C:\>nslookup 1.1.119.207.zen.spamhaus.org
    Server:  vnsc-pri.sys.gtei.net
    Address:  4.2.2.1

    *** vnsc-pri.sys.gtei.net can't find 1.1.119.207.zen.spamhaus.org: Non-existent
    domain
    and then tested again with astaro as dns server (remember astaro is using 4.2.2.1 as a forwarder)

    C:\>nslookup 1.1.119.207.zen.spamhaus.org
    Server:  gatekeeper.local
    Address:  192.168.0.1

    Non-authoritative answer:
    Name:    1.1.119.207.zen.spamhaus.org
    Address:  127.0.0.10
     and it works[;)] 

    Remember, William has had problems with the above setup so its up to you to decide if you want to run a setup like that. That way you will have no one to blame but yourself if you go that route and get unexpected results[:D]

    Regards
    Bill


    4.2.2.x are public dns servers so keep that in mind..[:)]

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 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.


    Thank you for this post.... That answer explains why my spam filter success dropped from 94% to 72% about a year and a half ago. That must be around the time they started blocking openDNS which I have used for 4+ years.

    To be honest, I actually thought that ASG made direct queriers to the black lists servers and didn't use the forwarders for RBL Activities. I know that works because you can set your name server in nslookup to point to spamhaus and query them directly and it works. That might be a feature enhancement for the product.

    Any how thanks again for bringing this to our attention; that should really be added to the help documentation of the product as it has major implications.

    Astaro really needs to leverage the new Sophos structure to build something like baracudacentral where all of our units could report back and improve the blocking of spam out breaks.