Stream - Port Forwarding does not work

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

If I have a stream host, listen port 21 (on 0.0.0.0) destination port 21, works, but if I have listen port 2021 or other port on 0.0.0.0 destination port 21 (the IP is a 192.168.0.x range), the proxy manager does not open the port. When I try with telnet, says refused. Is not the firewall because in the docker host, a VPS debian 11, i can't run ncat -l -4 -k -p 2021 because the port is being used by other aplication (docker-proxy), when I stop the docker that run nginx proxy manager and the port 2021 is released, i can connect from my laptop to the vps using ncat -l -k -4 -p 2021 without problems.

Nginx Proxy Manager Version

2.9.16 to 2.9.18 latest

To Reproduce
Steps to reproduce the behavior:

1. Go to stream
2. Click on add stream
3. Listen port 2021
4. Forward host any LAN IP (qemu) port 21 TCP and UDP
5. telnet "WAN IP docker" 2021 connection refused

Expected behavior

Can connect.

Screenshots

Operating System

Debian 11 amd64

Additional context

The connection between both VPS, the docker VPS and the other is fine, tested using ncat and ftp, so is not a network problem and, from my pc to the docker VPS the connection is fine. Only works when the port are the same Listen and Forward Port.

UPDATE:

Ok my bad, is not clear for my the documentation, the only port that docker-compose expone is the port Listen, the internal port, is managed by docker-proxy and is not like other dockers that need specify the internal port to open. So, close the bug.

Start with the Stream configuration and docker-compose port exposure described in the report, then review how docker-proxy handles the listen and destination ports. No source file or test is named. The report's update says the behavior was a documentation misunderstanding, so done would require confirming the documented port-forwarding behavior before making any change.