RAXE300-100NAS will not accept port triggering rules

[VideoGuy]

I have two Sensi 2 thermostats that send TCP traffic on ports 8883 and 443, receives updates on UDP traffic to port 8092 and TCP traffic to port 80.  I was able to program these rules on a 6 year Nighthawk R7900P but on my new RAXE300, I enter the data in all the fields, press 'Accept' and it returns to the table with no entries.  The 'Disable Port Triggering' checkbox is unchecked.  What am I doing wrong?  Thanks for any help....  I have firmware V1.0.7.62_1

[schumaku]

---

@VideoGuy wrote:

I have two Sensi 2 thermostats that send TCP traffic on ports 8883 and 443, receives updates on UDP traffic to port 8092 and TCP traffic to port 80.  I was able to program these rules on a 6 year Nighthawk R7900P but on my new RAXE300, I enter the data in all the fields, press 'Accept' and it returns to the table with no entries.  

---

Curiosity question: Where is the idea coming from you need any port forwarding (including port trigger) configured on the NAT router? In general, nothing is establishing a connection from the Internet -to- the IoT device like your thermostats. The IoT devices are establishing outgoing connections to the respective cloud service, from there your thermostats will be reachable. Without any port forwarding, and even less with port triggering.

Yes, it's well possible these IoT require -outgoing- connections from your LAN to the Internet, and it's cloud service by TCP on port 8883, 443, and 80. The UDP connection does typically serve as some kind of connection protocol, almost like a VPN.. This is what some unknown guidelines are commonly asking for - sometimes with some questionable wording.

[VideoGuy]

This is the quote from the Sensi 2 app note:

Sensi smart thermostat and Sensi Touch send TCP traffic on ports 80, 8091 and UDP traffic on port 8092. Sensi Touch 2 and Sensi Lite send TCP traffic on ports 8883 and 443. To receive over-the-air firmware updates, please make sure UDP traffic to port 8092 (34.233.82.197) and TCP traffic to port 80 (52.55.206.183) is open. For Sensi Touch 2, also make sure that TCP traffic to port 8883 (54.210.127.220) is open. This traffic needs to be able to navigate any network firewalls, proxies, or filter devices.

https://sensi.copeland.com/en-us/support/router-compatibility/advanced-troubleshooting-information 

I can receive information FROM (i.e. request the current temperature) the thermostats (via the Sensi app or Alexa skill), but I cannot SEND commands (i.e. set a temperature) from either method. I assume that the OEM will push out firmware updates to it also.

