NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RAXE300-100NAS will not accept port triggering rules
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 Nig...
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.
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.
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.
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.
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:
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.
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.