IPv4 -> IPv6 encoding causing issues with VPN split tunneling

[MammothJerk]

Type

Incorrect behavior

Operating System

Windows

OS Version

Windows 10

Bug description

Using the Mullvad VPN windows app i'm connected to my VPN.

Within the app you can choose applications to use your actual IP which can help with ping, referred to as "Split Tunneling"

With runelite added as an app to split tunneling it will no longer launch.

This issue was brought up on the Mullvad github page.
mullvad/mullvadvpn-app#2972

In the runelite discord #support channel i've seen a couple other people having an issue with launching runelite using the split tunneling feature of their respective apps - NordVPN, ExpressVPN, PIA, and of course Mullvad.
It's possible that some other VPN providers use the same system as Mullvad and thus are having the same issue creating the split tunnel for runelite.

According to the issue on the Mullvad github page

Turns out it's an issue with the specific Java runtime used by this game. It's pretending to make IPv6 connections but using IPv4 peer addresses encoded as IPv6 addresses.

There appears to be an issue with how the java runtime environment that runelite uses creates ipv6 connections which is causing this issue.

So in the way that Mullvad creates the split tunnel, this ipv4 -> ipv6 behavior breaks that functionality.

Is it possible to fix this issue?

Screenshots or videos

RuneLite version

RuneLite version: 1.8.22
Launcher version: 2.1.5

Logs

launcher.log

[Adam-]

Turns out it's an issue with the specific Java runtime used by this game. It's pretending to make IPv6 connections but using IPv4 peer addresses encoded as IPv6 addresses.

This reads like maybe RL is using IPv4-mapped IPv6 addresses, however the launcher sets preferIPv4Stack here https://github.com/runelite/launcher/blob/master/src/main/java/net/runelite/launcher/Launcher.java#L196-L197 so I am not sure why that would be. This would probably require digging into the Windows networking stack in the jdk. Is there some JDK version where this issue isn't present?

[MammothJerk]

Is there some JDK version where this issue isn't present?

I am not sure if there is.
Perhaps @mvd-ows remembers when he looked into it and could be of assistance

[mvd-ows]

Going by memory, it seemed like the JDK wanted to pretend the whole world uses IPv6. So the game was using regular IPv4 addresses, and the JDK encoded this into IPv6 addresses.

The issue in relation to VPNs, again from memory, is that the connection is initially seen as an IPv6 connection in the system. Any kind of processing or properties that are applied to the connection at this point are then lost moments later when the system converts it into a regular IPv4 connection.

I am not aware of any JDK versions that behave differently.

The linked JDK settings seem relevant. But perhaps they need to be configured sooner for it to have an effect.

You could also experiment with disabling IPv6 on your primary NIC and/or tunnel adapter.

[TheNightRider12]

Any update on this issue? I found this when searching for the problem which I am having now with Split Tunneling.

[T-Six]

Bump. Still an issue.

[bowerscd]

