Hello, I have a strange issue here. I purchased a Mikrotik hEX RB750Gr3 to replace my old router and it's a million times better, but I have a weird issue with a new "smart device" I bought; the Shark Ion Robot.

It will not connect to the cloud through the hEX.

I realize this is a wired router - I have a wireless router acting as an access point without any filtering on its side.

Anyway, I've tested it with other wireless routers and tethering on a phone and it'll connect, but I can't get it to work with the Shark. I've tried checking all of my firewall settings but I don't see anything in particular.

According to Shark's engineer, whom I had a very lengthy discussion with (and he had only 1 other case like mine and it was another MikroTik router that the client just got rid of - I'd rather keep mine), the Ion Robot uses the following ports:

TCP
80
443
53

UDP
55055
55056

Here are my rules and values..
Here are my NAT rules. I tried adding a bypass for it:
It looks like, after discussing with him, he's even added UPNP to the Ion Robot's features but I'm still not having any luck. Any ideas?

Any ideas?

the Ion Robot uses the following ports:
TCP: 80, 443, 53
UDP: 55055, 55056

What means "uses the following ports"? Does it listen at these ports, so you could connect to it from your smartphone or PC directly locally on its IP address, or do its cloud headquarters listen at these ports and you access the "home of all Shark Ion Robots" with username and password to control your own one?

In the first scenario, is your Wireless AP running in bridge more or does it have a NAT inside as well? I.e. does the robot get its IP address from the Mikrotik or from the AP?

In the second scenario, there should be no issue as the connections would be established by the robot itself and the default firewall rules normally permit LAN devices to establish any connection they want to the outside. But it could be that the UDP response comes so late from the HQ that the Mikrotik firewall closes the response window in the meantime.

If unsure, run the with the settings below, and then use Wireshark to see what's going on.

It looks like, after discussing with him, he's even added UPNP to the Ion Robot's features but I'm still not having any luck. Any ideas?

UPnP does not run automatically on Mikrotik, you have to define the inner and outer interfaces and enable it.

Tools - Torch - for some snifering

and ofcrouse firewall drop rules counting wil show for you small info

or remote help

I have the same issue only, I have a Mikrotik hAP that seems to not like this product either. Ive tried everything. From the items suggested above to changing all of the wifi settings and

The ion robot has its own internal wifi - 10.221.203.1

My internal mikrotik router is - 10.0.1.0/24

It instructs you to hold two buttons to active its wifi. While its in broadcast mode you must go now from your phone/tablet/pc (while being on your internal wifi network) search for the shark broadcasted ssid, leave your home wifi to connect wirelessly to the shark ion robot network, then as you connect a splash redirects to its internal .1 page where it asks you to connect to any of the scanned wifi networks (in this case “your home router”) then this is where it doesnt get past cloud resolution. It seems to connect to the mikrotik but doesnt appear to resolve/dns out .. it will sit.. and sit.. and sit to the point where it errors out and states an error

“Device service connection timed out - meaning its connection to its cloud server”

I whipped out another router, and powered down the mikrotik, made the same ssid/security/password identical and it connected no problem. I was now able to use the application on the tablet, control the shark bot, etc.

With it now registered and synced up, I proceeded to disconnect the test router, and plug back in the mikrotik assuming that with the shark now connected it will act as if the “router shut on and off and presume typical reconnection.” It now does not have a connection and continues to prompt about temporarily losing connectivity to the shark etc.

Like the op stated, it seems to work with every single router other than mikrotik, so it cant just be a coincidence that myself, in addition to him and the story relating to another person are experiencing the same issue.

I strongly believe this may be DNS and or DHCP server related, Ive always known and read about mikrotik’s being stingy with some devices with regards dns resolution.

Any suggestions wouod be greatly appreciated.

I can only repeat the advice I gave to the OP - you'd have to sniff the traffic of the device to see what it tries to do and why it fails with Mikrotik.

It makes no sense to speculate where we can measure instead.

I apologize but the the packet sniffer process you have advised brings up nothing but a blank wireshark log when stopped/imported to the desktop and ran on wireshark. It just does not seem to capture anything regardless of interface. Start/Stop/Save etc.

I apologize but the the packet sniffer process you have advised brings up nothing but a blank wireshark log when stopped/imported to the desktop and ran on wireshark. It just does not seem to capture anything regardless of interface. Start/Stop/Save etc.

Nothing to apologize about.

