I have just completed some testing on port forwarding using port 28000 and also my existing port 80 and 443 port forwards.
I used the
https://www.yougetsignal.com/tools/open-ports/
tool that you used and the GRC port testing tool
https://www.grc.com/x/ne.dll?bh0bkyd2
The yougetsignal tool only has two outputs - open or closed while the GRC tool has stealth, closed and open. Stealth is where there is no response to the port probe at all. Closed is where a response is given to the port probe but no service is available on it. Open is where the port gives a response and there is feedback from the service on that port.
GRC uses a TCP probe so any UDP Port Forward will not be seen by it. I am not sure about yougetsignal but I believe most of these probing services use TCP as that has handshaking associated with it and they can be certain if the probe got to its destination correctly.
All of my testing was carried out with TCP Port Forwards.
When I have my port forwards disabled then
yougetsignal gives closed
GRC gives stealth
Then I enabled the port forwards
youget signal gives open for port 80, 443 and closed for 28000
GRC gives open for port 80, 443 and closed for 28000
So GRC got a response back from my firewall to the port forward but no response from the service as I have nothing on that server that responds to port 28000.
I then changed my port 443 port forward to point to another of my computers that does not have a web server on it.
yougetsignal gave closed
GRC gave closed
The above tells me that yougetsignal can not differentiate between a port that is completely blocked or one that is available but has no service responding. GRC can differentiate between all three cases.
I also then checked the Firewall Log and found that when the port forwards were enabled all of the probes from both GRC and yougetsignal were being received by IPFire, the DNAT was carried out and then the Port Forward. So in all cases, including for port 28000 the communication was being forwarded by IPFire when the port forwards were enabled. For port 28000 no response occurred from the server as there is no service dealing with port 28000 on that machine.
You should do a port probe test, with either yougetsignal or GRC and then look in the Firewall Logs in the WUI and scan through them. Depending how many probing attempts are carried out on your RED interface from the internet you might need to search over several pages of the logs.
If the communication was received and forwarded then you will find a pair of messages as in the following from my test.
The DNAT is where the port probe came to my Public IP from yougetsignal (198.199.98.246) and then the port forward FORWARDFW occurs to the server on my system, 192.168.26.30 in this case.
If you find this double message this means that the port probe was Port Forwarded by IPFire but that the server in question did not respond to it for some reason.
If the Port Forward has a problem with it and is not working then you would find a DROP_INPUT message to the probe as the following screenshot when I disabled the Port Forward for port 28000.
