pfSense Blocking Roborock app
-
Ok So In testing the integration I went to the github page. Looks like I am not the only one with the issue. Here is a link to the problem someone else is having. I would bet anything he is also using a FreeBSD router. The plot thickens...
Similar issue found on github integration with Home Assistant
-
@kahodges1721 said in pfSense Blocking Roborock app:
Ok So In testing the integration I went to the github page. Looks like I am not the only one with the issue. Here is a link to the problem someone else is having. I would bet anything he is also using a FreeBSD router. The plot thickens...
Similar issue found on github integration with Home Assistant
Read through that chain on Github. I lean towards an app update being the problem, but why it works via Wi-Fi with the Netgear in place, but fails with pfSense and OPNsense in place, is a mystery. Might be subtle differences in how states are handed between the Netgear firewall engine and FreeBSD. State timeouts can be configured in pfSense. Perhaps setting the firewall optimization to "Conservative" might help. That option is here:
-
@bmeeks I gave the change a try and its a no go. I agree that it must be a change on the side of roborock. I guess the reason I am concerned is the population of users with pfSense and roborock devices might not be large enough to warrent a change from Roborock. Meaning I am left either leaving pfSense which I really dont want to do or get a different robot which this one is by far the best I have used so I dont want to do that either! I keep going back to the fact that the netgear works. This has to give us some clues. At first I considered that Roborock flagged my IP or something bc it didnt like the integration through HA but that cant be the case since it works through the Netgear. The only thing left is there is some difference either in DNS handling or firewall rules that is blocking the communication. With pfSense being so open to the user vs a standard router I feel there is a fighting chance to find the setting and configure it. Hopefully posting in the github brings more users with issues to light.
-
Some good information learned from the github link that I thought would be worth sharing here for ideas.
I believe the apps (Mi Home and Roborock) work slightly different. One thing I noticed is the Mi Home app connects using both their servers and locally to the device whereas the Roborock app connects to the device through their cloud MQTT service on port 8883 (in addition to TCP connections on 443). I don't believe the Mi Home app ever used MQTT since I explicitly had to allow that on my firewall to get the Roborock app to work. I haven't used pfSense or OPNsense for a while but I wonder if there's something weird when it comes to MQTT?
I also noticed my Sophos XG logs shows the MQTT connections with the Roborock MQTT broker as "SSL Traffic over Non-SSL Ports".
-
usiot.roborock.com is apparently the culprit. I got a message on the other forum from the developer of the integration and that’s the site that is being used for the api. It seems pfsense will not resolve it. I’ve never had this issue so not sure why or what to do to fix it but it at least pin points the problem. I’m curious if it resolves on anyone else running pfsense
-
@kahodges1721
It resolved here just fine.
-
@jarhead yes it shows “resolved“ on mine also but when I try to navigate to it I don’t get anything. I may be using the wrong terminology here. Basically I type in the aggress into a web browser and can’t reach it. Navigating to the other api euiot.roborock.com seems to not get blocked and opens a white page. I also ran a trace route below is what I got.
10.157.0.1 8.118 ms 7.113 ms 7.503 ms
2 209.196.177.66 7.205 ms 7.788 ms 8.731 ms
3 207.255.30.160 25.315 ms 24.719 ms 29.381 ms
4 99.83.89.162 28.368 ms
99.83.68.84 23.760 ms 24.622 ms
5 * * *
6 * * *
7 52.93.29.98 31.090 ms
52.93.29.92 33.040 ms
52.93.29.82 25.631 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * * -
This is what I get with the USIOT and Euiot address
Sorry for using the links but I can’t get to the computer right now and linking an image from my phone I couldn’t figure out how
-
The usiot.roborock.com hostname resolves fine on my pfSense box:
You said "usiot.roborock.com" in your first post, but then in the follow up with the link to Imgur you show both usiot and euiot. Which one is correct? Do both resolve properly on your firewall?
Go to DIAGNOSTICS > DNS Lookup in the pfSense menu and enter both hostnames, one at the time, hitting Lookup between attempts. Post back the output from the results window as I did above.
-
@bmeeks both resolve fine According to the test. I guess I was assuming it wasn’t resolving since when I type them into the web browser the US gives the server stopped responding error and the EU works just fine. Switching to LTE both work just fine and display a blank white page as expected.
Both are used for the api according to the developer of the integration. I focused only on the U.S. bc that seems to be the culprit of the issue
This is the post that lead to the testing:
Starting with the basics. Is your router resolving DNS euiot.roborock.com? (Which is the default base url to discover the real api to be used based on your account country). And, if your account from US, is it also solving usiot.roborock.com ?
-
@bmeeks dns lookup results
-
@kahodges1721:
Are you running pfSense CE or pfSense Plus? Those have different versions of theunboundDNS resolver, and the version in the current pfSense Plus (1.15.0) has some issues sometimes chasing CNAME records and/or resolving IPv6 stuff. IPv6 does not appear to figure in your problem, though, since those domains resolve to IPv4 addresses.I also need to ask one more time. When you say you reinstalled pfSense and chose the defaults, does that mean all of the following statements are true?
- You installed fresh from either an ISO image or USB memstick image and took all the offered defaults during installation, changing nothing other than probably answering "No" for anything IPv6 related.
- You did absolutely nothing to DNS. You did not type in any DNS server IP addresses anyplace at any time during or after the install procedure. DNS is 100% stock, out-of-the-box.
- You answered "Yes" during the installation when prompted whether to enable DHCP on the LAN. You took any offered defaults for that configuration as well.
- You did NOT restore any kind of previous configuration backup either during the install procedure nor after from the DIAGNOSTICS menu.
- You neither added to nor edited any of the firewall rules that came as part of the default out-of-the-box install.
- You have not installed (or restored) any add-on packages.
I want to make sure the firewall is truly in a default configuration, because that usually just works for everything.
I can successfully navigate to a web page at both hostnames you provided (usiot and euiot). I get a blank, white page in both instances which I assume is expected as that is really an API for authentication and not for HTML display.
I would also try really basic things like can you ping both host names from the DIAGNOSTICS menu of pfSense? Try using the
ping -s 1460option use a maximum size ICMP packet. -
@bmeeks that’s interesting it worked for you and disappointing bc I was hoping it wouldn’t work for anyone on pfsense haha hmm…
As far as defaults yes it was a fresh download of pfsense CE. All defaults were selected with DHCP on lan. I did enter a dns address of 8.8.8.8 for primary and 8.8.4.4 for secondary. This is also the dns addresses used on the NETGEAR. Nothing else was touched at all. Tested the app and it failed. I then upgraded it to pfsense plus which is what I typically run and same result. I haven’t found a way to install plus directly for some reason so maybe installing CE first is causing something? But what still doesn’t make sense is why it broke in the first place. Nothing about dns or pfsense was touched at all in the past like 6-8 months. I’ve had the same settings for a while and just let it go.
-
@kahodges1721 said in pfSense Blocking Roborock app:
I did enter a dns address of 8.8.8.8 for primary and 8.8.4.4 for secondary.
Remove those. You do not need them. Out of the box
unboundis configured to resolve in pfSense. That means it talks to the root DNS servers and walks down the tree to find IP addresses for hostnames. Also that is quite a bit more "private" than handing Google all of your DNS traffic so they can log where you go and target you with ads and otherwise profile you. Putting in those servers is not "default"
. They likely are not the problem here, but that is an unnecessary change to pfSense. Leave the DNS boxes under SYSTEM > GENERAL SETUP blank. Also go back and make sure the DNS server boxes in the DHCP server configuration page are blank. That way, DHCP will hand your clients pfSense as their DNS server (which is generally what you want).One other thing, make sure the DNS Server Override box is unchecked on the SYSTEM > GENERAL SETUP page!
-
@bmeeks again I can’t thank you enough for the help. Unfortunately I had to call it quits for the day and get ready for work tomorrow. I will give it a go again tomorrow after work and update
-
Your DNS configuration in pfSense is needlessly complex. You have 4 name servers listed. You should only have 127.0.0.1 showing there as the default configuration for pfSense uses
unboundrunning in resolver mode. Your DNS configuration is NOT default. You said earlier you did a fresh install and had everything set for defaults.Have you enabled "Forwarding" under SERVICES > DNS Resolver?
Have you checked the DNS Server Override box under SYSTEM > General Setup?
What are those two 173.44.120.88 and 173.44.120.89 DNS servers? Are they perhaps from your ISP? You certainly do not want those in the mix in my opinion.
Your DNS setup is NOT default! This could be a source of problems.
Notice in my screenshot for resolving the usiot.roborock.com host there is only a single DNS server listed. It's 127.0.0.1, which is the local
unbounddaemon running in resolver mode on my firewall. You need to do what I mentioned earlier:- Go to SYSTEM > General Setup and remove all the DNS server IP addresses you entered there (I think you said they were 8.8.8.8 and 8.8.4.4). There should be nothing at all in those DNS server boxes. Leave them blank.
- Be sure the DNS Server Override checkbox immediately below on the same page is unchecked (as in cleared or not checked).
- Go to the DHCP Server settings under SERVICES > DHCP and remove anything you typed into the DNS server settings there to be served to clients. Make sure all the DNS boxes are empty. That way, DHCP will serve clients the pfSense firewall's LAN IP as the DNS server they are to use. That is what you want.
- Go to SERVICES > DNS Resolver > General Settings and uncheck everything on that page except two boxes. Those are Enabled at the top, and DNSSEC about halfway down. Make sure both of those are checked.
After you make all these checks/changes, I would reboot the firewall to be 100% sure the new settings take effect. After rebooting the firewall, toggle your phone's the Wi-Fi off and back on so it will pick up the new DNS settings.
When you make multiple DNS servers available, your clients do not use them in the order you list them. Instead, clients randomly choose one and will continue to use just that one until it fails to respond. Only then will they try another one in the list. This is especially true of Windows machines. This can cause a really confusing mess if the various DNS servers return different results for some reason such as a misconfiguration on one of them. Stuff can then work on one client but fail with another on the same LAN because they choose different DNS servers from the available list to ask for name resolution. The DNS Lookup utility on pfSense will on purpose try every configured DNS server. But normal clients don't behave that way.
-
@bmeeks I have a configuration file saved that when I leave I from my computer I load up so it puts the firewall port forwarding and static IPs back into place so the unraid server and various other things work as they should. When I ran that testing it was back after I reloaded the file. When I sit down for testing I have a usb stick that I toss onto the server and start from scratch. That said more information is coming to lights on the integration site. More people are coming forward with the same issue. As it stands now the thought is that the integration flooded the server with MQTT requests to the roborock server so they might have put a ban in place to stop this. If this is true what I don’t understand is why changing the firewall would allow me to get around the ban. Is it possible that the ban is linked to the hwid or MAC address of the PC so when swapping it out it’s no longer banned? That could explain what’s going on here possibly
-
@kahodges1721 said in pfSense Blocking Roborock app:
@bmeeks I have a configuration file saved that when I leave I from my computer I load up so it puts the firewall port forwarding and static IPs back into place so the unraid server and various other things work as they should. When I ran that testing it was back after I reloaded the file. When I sit down for testing I have a usb stick that I toss onto the server and start from scratch. That said more information is coming to lights on the integration site. More people are coming forward with the same issue. As it stands now the thought is that the integration flooded the server with MQTT requests to the roborock server so they might have put a ban in place to stop this. If this is true what I don’t understand is why changing the firewall would allow me to get around the ban. Is it possible that the ban is linked to the hwid or MAC address of the PC so when swapping it out it’s no longer banned? That could explain what’s going on here possibly
No, a MAC address never goes beyond the local network. It is remotely possible that your ISP gives you a different dynamic WAN IP address when you change devices due to the MAC they can see on your WAN interface port (that goes to their modem), and the Roborock server has that IP banned. You can easily test that by configuring pfSense to clone the MAC address of your Netgear's WAN port.
But I think your firewall is not truly default, or else you have me very confused by some of your statements. You tell me it is default, but then you say this:
@kahodges1721 said in pfSense Blocking Roborock app:
I have a configuration file saved that when I leave I from my computer I load up so it puts the firewall port forwarding and static IPs back into place so the unraid server and various other things work as they should.
If you mean you are uploading a stored configuration to pfSense, then that is not what I consider "default". I outlined very clearly in my previous post what "default" means. It seems to me that you are bringing back some erroneous configuration when you upload that stored file to the firewall. And what do you mean about the USB stick? How does that figure in? It seems we are going around in circles here
. -
@kahodges1721 Power up the old router, find the MAC of the WAN port and copy it.
In pfSense go to Interfaces/WAN. Enter the old routers MAC in the MAC Address field.
Release/Renew WAN address. -
@bmeeks I think there is just some confusion. Sorry for that. The usb has the most current iso file for pfsense. When I’m playing with the setting and working on the issue of the app not connecting I plug in the usb and load a fresh copy of pfsense onto the computer and run full default config (minus I was entering the 8.8.8.8 and 8.8.4.4 into dns which I won’t moving forward) when I’m no longer working on the issue and leave for the day I load the saved configuration file so things like my Plex server and other integrations that required static ips or port forwarding rules work properly. The screenshots from my phone I sent last night were after I loaded the config file and quit for the day. That is why I had to send them via Imgur bc I didn’t have access to the pc. I won’t be able to revert back to full defaults until I get home from work this afternoon and can continue to test the issue. Hopefully that helps to clear up my process with this a little bit.
That said it seems more and more are showing to have the same issue most with various different routers. Tonight I will load a fresh copy of pfsense and change the mac address as defined above and just test that next.
Please let me know if it’s still not clear and I can try to explain in even more detail.
