Dear Community,
since i’ve switched to Mikrotik AC3 i’m able to use all my wireless devices apart the HiSense Aircon that use a wifi module to connect to their cloud.
The module itself is able to join the network but seams the traffic is somehow blocked.
I’ve sniffed all the traffic from those IP and i’ve enabled also uPnp, what i’m missing?
This is the communication that do not seams to work
forward: in:ether1 out:bridge, src-mac a4:91:b1:ee:fc:82, proto UDP, 35.158.106.156:55055->10.40.2.1:49162, NAT 35.158.106.156:55055->(10.39.0.10:49162->10.40.2.1:49162), len 68
forward: in:bridge out:ether1, src-mac ca:2c:4f:94:68:08, proto UDP, 10.40.2.1:49162->35.158.106.156:55055, NAT (10.40.2.1:49162->10.39.0.10:49162)->35.158.106.156:55055, len 68
Thanks in advance to anyone can help me sorting this out
This could be as simple as the DNS settings within the HI AIRCON.
if the firmware is coded to provide domain name that is not in the right format (upper case lower whatever it is),
the MT device will accept the wrong domain name but when it returns traffic to the HIAIRCON it will fix the domain name and the HIAIRCON will reject it.
Most other vendors just COPY the domain name and provide the copy back.
My suggestion is to try setting DNS to 1.1.1.1. or 8.8.8.8 for that device only and see if you get connectivity then.
as was stated also please post config
/export hide-sensitive file=anynameyouwish
Just to update this topic, i’ve solved the issue if anyone facing the same the solution is simple:
Just reset the device CHECKING THE FIELD that avoids the default config to be applied.
There is something in the default config that do not allow to communicate with Hisense server’s.
Be prepared because resetting without default config means that you need to use Winbox directly connected thru LAN to make a basic config
Regards!
Hey, guys. I have the same problem. Maybe someone knows how to fix it without router reset?
I created few rules and they opened port 53 but 55055 and 55056 still closed even with similar rules. Don’t know why. For port testing I use telnet www.example.com 55055.
Also I enabled UpNP as variant of fix, but this also didn’t help.
My config is:
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
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-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=55055 protocol=tcp to-addresses=192.168.88.1 to-ports=55055
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp to-addresses=192.168.88.1 to-ports=53
add action=dst-nat chain=dstnat dst-port=55056 protocol=tcp to-addresses=192.168.88.1 to-ports=55056
add action=src-nat chain=srcnat protocol=tcp src-port=55056 to-addresses=192.168.88.1 to-ports=55056
add action=src-nat chain=srcnat protocol=tcp src-port=55055 to-addresses=192.168.88.1 to-ports=55055
These rules set router as target of NATed packets … which is not what you want. You have to set to-addresses property to IP address of your aircon. Before doing it make sure aircon gets same IP address every time … by setting the appropriate DHCP lease to be static.
If you want to limit NAT rules only to act on packets originally targeting router (as you should), then add another property dst-address=<router’s WAN IP address> (it’ll work if router’s WAN IP address doesn’t change) or in-interface-list=WAN (assuming you still maintain WAN Interface list as you should). Both properties will fail if you want to control aircon using WAN IP address while inside LAN, in this case you have to implement hairpin NAT (not overly complex, but not as trivial as simple NAT).
So, changing ISP, and the same issue occurs.
ISP on which everything is working is just handing out a public IP on my ether 1, and that connects the internet.
ISP2 has a PPPoE connection on vlan 998 created on ether1.
Only, I have 3 aircons, Fujitsu general.
As I found online, Hisense and Fujitsu have the same basis, aylanetworks. https://docs.aylanetworks.com/docs
UPNP does not help.
Tried switching DNS, that did not help.
Ideas?
I will try opening ports for one aircon and see…
This is BS. any device connects to the cloud of the company and works.
The problem is not the MT as it does not block outbound traffic heading to the WWW.
The problem may be that the device AIRCON may have a hard coded DNS it needs to reach??
Have you sniffed the traffic leaving the device ( perhaps wireshark ).What DNS is being used what fqdn / addresses are being looked for??
Resolved this in the meantime.
DNS is the problem, but the DNS packet itself.
Packet sniffing revealed that response packet is somehow changed when going over new ISP, I’ll attach a picture.
It is the same response packet, both originate from 8.8.8.8 one on the left is new ISP, one on the right is my old ISP. My MT configuration is identical, except for differences in ISP Internet connection, old one is just a dhcp client, new one is PPPoE on a vlan interface.
Aircon is probably hardcoded to receive packet on the right. Anything changes, and cloud control does not work. Even though DNS response in both cases points to correct address.
Solution is to transition to DoH, so that ISP cannot touch DNS packets.
This applies to Fujitsu General and Hisense aircons as far as I know.