I was able to set these rules up on my prior Netgear router and it was working (it wasn't before I set them up).  The RAXE300 is not having it for some reason.  I'm not knowledgeable enough to know why.  Its got to be something really stupid.

[schumaku]

---

@VideoGuy wrote:

This is the quote from the Sensi 2 app note:

Sensi smart thermostat and Sensi Touch send TCP traffic on ports 80, 8091 and UDP traffic on port 8092. Sensi Touch 2 and Sensi Lite send TCP traffic on ports 8883 and 443. To receive over-the-air firmware updates, please make sure UDP traffic to port 8092 (34.233.82.197) and TCP traffic to port 80 (52.55.206.183) is open. For Sensi Touch 2, also make sure that TCP traffic to port 8883 (54.210.127.220) is open. This traffic needs to be able to navigate any network firewalls, proxies, or filter devices.

https://sensi.copeland.com/en-us/support/router-compatibility/advanced-troubleshooting-information 

---

This is the standard nomenclature describing all the outgoing connections from the LAN are open to reach the Internet and the Sensi cloud infrastructure, no Proxy infrastructure or similar (as usual on business networks) That's why I wrote there is no word of port forwarding or port trigger.

@VideoGuy wrote:

I can receive information FROM (i.e. request the current temperature) the thermostats (via the Sensi app or Alexa skill), but I cannot SEND commands (i.e. set a temperature) from either method. I assume that the OEM will push out firmware updates to it also.

I was able to set these rules up on my prior Netgear router and it was working (it wasn't before I set them up).  The RAXE300 is not having it for some reason.  I'm not knowledgeable enough to know why.  Its got to be something really stupid.

---

These commands are triggered from the IoT App and sent to the cloud infrastructure. Some reverse proxy connections (kind of a VPN) are keeping up the communication between the cloud infrastructure and the IoT devices.

All I can confirm is that there is no port forwarding or port trigger required. Typically, having these configured might imply a certain risk, but should not break the communication in either direction.

Something stupid might go on, but I doubt this is in your well-intended config. For the moment, I would suggest (keep in mind I'm neither Netgear nor Sensi) to remove the port forwards and trigger config, then cold reboot the router, and finally the IoT devices.

[VideoGuy]

so, to summarize  (?)

• you carefully fill out the fields per RAXE300 User Manual  (p169)
• click Apply
• then the screen re-paints and *poof* your work has vanished

Yes, that is correct.

are you by chance accessing the admin console via https? (port 443). that could be statefully confusing.

or maybe it's just the browser and/or its settings causing it.

I access the admin console via the Firefox browser.  I also tried Chrome with the same results.  The Nighthawk app doesn't provide access to this level of configuration - at least I didn't see it.  I tried a new test last night.  I CAN program port forwarding rules and they get into the table.  The port triggers are not being stored (!!)

[VideoGuy]

Something stupid might go on, but I doubt this is in your well-intended config. For the moment, I would suggest (keep in mind I'm neither Netgear nor Sensi) to remove the port forwards and trigger config, then cold reboot the router, and finally the IoT devices.

Well right now, there are no port command rules that have been saved.  I have rebooted the router.  I am loathe to reboot (or factory reset) the thermostats because then I lose all of my time/day programming and I can no longer push new programming to them from the Sensi app.  These thermostats are going to be the death of me.

I am surprised that you state that no port rules are necessary based on the app note description.  They are the only IoT devices in my house that don't "just work".  I even took the radical step of buying a new high-end router to try to solve this ridiculous problem.

[schumaku]

---

@VideoGuy wrote:

Something stupid might go on, but I doubt this is in your well-intended config. For the moment, I would suggest (keep in mind I'm neither Netgear nor Sensi) to remove the port forwards and trigger config, then cold reboot the router, and finally the IoT devices.

Well right now, there are no port command rules that have been saved.  I have rebooted the router.  I am loathe to reboot (or factory reset) the thermostats because then I lose all of my time/day programming and I can no longer push new programming to them from the Sensi app.  These thermostats are going to be the death of me.

---

This reads like an -awful- way of a cloud based IoT implementation. 

---

@VideoGuy wrote:

I am surprised that you state that no port rules are necessary based on the app note description.  They are the only IoT devices in my house that don't "just work".  I even took the radical step of buying a new high-end router to try to solve this ridiculous problem.

---

Carefully re-read the App note. No word of a required port forwarding!

Don't let some first level support mislead on potentially "required" but undocumented port forwarding. A consumer router like your RAXE300 does unlikely have block anything outgoing, certainly not out of the box. All assuming no ISP or government enforced blockings of certain FQDNs. However, as your IOT does establish the connection to it's cloud infrastructure ....

There could be something on the router blocking (or unexpectedly stopping) that UDP traffic where the reverse proxy style traffic is flowing forth and back, allowing bi-directional communication Cloud<->IoT. Something to talk with the IoT device vendor requiring some troubleshooting. 

The RAXE300 is your new router? Which router showed that similar issue before?

[VideoGuy]

The RAXE300 is your new router? Which router showed that similar issue before?

I had a Netgear Nighthawk R7900P (?).  I had similar problems with it.  Then, I located that Sensi app note and programmed those rules and if memory serves, everything worked right after.  Fast-forward 3 months and my internet service went down for a day.  When it came back on and I rebooted my modem and Netgear router (to solve other IoT device issues), the thermostat nightmare began again.

At the risk of going down the wrong path, why am I able to program port forwarding rules and not port trigger rules?

[schumaku]

---

@VideoGuy wrote:

The RAXE300 is your new router? Which router showed that similar issue before?

I had a Netgear Nighthawk R7900P (?).  I had similar problems with it.  Then, I located that Sensi app note and programmed those rules and if memory serves, everything worked right after.  Fast-forward 3 months and my internet service went down for a day.  When it came back on and I rebooted my modem and Netgear router (to solve other IoT device issues), the thermostat nightmare began again.

At the risk of going down the wrong path, why am I able to program port forwarding rules and not port trigger rules?

---

Can only guess. Potential reason is one of the ports is already occupied, typically the ubiquitous 80 or 443, for example by some UPnP-SSDP-enabled systems on the LAN (UPnP. NAT-PMP IGD Port Mapping Protocol), reserving a some port forwarding for it's own purpose, pointing to another LAN IP address, making it impossible to configure another port forwarding on top pf it.

Very vague, port trigger is always triggered by establishing a connection to a port forwarded service. Port triggering is done by defining a port which does trigger the open (NAT port forward) additional ports and/or protocols, for example you establish a connection to a server eg. on 80 (http) or 443 (https), from the Internet, to the public IP address (where a DNS entry is pointing to) which does trigger additional port forwardings. 

When looking over that famous IoT help, I see different IoT models with probably gain overlapping services. But this almost certainly isn't the case. Simply because no port forwarding is -ever- used or required for generic IoT devices.

Said this: The IoT service provider does certainly have diagnostic peek-and-poke options way beyond of what we can do here in the community. And fighting red herrings does barley lead to any results.

[VideoGuy]

Can only guess. Potential reason is one of the ports is already occupied, typically the ubiquitous 80 or 443, for example by some UPnP-SSDP-enabled systems on the LAN (UPnP. NAT-PMP IGD Port Mapping Protocol), reserving a some port forwarding for it's own purpose, pointing to another LAN IP address, making it impossible to configure another port forwarding on top pf it.

Wouldn't there be some kind of status message saying "you can't do that" instead of nothing?  It certainly won't let me set a port forward command to two different IP addresses (i.e. thermostats).  I get a message for that.

[schumaku]

---

@VideoGuy wrote:

Can only guess. Potential reason is one of the ports is already occupied, typically the ubiquitous 80 or 443, for example by some UPnP-SSDP-enabled systems on the LAN (UPnP. NAT-PMP IGD Port Mapping Protocol), reserving a some port forwarding for it's own purpose, pointing to another LAN IP address, making it impossible to configure another port forwarding on top pf it.

Wouldn't there be some kind of status message saying "you can't do that" instead of nothing?  It certainly won't let me set a port forward command to two different IP addresses (i.e. thermostats).  I get a message for that.

---

The point might be you can port forward a single public IP address and port to a single LAN IP only. 

Isn't the point more that the system -does- apply the config the user does suggest, and most likely does accept and allow, but it' does not lead to the result you expect? 

Without exact details, current UPnP-PMP status, and the attempted exact port forwardings and port triggering definitions you try to apply on your NAT router, ... red herring again?

Are we still talking on one or two of these Sensi IoT device models - where -none- does require any explicit (by router NAT config) nor automatic (UPnP-PMP) ?

And yes, many things could be implemented more customer friendly, no doubts about that. And I'm happy that (sometimes) Netgear does listen to my advise and feedback every now and then it comes to the business products.

[VideoGuy]

The point might be you can port forward a single public IP address and port to a single LAN IP only. 

Yes, I understand that point.  It was merely to confirm that the firmware can and does object to errors.  In the case of port triggering, Netgear is more like "I ain't doing that and I ain't telling you why".

Without exact details, current UPnP-PMP status, and the attempted exact port forwardings and port triggering definitions you try to apply on your NAT router, ... red herring again?

I already explained in detail about the port triggering that I was attempting.  I am aware that port forwarding is to a single IP.  There is no user-initiated port forwarding or port triggering in the current table.  I will get the UPnp-PMP status tonight and reply.  I have gone through all of the admin menus and do not recall seeing anything, but I will confirm.

[schumaku]

It's consumer class C and sometimes C++ code.

A simple table of what port forwardings you try to achieve would help the reader here lacking of any over natural powers.

However, this is what Sensi does document:

Sensi Network Security Guide

[VideoGuy]

would help the reader here lacking of any over natural powers.

I already explained in detail about the port triggering that I was attempting (see the original post).  Your comments are condescending and I’m not really sure why you feel the need to go there except to assert some kind of implied knowledge superiority.  By the way, this is far off-topic, but I am far from the only one suffering with these ridiculous thermostats and am grasping at straws to find an answer.  If that isn't reason enough to act civil, then please don't answer anymore.  

[VideoGuy]

I was unable to post under the original thread for "RAXE300-100NAS will not accept port triggering rules", but I have stumbled across my solution by accident.  The "Service Name" that you select for a port triggering rule cannot contain a BLANK character.  For instance, you cannot select "UDP 8092", it has to be "UDP8092".  If you include a blank character, it just ignores your request and returns to the rule table without any error messages.  With that simple fix, my frustrating Sensi 2 Thermostats are now working 100% with the cloud I/O.