2kbps DNS-Resolution Spam for cloud.mikrotik.com from detect-interface feature

RouterOS General
1

I have a RB1100Dx4 running Router OS 7.18.2.

It has multiple VLAN-Interfaces on a LAN-Bridge, of which 3 have local-proxy-arp configured.
I noticed, that these 3 VLAN-Interfaces had ~2kbps of constant traffic, even when there was not a single device on that VLAN beside the Router.
I even tested disconnecting all ports beside WAN, and the traffic on these 3 local-proxy-arp interfaces was still there.

Using the packet-sniffer and Wireshark (see below) I inspected the traffic and noticed, that the router sends out DNS-Queries on these 3 interfaces multiple times per seconds, trying to resolve cloud.mikrotik.com
These are the only DNS-Requests going there, and the only ones not correctly routed over the WAN-Interface. There are also no routers configured leading into any of those VLANs.
Strangely enough, the requests also rotate between 3 DNS-Servers - one of which is 8.8.8.8, which I have never used as an DNS.

Coming across this post, I checked all features that are listed there as using the Mikrotik cloud and figured that the requests stopped as soon as I disabled the “detect-internet” feature.

I feel like this is a bug and should probably be either documented or changed.
Foremost, the packages introduce unnecessary load and the fact that they only occur on local-proxy-arp interfaces does not seem intended.
Secondly, I don’t want my router to query any google DNS unless I specifically configure it.

Any insight on why this might be intended or a response from the maintainers if this is a known bug would be greatly appreciated :slight_smile:
So far, I’am fine with disabling detect-internet.

Interface & Bridge Config

# Interface that gets the DNS-Spam
name="vlan_xyz_iot" mtu=1500 l2mtu=1588 mac-address=xxx arp=local-proxy-arp arp-timeout=auto loop-protect=default loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m vlan-id=3004 interface=bridge_LANs use-service-tag=no mvrp=no 

# Interface that acts normal and doesnt get it
name="vlan_xyz_office" mtu=1500 l2mtu=1588 mac-address=xxx arp=enabled arp-timeout=auto loop-protect=default loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m vlan-id=3010 interface=bridge_LANs use-service-tag=no mvrp=no 

# Bridge
 0  R name="bridge_LANs" mtu=auto actual-mtu=1500 l2mtu=1592 arp=enabled arp-timeout=auto mac-address=xxx protocol-mode=rstp fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=yes ether-type=0x8100 pvid=1 
      frame-types=admit-only-vlan-tagged ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no max-learned-entries=auto 
      
# /interface/bridge/vlan/print detail  
Flags: X - disabled, D - dynamic 
 0 D ;;; added by pvid
     bridge=bridge_WAN vlan-ids=1 tagged="" untagged=bridge_WAN,ether11.wan mvrp-forbidden="" current-tagged="" current-untagged=bridge_WAN,ether11.wan 

 1   bridge=bridge_LANs vlan-ids=3000 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 2   bridge=bridge_LANs vlan-ids=3001 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 3   bridge=bridge_LANs vlan-ids=3002 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 4   bridge=bridge_LANs vlan-ids=3003 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 5   bridge=bridge_LANs vlan-ids=3004 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 6   bridge=bridge_LANs vlan-ids=3005 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 7   bridge=bridge_LANs vlan-ids=3006 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 8   bridge=bridge_LANs vlan-ids=3007 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

 9   bridge=bridge_LANs vlan-ids=3008 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

10   bridge=bridge_LANs vlan-ids=3010 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

11   bridge=bridge_LANs vlan-ids=3128 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

12   bridge=bridge_LANs vlan-ids=3144 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

13   bridge=bridge_LANs vlan-ids=3176 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

14   bridge=bridge_LANs vlan-ids=3192 tagged=ether13.lantrunk untagged="" mvrp-forbidden="" current-tagged="" current-untagged="" 

15 D ;;; added by pvid
     bridge=bridge_LANs vlan-ids=3000 tagged="" untagged=ether1.mgmt mvrp-forbidden="" current-tagged="" current-untagged=ether1.mgmt 

16 D ;;; added by vlan on bridge
     bridge=bridge_LANs vlan-ids=3000-3006,3008,3010,3128,3144,3176,3192 tagged=bridge_LANs untagged="" mvrp-forbidden="" current-tagged=bridge_LANs current-untagged=""

Package Capture

2

bug or feature :wink:

3

So far, I’am fine with disabling detect-internet.

So you found the solution. Nice :slight_smile: Any questions then?

4

For me the question is, to default ON or disabled. Seeing as the majority of users end up turning this OFF and it does create traffic probably unbeknownst to most, it should really be defaulted to disabled.

The associated MT doc page is perhaps vague on its purpose and seems to indicate it is OFF by default and needs to be enabled.
What the heck is precaution?? No need for PRE, just like there is little need for detect internet :wink:

Note that Detect Internet can install DHCP clients, default routes, DNS servers and affect other facilities.
Use with precaution, and after enabling the service, check how it interferes with your other configuration.

If it comes default disabled, then we are all good, but I do think a better explanation of its purpose is spelled out. Also the doc doesn’t mention the torrent of traffic to MT this invokes.

5

The problem is that when using the mobile MikroTik app, there is a very intriguing text right on the homepage saying that “Internet detect” is disabled. And after tapping on it, just another tap is enough to have Detect Internet turned on. And mobile users also quickly learn that Detect Internet must be active in order for the fancy graphs and traffic counters to be visible on the app home screen.

I bet most those wo have Detect Internet active have accidentally turned it on that way.

Maybe the mobile apps should not rely on that feature for the graphs and just use the interface list WAN created by defconf instead?

6

As I already wrote - how can it be, that my own router tries to contact a Google-DNS without me ever having configured that or having any chance to know that it does that without package sniffing.

If it wouldn’t be for a customer but for me personally, that alone would be a reason for me to return the router and never buy a Mikrotik Product again.
This is absolutely unacceptable for enterprise grade networking hardware.

7

Is your issue with router checking if there is internet access, or with Google specifically? Router did not “contact” google and did not send anything to google. It’s not using google for DNS, it’s checking reachability of various services

8

I think the issue is, that the router is behaving in an undocumented way, that one would not anticipate.

I normally work in large enterprise networks that imply security measurements like traffic monitoring for dropped or undelivered packages or unexpected connections.
Having a router contact any unexpected IP-Address on an unexpected interface would surely raise a security-ticket in such an environment. Let alone, if it’s public IP, let alone if its Google-DNS.
I spent over an hour trying to find out where the requests come from - and i am just in the deployment of a very small network. Finding the cause in an established, large network could easily take more time. Adding to that, I cannot believe this is intended behavior as it only happens on proxy-arp interfaces.

How could I recommend a router to anyone for enterprise use if it introduces unintended, undocumented behavior that can easily take hours to rule out?

9

Well … whether you intended it or not, you had feature called “detect internet” enabled. And based on feature name and using common sense it’s pretty clear that function has to try access certain (well known) services provided by internet servers in order to declare some interface as “internet facing”.

Now, we can agree that it would be nice if this kind of functions were documented in detail. But you can’t say that this function is not documented, because it is documented. And documentation includes some details.
OTOH, in true enterprise environment, admin (or hired integrator) would reset device to no config and configure it from scratch. No config means “detect internet” is disabled.

10

I would add mkx, an admin using MT equipment would probably be trained to some degree to use the equipment in an enterprise networking position. I wonder if any of the certs cover detect internet. OR,
to have at least read http://forum.mikrotik.com/t/the-twelve-rules-of-mikrotik-club/182164/1 :wink: Item 5