Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 4641 views
  • Users 0 members are here
Options
Suggested
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

Puzzling DNS Request Routing Problem

Petros
Hello all,

I have a virtual Sophos UTM 9 (latest firmware 9.105-9) running in an Amazon AWS instance with a proper purchased virtual license.

Everything is working perfectly except a puzzling issue with DNS as follows:

In addition to many other roles, the UTM acts as the DNS server for all instances behind it within an Amazon VPC.  In general everything works perfectly and as expected.

HOWEVER, every time I do a firmware upgrade DNS resolution breaks.  Specifically, resolution from the UTM box (Support/Tools/DNS Lookup) works fine. However DNS from any of the other instances which use the UTM as the DNS server just does not work.  Any DNS lookup (whether implicit e.g. via ping host.fqdn or explicit via nslookup) returns timeouts followed by a "host not found".  In all cases there is nothing in any log to indicate a problem.  I've checked the reasonably expected reasons such as:

  •  Negative caching of failed lookups (e.g. I though maybe if the instances try DNS and it fails a few times while the UTM is rebooting then they cache the negative lookup and do not re-try the UTM as DNS for a while)
  •  Issues with DNS Allowed Networks
  •  Issues with Firewall rules
  •  Issues with DNS forwarders
  •  etc.

And all is fine.  During the period when the DNS does not work EVERYTHING else works fine: e.g. I can ping the UTM, I can access external resources by IP address, in bound traffic behaves as expected, DNS resolution using nslookup with a Google DNS (8.8.8.8) works fine.  It's just that the UTM refuses to resolve anything.

Last time I encountered the problem (in May 2013) I spent about 30 minutes trying several things and eventually after about 30 minutes the problem just went away. I have no idea why/how.

Last night when I performed another firmware upgrade I encountered precisely the same problem.  This time I did a more structured problem identification.  Nothing I tried worked EXCEPT when I got to request routing.  When I disabled the single request routing rule I have in place DNS resolution immediately started working perfectly again.  But I cannot say 100% for sure whether this was the cause or whether the elapsed time (about 30 minutes again) was what "fixed" the issue.

The only reasonable assumption I can come up with is that there is a problem with my request routing configuration OR (potentially) some defect with request routing?

Essentially the request routing rule says that DNS lookups for a sub-domain (of the domain for which the UTM is a member) should be resolved by another UTM device which is connected to this one via an SSL site-to-site VPN).  

