Good day, I am attempting to connect a Honeywell lyric leak detector via their smartphone App.
It appears the device (knowing its IP) is trying to connect to honeywell NTP.orgs as each seems to have a number of WANIps associated.
However the device goes out on 8.8.8.8 to do so.........
(image attached)
https://imgur.com/yMCtNWu

Too bad as the router DNS setup forces all users to be redirected to my DNS setup.
/ip dns
set allow-remote-requests=yes servers=8.8.4.4,208.67.220.220

add action=accept chain=input comment="Allow LAN DNS queries-UDP" dst-port=53 \
in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=\
53 in-interface-list=LAN protocol=tcp

(and under dst nat rules)
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - TCP" dst-port=53 protocol=tcp
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - UDP" dst-port=53 protocol=udp

(in my routing rules)
/ip route
add check-gateway=ping distance=2 gateway=8.8.4.4
add check-gateway=ping distance=3 gateway=208.67.220.220
add distance=10 gateway=2?.xx.yyy.1
add distance=2 dst-address=8.8.4.4/32 gateway=14x.yy.ccc.1 scope=10
add comment=Email_bypass distance=1 dst-address=24.222.0.20/32 gateway=\
2?.cc.ddd.1
add distance=3 dst-address=208.67.220.220/32 gateway=14x.uu.ttt.1 scope=10

+++++++++++++++++++++++++++++++++
So is there any adjustment I can make to alleviate the problem??

And what's the problem? Device wants to ask 8.8.8.8, you redirect requests to your router, it answers instead and device will never know the difference.

It tries to get accurate time info via ntp.org and for this needs its IP address via google DNS (probably coded in hard into the detector).
What is the problem you are then observing?
Should be resolved via your DNS server as stated earlier.

Personally I prefer to have my IOT devices in DMZ without any direct access to the router, without DNS cache access, NTP server etc.
You really do not know what is inside of these things and what they know and who uses them in which way.

Well whatever its looking for it never finds, as you can see it starts polling all the groups of honeywell servers......


Concur W, intend to put it on a VLAN with access to the internet only.
However, if I cant get it to connect to honeywell its a useless hunk of plastic.

And what's the problem? Device wants to ask 8.8.8.8, you redirect requests to your router, it answers instead and device will never know the difference.

Good question? You will note the continued attempts to reach HYWell servers, port 3000, 3001, 3002 and so on to hwyell ntp.org pools 0, then 1, then 2 and so on, till the device just stops trying.

Is there any other information you need to assist in what is going on, each lines wireshark readout?

I tried turning off my dsntnat redirection DNS rules to see if that would facilitate connection but no joy with that attempt.
One can see the output of my packet sniffer here.

https://www.dslreports.com/speak/slides ... LW5lZWRlZA

According to your screenshot, it gets addresses of NTP servers. The rest is up to you. Are you blocking other access to outside?

Hi Sob, not that I am aware of?
Are you asking am I blocking stuff coming back in, or stuff getting out?? (to the internet).
My FORWARD rules always end with drop all else.

If its established related etc........ its allowed.

Stuff getting out. Because that could be problem for the device, if you block it. For DNS, as far as the device knows, its hardcoded DNS server 8.8.8.8 (which is really not smart) is working just fine. It has no way to find out that it's actually your router responding. But then it starts connecting to those addresses and expects to be able to do it. If you block the attempts, device won't be happy.

Hi Sob I agree with the hard coded 8.8.8.8 on their part is not smart. Try to explain that to a tech support guy that says, on 'normal' routers it works fine.
So other than turning off my redirect dstnat rules, is there anything else I can try to let it work............ at least temporarily to establish a connection.

If you have redirect only for DNS, that's not it. Well, shouldn't be. But it's not completely impossible, I do remember reading about some devices having problems with RouterOS resolver (something about mixed-case queries). But you wrote that you already tried to disable them...

Currently the only advice is to make sure that you're doing it right, i.e. power on the device only after you disabled DNS redirects (or you made an exception for the device), to make sure that it starts fresh. And if you don't block anything, it will be like behind any "normal" router.

