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

DNS Resolution Timeout

Hello Fellow Astaro Fans!

We have an Astaro ASG320 appliance (v8.309) configured with dual ISP connections.  

 - Cox Cable Modem is on Eth2
 - Verizon FIOS is on Eth4

The connections are both used throughout the day in a randomized load balancing model.  We have about 100 users on the internal network and when they are web browsing, they sometimes go out via Cox and sometimes go out via Verizon.

For about 1.5 years, this has worked great.  As of 2 weeks ago, we've been getting a lot of people who cannot browse the web at all.   Most web requests that seem to go out the FIOS pipe result in an Astaro error page that reads:

DNS resolution timeout

This does not make any sense because none of our user workstations utilize the DNS services of the Astaro.  Instead, they all point to our internal Windows Active Directory DNS which then forwards to Google (8.8.8.8) and Level 3 (4.2.2.1) for FQDN's that it cannot resolve. Again, this has been fine for 1.5 years so I know it is not our setup.  

The only way I can seem to fix this issue is by disabling the FIOS connection on Eth4.  When I do that, the DNS resolution timeout goes away.  I have done full integrity testing on the FIOS connection by plugging a PC directly into it (with no firewall/router in between) and it is fine.  DNS requests to both Google and Level 3 come back fine (FIOS is not blocking DNS requests to these 3rd party servers) and the web browsing is fast (35 Mb/s up and down). 

My suspiscion is something odd has started happening with Astaro's load balancing and I think the DNS is a red herring sort of error message.  

Any thoughts?  We are currently on just one ISP connectio (Cox) which is OK, but I'd like to get back to full redundancy ASAP.  Sophos support suggested I send all DNS traffic requests via Cox, but that defeats my redundancy model (e.g. what happens if Cox goes down?  People won't be able to fulfill DNS requests to the Internet).  

I'm looking for a solution or confirmation that this is a bug somewhere in the Astaro system that will be resolved soon.

Many thanks!


This thread was automatically locked due to age.
Parents
  • Sorry for the delay and thanks for the feedback.  We got on the phone with Astaro Support and they setup a multi-path rule so all DNS request go out the Cox pipe.  We are now monitoring it to see if the issue re-occurs.  My understanding is that multi-path rule is smart enough to route DNS through FIOS if Cox goes down (despite the rule forcing it through the Cox pipe).

    In terms of logs, you can see the error in the Web Filtering Log.  Here's an example:

    Line 7035: 2013:05:23-07:40:48 ASGFW httpproxy[6434]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.90.107" dstip="" user="" statuscode="500" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="0" request="0xc238b060" url="www.aloharag.com/.../logo.gif" exceptions="" error="DNS resolution timeout" category="174" reputation="neutral" categoryname="Fashion/Beauty"

    The 2 DNS forwarders are 8.8.8.8 and 4.2.2.1 in the Astaro itself

    I did note that on some independent testing of our Verizon FIOS connection, DNS resolution works fine, but continuous ping to 8.8.8.8 results in 7% packet loss.  Not sure if they are doing something weird with that.  

    The overall config has been confirmed with Astaro Support.  Let's see if this DNS Multi-Path rule helps.  Stay tuned!
Reply
  • Sorry for the delay and thanks for the feedback.  We got on the phone with Astaro Support and they setup a multi-path rule so all DNS request go out the Cox pipe.  We are now monitoring it to see if the issue re-occurs.  My understanding is that multi-path rule is smart enough to route DNS through FIOS if Cox goes down (despite the rule forcing it through the Cox pipe).

    In terms of logs, you can see the error in the Web Filtering Log.  Here's an example:

    Line 7035: 2013:05:23-07:40:48 ASGFW httpproxy[6434]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.90.107" dstip="" user="" statuscode="500" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="0" request="0xc238b060" url="www.aloharag.com/.../logo.gif" exceptions="" error="DNS resolution timeout" category="174" reputation="neutral" categoryname="Fashion/Beauty"

    The 2 DNS forwarders are 8.8.8.8 and 4.2.2.1 in the Astaro itself

    I did note that on some independent testing of our Verizon FIOS connection, DNS resolution works fine, but continuous ping to 8.8.8.8 results in 7% packet loss.  Not sure if they are doing something weird with that.  

    The overall config has been confirmed with Astaro Support.  Let's see if this DNS Multi-Path rule helps.  Stay tuned!
Children
No Data