Cannot join online-mode servers that use prevent-proxy-connections=true

[itsTyrion]

Minecraft Version: 1.20.2, 1.20.1, 1.20, 1.19.4, didn't test further back.

Forge Version: 48.0.40 down to at least 45.2.0, didn't test further back

Logs:

• First start; fresh install: https://mclo.gs/uJhdUS8
• Second start: https://mclo.gs/pN7dcVO

Steps to Reproduce:

1. Start the game. Join a server with prevent-proxy-connections=true
2. Vanilla server says "tried to join with an invalid session" and "Failed to verify username", Velocity and BungeeCord both give issues related to not being able to authenticate the session/account ("Not authenticated with minecraft.net")

Description of issue:
When trying to connect to a server that has prevent-proxy-connections=true, doesn't seem to matter if it's with BungeeCord, Velocity, just Paper or a plain vanilla server, it cannot auth with Mojang if this setting is enabled.

I am not using a proxy or VPN and I wasn't able to replicate this with the client being Vanilla/OptiFine/Fabric/LabyMod.

No errors in the client- or server log.
HOWEVER: With a fresh MC install or MultiMC instance AND fresh forge install, it works the first time the game is started and only then. After restarting the game, it's borked.

This is on Windows 10 with Java 17 and 19, the standard launcher and Prism, a MultiMC fork, no Forge mods in use.
Originally reported and double-checked by a friend so it shouldn't be something specific to my machine or ISP.

[PaintNinja]

Please follow the steps in this guide and report back if it worked or not. If it worked, please let us know which step did for you: https://forums.minecraftforge.net/topic/121862-troubleshooting-login-errors-in-forge/

[itsTyrion]

Most of these don't apply because the client can log-in/authenticate and connect to servers that have prevent-proxy-connections set to false or when using anything other than forge.
A friend using a different ISP and just the vanilla launcher, router settings, DNS settings etc. is also affected.
But for good measure:

• hosts file is clean
• my primary DNS is CloudFlare, my secondary DNS is google
• The VPS' DNS (where MC runs) can resolve the authserver. I tested it on 2 3 VPS' at 2 different hosters and 2 locations (Germany/Netherlands)
• Firewall settings LGTM
• I tried using Java 17 and 19, the official launcher and Prism (MultiMC fork)
• No VPN or proxy is active and connecting works with a client that isn't forge without changing other variables.
• Router settings LGTM, DNS there is set to CloudFlare (DoT) with fallback to CloudFlare and Google (plain DNS). IPv6 is always active because my ISP only offers DualStack-Lite.
• Disabling AV does nothing
• Server is not running in a docker container.

[itsTyrion]

Video context:

• The VPS is fresh, hosted at Hetzner in Germany, using their Ubuntu 22.04 image, only installed fish (shell) zsh and Java.
• I'm not on Windows 7 but Windows 10, that's just a theme.
• Video is on my VPS because GH has a 10MB limit and YT somehow nuked the quality to the point of making text almost unreadable.
  https://v.itstyrion.de/random/2023-11-20_17-17-42.mp4

[LexManos]

The facts that I can't reproduce this on a vanilla or forge server. Combined with us not touching the server authentication code at all. Leads me to believe this is a paper issue.
Can you reproduce it without paper?
I tried a quick glance over paper's code but couldn't navigate it on their github so no idea what they do with that flag that vanilla doesn't.
All vanilla does is send the client's IP address to the auth server when testing the connection.

SocketAddress socketaddress = ServerLoginPacketListenerImpl.this.connection.getRemoteAddress();
return ServerLoginPacketListenerImpl.this.server.getPreventProxyConnections() && socketaddress instanceof InetSocketAddress ? ((InetSocketAddress)socketaddress).getAddress() : null;

And Forge doesn't interfere with that at all, hell it can't because the client doesn't send it's IP address, the auth servers snag it from the TCP connection.

[itsTyrion]

Can you reproduce it without paper?

yup. Vanilla, Waterfall and Velocity.
Vanilla:

BungeeCord:

(nothing in the console, aside from IntialHandler has connected, which always shows up)

Velocity:

(same thing in-game and in the console)

And again right after with a Fabric client, no other changes:

I agree, it makes ZERO damn sense. This should simply not be possible to happen.
(ik my real IP is visible but I don't care, the odds of someone seeing this and showing up at my door are basically zero)

[PaintNinja]

Out of interest, does it work if you add the following JVM arg to the Vanilla server: -Djava.net.preferIPv6Addresses=system?

[itsTyrion]

It doesn't, neither does connecting to the VPS' IPv6. As this is a fresh VPS with nothing on it, I can provide access via SSH pub key if that helps (probably not, it's a bog standard setup)

[PaintNinja]

I think I've figured out the cause...

IPv6 is always active because my ISP only offers DualStack-Lite.

I believe MC treats IPv6 over IPv4 solutions as a form of proxy connection, which means it gets blocked when setting prevent-proxy-connections to true. This issue doesn't happen with Vanilla because it doesn't support dual-stack IP modes (always IPv4 by default or always IPv6 with opt-in).

Does the issue also happen on Vanilla if you add these JVM args to your client and server? -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true

[itsTyrion]

Good theory, but it still happens, including on localhost (with both 127.0.0.1 and ::1) (idk if it not MAYBE still does something weird?)