Is there any chance that you’re running a virtual machine in this instance? , If so play with the ports forwarding Within the virtual machine settings just advance than buy one and then try to connect.
@mraes What do you mean exactly by enabling ipv6 ? I tested netcat listening in ipv6 (with -6).
@SaltyGrandpa As I said, iptables count the packets as accepted.
@ArmAGawD No VM (dedicated server from OVH). But it’s probable that the issue is coming from a configuration on/around the machine.
More info:
netstat -s | grep -i drop
6626 outgoing packets dropped
132 dropped because of missing route
2256 SYNs to LISTEN sockets dropped
TCPReqQFullDrop: 2244
The SYN line may be a symptom.
Also if I have confirmation that the heartbeats happen only when a player try to join (with an empty server), that would mean that TCP is accepting connections (so it could be an UDP, fxserver, outgoing issue).
I hope this doesn’t sound like lack of research but, i’ve not fully understood how #sv_authMaxVariance 1 #sv_authMinTrust 5
worked within server.cfg I do get the principle and have some hunch it might hold potential, In my current server.cfg there #decommented. https://gyazo.com/de6ccbe9b27f48ec69c65caff1729263
I think we can ignore the firewall (except if there are local rules), nmap from localhost show open on a working machine, and filtered on an non working one. The packets (in or out) are probably lost somehow because of a local issue (but only related to fxserver).
nmap on the local machine will pretty much always show open. It’s the same reason, for example, that you can access a MySQL database server running locally even if the host firewall doesn’t have the port opened.
What Linux distro are you using? Most of these issues truly are host firewall issues. Could you disable iptables briefly and try connecting? Not a major security risk for brief testing. If you’re unwilling to do that, try a different firewall option like ufw or firewalld.
@SaltyGrandpa That’s the point, nmap showing filtered from localhost is the issue, not the firewall.
Also I tested a dummy server from the alpine root (using proot) without problems, so I don’t really understand what fxserver is using for network interactions to not work.
Okay, after lot of testing we isolated the issue, it’s not really coming from the firewall itself (not iptables), but from the usage of ufw.
We reproduced it like this:
fxserver port open
install ufw
enable ufw
fxserver port is always filtered
disable ufw
uninstall ufw
clear iptables rules
fxserver port is still filtered
reboot the machine without ufw and the problem is gone
So I have no idea what ufw is doing, if it’s a OVH image config issue, ufw or iptables issue or the combination of them (and fxserver, because it’s the only server impacted).
You should only use one firewall solution, either ufw or iptables. I believe ufw may control iptables, but you should only manipulate the firewall through one.
I’d suggest wiping all rules in both iptables and ufw, and using only ufw.