In your case, you have to sniff at the wlan interface (wlan1 in the default configuration); the OP had a wireless-less machine so I was assuming that it was enough to sniff on the uplink, and the fact that the OP has a wired-only device is also the reason why I think that the issue is not in the wireless part of the path.

I don't know how many other devices are connected to the WLAN so I don't know whether any filtering is necessary at all; it would be best to disconnect any other device from the AP when asking the robot to attempt to connect, so the only filter condition of the sniffer would be "interface=wlan1" and all other conditions would be empty.

The phases should be the following:

1. the robot connects and authenticates to the AP, so you should see its MAC address in the wireless registrations table; this would be visible in the wireless sniffer but not in the regular packet sniffer
2. the robot asks for an IP address using DHCP and receives it, so you should see a dhcp-server lease in the leases table; this should already be visible in the regular sniffer
3. the robot sends a DNS query, and if a response arrives, tries to establish some further connections. This should also be visible in the regular sniffer.

To check whether the sniffing works at all, it is good to try it first using some other device instead of the robot.

The sniffer settings can only be changed while it is stopped. So Stop it if running, then set the interface to wlan1 or the name you actually use, unset all other filter fields, then Apply, then Start, then switch on the robot and when it gives up, Stop the sniffer. While the robot is trying, watch the Mikrotik log, some events regarding the wireless association and dhcp should be visible in it.

While I perform this, not sure if this will help, but I was able to narrow down the ion shark mac/ip as it appears to have arp-ed. So I torched the associated/linked ip for the bot and was able to snap this.

it appears that it leaves the router 10.0.1.124 UDP utilizing (Ports 49150-49160) and tries to hit a series of external source IP's (presuming it is the cloud databases) at ports 123,
after it times outs on the connections status, it stays with

SRC 10.0.1.124:49153
DST 10.0.1.1:53 (timeout of 2:50)

it appears that it leaves the router 10.0.1.124 UDP utilizing (Ports 49150-49160) and tries to hit a series of external source IP's (presuming it is the cloud databases) at ports 123,
after it times outs on the connections status, it stays with

SRC 10.0.1.124:49153
DST 10.0.1.1:53 (timeout of 2:50)

Looking at the torch results, you can see that the exchange on DNS port (UDP port 53) is bi-directional (there are both Rx and Tx packets), so the robot did get some answer from the Mikrotik's DNS cache, the question is how much did it like it. To see the actual contents of the query and the answer, torch is not enough and sniffing is necessary.

UDP port 123 is normally used for NTP (network time protocol), the question is whether the robot uses it this way or not. The address resolves to mdnworldwide.com, is it in any way related to the robot manufacturer? If not, it likely is an NTP server from a pool.

Here is the requested packet sniff with nothing but the Shark requests. This is all that the packet sniff spits out. There is nothing after line 117. How would you like me to post the wireshark? I can take screen shots as well but you wont be able to navigate through the layers and view the respective data.

I can take screen shots as well but you wont be able to navigate through the layers and view the respective data.

Great point. You wouldn't believe how many people post screenshots on ask.wireshark.org and expect someone to be able to debug on them.

One possibility is to use any plain file sharing service, another possibility is to use cloudshark.org. And put a link to the file here, just make sure that the link is login-free.

BTW, the address to which the robot has sent the NTP packet this time resolves to ntp2.doctor.com, so I assume it really is a NTP request. The fact that there is no reponse makes me cautious, so it would be fine if you could post here also the output of /export hide-sensitive, after sysrematically replacing each occurrence of any public IP you don't want to publish by a meaningful distinctive string like my.public.ip.1 - maybe your firewall is too strict.

While I work on the sharing, I have provided the sensitive omitted config to view, Im still learning a lot of the L3+, granted I work in the field but primarily deal with L1/L2 (submarine/terrain optical transport only) But I can't thank you enough for assisting me with this! It just seems to not make any real sense. Its almost as if it doesn't even get a response from a queried DNS while digging into some of the wireshark log.

(rv750-39a9391a-device.aylanetworks.com) After doing some digging and retrieving this from the encapsulated section, I tried pinging the DNS from terminal and it is live and responding with a public ip of 34.196.75.19.

IP-Adresse: 34.196.75.19
Provider: Halliburton Company
Region: Ashburn (US)

But again, not sure if this changes or stays consistent without running multiple logs. As we've seen, it appears to hit a series and multiple set of ips.

