Can’t remotely access WIFI thermostats.
I have been fighting some issues for three weeks now and have exhausted all resources.
I am absolutely stumped.
Running PfSense nano (2.24) on a WATCHGUARD FIREBOX X750E CORE.
No VLANs or any other advanced settings, just a flat network.
I've enabled the service enabled UPnP and NAT-PMP, external WAN, internal LAN.
I have Devices that work with no port forwarding or any other modification.
OBI200 VOIP device
Weather station Bridge. Which connects to the manufactures server.
However, the only entries that appear on the Status/UPnP page are two connections between a windows 10 laptop and Microsoft. So I’m not sure how the above devices are working. Is this normal for connections to not show on the status page?
Other devices working with port forwarding are IP cameras and Web server.
Now here are my problems.
I have two WIFI enabled Thermostats (static IP) which need access to the manufactures server for controlling from the WAN side. From my WIFI network the Thermostats can be fully controlled, however are shown offline for external control. I have initiated the (setup) reconnection process numerous times with the same results…..(cannot connect).
I also have three Wemo style WIFI home automation sockets (DHCP). As with the Thermostats they can be controlled form my WIFI network. When trying to control from the wan side the application just times out.
I have checked the firewall logs and can’t find any related connections attempts being blocked.
I have also done some packet capturing for both the WAN and LAN side and can’t seem to find any communication attempts (although not really sure what I’m look for)
All of this worked flawlessly with a router running DD-WRT.
Any suggestion would be greatly appreciated.
THANKS in advance.
firewalluser last edited by
Status, System Logs, Settings tab, do you have all for tick boxes checked in the Log Firewall Default Blocks?
I'm assuming you have all your firewall rules logging as well?
I dont use UPnP so cant comment on it, but do you see anything in the system logs?
One option is to disconnect what you dont want to be hacked, and then create a rule which allows everything through on both interfaces and see if the devices connect up then?
The default setup of pfsense is not unlike any ISP supplied router, its also worth checking for any firmware/software updates as these sometimes dont always work out of the box when dealing with new types of products on the market.
There must be a clue somewhere as to what these devices are doing.
heper last edited by
have you tried filling in the gateway & dns servers on these devices ?
KOM last edited by
For external access via WAN, you have to have firewall rules to allow it. If the devices themselves aren't punching holes via uPnP then you might have to do it manually and create your own port-forward and firewall rules.
If your Wi-Fi thermostats really require an inbound connection and a firewall rule (or UPnP) I would box them up and return them for a refund. They should connect to the server, not the other way around.
These IoT people will only understand one thing to get it right: $$$.
My gut says they don't require such rules and you're missing something else. Do they have good DNS? Default gateway?
Yes I have all logging enabled. Except RAW which I have toggled on and off for trouble shooting.
That is what makes this so frustrating. I see no communication attempts from the devices in question.
The WIFI sockets have no user changeable settings, strictly DHCP, so I would assume that the Gateway and DNS would be correct as on all other devices on the network.
The strange thing is that the WIFI sockets are now working and accessible form the WAN. This happen after I replaced the PFSense box with my old router for testing, then switched back to the PFSense box.
Thermostats are still not syncing or accessible form the WAN. I have reached-out to the manufacture for the communication specs so that a manual rule can be created.
I believe this may be a bug in miniupnpd because the other working devices using UPnP do not appear on the Status/UPnP page or any of the other logs.
I will be doing further testing for possible DNS / Gateway issues.
firewalluser last edited by
If you think its a bug in the pfsense UPNP, can you plug your old router which works with these devices into a pfsense interface, switch off DHCP on the router so the pfsense interface does it and see how it goes?
Some routers are not well written so you can easily use them as wifi access points as well if interested, the trick is to make the router have a different ip address not in the network ip address range used by the pfsense interface, then the ports on the router just act like a switch/hub as does the wifi if it doesnt support isolate, but again toggle any wifi isolate option as YMMV.
The Computer Guy last edited by
What are your thermostats?
I have 2 X Nest thermostats and a Nest protect, can control them with no issues.
I have 3 X Wemo sockets, again no issues with these
I also have Phillips Hue that can be controlled remotely.
Upnp is not enabled, you don't need to. As long as the devices can see the Internet, they'll work?
^ exactly… Those devices should be phoning home.. You make the settings there, they get them..
dreamslacker last edited by
Might be badly coded thermostats that need a static port outbound because they tell the server to explicitly connect on a 'fixed' port that is lost when the device is translated via NAT on outbound.
Have you tried using manual outbound NAT and setting static port for the thermostats?
First of all I would like to say thanks for all of the responses.
After going back to my old DD-WRT router for a few days I then put the PFSense box back online. The only thing that I changed was to disable Upnp and now everything works!
I’m not sure what happen here but As long as it doesn’t break again as mysteriously as it fixed its self everything should be fine.
The model of my thermostat is (CT50) RADIO THERMOSTAT COMPANY OF AMERICA. Also sold under the brand: Filtrete or 3M
Yeah reading about this.. It phones home and you control from their server.. Or you could access it via http to actual IP on your network.. So if you wanted to do that remotely you would need to vpn into your network or port forward 80..
But I could find no special ports need to be forwarded that is for sure to have it phone home and access it..