Weird outbound UDP traffic

Uqbar · Wed Sep 19, 2018 1:09 pm

Hi all.
I've setup a new Mikrotik box.
My policy is to only allow traffic that's meant to be allowed and dropping anything else.
Soon after the upgrade to v6.43.1 I am finding a number of events in the logs like this one:

DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:38962->159.148.147.201:15252, len 66
DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:49614->159.148.172.251:15252, len 66

every two minutes. 192.168.255.252 is the management IP address of the box and there's also a default route though it.
Both public IPs are Latvian IPs.
And very likely they are run by the Mikrotik company itself as www.mikrotik.com=159.148.147.196 and download.mikrotik.com=159.148.147.204,159.148.172.226.
A similar box running v6.42.7 isn't showing such traffic.
That wouldn't be a problem, as long as I knew this is a normal™ behaviour.

Is this a normal behaviour?
What's going on?

Some investigation lead to this:

UDP:15252 Used by MikroTik routers:
When enabled '/ip cloud' will send encrypted UDP packets to port 15252 to hosts that resolves from cloud.mikrotik.com. (https://wiki.mikrotik.com/wiki/Manual:IP/Cloud)

Useless to say that I don't have any Could service in use.
And that cloud.mikrotik.com resolves to 81.198.87.240 (for me at least).

/ip cloud print

shows a default "update-time: yes".
Once I disabled that setting, I am still able to see those outbound UDP packets.

Anumrak · Wed Sep 19, 2018 1:27 pm

Very interesting. Join the topic.

Uqbar · Wed Sep 19, 2018 1:57 pm

Read here:
viewtopic.php?t=137708

I really don't expect a default "blank" router configuration to enable outbound connections over unknown protocols.
So I've also disabled that "Time Zone Autodetect" setting.
I still see those outbound UDP:15252 connections.

Anyway, if that's legitimate, I think there should be some documentation about it.
Also the firmware update procedure should be documented as its traffic is legitimate.
But in that case, the default behavior is that the updates are run manually by the net admin and not automatically nor by default configuration.

Uqbar · Wed Sep 19, 2018 4:56 pm

Those settings all get actualized ONLY after a reboot.
Only after the reboot all that UDP traffic stopped.
Which is really weird: a router shouldn't never be rebooted, unless a firmware update has been done or a huge bug is freezing it.
I would treat this a bug and file a ticket for it if there was a ticketing system.

R1CH · Wed Sep 19, 2018 5:14 pm

Emailing support@mikrotik.com will generate a "ticket". I agree this is poor behavior.

CZFan · Wed Sep 19, 2018 8:15 pm

@Uqbar,

Please keep us posted

janisk · Thu Sep 20, 2018 8:56 am

Soon after the upgrade to v6.43.1 I

DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:38962->159.148.147.201:15252, len 66
DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:49614->159.148.172.251:15252, len 66

$ host cloud2.mikrotik.com
cloud2.mikrotik.com has address 159.148.147.201
cloud2.mikrotik.com has address 159.148.172.251
cloud2.mikrotik.com has IPv6 address 2a02:610:7501:1000::201
cloud2.mikrotik.com has IPv6 address 2a02:610:7501:4000::251

starting from 6.43 IP Cloud services are connecting to cloud2.mikrotik.com

Also, wiki page about IP Cloud was updated on 17th of September to include cloud2.mikrotik.com as a domain that is used

Uqbar · Thu Sep 20, 2018 9:12 am

Soon after the upgrade to v6.43.1 I

DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:38962->159.148.147.201:15252, len 66
DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:49614->159.148.172.251:15252, len 66
Code: Select all
$ host cloud2.mikrotik.com
cloud2.mikrotik.com has address 159.148.147.201	
cloud2.mikrotik.com has address 159.148.172.251
cloud2.mikrotik.com has IPv6 address 2a02:610:7501:1000::201
cloud2.mikrotik.com has IPv6 address 2a02:610:7501:4000::251
starting from 6.43 IP Cloud services are connecting to cloud2.mikrotik.com

Also, wiki page about IP Cloud was updated on 17th of September to include cloud2.mikrotik.com as a domain that is used

Thanks for the insight and the wiki reference: while I do usually read the changelogs, I don't re-read the whole wiki at every update.

Why there's no reverse DNS for Mikrotik IPs?

support@Feynman ~] nslookup 159.148.147.201
** server can't find 201.147.148.159.in-addr.arpa: NXDOMAIN

[support@Feynman ~] nslookup 159.148.172.251
** server can't find 251.172.148.159.in-addr.arpa: NXDOMAIN

If you know the host names, you can check the IP address, just like you did.
But if If you don't know and there's no reverse DNS (like 201.147.148.159.in-addr.arpa.) you won't ever know the host name.

The main point, in the end, is not who my router is talking to, but rather, why is it doing it without my consent/configuration.
And, secondly, why on earth do I need a reboot to disable those few settings.

Then it's interesting to read on the wiki about the protocol to be used for the cloud features:

When /ip cloud set ddns-enabled=yes is set, then the device will send encrypted packets to MikroTik's Cloud server using port UDP/15252. For devices using RouterOS v6.43 and newer the encrypted IP/Cloud packets are going to be sent to cloud2.mikrotik.com. For devices using older RouterOS versions (prior to v6.43), encrypted IP/Cloud are going to be sent to cloud.mikrotik.com.

But in the very beginning I had to really struggle to link the weird traffic to the cloud features.

janisk · Thu Sep 20, 2018 2:57 pm