[admin@MR101] > /export
# may/21/2018 14:36:24 by RouterOS 6.42.2
# software id = US37-6JHC
#
# model = RouterBOARD 962UiGS-5HacT2HnT
# serial number = XXXXXXXXXXXX
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no comment=defconf fast-forward=no name=bridge
/interface ethernet
set [ find default-name=ether2 ] name=ether2-master
set [ find default-name=ether5 ] poe-out=off
set [ find default-name=sfp1 ] disabled=yes
/interface list
add exclude=dynamic name=discover
add name=mactel
add name=mac-winbox
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa-psk,wpa2-psk eap-methods="" management-protection=allowed mode=dynamic-keys name="Passkey 01" supplicant-identity="" \
wpa-pre-shared-key=XXXXXXXX wpa2-pre-shared-key=XXXXXXXX
add authentication-types=wpa-psk,wpa2-psk eap-methods="" management-protection=allowed mode=dynamic-keys name="Passkey 02" supplicant-identity="" \
wpa-pre-shared-key=XXXXXXXX wpa2-pre-shared-key=XXXXXXXX
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n country="united states" disabled=no distance=indoors frequency=auto mode=ap-bridge security-profile=\
"Passkey 01" ssid="WIFI 01" wireless-protocol=802.11 wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-a/n/ac country="united states" disabled=no distance=indoors frequency=auto mode=ap-bridge security-profile=\
"Passkey 02" ssid="WIFI 02" wireless-protocol=802.11
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/queue tree
add disabled=yes limit-at=28M max-limit=28M name=queue1 parent=ether1 queue=default
add disabled=yes limit-at=50M max-limit=50M name=prio5-streaming packet-mark=streaming parent=queue1 priority=5 queue=default
add disabled=yes limit-at=100k max-limit=9500k name=prio8-untagged packet-mark=no-mark parent=queue1 queue=default
add disabled=yes limit-at=1G max-limit=1G name=prio3-gaming packet-mark=gaming parent=queue1 priority=3 queue=default
add disabled=yes limit-at=1G max-limit=1G name=prio2-misc-fast packet-mark=misc-fast parent=queue1 priority=2 queue=default
add disabled=yes limit-at=100k max-limit=9900k name=prio6-http packet-mark=http parent=queue1 priority=6 queue=default
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0
/system logging action
set 0 memory-lines=1
/interface bridge port
add bridge=bridge comment=defconf interface=ether2-master
add bridge=bridge comment=defconf hw=no interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=all
/interface ethernet switch host
add mac-address=XX:XX:XX:XX:XX:XX redirect-to-cpu=yes share-vlan-learned=no switch=switch1 vlan-id=1
/interface list member
add interface=wlan1 list=discover
add interface=ether2-master list=discover
add interface=ether3 list=discover
add interface=ether4 list=discover
add interface=ether5 list=discover
add interface=sfp1 list=discover
add interface=wlan2 list=discover
add interface=bridge list=discover
add list=discover
add interface=bridge list=mactel
add interface=bridge list=mac-winbox
/interface pptp-server server
set enabled=yes
/ip address
add address=10.0.1.1/24 comment=defconf1 interface=bridge network=10.0.1.0
add address=192.168.0.2/29 disabled=yes interface=ether1 network=192.168.0.0
/ip arp
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
add address=10.0.1.XXX comment=XXX interface=bridge mac-address=XX:XX:XX:XX:XX:XX
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1 use-peer-dns=no
/ip dhcp-server
add address-pool=default-dhcp authoritative=after-2sec-delay disabled=no interface=bridge name=defconf
/ip dhcp-server lease
add address=10.0.1.145 always-broadcast=yes client-id=XX:XX:XX:XX:XX:XX mac-address=XX:XX:XX:XX:XX:XX server=defconf
/ip dhcp-server network
add address=10.0.1.0/24 comment=defconf dns-server=10.0.1.1 gateway=10.0.1.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,1.1.1.1
/ip dns static
add address=8.8.8.8 name=Google
add address=1.1.1.1 name=DNS1
/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=ether1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1
add action=drop chain=forward comment="Disable NAS Outbound (TCP)" dst-address=0.0.0.0/0 out-interface=ether1 protocol=tcp src-address=10.0.1.XXX src-port=\
""
add action=drop chain=forward comment="Disable NAS Outbound (UDP)" dst-address=0.0.0.0/0 protocol=udp src-address=10.0.1.XXX
/ip firewall mangle
add action=mark-packet chain=postrouting connection-mark=streaming disabled=yes new-packet-mark=streaming passthrough=no
add action=mark-packet chain=postrouting connection-mark=gaming disabled=yes new-packet-mark=gaming passthrough=no
add action=mark-packet chain=postrouting disabled=yes new-packet-mark=misc-fast packet-size=40 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=postrouting disabled=yes dst-port=53 new-packet-mark=misc-fast out-interface=ether1 passthrough=no protocol=udp
add action=mark-packet chain=postrouting connection-mark=http disabled=yes new-packet-mark=http passthrough=no

