[2.1.16] Returned UDP packets come out of the wrong IPv6 address

[synchromach]

What did you do?

I hosted a LAN game via the GUI on Windows, and had a player join and play.

What happened?

The player can connect and play to my server just fine for my particular setup, but Wireshark indicates the game is sending UDP packets back to the connecting player using the wrong source IPv6 address. For example, the player connects to my server at [xxxx:xxxx:xxxx:xxxx:96b5:790a:cff8:b933]:34197, and the server will send UDP packets back via source address [xxxx:xxxx:xxxx:xxxx:f9d1591d:ff4c]:34197 rather than [xxxx:xxxx:xxxx:xxxx:96b5:790a:cff8:b933]:34197.

This is due to the Ethernet interface of the host having multiple IPv6 addresses, often one persistent and several temporary ones. Even when you give the persistent one to the player to join, return packets are sent via one of the temporary ones.

What did you expect to happen instead? It might be obvious to you, but do it anyway!

I expected the host to use the same address the client used to connect to the host to send packets back to the client, which would solve several potential firewall problems and save hosts some headaches.

Does it happen always, once, or sometimes?

It happened both when I was hosting an actual game via IPv6 for someone else, and when I tried to reproduce the issue. Using Wireshark in both cases revealed the problem.

Save file, logs

mp test.zip

(753.02 KiB) Downloaded 28 times

factorio-current.log

(8 KiB) Downloaded 24 times

[Rseding91]

I'm not sure if this will ever be addressed. The way networking works within Factorio is: at multiplayer host-start the server binds to a specific IP address on a specific network adapter. It receives packets through it and sends packets back through it.

In your case it sounds like the operating system is receiving packets on adapter A and forwarding them to another adapter (B) - the adapter Factorio is using. Factorio is not built to handle this scenario. It expects packets that it gets to be sent to the adapter it's binding to.

[synchromach]

I'm not sure if this will ever be addressed. The way networking works within Factorio is: at multiplayer host-start the server binds to a specific IP address on a specific network adapter. It receives packets through it and sends packets back through it.

Hi, thanks for the quick response.

In this case it is not a multi-adapter or packet forwarding problem, since everything is happening on the Ethernet adapter. Both of the IP addresses in my report belong to the exact same Ethernet interface (confirmed via ipconfig /all).

Unlike IPv4 where each interface only has one address, OSes assign multiple IPv6 addresses to a single adapter (one static/persistent, and one or more temporary ones for short-term outbound-first traffic for browsers). When sending a packet back out to the client, one of these addresses will need to be selected to be the source address. It is likely that either the networking library used by the game, or the networking stack of the OS, did the source address selection automatically and ended up using the wrong source address. Based on what networking library the game uses, it is likely the server (i.e. the game when acting as a host) will need to track the specific address the client is using to connect to it, and communicate back using that same address as the source address, in order to lower the chance of being blocked by firewalls.

[eugenekay]

Your logfile does not show a Multiplayer Server session or Client log, so it is not clear what Address/Interface was chosen to Bind to. For Example, on a Windows Desktop I see:

149.010 Info UDPSocket.cpp:38: Opening socket at (IP ADDR:({0.0.0.0:34197}))
149.012 Hosting game at IP ADDR:({0.0.0.0:34197})

Windows' IPv6 Source Address Selection defaults to preferring the Privacy Extensions-generated addresses, rather than the ones assigned by SLAAC/DHCP6. You can disable this behaviour with Set-NetIPv6Protocol -UseTemporaryAddresses Disabled.


Good Luck!

[synchromach]

Windows' IPv6 Source Address Selection defaults to preferring the Privacy Extensions-generated addresses, rather than the ones assigned by SLAAC/DHCP6. You can disable this behaviour with Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

Good Luck!

Hi, thanks for the suggestion.

This is unfortunately not the solution. Disabling IETF RFC 4941 system-wide is a bad idea for privacy. A more elegant Factorio-only solution to work around this is to make the server bind to the specific, desired address via the --bind command-line parameter.

IETF RFC 8085 is a thing, and IPV6_PKTINFO also exists on Windows for applications wanting to implement it.

[eugenekay]

This is unfortunately not the solution. Disabling IETF RFC 4941 system-wide is a bad idea for privacy. A more elegant Factorio-only solution to work around this is to make the server bind to the specific, desired address via the --bind command-line parameter.

IETF RFC 8085 is a thing, and IPV6_PKTINFO also exists on Windows for applications wanting to implement it.

It is not the solution; but it is a possible workaround which helps to constrain the Bug's behaviour. If you can demonstrate that it works with this configuration change, then perhaps it would make sense for Wube to implement Source-Reply address matching with ULA & PE addresses. At the moment, the behaviour is "network standards compliant" insofar as UDP streams are not intended to be stateful.... which is obviously wrong, since Factorio establishes a login session on top of this stream.

There are dozens of us trying to use IPv6 in the real world. Dozens!

[synchromach]

If you can demonstrate that it works with this configuration change, then perhaps it would make sense for Wube to implement Source-Reply address matching with ULA & PE addresses.

You make a good point...

Attached are 3 screenshots from Wireshark showing 3 scenarios (their descriptions are written in the file comments).

These are the results I expected. As Rseding said, Factorio just binds, sends and receives the packets, so the game works fine in all 3 scenarios, but only if there are no firewalls between them. These tests were done on two Windows machines on the same LAN. I did notice that Windows firewall does get in the way in the Set-NetIPv6Protocol -UseTemporaryAddresses Enabled (Windows default) case, and I have to select "Browse LAN games" from the client / connecting player side, then go back to "Connect to address" to actually get the connection to succeed (I assume the LAN discovery chatter created a hole in the stateful Windows firewall). I guess that is already one prime example of why this is sort of a game "bug".

[justarandomgeek]

i've dug into this some and the TL;DR is that if we were using TCP (and for things like RCON where we *are* using TCP), the socket would just handle this for us because when it forms a connection, that connection is identified by the full tuple (local addr, local port, remote addr, remote port) and thus keeps the local end's identity as that it was called on. however, factorio's Transmission Control manager for the UDP connection only identifies connections by the remote half of that tuple, ignoring which address incoming packets arrive on, and doing normal destination-based source selection when sending each packet (so it's chosen source may even change over time on a long running server!). I *think* it's fairly straightforward to plumb the local half of that connection info through (and may even address some other IPv6 oddities, based on chatting with raiguard about it), but it touches several places so it'll take a bit of doing to get from here to there.

But rest assured that you're not the only one that cares about IPv6!