Incompatiability with ViaVersion about realip HOT 15 CLOSED

Infrared doesn't remove the signature. The feature @gcurtiss is talking about upgrades the handshake packet to mimic what TCPShield would send. This enables the preservation of IP addresses like HAProxy protocol does without needing BungeeCord or other HAProxy solutions.

Here is the function that upgrades the handshake.

from realip.

Hi,

Thanks for your report. We have tried with the steps indicated but have been unable to reproduce. Did you have ProtocolLib installed in your case? If so, could you also let me know the Java version used?

Thanks

from realip.

Yes. ProtocolLib was installed, and Java is on Java 11.

Also note I am using TCPShield 2.4. 2.5 doesn't work with the reverse proxy I'm using yet. If you can reproduce this bug on 2.4 but not 2.5 I will close this issue.

from realip.

Oops, accidentally closed the issue. Reopened :)

from realip.

Can you elaborate more on the incompatibility issues you described with your reverse proxy (on 2.5)?

from realip.

I'm using Infrared reverse proxy. 2.5 broke Infrared since Infrared sends the payload that was correct in 2.4 but is no longer accepted in 2.5 because of the new payload validation; I'm waiting for it to update.

from realip.

I'm using Infrared reverse proxy. 2.5 broke Infrared since Infrared sends the payload that was correct in 2.4 but is no longer accepted in 2.5 because of the new payload validation; I'm waiting for it to update.

Hi, I am another contributor to this. I am not sure what you mean by this, the payload data was the same throughout 2.4 and 2.5, it's just 2.4 ignored some of the validation sections in the payload. Are you able to send debug information showing what payload data is received, or if it's another error entirely. If we get 2.5 working for you, then your original issue should be fixed. Thanks

from realip.

haveachin/infrared#71

This is the issue as marked by Infrared. It points out specific lines of code & errors that I helped to debug (I worked with the original poster in diagnosing the error).

from realip.

haveachin/infrared#71

This is the issue as marked by Infrared. It points out specific lines of code & errors that I helped to debug (I worked with the original poster in diagnosing the error).

Thanks for the insight, I'm still a little confused on how Infrared causes the signature to be removed completely, and preserve every other section (at least it isn't outlined in the issue). As I see, this issue would have occurred on versions 2.3 and lower as well; this isn't a "new" bug from this specific version. I'll be happy to work on this issue once I get more information on the Infrared side of things.

from realip.

Infrared sent the payload without the signature, which worked in 2.4. It seems that in 2.5 it's looking for 4 payload arguments (the original 3 + the signature) and when Infrared only sends the original 3 arguments (without the signature) RealIP ignores the request since there is no validation signature.

from realip.

Infrared sent the payload without the signature, which worked in 2.4. It seems that in 2.5 it's looking for 4 payload arguments (the original 3 + the signature) and when Infrared only sends the original 3 arguments (without the signature) RealIP ignores the request since there is no validation signature.

Yeah, but I'm referring to why Infrared removes the signature argument at the end, this could be fixed with slight tweaking on TCPShield's end if its something simple.

from realip.

I don't believe the signature argument was present (or required/enforced) in 2.4.

from realip.

I don't believe the signature argument was present (or required/enforced) in 2.4.

It was present, just ignored along with the timestamp verification. The current verification system was used in older versions (discluding the IP whitelisting with CIDR). 2.4 looked for only 2 sections which allowed this issue to fly under the radar. But I still don't know why Infrared removes the end of the payload.

from realip.

Infrared doesn't remove the signature. The feature @gcurtiss is talking about upgrades the handshake packet to mimic what TCPShield would send. This enables the preservation of IP addresses like HAProxy protocol does without needing BungeeCord or other HAProxy solutions.

Here is the function that upgrades the handshake.

That makes way more sense now, thanks for clearing that up 👍🏻. So I guess the solution is to turn that option off since IP manipulation is already handled by TCPShield.

from realip.

That makes way more sense now, thanks for clearing that up 👍🏻. So I guess the solution is to turn that option off since IP manipulation is already handled by TCPShield.

There is a slight problem here, TCPShield the service isnt being used. This is the only way it makes sense what is happening would be if @gcurtiss refer to RealIP as TCPShield if i look at the first message:

... server with TCPShield ... installed.

Its possible to have a client connection: client -> tcpshield -> infrared -> backend there is only an issue with the status of an server since the cname record is different from the domain being send by tcpshield. Which could be solved by adding a second config to you infrared which has the domain name of the domain and also point that to your server. It doesnt matter or the "realIP" config value is turned on or off. (this is perhaps a different issue at the TCPShield backend, status requests are being send to the target ip with the player address address being 127.0.0.1:25565 and the domain being the registered domain and not the cname subdomain which is being used as server address. )

If you try to connected with a server which has RealIP 2.5 and you try to join with client -> infrared -> backend you will get this issue of missing a signature, which easily can be solved by making the tcpshield-ips.list file and putting in there the cidr of the proxy server(s). This doesnt work but it should...?

from realip.