add action=mark-connection chain=postrouting comment=Streaming connection-state=new disabled=yes dst-port=1935 new-connection-mark=streaming out-interface=\
ether1 passthrough=yes protocol=tcp
add action=mark-connection chain=postrouting comment="Web Browsing" connection-state=new disabled=yes dst-port=80,443 new-connection-mark=http \
out-interface=ether1 passthrough=yes protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX88UDP disabled=yes dst-port=88 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX88TCP disabled=yes dst-port=88 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX53UDP disabled=yes dst-port=53 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX53TCP disabled=yes dst-port=53 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX500UDP disabled=yes dst-port=500 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX4500UDP disabled=yes dst-port=4500 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX3544UDP disabled=yes dst-port=3544 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX31112UDP disabled=yes dst-port=31112 new-connection-mark=gaming out-interface=ether1 passthrough=\
yes protocol=udp
add action=mark-connection chain=postrouting comment=XBOX31112TCP disabled=yes dst-port=31112 new-connection-mark=gaming out-interface=ether1 passthrough=\
yes protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX3074UDP disabled=yes dst-port=3074 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=udp
add action=mark-connection chain=postrouting comment=XBOX3074TCP disabled=yes dst-port=3074 new-connection-mark=gaming out-interface=ether1 passthrough=yes \
protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX31112UDP disabled=yes dst-port=31112 new-connection-mark=gaming out-interface=ether1 passthrough=\
yes protocol=udp
add action=mark-connection chain=postrouting comment=XBOX31112TCP disabled=yes dst-port=31112 new-connection-mark=gaming out-interface=ether1 passthrough=\
yes protocol=tcp
add action=mark-connection chain=postrouting comment=XBOX1200-1299UDP disabled=yes dst-port=1200-1299 new-connection-mark=gaming out-interface=ether1 \
passthrough=yes protocol=udp

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1
add action=dst-nat chain=dstnat comment="XBOX 3074 UDP" dst-port=3074 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=3074
add action=dst-nat chain=dstnat comment="XBOX 3074 TCP" dst-port=3074 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=3074
add action=dst-nat chain=dstnat comment="XBOX 4500 UDP" dst-port=4500 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=4500
add action=dst-nat chain=dstnat comment="XBOX 31112 TCP" dst-port=31112 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=31112
add action=dst-nat chain=dstnat comment="XBOX 31112 UDP" dst-port=31112 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=31112
add action=dst-nat chain=dstnat comment="XBOX 3544 UDP" dst-port=3544 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=3544
add action=dst-nat chain=dstnat comment="XBOX 500 UDP" dst-port=500 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=500
add action=dst-nat chain=dstnat comment="XBOX 88 UDP" dst-port=88 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=88
add action=dst-nat chain=dstnat comment="XBOX 80 TCP" dst-port=80 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=80
add action=dst-nat chain=dstnat comment="XBOX 1200-1299 UDP" dst-port=1200-1299 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=1200-1299
add action=dst-nat chain=dstnat comment="XBOX 16000 TCP" dst-port=16000 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=16000
add action=dst-nat chain=dstnat comment="XBOX 16000 UDP" dst-port=16000 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=16000
add action=dst-nat chain=dstnat comment="XBOX 53 TCP" dst-port=53 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=53
add action=dst-nat chain=dstnat comment="XBOX 53 UDP" dst-port=53 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=53
add action=dst-nat chain=dstnat comment="SONY PS4 3478-3479 UDP" dst-port=3478-3479 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=\
3478-3479
add action=dst-nat chain=dstnat comment="SONY PS4 3658 UDP" dst-port=3658 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=3658
add action=dst-nat chain=dstnat comment="SONY PS4 3478-3480 TCP" dst-port=3478-3480 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=\
3478-3480
add action=dst-nat chain=dstnat comment="SONY PS4 443 TCP" dst-port=443 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=443
add action=dst-nat chain=dstnat comment="SONY PS4 1935 TCP" dst-port=1935 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=1935
add action=dst-nat chain=dstnat comment="SONY PS4 8080 TCP" dst-port=8080 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=8080
add action=dst-nat chain=dstnat comment="SONY PS4 5223 TCP" dst-port=5223 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=5223
add action=dst-nat chain=dstnat comment="SONY PS4 80 TCP" dst-port=80 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=80
add action=dst-nat chain=dstnat comment="SONY PS4 3074 TCP" dst-port=3074 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=3074
add action=dst-nat chain=dstnat comment="SONY PS4 3074 UDP" dst-port=3074 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=3074
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip pool
add name=default-dhcp next-pool=default-dhcp ranges=10.0.1.10-10.0.1.255
/ip route
add check-gateway=ping disabled=yes distance=1 gateway=192.168.0.1
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip smb
set allow-guests=no
/ip smb shares
set [ find default=yes ] directory=/pub
/ip upnp interfaces
add disabled=yes interface=ether1 type=external
add disabled=yes interface=bridge type=internal
/system clock
set time-zone-name=America/New_York
/system identity
set name=MR101
/system routerboard settings
set silent-boot=no
/tool mac-server
set allowed-interface-list=mactel
/tool mac-server mac-winbox
set allowed-interface-list=mac-winbox
/tool sniffer
set file-name=test.pcap filter-interface=wlan1 filter-operator-between-entries=and
[admin@MR101] >