So the UTM is within the domain "mydomain.com" and the request routing rule says that resolution of "sub.mydomain.com" should be sent to the other UTM over the SSL VPN.  
Incidentally I never managed to get this request route to work correctly (it's an open issue that I have not managed to resolve yet).  I.e. DNS resolution requests for "somehost.sub.mydomain.com" are not resolved and the target UTM does not even get to see the DNS requests.
So perhaps the two are related?

I need help with the following:
[LIST=1]
  •  Is this type of request routing rule "allowed" (request route is for a sub-domain)?
  •  Do I need to do something special to get this working correctly?
  •  Any ideas how I could troubleshoot this better?
[/LIST]

Many thanks in advance for any suggestions!


This thread was automatically locked due to age.
  • 0
    Hi, Petros, and welcome to the User BB!

    Please [Go Advanced] below and attach a picture of the Edit of the Request Route with the target open in Edit mode with the 'Advanced' section visible.  Since the server is connected via VPN, please attach a picture of the 'Site-to-site VPN tunnel status' for that tunnel.

    Also, please explain how your DNS setup at Amazon differs from DNS Best Practice.

    Cheers - Bob
  • 0
    Hi Rob.

    Thanks for the welcome and the reply!

    As requested, I attach a screenshot of the problematic request route.  The blurred domains are all exactly the same "ourdomain.com". the "gw.hq.{ourdomain.com}" is simply a host definition with the correct IP (internal IP).  
    (Not sure if this is what you wanted because there is no "advanced" section in the DNS Request Routing tab - at least not on my Sophos UTM!)

    I know the tunnel is working OK because if I ping the IP of the remote UTM participating in the tunnel from one of the Amazon instances behind the Amazon UTM to which the SSL VPN terminates the ping works just fine.  The tunnel is initiated by the remote physical UTM.  

    I also attach the SSL tunnel status for the tunnel involved.

    I believe our DNS setup is precisely as the DNS Best Practice suggests.  I'd already tried to find a solution by searching the forums and knowledge-base and had found that article.

    Basically we have:
    (If the below are not very clear let me know and I can send a diagram)

    Amazon UTM

    •  Uses Google public DNS as forwarders
    •  Uses the above request route to a physical UTM in another location


    Instances behind Amazon UTM: Use the Amazon UTM as their DNS server

    The physical UTM in the other location:

    •  Uses Google public DNS as forwarders
    •  Has a request route to an internal Windows Server (Active Directory DNS): this is for the hq.{ourdomain.com} domain and works fine
    •  Has a request route to the Amazon UTM: this is for the {ourdomain.com} domain. (Reason being that there are some static entries defined on the Amazon UTM hence why resolution for this domain is routed to the Amazon UTM). This also works fine.

    (Essentially the request route in the Amazon UTM is to allow the Amazon instances to reach the Active Directory DNS)

    Anything we are doing wrong?

    Many Thanks!

    Best Regards,

    Petros
  • 0
    Sorry forgot to mention that the request route on the Amazon UTM is currently disabled because of the problems I experienced when upgrading the firmware last night.  Disabling this is what "seemed" to fix the general DNS resolution problem and I haven't dared re-enable it since...
  • 0
    Petros, all of that looks perfect.  Please post a picture of the Edit of the Host definition for gw.hq.ourdomain.com with the 'Advanced' section visible.

    Cheers - Bob
  • 0
    That looks perfect.  If you're using a VPC tunnel from the UTM to the rest of the devices (in 10.10.2.0/24?), please attach a pic of the Status.  If not, please show how WebAdmin knows about 10.10.2.0/24.
  • 0 in reply to BAlfson
    The UTM is connected to both LANs via 2 interfaces - see attached.
    We are not using VPC tunnels but Sophos UTM to Sophos UTM site-to-site SSL VPNs instead.
  • 0
    It's going to take some spelunking to figure this out, I think.  Hopefully, you already have a ticket open with Sophos Support.

    Cheers - Bob
  • 0 in reply to BAlfson
    At least it wasn't something really simple that I'd missed! [:)]

    Thanks for all your help Bob - much appreciated.

    I have a ticket open with our local Sophos vendor.

    Best Regards,

    Petros
  • 0 in reply to Petros
    For the benefit of anyone else that may be having a similar issue:

    We solved this issue with the help of our local Sophos distributor in Athens, Greece.

    We traced the issued down to the fact that DNS response packets were not getting back to the Amazon UTM.  Packets were being correctly routed to the remote UTM over the tunnel, the final target DNS server was responding, the response packets were getting back to the remote UTM but not from the remote UTM to the originating (Amazon) UTM.

    Firewall rules were all fine etc. so this was quite puzzling for a while.

    Eventually via use of tcpdump on the remote UTM we were able to see that the packets were arriving to the remote UTM from the virtual SSL VPN IP and NOT from the IP of a local interface on the UTM.  This was a surprise because I'd expect the behaviour to be as for all other instances behind the UTM: i.e. traffic originating from the local IP of the originating instance.  Not for the UTM itself it seems.

    In any case, firewall rules to allow this were in place and so we still could not figure out why it wasn't working...

    Eventually, we worked out that the Virtual SSL IP Pool was not in the list of allowed networks for the tunnel.  Hence the remote UTM did not "know" how to send the packets back because (presumably) the route was not being advertised.  

    Adding the virtual IP Pool as an allowed network solved everything! [[:D]] [[:D]]

    Thanks to all for all suggestions and help and particularly Bob for his initial suggestions and NSS our local Sophos distribution in Greece (https://www.nss.gr/)!

    Regards,

    Petros