It is set to Any in Sven’s screenshot and that should be fine.
1 Like
Per the wiki
When creating NAT rules with selected TCP or UDP protocol yet another item will be displayed. It is used to specify theExternal Port which will be forwarded to a given port and host.
Seams strange to not have source port filled in.
These are different versions of the game, and therefore have different ports requirements. The Quakeworld community, who has some very smart people, have assured me, I only need what I have defined. Which is the whole reason I began pointing towards my router. If other people are doing it, with the same few ports I’ve listed, then it must be because my router differs from theirs. If you REALLY REALLY NEED me to right rules for all these ports that aren’t specific to my game, in order to further this troubleshooting process, I can do that. I just really think that these ports are not applicable. Especially considering on both client and server side I’ve done TCPDUMPs in attempts to sniff what ports are being broadcasted and communicating and etc…etc…
I don’t have any other rules written, because I don’t have any other services running or am trying to run other services. Are you suggesting I try writing a port forward rule for port 80 and seeing if the “yougetsignal.com” testing site shows port 80 as open? I can do that. Just confirm if that’s what you want me to try. Do you want me to just dump my iptables -S results? Thanks!
Source ports are typically ephemeral. I’m pretty sure that’s why. The game client is going to pick an ephemeral port and it’s not always going to be the same.
1 Like
With the Steam version.
Looks like Port Source 26000:28000
Destination port 26000:28000
should do
Hi, this is not through steam.
PC version only needs port 26000
I would do port source and destination 26000 UDP and TCP
If the server start response over another port that will be allowed by default.
Need to get communication started.
1 Like
Come on guys, don’t do step 10 before 1 and play with rules before knowing ipfire is the source of the problem
That means you should not use ipfire in the chain (for testing purpose). Connect the host/pc directly to the modem and try again. If it still fails. Ipfire isn’t the problem and you don’t need to wast any time on firewall rules etc.
2 Likes
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.
5 Likes
I’ve not seen the “enthusiasm” message before. How odd!
I’ll have to research to see if it can be adjusted…
More ports than necessary.
But looks good for Quake.
So long as Quake is running should get respone from port checker
“Yougetsignal” from above worked for me.
this message was very disruptive to our discussion as I was trying to respond to everyone in a timely manner but you could see I had to wait 20 hours before posting those screenshots to answer you guys 
I agree! It is disruptive…
This step will certainly take ipfire out of the equation for testing purposes.
2 Likes
bear with me, busy with work and infant son 
will test and update ASAP
OK, been super busy with work and newborn (first time parent). Also, it’s not an easy ask to replace my router with another product to confirm my issue.
However, as requested, I replaced the ipfire box with pfsense. My game server works with pfsense as my router. I didn’t have to modify anything on the game server itself to get any of it to work. Everything configured to get it working, was done on the router (pfsense) entirely. The two main things to get it to work in pfsense were:
- creating NAT (port forward) rules for the game ports
only 3 ports needed for Quake (TCP/UDP 28000-28501-28502) - change outbound NAT mode, and then add outbound NAT rule for Static Ports
With this information, how can we begin troubleshooting ipfire?
