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.
Parents
  • 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
Reply
  • 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
Children
No Data