Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 29 subscribers
  • Views 2604 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

Sophos XG trying to connect to unknown DNS servers, which are not configured

Dwayne Parker

Hi,

 

I am running a Sophos XG behind an other Firewall.

I am only allowing DNS connections to the DNS server, which I have configured in XG. Today I see a overwhelming mass of blocked attempts from the XG to connect to unknown IP addresses on Port 53/ Service DNS.

Since there are no Logs about these connections found in XG, and all connections to DNS from devices behind XG are blocked, there is actually some evidence that these connections are initiated from the XG it self.

Some of these IPs resolve to *.root-servers.net, others are not resolvable.

 

Is that a expected behaviour of XG?

I am running XG 18.0.1-MR1

 

Regards

Dwayne Parker



This thread was automatically locked due to age.
Parents
  • 0

    Hello Dwayne,

    The XG will only query the DNS configured under DNS. 

    Those *.root-servers.net are queries to the root DNS servers, so they are valid queries.

    What is the evidence you have found that the XG is initiating these queries? 

    Regards,

  • 0 in reply to emmosophos

    Hi,

     

    thank you for your quick Answer!

     

    Firstly I've configured Rules to drop all Traffic to Port 53 from any Device behind XG, but the blocked connection attempts in my firewall before XG are still logged.

    After that I've disconnected all Devices connected to XG, but the requests are still seen. So I am relatively sure, that these queries are initiated by Sophos XG.

     

    These servers are definitely not configured in XG, so I wonder why there are these Queries!

     

    Regards

  • 0 in reply to Dwayne Parker

    So, I'm not 100% sure about XG, but I know if one configures link monitoring (or link balancing, etc.) on Sophos UTM, the default mechanism used to determine if a link is "alive" or not was to do a lookup for or against a root DNS server, then it would ping the closes available responding hop for monitoring purposes (settings which can be changed BTW).  Maybe XG is doing this or something similar for WAN uplink status monitoring?

  • 0 in reply to BrucekConvergent

    I don't think that this is the point.

    On XG you configure which IP adress gets pinged to check the status of the Uplink. I've configured mine to ping the Interface of the second firewall. As soon as I set the Interface on the second Firwall not to react on pings, XG says that the uplink is down.

    Do you have any other ideas what causes this issue?

     

    Regards

  • 0 in reply to Dwayne Parker

    Could also be maybe the up2date process ... I know it can failback on other products to using root lookups.  Not sure why it would if regular configured DNS is working, maybe its a sanity check item, who knows.  Probably not a big deal.  Maybe setup a packet capture so you can see what the queries actually are, that would certainly explain it.

  • 0 in reply to BrucekConvergent

    I've just captured the Packages, thay are containing queries to look up many international Google Domains like "www.google.co.mz" or "www.google.rw", or "www.google.co.lb", or "www.google.hr", or "www.google.sh" ....

    I really don't know what's the goal of looking up dozens of Google Domains? Also it looks like XG is sending also DNS Queries to the configured DNS Server.

Reply
  • 0 in reply to BrucekConvergent

    I've just captured the Packages, thay are containing queries to look up many international Google Domains like "www.google.co.mz" or "www.google.rw", or "www.google.co.lb", or "www.google.hr", or "www.google.sh" ....

    I really don't know what's the goal of looking up dozens of Google Domains? Also it looks like XG is sending also DNS Queries to the configured DNS Server.

