Smart Hub 7 Plus Port Forwarding Issue

[jsviper77]

Hi All,

Another Issue with the Hub 7 Plus, probably on others too.

When i create a Port forwarding rule, it always comes up with an error and doesn't save or eventually when it does save, it has created duplicate rules. Try to remove one and it removes both, aaarrrgghh! These EE hub are very frustrating.

I hope someone who can help sees this and my other post, to help fix these issues.

[SamyM]

Hi, I've tried it with port 20 and still same issue.  But I have not tried forward port 100:100 (external) to port 21:21 (internal). I'm planning to plug my EE Hub 7 Plus next week and have another play. Its funny... some of the ports were created between the WD cloud and the EE Hub 7 Plus and those are open.  Yet the ones I create manully don't.  Confusing!   With DMZ enabled port 21 works. 

Why is that? 

Makes me think there is some logic issues in the firmware. 

Samy

[Pecbeck]

If upnp works, you could try manually creating port  rule

On Ubuntu or Debian-based systems, install the miniupnpc package, which provides the upnpc command-line tool.

:

[SamyM]

Hi, Tried setting up  port forwarding rule  100:100 (external) & port 21:21 (internal).  port 100 was closed with the port checker as well as 21.

Any ideas why this is happening?

Samy

[Pecbeck]

1. Did you try my manual upnp suggestion?  What was the result?

2. Enable ftp on you windows pc, check it's open on your lan, then setup the port 21 rule to point at windows pc. What is the result? 

[SamyM]

Hi, I don't use Ubuntu or Debian-based.  I have played around with Kubuntu a little.

Samy

[Pecbeck]

You could try Google like I did.  Runs on windows. This is becoming quite hard work

What about my other suggestion re enabling ftp,on windows?

Here are some common miniupnpc (upnpc) command‑line examples for UPnP port‑forwarding on Linux or Windows (from cmd or PowerShell):
Basic syntax
Add a mapping:
upnpc -a <INTERNAL_IP> <INTERNAL_PORT> <EXTERNAL_PORT> <TCP|UDP> [DURATION_SEC]
Delete a mapping:
upnpc -d <EXTERNAL_PORT> <TCP|UDP>
List all current mappings:
upnpc -l
Concrete examples
1. Forward external port 32400 → Plex (TCP)
upnpc -a 192.168.1.10 32400 32400 TCP
This tells the router: any TCP packet on public‑facing port 32400 should be forwarded to 192.168.1.10:32400. ��
2. Forward external 8080 → internal 8080 (TCP)
upnpc -a 192.168.1.20 8080 8080 TCP
Useful for a web server or app that listens on port 8080. ��
3. Forward external 2222 → internal 22 (SSH, TCP)
upnpc -a 192.168.1.10 22 2222 TCP
Allows incoming SSH on external port 2222 → internal SSH server on 22. ��
4. UDP mapping (e.g., game server)
upnpc -a 192.168.1.15 27015 27015 UDP
Game traffic on public port 27015 goes to 192.168.1.15:27015 over UDP. ��
5. Delete a mapping
upnpc -d 32400 TCP
upnpc -d 27015 UDP
Removes the corresponding external‑port rules. ��
6. List all mappings
upnpc -l
Shows WAN IP, current port mappings, protocol, and description. ��
If you tell what machine IP and service you want to expose (e.g., “Plex on 192.168.1.100, port 32400”), I can give you the exact one‑line command for your case.

[bobpullen]

@Pecbeck - I think it will be an uphill struggle trying to hack around things with a UPnP client, not least because there's likely to be security limitations in place that prevent e.g. 'Machine A' from creating a UPnP rule for 'Machine B'. It's given me an idea though...

[Pecbeck]

It was a troubleshooting suggestion given the upnp rules mentioned do work. 

I have no other suggestions on this. The rules work for me and you, so I suggested a process of elimination which is how we found issues during my 50 years in it and development

[bobpullen]

---

@bobpullen wrote:

 It's given me an idea though...

---

So, looking back at @SamyM's broken examples, I've tried to closer replicate the problem. After factory resetting my 7 Plus...

Used a UPnP client to mimic the creation of the TCP rule the NAS is creating: -

MiniUPnP> .\upnpc-static -u http://192.168.1.254:5000/rootDesc.xml -a 192.168.1.100 49592 49592 TCP
upnpc : miniupnpc library test client, version 2.2.3.
 (c) 2005-2022 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
Found valid IGD : http://192.168.1.254:5000/ctl/IPConn
Local LAN ip address : 192.168.1.100
ExternalIPAddress = [REDACTED]
InternalIP:Port = 192.168.1.100:49592
external [REDACTED]:49592 TCP is redirected to internal 192.168.1.100:49592 (duration=604800)

 I then created an FTP rule via the Hub Manager and spun up the same FTP server I used previously (where I was previously unable to replicate the problem): -

And lo and behold when checking the FTP port, it's closed! Exactly the same as what @SamyM  is seeing: -

And for the somewhat interesting bit. If I factory reset my hub and try  again, but with the rules created the other way round: -

I check the FTP port and it's open again!

Looking like a bug that's potentially related to the order of UPnP versus manual rules in the port forwarding list.

Assuming so, couple of potential workarounds: -

• Factory reset the 7 Plus and create all manual rules 'offline' i.e. before connecting the NAS/any LAN devices. This should hopefully make the FTP rule the first in the list - meaning it works, or...
• Disable UPnP on the NAS, factory reset the 7 Plus and recreate manual rules. Not sure how easy this is to do on the NAS, and it might mean you need to manually create the rule for whatever UPnP is currently opening access to.

I would have suggested simply deleting the UPnP rules but I can't see any way to do that once they've been created.