Topic: Ecowitt - Cloud service blocked under country block set on Router

[Bdav]

Using an Ecowitt station with their cloud service, it seems we are unable to connect to the cloud service due to a block on Russian IPs.

I was under the impression Ecowitt were Chinese / Hong Kong - Is it expected that their cloud services reside in Russia?

[Rover1822]

Where is your originating request coming from "country", I mean where are you? , using a VPN?

The block response could be generic or something else, But as far as I know the the target sites are in China, unless, there is some form of redirect.

We do know that VPN connections may have an issue, but no idea what your connection is. I am in the US and have had no issues.

[Bdav]

No VPN, UK origination.

When I do the DNS lookup on Ecowitt.net I get the attached (79.133.176.209) which resolves to Russian IP space when using MaxMind. I’ve removed the restriction on the UniFi router for now, but is still curious.

 [ You are not allowed to view attachments ]

[Gyvate]

that geoip thing is wrong (or partly wrong, or wrongly interpreted).
The IP range belongs to a big Chinese IT service and network provider who afaik even "hosts" (uses) some of these ranges in Germany - but, true, there are also .ru domains hosted in that range.
Not only servers have IP addresses, by the way, also other network equioment 
However, you can host any doesn't-matter-which TLD (top level domain) on any host anywhere in the world.
There was the same discussion in a German weather forum - with the same (not looking deeply enough) conclusion drawn - until we went to the bottom of it.
These geoip services often only take the first two triplets of an IP4 IP address to identify the country ... - and that's not a 100% working algorithm ... 
.ru only means top level domain Russia - but nothing is said where (physical location) the server where it is hosted stands.
So the Ecowitt servers stand on Chinese ground and their service provider is Chinese, not Russian.
And the network infrastructure used belongs to a Chinese service provider too.

[Bdav]

Yeah I understand that its range based, and even then its a "best effort" guess at where it is based on routing.

Unfortunately the hardware I'm using (UniFi UDM SE) is using this data - It's not a massive deal for now (I've just turned off the country restrictions), but unfortunate! Its the first time I've come across a clashing range (they must be sat in quite a small, shared range, which is fairly unusual!)

I was hoping the IP allowlist would take precedence over the country blocking, but the country blocking seems to happen first sadly.

[henry]

It is the CDN issue. Now it should be ok.  If still having issues, please post here.

[Bdav]

Unfortunately it seems so - although it may be stale DNS - the TTL appears to be 0 so it *shouldn't* be stale DNS...

Code: [Select]

dig a ecowitt.net                                                                                                                                                                     1 ✘  15:40:02

; <<>> DiG 9.16.1-Ubuntu <<>> a ecowitt.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64081
;; flags: qr rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ecowitt.net.                   IN      A

;; ANSWER SECTION:
ecowitt.net.            0       IN      CNAME   ecowitt.net.w.kunlunsl.com.
ecowitt.net.w.kunlunsl.com. 0   IN      A       79.133.176.209

;; Query time: 339 msec
;; SERVER: 172.19.176.1#53(172.19.176.1)
;; WHEN: Mon Feb 27 15:40:38 GMT 2023
;; MSG SIZE  rcvd: 122
Maxmind: 79.133.176.209   RU

[kheller2]

That is weird, and pretty amazing you caught both TTL timers at 0.

State side I have this, for reference:
;; ANSWER SECTION:
ecowitt.net.      558   IN   CNAME   ecowitt.net.w.kunlunsl.com.
ecowitt.net.w.kunlunsl.com. 19   IN   A   47.246.20.180

But yes it is all related to how Alibaba cloud is returning the A record for your query (and then for whatever product is blocking that IP range you get).  Having said that, 79.133.176.209 does have a Russian mailing address according to whois, and is owned? by Zhejiang Taobao Network Co.,Ltd.  weird.

This is also assuming that your Internet provider isn't hijacking DNS and injecting whatever they want.

[Gyvate]

Zhejiang Taobao Network Co.,Ltd.

that's exactly what we found out the other day ....
=> a domain name or an email with a domain name has not necessarily viable information about where it is hosted.
whatever the TLD is
a .us domain could be hosted on a server in Russia (or anywhere else)

[kheller2]

Zhejiang Taobao Network Co.,Ltd.

that's exactly what we found out the other day ....
=> a domain name or an email with a domain name has not necessarily viable information about where it is hosted.
whatever the TLD is
a .us domain could be hosted on a server in Russia (or anywhere else)

Correct.  But as you probably know, it has nothing to do with a TLD. It has to do where the physical IP address is located.  If that IP block is registered to a Russian entity, I can see why it might be blocked. 

Oddly enough, 79.133.176.209 in some databases show it as a UK geolocations address.
The SSL Cert returned from that address is registered to ALICDN.COM  (I'm assuming Alibaba)

https://www.iplocation.net/ip-lookup  for that address shows it from England OR Russia. hah.
It could be a Russian service IN Manchester.

retn.net seems to be the owner.. and that is part of the "Eurasian Network" which includes several countries.