I find it hard to believe the forum has no private message features! Bummer!! Ive done a deep scan on the wireshark file and it appears to not have any sensitive data on it so hopefully I wont be attacked by tomorrow lol.

I can take screen shots as well but you wont be able to navigate through the layers and view the respective data.

Great point. You wouldn't believe how many people post screenshots on ask.wireshark.org and expect someone to be able to debug on them.

One possibility is to use any plain file sharing service, another possibility is to use cloudshark.org. And put a link to the file here, just make sure that the link is login-free.

BTW, the address to which the robot has sent the NTP packet this time resolves to ntp2.doctor.com, so I assume it really is a NTP request. The fact that there is no reponse makes me cautious, so it would be fine if you could post here also the output of /export hide-sensitive, after sysrematically replacing each occurrence of any public IP you don't want to publish by a meaningful distinctive string like my.public.ip.1 - maybe your firewall is too strict.

There isnt any way to PM you the link?

Unfortunately PM on this forum is blocked.

There isnt any way to PM you the link?

Use <-- , I'll edit it out as soon as the message comes.

You have me stumped on that one I just threw in the flag haha Let me know when you download.

Please save the quote with the address somewhere else and then edit it out from your post above. Have you given a thought to reading it in the direction of the arrow? Downloaded.

Please save the quote with the address somewhere else and then edit it out from your post above. Have you given a thought to reading it in the direction of the arrow? Downloaded.

Im officially a dumb ass lol, sounds good!

btw I removed the quote with.. ofni ruoy <--

So what we know is that:

• the AI sends a DNS query to pool.ntp.org, gets a list of four candidates for a NTP server, uses one of them and when it gets no response from there, it doesn't bother to try another one.
• it sends a DNS query to RV750-39a9391a-device.aylanetworks.com, and when it gets an answer which looks decent in all aspects, it does nothing else based on that answer and tries again in a while, and so on so forth.

So what I've done was that I've sent a query to the same domain name from my Windows bypassing the Mikrotik's DNS cache, and I've got an answer which, on top of the one provided by the Mikrotik, contains two more sections, Authoritative Nameservers and Additional Records.

It could be that the AI authors use this to check that nobody tampers with the DNS responses. So please change the /ip dhcp-server network in your configuration, namely, change dns-server=10.0.1.1 to dns-server=8.8.8.8, so that the AI would bypass Mikrotik's DNS and ask uncle Google's one directly. (Of course you have to restart the AI to get this via DHCP) If it helps, we can find a way to do that selectively for the AI only, keeping the standard setting for all other devices.

Do that fast as I am about to hibernate soon

So what we know is that:

• the AI sends a DNS query to pool.ntp.org, gets a list of four candidates for a NTP server, uses one of them and when it gets no response from there, it doesn't bother to try another one.
• it sends a DNS query to RV750-39a9391a-device.aylanetworks.com, and when it gets an answer which looks decent in all aspects, it does nothing else based on that answer and tries again in a while, and so on so forth.

So what I've done was that I've sent a query to the same domain name from my Windows bypassing the Mikrotik's DNS cache, and I've got an answer which, on top of the one provided by the Mikrotik, contains two more sections, Authoritative Nameservers and Additional Records.