Children
  • 0 in reply to Dwayne Parker

    It would be really nice if I could disable this somehow, since it is filling up the logs, and generating traffic.

  • 0 in reply to Dwayne Parker

    Hello Dwayne,

    Could you please create a case with Support and send me via PM the Case ID, once you have done that please enable Support Access in your XG and send me the Access ID.

    Monitor & Analize >> Diagnostics >> Support Access >> ON >> Access Status >> And copy & paste the Access ID and send it to me.

    Regards,

  • 0 in reply to emmosophos

    Unfortunately I am a Home User, so I can't open a case.

     

    Could you please explain me why do you need access to my XG?

  • 0 in reply to Dwayne Parker

    Hi together,

    I read an old documentation of Cyberoam stating that you should use 127.0.0.1 as primary DNS server for performance reasons. This will ask the root servers first and cache all dns entries afterwards. I also had this setting in v18 for some time, but reverted it in the last days to retest woth normal settings.

    But I think that XG is using the root servers sometimes.

    Haven‘t found the old docu of Cyberoam yet, but this one points in the direction:

    Best Regards

    Dom

  • 0 in reply to Dom Nik

    Actually does DNS request are caused by the x.000 FQDN hosts, which are created per default on XG.

     

     

    As XG tries to hold them into the cache, you will find dozens of DNS requests to keep all of them saved for quicker response. 

    Try to delete them and it should be "quite". 

    As i looked at those requests for one day, i found only ... few MB per day DNS requests, which is not worth talking about. 

  • 0 in reply to Dwayne Parker

    Hello Dwayne,

    Oh I see, thank you.

    Just wanted to confirm the queries are like this which are legit queries 

    16:43:46.020570 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 75: 99.199.65.43.59584 > 192.168.0.1.53: 61784+ A? www.google.az. (31)
    16:43:48.035120 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 86: 99.199.65.43.56620 > 8.8.8.8.53: 5812+ A? dual-a-0001.a-msedge.net. (42)
    16:43:48.035189 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 75: 99.199.65.43.14661 > 8.8.8.8.53: 13225+ A? www.google.fr. (31)
    16:43:48.039292 Port2, IN: In a4:7b:2c:4f:1f:b5 ethertype IPv4 (0x0800), length 118: 8.8.8.8.53 > 99.199.65.43.56620: 5812 2/0/0 A 204.79.197.200, A 13.107.21.200 (74)
    16:43:48.039492 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 195: 127.0.0.1.53 > 127.0.0.1.2155: 17476 4/0/0 CNAME a-0001.a-afdentry.net.trafficmanager.net., CNAME dual-a-0001.a-msedge.net., A 204.79.197.200, A 13.107.21.200 (151)
    16:43:48.039542 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 173: 127.0.0.1.53 > 127.0.0.1.44926: 17476 4/0/0 CNAME www2-bing-com.dual-a-0001.a-msedge.net., CNAME dual-a-0001.a-msedge.net., A 204.79.197.200, A 13.107.21.200 (129)
    16:43:48.039583 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 188: 127.0.0.1.53 > 127.0.0.1.47641: 17476 4/0/0 CNAME www4-bing-com.trafficmanager.net., CNAME dual-a-0001.a-msedge.net., A 204.79.197.200, A 13.107.21.200 (144)
    16:43:48.039630 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 196: 127.0.0.1.53 > 127.0.0.1.49593: 17476 4/0/0 CNAME a-0001.a-afdentry.net.trafficmanager.net., CNAME dual-a-0001.a-msedge.net., A 204.79.197.200, A 13.107.21.200 (152)
    16:43:48.047537 Port2, IN: In a4:7b:2c:4f:1f:b5 ethertype IPv4 (0x0800), length 91: 8.8.8.8.53 > 99.199.65.43.14661: 13225 1/0/0 A 216.58.217.35 (47)
    16:43:48.047617 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 91: 127.0.0.1.53 > 127.0.0.1.54438: 17476 1/0/0 A 216.58.217.35 (47)
    16:43:49.040360 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 75: 99.199.65.43.48345 > 8.8.8.8.53: 12366+ A? www.google.az. (31)
    16:43:49.054866 Port2, IN: In a4:7b:2c:4f:1f:b5 ethertype IPv4 (0x0800), length 91: 8.8.8.8.53 > 99.199.65.43.48345: 12366 1/0/0 A 216.58.217.35 (47)
    16:43:49.055001 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 91: 127.0.0.1.53 > 127.0.0.1.16423: 0 1/0/0 A 216.58.217.35 (47)
    16:43:50.261918 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 79: 127.0.0.1.36334 > 127.0.0.1.53: 43433+ A? www.google.com.au. (35)
    16:43:50.262100 lo, IN: In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 75: 127.0.0.1.33605 > 127.0.0.1.53: 43433+ A? www.google.pt. (31)
    16:43:50.262295 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 79: 99.199.65.43.10191 > 192.168.0.1.53: 20200+ A? www.google.com.au. (35)

    and those are queries to the DNS configured in the XG 

    16:43:46.020570 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 75: 99.199.65.43.59584 > 192.168.0.1.53: 61784+ A? www.google.az. (31)
    16:43:48.035120 Port2, OUT: Out 7c:5a:1c:79:37:98 ethertype IPv4 (0x0800), length 86: 99.199.65.43.56620 > 8.8.8.8.53: 5812+ A? dual-a-0001.a-msedge.net. (42)

    Regards,