I have successfully connected to some NEST products and the Honeywell T5 but not the leak detector and now also tried a skybell HD door bell with same frustrating results..........

Lot of traffic back and forth between the gateway of the LAN and the LAN IP of the Skybel with DNS traffic but no other type. In other words connects to wifi fine but cannot connect to their server for some reason.

Here are my results from teh Skybell. Seems perhaps to be more an ICMP issue than DNS?? What could cause ICMP failure in this case?

https://i.dslr.net/syms/d93bec898a262b9 ... 112451.jpg

https://i.dslr.net/syms/f46a474569c314c ... 3694a3.jpg

First image gives 404. Second shows that your plan from other thread (to give device only 8.8.8.8 to use as dns) for some reason didn't happen, because the device is still using router as dns resolver. It's not possible to tell from this if it's because of dhcp config or your redirect rules in dstnat.

Icmp messages mean "port unreachable" and it's as if router tried to connect to something on the device, but it's impossible to tell what it was.

Hi Sob, are you sure 404?
THey both work for me?
I didnt plan on giving out 8888 to this device, I kept the router as is from original setup. This is a different device.
By the way I hooked up an R7000 netgear plain vanilla wifi router to a spare WANIP and the other device the leak detector connects with no issues whatsoever ARGGGGG!
So one could conclude my Mikrotik is blocking this type of connectivity and I dont know why.
https://imgur.com/a/kjGFS7j

Here is my NTP (or sntp) setup if that sheds any light???????

https://i.dslr.net/syms/280df186c9254a0 ... 253361.jpg

RouterOS blocks only what you tell it to block.

The capture is strange. When you look at it, there's query for srv.myskybell.com, reply for A record comes back, but device doesn't connect there, instead it sends the same query again and again. It would probably be good idea to let it try unlimited access to internet, i.e. without your dns redirection.

And for icmp, look at details, about what port it complains.

Hi Sob,
So basically I will disable my redirect rules but keep my current allow LAN to DNS input chain rules (tcp, udp) and my allow remote requests DNS rule (in IP DNS).

I should note that Skybell literature says the ports they use are 53, 123, 443 and a bunch of high ports,
Now I noticed when my honeywell t5 Lyric connected it was successful and used 443 for some traffic, without any intervention by me.

Should I infer from that that I do not need to add 123 and 443 to an allow input rule from LAN to router like there is for DNS??

Also I have no NTP servers selected and the device seems to want to connect to NTP?

Here is my ICMP line in detail form the unsuccessful attempt in sharkscribe...........
https://imgur.com/a/Eeg2b0X

You didn't do your homework, did you?

You previously wrote that you don't block outgoing traffic, so connection to port 443 should succeed.

If device tries to connect to external servers, then input chain is irrelevant, that traffic goes to forward. Ok, unless you force it to input using dstnat, but current idea is to not do that.

With NTP, device asked for address of pool.ntp.org, so it's not really a surprise that it tries to connect there.

That ICMP is strange, it looks like device sees DNS reply as unexpected. I wouldn't think much about it now, let it try without your redirects first.

Okay last attempt for the evening, I greyed out the redirect DNS rules and it looks like I got more Natting going on but still no success.
Here is the Sharkscribe jpeg
https://imgur.com/a/H5ErRsQ

Here are the logs.....
https://imgur.com/FBdY31z

It seems that it searching for something via NTP but never finds it??
On the plus side, at least not using DNS redirect cleaned up the ICMP no port found issue.

There's not much difference. It's still asking for srv.myskybell.com and for some reason sends always two queries in less than one millisecond, which doesn't make sense to me. If they were to two different servers, then maybe, it could be trying to speed things up. Interestingly, even with two queries, only one response comes back. And even though it clearly gets an IP address, it doesn't try to connect to it, which is something you'd expect, because why it would be asking otherwise.

NTP seems fine. It asks for address and you can see that there's some communication happening, so I'd say this part is ok.