It could be that the AI authors use this to check that nobody tampers with the DNS responses. So please change the /ip dhcp-server network in your configuration, namely, change dns-server=10.0.1.1 to dns-server=8.8.8.8, so that the AI would bypass Mikrotik's DNS and ask uncle Google's one directly. (of course you have to restart it to get this via DHCP) If it helps, we can find a way to do that selectively for the AI only, keeping the standard setting for all other devices.

Do that fast as I am about to hibernate soon

Done, about to reboot the router and AI.

Done, about to reboot the router and AI.

My correction came too late. No need to reboot the router, only the AI.

So please change the /ip dhcp-server network in your configuration, namely, change dns-server=10.0.1.1 to dns-server=8.8.8.8, so that the AI would bypass Mikrotik's DNS and ask uncle Google's one directly. (Of course you have to restart the AI to get this via DHCP) If it helps, we can find a way to do that selectively for the AI only, keeping the standard setting for all other devices.

Do that fast as I am about to hibernate soon

IT WORKS! HOLY CRAP... But now all other devices on the network will rely on direct dns route 8.8.8.8 rather then relying on mikrotik internal dns? Doesn't this make my network / devices more susceptible to DNS/DDOS attacks? Or will the firewall still suppress these from an individual or overall stance

But now all other devices on the network will rely on direct dns route 8.8.8.8 rather then relying on mikrotik internal dns? Doesn't this make my network / devices more susceptible to DNS/DDOS attacks? Or will the firewall still suppress these from an individual or overall stance

First, don't worry, this change does not expose your LAN to DNS attacks from outside.
Second, what did you have in mind when putting in these two rules?
Because this means that when someone from outside sends a DNS request to the public IP of your 'Tik, you forward that request to the Xbox.

Third, to make sure that only the AI will have this special DNS treatment, you have first to create a static lease for it (you can just make the current one static, or you can choose some address you deem more appropriate than 10.0.1.124), then add two rules:
and then set the dns-server in /ip dhcp-server network back to 'Tik's own LAN IP.

The two rules are there to evenly distribute the queries between the two servers so that if one of them is down, the next attempt will hit the other one.

Second, what did you have in mind when putting in these two rules?

Code: Select all

/ip firewall nat
add action=dst-nat chain=dstnat comment="XBOX 53 TCP" dst-port=53 in-interface=ether1 protocol=tcp to-addresses=10.0.1.XXX to-ports=53
add action=dst-nat chain=dstnat comment="XBOX 53 UDP" dst-port=53 in-interface=ether1 protocol=udp to-addresses=10.0.1.XXX to-ports=53

Because this means that when someone from outside sends a DNS request to the public IP of your 'Tik, you forward that request to the Xbox.

At one point I did have issues with port forwarding with XBOX and resorted to the following link which instructs to apply firewall rules the following
https://support.microsoft.com/en-us/hel ... r-xbox-one

Please do correct me if im wrong with this!

Third, to make sure that only the AI will have this special DNS treatment, you have first to create a static lease for it (you can just make the current one static, or you can choose some address you deem more appropriate than 10.0.1.124), then add two rules:

Code: Select all

/ip firewall nat
add chain=dstnat action=dst-nat protocol=udp dst-port=53 to-addresses=8.8.8.8 src-address=10.0.1.124 per-connection-classifier=src-port:2/0
add chain=dstnat action=dst-nat protocol=udp dst-port=53 to-addresses=1.1.1.1 src-address=10.0.1.124 per-connection-classifier=src-port:2/1

and then set the dns-server in /ip dhcp-server network back to 'Tik's own LAN IP.

The two rules are there to evenly distribute the queries between the two servers so that if one of them is down, the next attempt will hit the other one.

Sounds great!!!! I will definitely apply everything you've suggested!

At one point I did have issues with port forwarding with XBOX and resorted to the following link which instructs to apply firewall rules the following
https://support.microsoft.com/en-us/hel ... r-xbox-one

Please do correct me if im wrong with this!

I'm afraid it's not you but Microsoft who confuses the terms... I cannot see why you should expose http and dns server ports of the xbox for access from outside. Where firewalls are really paranoid, connection to these ports in the internet may be restricted for clients on LAN, and that's what that Microsoft guy had in mind. But that's not the case of your firewall rules which permits anything on the LAN to initiate connections to anything in the internet. And "port forwarding" always means "forwarding requests coming from outside to a particular port on the WAN address to an address of a LAN device", which is a different thing than "opening access to ports in the internet for requests coming from LAN devices". So I would definitely disable all those Xbox rules, switch the Xbox off, remove all established connections with the Xbox IP address from the firewall, and switch the Xbox on again. If it would not work, I'd enable the rules one by one and only keep those which are really necessary for it to work. Should be none, though.

