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

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

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

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

    PfSense w/Suricata, ntopng, 

    Other addons to follow


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

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

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