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

We just received our astaro box, a 220.  The vendor did much of the configuration and we are having some teething problems.  

The topology is that we have a perimeter firewall, with the Astaro set up behind it in bridged mode, with all clients/servers set up behind that with those machines set to use the 220 as their gateway.  Currently, intrusion prevention is off and the packet filter is set to allow all traffic.

We are using the http proxy and the dns proxy is set to forward to our internal DNS servers (windows 2003 servers).  For those on internal machines, resolution works great.  For remote employees it is not working.  Remote workers VPN into the perimeter firewall at which point they are given an internal ip address.  That is physically, they are connecting through the eth1 interface of the astaro.  When they try to access internal resources by name, they get an error page generated by squid saying that the requested url could not be retrieved by the cache.  

Any thought, ideas, or fully formed solutions would be appreciated.

Scott Klassen


This thread was automatically locked due to age.
  • I've now got a little more information and think that I know the root cause, just not certain where to fix it at with the Astaro box.

    In WebAdmin>Network>Ping check if I simply type in a hostname, the ping fails, if I put in the FQDN it succeeds.  We use a split brain internal DNS structure of a .com for our external resources which we host internally (web and mail) and a .corp for internal resources.  We do have an external DNS host for internet resolution of the .com.

    I think what is going on is that even though the astaro has been joined to our domain in system>user authentication, somewhere on this box the vendor set it as .com and that's what it is trying to resolve to by default.  Any hints where I may be able to find this information at?  Possibly related, under network>hostname, nothing is listed there.
  • AFAIK, the authentication in ASL is not tied to ASL's DNS proxy.

    You can set the DNS resolvers in Proxies - DNS.

    You cannot reliably point to one DNS for INT, and one for EXT. You need to point to one that handles both, or only EXT.

    Barry
  • That's how we have it, everything (clients, ASL, perimeter firewall) are all pointing to the internal DNS servers.  It seems that squid seems to have some sort of issue with CNAME DNS records (in this case a single word).  

    I did some debug logging on one of my DNS servers and found that a resolution request for that record from the "inside" interface of the ASL succeeds, while one from the other side of the ASL (which is done by squid as a proxy in the ASL is my understanding) fails.  I'm getting the distinct feeling that squid is munging the request somehow, so that the DNS server gets something it doesn't understand.  At some point in the next couple of weeks I'll set up some sniffers on the network to pick up exactly what is being passed back and forth during a request for that specific record, both from a client who is in the LAN side of the ASL and the traffic for one on the other side of the ASL.
  • Mostly the original post here had to do with a failure of resolution for an intranet site with a CNAME record.  I found the fix in another post in this forum.  I added the machine the site "lives" on as a host on the Astaro box, then added it to the exception list under HTTP proxy.  Not the optimal solution as that machine doesn't get the protection that the proxy adds, but hopefully it's something which can be fixed in a future update.