Logging in to certain servers on certain networks is not possible due to a "Failed to verify username!" error message. The launcher is logged in to a Microsoft account with a valid Minecraft license. Server online mode is active.
Wireshark shows successful TCP & TLSv1.3 traffic to sessionserver.mojang.com during the connection attempt.
Error happens always network-wide on certain networks but only for certain Minecraft servers. There is no firewall or DNS issue - this has been intensively investigated. It is not possible to find the cause on the network by any sort of diagnostic method.
Log output in Minecraft does not exist for this error. Therefore a log output which shows the root cause of this error is mandatory. Also the entire functionality/subroutine that leads to this error should be severely questioned.
Comments 7
Steps to reproduce:
Start a Minecraft server on any OS with 1 network adapter that has a private IPv4 address.
NAT a public IPv4 on the router to the private IP of the server.
Connect a Minecraft client to the local network the server is in or any different local network as long as there are only hops with private IPv4 interface addresses between client and server.
Connect in Minecraft to the server using the local IP of the server = does not work
Connect in Minecraft to the server using the public IP of the server = does work
Hi
We have enabled ip validation quite recently. This means that if the server has IP validation turned on(only a 5-10% of public server has) it will provide the public IP of the connecting client in the hasJoined request and the sessionserver will compare it with the public IP of the Join request. It the IP's does not match, we reject the hasJoined request (204)
If public IP och both server and client are the same we consider it on the same LAN and accept that also.
I cannot reproduce this with exactly the same setup. Some questions:
What is your prevent-proxy-connections setting on the server?
What range are your local IPs in?
In the NAT setup, are the public IPs of client and server the same?
I was completely unable to find any information about IP validation or how to enable/disable it or find out what the current status is.
I would appreciate it if there would be any documentation available on this feature.
Server and client have different public IP addresses.
Both server and client are in a different private class B subnet which is connected via site-to-site OpenVPN with tunnel interface IPs in the private A range (constellation is server runs in datacenter and client runs at different location within the company's internal network).
Initially prevent-proxy-connections was true. Setting it to false solved the issue.
In older Minecraft versions this has never been a problem when enabled (I can't tell which version was the first that changed that). So I assume the behaviour of this feature has also been changed in the past.
You connected through a proxy (even if the proxy in this case was a site-wide one, it's still a proxy), which is why the game prevents the connection if you have prevent-proxy-connections set to true.
You're right that this wasn't correctly verified in the past, but that is a bug fix rather than a problem. So, the current behavior seems to be working as intended - just keep prevent-proxy-connections off if you need to connect through some form of proxy.
After a deeper check into the TLS traffic I found out there is an API call to https://sessionserver.mojang.com/session/minecraft/join containing JSON with fields accessToken, selectedProfile, serverId. The response to this request is a 204 No Content HTTP status with an empty body.
According to the API documentation (https://wiki.vg/Protocol_Encryption#Client) a 204 status is success and a 403 status is failure.
During testing in a network accepted by Minecraft and a network not accepted by Minecraft the selectedProfile and accessToken stayed the same. But the serverId has changed.
I have found that a network is not accepted when none of the hops between client and server have interface IP addresses outside the private ranges.
Workaround is therefore to have at least one hop with a public IP address between client and server.