At one point I did have issues with port forwarding with XBOX and resorted to the following link which instructs to apply firewall rules the following
https://support.microsoft.com/en-us/hel ... r-xbox-one

Please do correct me if im wrong with this!

I'm afraid it's not you but Microsoft who confuses the terms... I cannot see why you should expose http and dns server ports of the xbox for access from outside. Where firewalls are really paranoid, connection to these ports in the internet may be restricted for clients on LAN, and that's what that Microsoft guy had in mind. But that's not the case of your firewall rules which permits anything on the LAN to initiate connections to anything in the internet. And "port forwarding" always means "forwarding requests coming from outside to a particular port on the WAN address to an address of a LAN device", which is a different thing than "opening access to ports in the internet for requests coming from LAN devices". So I would definitely disable all those Xbox rules, switch the Xbox off, remove all established connections with the Xbox IP address from the firewall, and switch the Xbox on again. If it would not work, I'd enable the rules one by one and only keep those which are really necessary for it to work. Should be none, though.

Crap. I will definitely perform this right now. I hope I haven't kept you from hibernation. I will follow up tomorrow! Thank you again for the help! i'm glad I was able to at least provide you with enough info the crack down the root of the issue!

I've realized that the AI may be sending a targeted DNS query to the authority servers indicated in the answer later on, so I've edited the rules in post #25 (because I think it is the post which the OP should mark as the solution if he eventually gets back to the topic) by adding a condition that only query to Mikrotik's DNS would be redirected - dst-address-type=local
Other than that, you may want to send a support ticket referring to this topic to support@mikrotik.com. RFC1034 mentions caching the answer and doesn't discuss any kind of filtering its contents, so I would suppose it should be cached as a whole, including the RRs which RouterOS currently does not forward.

I've realized that the AI may be sending a targeted DNS query to the authority servers indicated in the answer later on, so I've edited the rules in post #25 (because I think it is the post which the OP should mark as the solution if he eventually gets back to the topic) by adding a condition that only query to Mikrotik's DNS would be redirected - dst-address-type=local

Code: Select all

/ip firewall nat
add chain=dstnat action=dst-nat protocol=udp dst-port=53 to-addresses=8.8.8.8 src-address=10.0.1.124 dst-address-type=local per-connection-classifier=src-port:2/0
add chain=dstnat action=dst-nat protocol=udp dst-port=53 to-addresses=1.1.1.1 src-address=10.0.1.124 dst-address-type=local per-connection-classifier=src-port:2/1

Other than that, you may want to send a support ticket referring to this topic to support@mikrotik.com. RFC1034 mentions caching the answer and doesn't discuss any kind of filtering its contents, so I would suppose it should be cached as a whole, including the RRs which RouterOS currently does not forward.

Sindy,

I have been testing the Shark since our last discussion and am glad to report back that I have had "zero" issues both internal/external of my LAN. I can send requests from outside in through LTE and while in the area of wifi coverage I have no comm issues either. Safe to say the DNS aspect was the issue and will definitely take time now to report to Mikrotik Support. I decided to keep the DNS config as is, since as you stated there is no real threat and since have seen some improvements overall within the network. As for making this AI static, The AI including AI Application doesn't give me an option to apply static configurations from a client perspective, so I have a feeling at some point when and if the battery ever drains and cant make its way back to the dock for a charge, might lose its IP config and re-register. I went into DHCP and made it a static and assigned an IP, lets see what happens down the line.

Off topic, I am a bit still concerned about the XBOX port/forwarding aspect id like to run by you on the side. I don't play much but would still not have to worry about NAT related issues (Strict NAT format) when I do decide to power on and use for media and or multiplayer play. Let me know if your'e ok with me asking away or if I should open a new topic/post.

As for making this AI static, The AI including AI Application doesn't give me an option to apply static configurations from a client perspective, so I have a feeling at some point when and if the battery ever drains and cant make its way back to the dock for a charge, might lose its IP config and re-register. I went into DHCP and made it a static and assigned an IP, lets see what happens down the line.

This is exactly what I had in mind when I wrote

create a static lease for it

Off topic, ... Let me know if your'e ok with me asking away or if I should open a new topic/post.

It's not so much about my personal preferences, but the forum is most useful when kept structured. So creation of a new topic is a better approach.