UDP#15252 is everything related to cloud - Time-zone detection, time (if not set in SNTP/NTP), DDNS, backup management frames.
TCP#15252 is IP Cloud backup

Did some magic with PTR

mkx · Thu Sep 20, 2018 3:19 pm

Did some magic with PTR

It's time to rock'n'roll!

Uqbar · Thu Sep 20, 2018 3:32 pm

UDP#15252 is everything related to cloud - Time-zone detection, time (if not set in SNTP/NTP), DDNS, backup management frames.
TCP#15252 is IP Cloud backup

Did some magic with PTR

It's OK: there's reverse DNS now.
That's not really a trick, though: PTR records have been "invented" just for that: reverse DNS lookups!

janisk · Fri Sep 21, 2018 10:46 am

Also, the problem about disabling IP Cloud DDNS sending packets after disabled - it sent "remove my IP from DDNS" packets to IP Cloud servers. Also, if you print in that menu, it could trigger check - if DDNS is disabled check and if disabled - "delete my IP address" packet was sent once again - will be resolved in future releases.

If you are checking your DDNS entry - if that is deleted, give some time (up to 5 minutes) to check against our IP Cloud NS servers, also, make sure that someone in between is not caching entries.

Edit: in this transition period from old IP Cloud to the new IP Cloud - if you remove your address from new IP Cloud and you did not remove it from the old, your assigned domain will still reply with your old entry from the old Cloud if not removed. After some time this will go away when the old IP Cloud servers are shut down.

Uqbar · Fri Sep 21, 2018 12:41 pm

Also, the problem about disabling IP Cloud DDNS sending packets after disabled - it sent "remove my IP from DDNS" packets to IP Cloud servers. Also, if you print in that menu, it could trigger check - if DDNS is disabled check and if disabled - "delete my IP address" packet was sent once again - will be resolved in future releases.

If you are checking your DDNS entry - if that is deleted, give some time (up to 5 minutes) to check against our IP Cloud NS servers, also, make sure that someone in between is not caching entries.

Edit: in this transition period from old IP Cloud to the new IP Cloud - if you remove your address from new IP Cloud and you did not remove it from the old, your assigned domain will still reply with your old entry from the old Cloud if not removed. After some time this will go away when the old IP Cloud servers are shut down.

I see two lines here:
1) a completely reset router should never send out anything without consent and configuration;
2) no setting should require a reboot.

Those cloud settings seem to deviate from those two lines.
Then, I'd like to know what is being sent out when I enable the cloud thing.

janisk · Fri Sep 21, 2018 2:09 pm

I see two lines here:
1) a completely reset router should never send out anything without consent and configuration;

there are defaults that are enabled, like time-zone detection. and other stuff that is not setting/saving any information about you anywhere

2) no setting should require a reboot.

Those cloud settings seem to deviate from those two lines.
Then, I'd like to know what is being sent out when I enable the cloud thing.

and there is a service like DDNS that is saving your IP address. if you disable the service then UDP packet is sent to remove you. UDP packet can fail to reach the target, as a result, your IP is still listed in our service. I as a security conscious person would rather ensure that MY IP is removed for sure if want that service disabled. That was that traffic you were seeing - repeated packets of "please delete my IP, thank you". You disabling a service does not mean - do not send traffic. It means " remove me from your service"

Now, disabling the service will send 1 packet to unsubscribe, if it fails to reach us, your IP will still be assigned to the generated FQDN and you will have to enable/disable the service until we do receive said UDP packet.
force-update also will not work if you disable DDNS. Prior to this, it was possible to disable service and if UDP did not reach and your IP is not removed, one could force-update that you have disabled the service.

Best way to ensure that no traffic leaves your router - is ip/ipv6 firewall filter chain=output. Nothing gets past that.

sindy · Fri Sep 21, 2018 2:42 pm

Best way to ensure that no traffic leaves your router - is ip/ipv6 firewall filter chain=output. Nothing gets past that.

...except DHCP server responses and VRRP master advertisements... what else? I know both these cases are specific, but is there a full list of protocols which are handled between the interface and the firewall so the firewall cannot be used to block them?

janisk · Fri Sep 21, 2018 3:39 pm

Anything from IP Cloud will be blocked by the firewall.

Uqbar · Fri Sep 21, 2018 4:47 pm

Maybe I am wrong, but a router that's been reset should simply not be sending anything out. Period.
If I enable a "cloud" feature, I can expect some traffic getting out.
If I enable NTP, I also expect some traffic getting out.
An "empty" router should not be sending any traffic anywhere.

mkx · Fri Sep 21, 2018 9:12 pm

There are two "levels" of "router reset":

reset to default config. Default config on my models has "time zone detect" enabled and according to janisk cloud functionality is used for this. It is debatable whether this should be enabled or not, my vote is NO (my network gear and servers are all set to UTC even though that's not my local time zone).
reset to blank config. In this case I agree with Uqbar that router should not send out anything for "its own entertainment".

Uqbar · Fri Sep 21, 2018 9:50 pm

Reset means blank, completely blank in my experience.

janisk · Mon Oct 01, 2018 9:14 am

the default configuration is available on wiki.mikrotik.com and on all the routers it is possible to reset this configuration to the one you desire using Netinstall (when Netinstall is used to re-install software on the router it is possible to provide a new default configuration that will replace one provided by MikroTik)

So, if your use case requires different defaults feel free to customise your router. Current default configuration represents what MikroTik thinks is best for its customers.

Weird outbound UDP traffic

Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Re: Weird outbound UDP traffic

Who is online