It could be that the master server endpoint doesn't work under some conditions. After some debugging on my own systems suffering the same problem, I found that the master server list endpoint may not be behaving correctly. Below is a technical description, so basically tl;dr: it telling you that the server was added to the list is potentially a bug, especially if it gave you errors alongside it like "Server can't be reached". Also check and see what happens if someone tries to connect to your IP directly from whatismyip.com. (You can hit the Insert key when looking at the server list to manually add a server IP).
It looks like the master endpoint tries to send multiple responses at once, even if they conflict or are just repeats. On my own network I have it telling me all in one response that my server can't be reached, the heartbeat was confirmed and the server was added to the list so I'm left wondering how the heartbeat can be confirmed if my server can't be reached, especially considering that the end result is the server not being listed:
HTTP/1.1 200 OK\r\nDate: Sun, 11 Sep 2016 20:08:55 GMT\r\nServer: Apache\r\nVary: Accept-Encoding\r\nAddress: 220.127.116.11\r\nCache-Control: max-age=300\r\nExpires: Sun, 11 Sep 2016 20:13:55 GMT\r\nKeep-Alive: timeout=2, max=100\r\nConnection: Keep-Alive\r\nTransfer-Encoding: chunked\r\nContent-Type: text/html\r\n\r\n1\r\n2\r\n0\r\n\r\n
That is what happens when I have my Tribes 2 server behind a routing box that is masquerading the incoming connections. This also causes the MITM check to fail when people try to join (via direct IP since the server isn't listed) and crash clients because of the way masquerading works and the fact that Tribes 2 has a crash bug related to dialogs being displayed too quickly. So even if the server showed up correctly under this situation, nobody can join.
(In the \r\n\r\n1\r\n2\r\n0\r\n\r\n you see 1,2,0 appearing in that order for the endpoint response codes)
When I rework my network to not use the masquerading and purposely make the server not reachable, I get just the server can't be reached and the server was added to the list responses, and the "Server can't be reached" response is duplicated twice.
HTTP/1.1 200 OK\r\nDate: Sun, 11 Sep 2016 20:27:06 GMT\r\nServer: Apache\r\nAddress: 18.104.22.168\r\nCache-Control: max-age=300\r\nExpires: Sun, 11 Sep 2016 20:32:06 GMT\r\nVary: Accept-Encoding\r\nTransfer-Encoding: chunked\r\nContent-Type: text/html\r\n\r\n1\r\n1\r\n0\r\n\r\n
(In the \r\n\r\n1\r\n1\r\n0\r\n\r\n you see 1,1,0 appearing in that order for the endpoint response codes)
When I setup the non-masquerading network correctly, I get the same exact endpoint response as I did under the masquerading configuration but the server is actually listed correctly.
To test the masquerading setup to be absolutely sure that the server is actually reachable, I've also setup a simple local UDP server on the machines that normally would be running the game and they are indeed receiving UDP data from the TribesNext master server probing for a live game server. Just instead of it receiving from the TribesNext server prober, it receives from my masquerading router box. The inconsistent reporting behavior is at the least pretty confusing and makes it quite a ways harder to debug and both the MITM checks & server list not working correctly on networks that might be "masqueraded" is causing headaches for people that end up in these situations.
However, given the original poster's setup above the only relation this may have to the issue at hand is that the router isn't actually forwarding but masquerading (hence why I asked to see what happens if he has someone connect directly).