[Linux] fxserver not accepting connections


Probably an issue similar to this one: FiveM FX Server won't respond to queries

  • port open, packets accepted by the firewall (iptables count)
  • tested the same port working with dummy servers (netcat)
  • tcpdump showing connection packets, but no response from fxserver
  • nmap show “filtered”, the server is listening but not really responding
  • sometimes the server send heartbeats, UDP packets are sent/received to/from the master server
  • the server receive packets (TCP) from the master server but don’t answer
  • fresh install, last fxserver, last resources, basic server.cfg
  • doesn’t seem to be related to the OS/distribution used, but to the machine and the network config

Problem with TCP accept ?


IPv6 enabled?


Probably, but should it be an issue ? Didn’t find any server (service) who can reproduce the same problem.


I couldn’t connect to my server until I enabled ipv6 (FiveM uses enet which requires it).
Might not be the issue but just wanted to share.


nmap showing filtered indicates to me that the packets are being dropped somewhere, either from the perimeter firewall/router or the host firewall.


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).


What does iptables -L look like?


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.


This is not the point. Anyway if people have the same issue, now they know that they should probably not use ufw.


Also having this issue, regardless of IPV6 enabled/disabled.