The difference between setting Mikrotik to use 8.8.8.8 as its upper tier DNS server and telling Mikrotik's DHCP clients to use the Mikrotik itself as their DNS server (case A) and telling Mikrotik's DHCP clients to use directly 8.8.8.8 as their DNS server (case B) is that in case A, Mikrotik caches the DNS responses and if some other LAN client sends the same query, Mikrotik provides the response from the cache and doesn't waste the uplink bandwidth and load the upper tier DNS server by sending the same query another time. However, as it doesn't cache every single bit of the answer, in rare cases like the one which has sparked this topic, the client may behave different if the DNS answer doesn't contain some information it expects there although that information is not necessary for the name resolution itself (which is why Mikrotik dares not to cache it).

In some other scenarios, where you use an fqdn as an address in /ip firewall address-list, the response of the DNS server to Mikrotik's query about that fqdn, which is used to create dynamic items on the address list which have the ip numbers to which the fqdn has been translated as address, it might theoretically happen that an answer of the same server to a direct query of a LAN client for the same fqdn contains a different list of IP numbers, so the firewall rules referring to the address list would permit what should be blocked or block what should be permitted. So this could be another reason, on top of network resource conservation, to indicate Mikrotik itself as a server to the LAN clients.

As for NTP, the logic is similar, bothering external NTP servers with synchronisation requests from individual LAN clients causes an unnecessary load to them without providing any actual benefit to the user, except if the Mikrotik's real time clock discipline was so bad that the jitter of the clock at the end client would be much smaller if it would talk directly to the higher tier NTP server, but in an average home network this is rarely an important factor.

Okay so its fair to say, that for when smart devices are acting up in terms of connecting to home (at first install for example),
the issues are likely to be NTP, DNS related. In this case, its best to put 8888 or dyndns right into the dhcp server settings to see if that resolves the issue?

Frankly, the only correct thing to do is to analyse how the communication goes since powering the device on. The fact that in this particular case the root cause was that RouterOS has censored out part of the DNS response implies nothing at all regarding why another smart device fails to communicate properly, so trying to give that device a pointer to a public DNS is not harmful but it is really unlikely that it would be a universal remedy.

As for the NTP issue, why or what is a smart device doing attempting to go out UDP on port 123?

The smart device may need to know the real time for some "visible" purpose (like using a weekly schedule to control its operation), but it may also merely want to check the validity of certificates used to authenicate the encrypted communication of the device with its cloud servers.

Is this considered a new connection by the router in the forward chain (or is UDP not detected?) and if not what happens to the reply?
What should be done to outgoing UDP connections on port 123? Special rules??

UDP connections are normally also tracked by firewall; the default firewall rules block incoming connections from the internet but permit LAN devices to initiate connections anywhere they want. So unless you've tightened your firewall rules in this regard (i.e. unless you only permit LAN devices to connect to whitelisted destinations) or broken the NAT functionality, the firewall should not be the reason why no NTP response comes.

I guess I am a bit lost on NTP because I dont use it.... for the router I setup sntp or something (assuming this is so the router has the correct date/time) and that if any clients need it they will query the router for it and not try to go external to the internet. My knowledge is weak so its very fuzzy for me.

The purpose of NTP is to synchronize the device's real time clock to reference servers chosen according to some criteria from a larger set. The purpose is to choose the servers which are closest to the primary reference (usually a GPS-provided time), to which the communication path is least jittery, and to exclude servers providing clearly wrong data (by comparing the information from several servers and excluding those which differ too much from the average). After reaching a tracking state, the drift of the internal clock is evaluated, and the frequency of querying the reference servers is reduced to once in tens to hundreds of seconds, with the aim to keep the local clock as precise as possible and at the same time as smooth as possible.

SNTP uses the same protocol messages like NTP to query a single reference server once per longer period of time, and rather than softly regulating the rate of the local clock to compensate the offset of the local clock from the reference smoothly, it updates the local clock quite abruptly.

In either case, it depends on the device implementation whether it uses the NTP server indicated in the response of the DHCP server or whether it uses DNS to obtain address(es) of one or more servers from pool.ntp.org even if the DHCP response does contain the "time server" Option, and whether unavailability of a time reference prevents the device from working properly or not.

Firewall rules cannot be thought about separately, there is a lot of interaction between them (briefly rules higher/earlier in each chain are exceptions from the rules lower/later in the same chain). The rule you mention suggests that it is used where access to services of the router itself from devices connected to its LAN is restricted to just a few ones, which is in general a good idea but the default firewall doesn't restrict access to router from LAN at all.