Multiplayer game inside GUI binds to temporary IPv6

[xZise]

Hello all,

I was trying to play with my brother yesterday using IPv6 (because I'm behind a CGNAT I cannot use IPv4). I'm on Windows 10 and used ipconfig to get my IPv6 addresses and my brother tried to connect to it. After some attempts I was looking at Wireshark what is actually happening and noticed that packets arrived on the correct IPv6 address (so there was no typo on his side) but Factorio was responding on my temporary IPv6 address. After I saw that I instructed him to use that address and it worked flawlessly.

Now I'm not 100% sure how IPv6 is actually working and whether this is normal behaviour, but it strikes me as odd. I wanted to give my brother a (more) permanent IPv6 address so that he could just connect to it the next time. So do I need to set up a headless server to bind it to a certain IPv6 address (maybe using the command line option "--bind") or is there some other option I need to turn on?

Thanks for you help in advance!

PS: 2a02:8108:...:2b is my brothers IPv6 while 2a02:8108:...:c308 (temporary) and 2a02:8108:...:41ca are my IP addresses.

[Tesse11ation]

So, I just looked up that CGNAT is. All I can say is... wow, that's garbage.

Unfortunately you might be SOL. Many games only support multiplayer server hosting over IPv4 protocol. I'm not sure if this is the case with Factorio but I've definitely never tried it myself.

If your brother is in the same physical network location as you, you can try hosting on LAN and see if your game shows up to him. If that doesn't work I recommend hosting through Steam. It's sub-optimal but it might be the only choice.

[xZise]

Hey,

well IPv6 works, and using a dedicated server with a bound IP-Adress works too. So it seems to me, that the UI/Settings need an entry to set a specific IPv6 adress. Now I don't know which API Factorio is using, but another solution would to force to reply from the same IP adress to which the original packet was sent.

[Hornwitser]

This problem also exists for multi-homed IPv4 hosts. The server listens on every address but only replies back from one. So if the server has has for example both 192.168.1.4 and 10.0.0.20 as IPv4 addresses, it chooses one and only ever use that as the source address to reply back with even if the packets come from the other network.

[Optera]

Try to bind factorio to the correct adapter.
I've used ForceBindIP in the past to solve such routing problems on Windows.
https://social.technet.microsoft.com/Fo ... networking

[ptx0]

This problem also exists for multi-homed IPv4 hosts. The server listens on every address but only replies back from one. So if the server has has for example both 192.168.1.4 and 10.0.0.20 as IPv4 addresses, it chooses one and only ever use that as the source address to reply back with even if the packets come from the other network.

I don't believe this is the case on Linux, where I can connect to a VPN address or public IP.

[Hornwitser]

I don't believe this is the case on Linux, where I can connect to a VPN address or public IP.

Linux is what I experienced it on. It might be that only happened on my really weird network setup, where the same interface was part of two subnets, I don't remember if both had a default route to the internet or not. But either way it didn't work well and I stopped doing two subnets.

[SoShootMe]

This problem also exists for multi-homed IPv4 hosts. The server listens on every address but only replies back from one. So if the server has has for example both 192.168.1.4 and 10.0.0.20 as IPv4 addresses, it chooses one and only ever use that as the source address to reply back with even if the packets come from the other network.

I don't believe this is the case on Linux, where I can connect to a VPN address or public IP.

Linux is what I experienced it on. It might be that only happened on my really weird network setup, where the same interface was part of two subnets, I don't remember if both had a default route to the internet or not. But either way it didn't work well and I stopped doing two subnets.

Factorio leaves the source address unspecified by default. This means when it replies to a client, the source address is chosen by the OS, normally according to the destination (the client's source address), after consulting the main routing table. This is normally an address in the same subnet as either the destination (if directly reachable) or the router for the destination (if not). Maybe this isn't necessarily true if you have two subnets on the same interface.

For IPv4, the end result is that things usually work except if the client and server can directly reach each other but the client doesn't use a directly reachable address for the server. However, I wrote "an address" above because even after narrowing the selection to the relevant subnet, there may be more than one address for the server to choose from, so the possibility that the one chosen is not the same as the one the client used remains.

Though having multiple local addresses within the same subnet is possible with both IPv4 and IPv6, it is far more common with IPv6, and will cause a problem when - as is typical - one of the addresses is a temporary address which is preferred for sending, exactly as the OP found. The simplest fix is for the server to specify the source address, which means binding to it, and the client using that address. On that note:

So do I need to set up a headless server to bind it to a certain IPv6 address (maybe using the command line option "--bind") or is there some other option I need to turn on?

I'm not sure if the "--bind" option works as with a headless server. But if not, another (less preferable) option is to disable temporary IPv6 addresses at the OS level.

The best solution for a UDP server to allow clients to reach it via any local address is for the server to bind to each local address, which enables it to always respond from the same address the client used. However, this is a non-trivial change, but would also make it easy to allow a user to specify a list of addresses to bind to rather than any (distinct from "each", and which has issues) or one in particular.

[xZise]

[...]

So do I need to set up a headless server to bind it to a certain IPv6 address (maybe using the command line option "--bind") or is there some other option I need to turn on?

I'm not sure if the "--bind" option works as with a headless server. But if not, another (less preferable) option is to disable temporary IPv6 addresses at the OS level.

Well using "--bind" with the headless server works, but has the undesireable sideeffect to run the game twice:

Hey,

well IPv6 works, and using a dedicated server with a bound IP-Adress works too. So it seems to me, that the UI/Settings need an entry to set a specific IPv6 adress. Now I don't know which API Factorio is using, but another solution would to force to reply from the same IP adress to which the original packet was sent.

[ptx0]

yeah seems like an oversight/bug for Oxyd or someone.

[SoShootMe]

I'm not sure if the "--bind" option works as with a headless server. But if not, another (less preferable) option is to disable temporary IPv6 addresses at the OS level.

Well using "--bind" with the headless server works, but has the undesireable sideeffect to run the game twice:

Sorry, I could have been clearer ("works as with" -> "has the same effect when hosting a game as it does with"). I meant using "--bind" but not starting Factorio as a headless server. In other words, whether "--bind" functions as a command-line equivalent to this:

So it seems to me, that the UI/Settings need an entry to set a specific IPv6 adress.

This should be a relatively straightforward feature to add, but I think the best solution is this:

another solution would to force to reply from the same IP adress to which the original packet was sent.

Based on my understanding of how the game works now, this would be a non-trivial change, but in most cases (including yours as far as I can tell) "reply from the same IP address" can be indirectly ensured by disabling temporary IPv6 addresses at the OS level. That is, the other (less than ideal) solution I offered.