XBlast uses a number of fixed ports and also ephemeral ports for both TCP and UDP. Here is a detailed list of all xblast network ports:
XBlast Game Server:
XBlast Game Client
The majority of XBlast networking problems are based on an inadequate firewall/router configuration. In most cases it should be sufficient to unblock a few ports on the XBlast server. But the client as well can be affected by a "dumb" firewall/router, which does not recognize replies to ephemeral UDP ports.
Assuming that the all firewall/routers are smart enough to detect ephemeral UDP replies, the server needs to open the server game port (default 16168/tcp) and the game data ports (default */udp). Optionally the LAN port (16168/udp) may be opened to allow client LAN searches. To restrict the udp range, the option Fixed Udp Ports may be set to force the data ports into the range 16169-16184/udp. An alternative is to open the ephemeral UDP port range. The client should have no problems in this scenario.
Assuming a dumb firewall/router server-side, there is no real problem. The only small bad effect is that connection information sent to central will have their UDP replies from central blocked. The only consequence of that is that the server can not close the game entry on central appropriately. Since central autocleans its entry list anyway, the game will not clutter up the central game list either way.
Assuming a dumb firewall/router client-side, the problem is much more serious as ping replies from server probably don't get through, causing either the client or server to timeout, as the data connection cannot be established. The only solution available so far is to open the ephemeral udp port range on the client.
The ephemeral TCP ports usually pose no problem, since the connection is always established in both directions by connecting to a fixed port; even when the client connects from an ephemereal port, a firewall/router usually makes an exception for the return transmission from the server, even if that port is normally blocked.
The ephemeral UDP ports are more problematic since UDP is connectionless so that each UDP transmission requires a peer port that is not blocked by a firewall. Both xblast server and client may use an ephemeral UDP port, depending on the configuration. Some more intelligent firewalls/routers recognize return transmissions and allow them, similar to TCP. But not all are that intelligent...
To determine and change the system-wide ephemeral port range, have a look at the following ncftp doc.
Since version 2.10.0, the defines USER_MINPORT and USER_MAXPORT let the user choose an XBlast-specific ephemeral port range at compile time; the fixed ports are not affected by this range. If USER_MINPORT is strictly smaller than USER_MAXPORT any ephemeral port (both tcp and udp) will be bound to a port in the defined range. Otherwise, the ephemeral port is chosen by the system, as usual.
If a client is behind NAT, the client router must be able to detect UDP replies, otherwise the client will never get any pings or game data from server. Obviously, the server has to allow NAT clients by setting the Allow NAT option.
To property of being behind NAT can be compiled into the binary using the define DEBUG_NAT. This can also be done (mostly) without harm for clients that are not really behind NAT; the only drawback for such clients that they depend on servers that allow NAT, which is not really necessary.
Alternatively, one may rely on the internal NAT detection code which compares the local interface ip with the ip the server sees to determine the NAT status. For older versions (<2.10) this routine is flawed, so it is recommended to use the DEBUG_NAT define unless you know for sure that the client is not and never will be behind NAT; the flawed routine might detect NAT anyway, so servers might have to allow NAT when having such clients.
If a server sees clients with no pings in the wait menu, this means that the UDP connection to that client has not yet been established. This very likely means that UDP access to the game data ports is blocked, either at the server or the client. The server needs to check its firewall/router settings and probably should ask the clients with missing ping times to do the same (chat is tcp-based and should work if the client is visible).
If a client sees no pings at all, the client game data ports are almost certainly blocked and need to be opened. If a client only misses some ping times, its own connection is okay, only the clients with missing ping times have trouble connecting.
Assuming that there are in fact games in central (which might be checked via the html-game list, if accessible), this potentially indicates a dump firewall/router, which blocks the UDP replies from central. The ephemeral udp port range has to be opened in this case.
Another possibility applies for windows systems with xblast versions <2.10.0: since there has been a bug in a winsock update, the available network interfaces might not be detected completely with the regular detection routine. A workaround is to compile xblast with -DWSIF_MOD which implements a modified detection routine which takes the bug into account. On some win2k systems searching central only works without -DWSIF_MOD, while on winxp it seems to work with -DWSIF_MOD only. Unfortunately I have not yet figured out, which win version needs which variant and under which conditions, so for now just try both versions. For versions 2.10.0 and up this particular problem has been fixed, so the best solution is probably to update, if possible.