So, you can get the launcher/client working (on Win10/Launcher 2.6.4/RuneLite 1.10.13) by setting the environment variable JAVA_TOOL_OPTIONS, to -Djava.net.preferIPv4Stack=true (At least, with Mullvad's split tunneling).

Ping is still just as horrendous as if the VPN is enabled, though; It's unclear if that's Runelite, Mullvad, or the overhead of the VPN in the first place.

This suggests the launcher isn't applying the setting correctly?

[Adam-]

So, you can get the launcher/client working (on Win10/Launcher 2.6.4/RuneLite 1.10.13) by setting the environment variable JAVA_TOOL_OPTIONS, to -Djava.net.preferIPv4Stack=true (At least, with Mullvad's split tunneling).

Ping is still just as horrendous as if the VPN is enabled, though; It's unclear if that's Runelite, Mullvad, or the overhead of the VPN in the first place.

This suggests the launcher isn't applying the setting correctly?

705fbaf8bbb3430d5f5fa0721d8ee227788a3052 removed the setting in 2.4.4 due to it being set too late:

Remove java.net.preferIPv4Stack

This is set too late currently. Both libnet and PlainSocketImpl both
read this prop, but libnet reads it OnLoad which is during VM
initialization, so we end up running with libnet having this set to
false while PlainSocketImpl has it set to true.

This ends up causing InetAddress to pick the v6 networking stack,
resolving addresses to ipv6 ips, and then PlainSocketImpl erroring when
it encounters an non-ipv4 address when in ipv4 only mode.

Since this seemingly has never really worked just remove it.

So if you have a 2.4.4+ launcher, it will not have this setting set anyway, which explains why you might need to set it. You can additionally run RuneLite (configure) and set it as a JVM property there.

[Adam-]

This is caused by Java using IPv4-mapped IPv6 addresses and also Mullvad not supporting IPv4-mapped IPv6 addresses. The only way to make Java not use this is to set -Djava.net.preferIPv4Stack=true as previously mentioned. However it needs to be set on both the launcher and also the client, and RuneLite (configure) sets only the client vm args. If you can otherwise control the launcher VM args (such as running the jar directly), that will work. You can also edit config.json to add -Djava.net.preferIPv4Stack=true and mark it readonly.

The relevant java code is here:

JNIEXPORT jint JNICALL Java_java_net_PlainSocketImpl_connect0
  (JNIEnv *env, jclass clazz, jint fd, jobject iaObj, jint port) {
    SOCKETADDRESS sa;
    int rv, sa_len = 0;
    int so_rv;
    SOCKET s = (SOCKET)fd;
    int type = 0, optlen = sizeof(type);
    jboolean v4MappedAddress = ipv6_available() ? JNI_TRUE : JNI_FALSE; // tests !preferIPv4Stack

    if (NET_InetAddressToSockaddr(env, iaObj, port, &sa,
                                  &sa_len, v4MappedAddress) != 0) {
        return -1;
    }

and then this, which actually makes the v4-to-6 mapped address:

JNIEXPORT int JNICALL
NET_InetAddressToSockaddr(JNIEnv *env, jobject iaObj, int port,
                          SOCKETADDRESS *sa, int *len,
                          jboolean v4MappedAddress)
{
    jint family = getInetAddress_family(env, iaObj);
    JNU_CHECK_EXCEPTION_RETURN(env, -1);
    memset((char *)sa, 0, sizeof(SOCKETADDRESS));

    if (ipv6_available() &&
        !(family == java_net_InetAddress_IPv4 &&
          v4MappedAddress == JNI_FALSE))
    {
        jbyte caddr[16];
        jint address;
        unsigned int scopeid = 0;

        if (family == java_net_InetAddress_IPv4) {
            // convert to IPv4-mapped address
            memset((char *)caddr, 0, 16);
            address = getInetAddress_addr(env, iaObj);
            JNU_CHECK_EXCEPTION_RETURN(env, -1);
            if (address == INADDR_ANY) {
                /* we would always prefer IPv6 wildcard address
                 * caddr[10] = 0xff;
                 * caddr[11] = 0xff; */
            } else {
                caddr[10] = 0xff;
                caddr[11] = 0xff;
                caddr[12] = ((address >> 24) & 0xff);
                caddr[13] = ((address >> 16) & 0xff);
                caddr[14] = ((address >> 8) & 0xff);
                caddr[15] = (address & 0xff);
            }
        } else {
            getInet6Address_ipaddress(env, iaObj, (char *)caddr);
            scopeid = getInet6Address_scopeid(env, iaObj);
        }

So I do not have many options here to fix this. I could globally enable java.net.preferIPv4Stack, but that would make people who do have working ipv6 unable to use it. I could also patch the jvm maybe, but we currently do not use home-built jdks and I do not want to start just for this.

I really think this is a Mullvad issue since it does not support v4 mapped v6. They seem somewhat aware of this mullvad/mullvadvpn-app#2972 (comment) but also think they can't fix it now. So I recommend using the -Djava.net.preferIPv4Stack=true workaround until then.

[robmonte]

Thank you for the workaround! This is starting to become required as Jagex has started to block many of Mullvad's IP's. This means whether using split tunneling or not the game would either fail to login or fail to launch.