From my understanding I’d guess that the client first tried the first specified endpoint (which is the ipv6 adress).
I have the following ideas for better behaviour:
Check ipv6 (and v4 respectively) support beforehand and select appropriate endpoints on it. (Probably best to use something similar to usual https: Use ipv6 if availables, else use ipv4)
If first endpoint fails, try the next without an error message
Or is there an error in my configuration?
PS: I am using a firewall similar to this: GitHub - Ekinoxx0/reqip
Because of the webserver being behind cloudflare I have to offer v6 support since cloudflare will use ipv6 where possible.
Meaning that if I would only allow v4 the following would happen for players with v6 support:
Connects to init-phase using cloudflare (cloudflare uses v6 adress of client. This adress will be set on player.Endpoint for playerConnecting)
The code in playerConnecting whitelists the endpoing (V6)
The actual (fivem) client uses first given endpoint (v4). Thus the firewall will not allow any connection.
Endpoints are used in random order (round-robin style), but either way there’s indeed no retrying logic at this time. I believe the original intent for the endpoints stuff is that the server (or a proxy there) would automatically provide only available endpoints, the sv_endpoints stuff was a pull request I believe for simple cases. In your case, however, as server-side policy requires the same endpoint be used as used for HTTP, this is much rather a case for your proxy to handle the getEndpoints call directly rather than using a static list via sv_endpoints.
Either way, any such change would rather be a feature request than a bug report. ‘Detecting IPv6 capability’ would however again be silly and failure-prone, as there may be such connectivity but despite that there’d still only be one routable endpoint.
I have moved the post now so it’s not confused with a bug report.
I have a bit of problems with understanding Proxy Setup - Cfx.re Docs to be honest
I don’t understand what getEndpoints is. (Is it a get-/post request?)
Detecting IPv6 capability’ would however again be silly and failure-prone, as there may be such connectivity
I think that current handling would hold ipv6 availability back a lot.
Since (to my understanding) if you now specify an ipv4 and ipv6 you have to make (to me or server owners) complex handling on what endpoint(s) to give to the client. Since if a user does not have ipv6 capability they will randomly get the v6 adress and a subsequent error.
Wouldn’t it be nicer to be able to specify ipv4 and v6 endpoints and the client using the one it has the capability to use?
Also retrying logic would probably “hide” the problem in a usable way so might be a viable alternative.
For somewhat unknown reasons, it’s a POST call on /client. This sadly does indeed mean that any proxy to route this would first have to read the request body, then forward any response back in its entirety.
As to the bit below, note that if a client can’t connect using IPv6, using the IPv6 endpoint will likely instantly error out as unrouteable. Treating the endpoints as an ordered list to try may be more desirable, indeed, but that still wouldn’t work well for your issue at all where the different endpoints are actually not equivalent as the user is only accepted in a firewall for some of them, i.e. the endpoints call should only return the endpoints the user is actually able to use.
Treating the endpoints as an ordered list to try may be more desirable, indeed, but that still wouldn’t work well
I agree.
If my assumption is correct, that this (round-robin) was intended for clusters, it would essentially disable this functionality for a different one and potentially break current setups.
the endpoints call should only return the endpoints the user is actually able to use.
What do you think of the idea to be able to edit the endpoints using the deferral object during playerConnecting?
If the function is not called, the current default (round robin) will be used.
If an update is called, round-robin will be used on the new value(s).
The reason for my need is that I have cloudflare in between the client and server.
Cloudflare automatically uses ipv6 where possible (as expected).
This can only be disabled on the premium package.
But this would also mean that anyone using such a protection would probably expect the same issue.
So I don’t think this will go away in the near future.
If I understand you correctly, the client only gets a random entry selected by round-robin from the server.
So the client can’t chose which ip to select?
If so would it be a viable option to send one endpoint for ipv4 and one for ipv6 to the client.
The client then chooses on availability (with v6 preferred).
Wrong. The entire list gets sent, which is yet another reason why multiple entries aren’t technically supported, it however was easier to implement multiple entries in the client anyway in case someone would have a use case for it in their proxy setup, but then someone added this sv_endpoints thing as a PR that was easier to accept than ask for them to just not. A PR like this wouldn’t get accepted these days either as it’s lacking almost any semblance of info as to why, the commit sequence was a mess, and so on, but I guess at the time there was some pressure to rush through PRs that had no obvious objections as someone went ‘you never merge these so why should I post any?’.
Generally it’s still recommended (for obvious reasons) to send only one endpoint so a user won’t have a complete list of all endpoints at all times to simultaneously flood.
… how many times do I have to tell you that there’s no way to conclusively tell if IPv6 works (or IPv4, for that matter)?
It’s much easier if you just handle getEndpoints in your proxy the way the original design intended endpoints to be handled instead of requesting weird heuristics or other stuff that would be prone to more problems for other users in the future. There’s a lot of odd setups out there and this is also extremely difficult to test or help people with if having issues.
… how many times do I have to tell you that there’s no way to conclusively tell if IPv6 works?
Sorry I forgot that
Generally it’s still recommended (for obvious reasons) to send only one endpoint so a user won’t have a complete list of all endpoints at all times to simultaneously flood.
I understand that but I think sending at least one ipv4 and one ipv6 would be a better way. How you handle both informations is another question. Especially since we’re in the transitioning phase from v4 to v6.
Since it can’t tell if ipv6 is supported maybe try ipv6 first and ipv4 if it didn’t work?
Or in fivem’s case maybe try them randomly until one works?
using the IPv6 endpoint will likely instantly error out as unrouteable
Would this mean that you can check working ip’s easier in this case?
I.e.: try first ip. If it is unrouteable try the next one?
If so, one could implement this with the original round-robin (instead of an ordered list) to not break / alter current behaviour too much and allow “backwards” compatibility (i.e. scripts relying on round-robin behaviour not breaking).
Also thanks a lot for the fast and informative responses
