[0.12] Headless mode and multiple clients behind NAT

[Boogalo]

One issue I have might be uncommon, but affects my setup. I have a server I run a few games on from my home network, sharing a single external IP. Ports forwarded to the box running the server. External people can connect just fine, but I can't connect from another machine on my local network. When connecting, I get the error can't connect to player, and it lists their ip address. I believe this is due to everything still working peer to peer. I had to set up a port forward on my router so external folks can connect, but then all traffic on that port goes to the server, and none to my client, and thus it can't talk to other players. I can't see a way around this other than a server working on one port, and clients talking port+1 or something (would need to be coded for it). I understand this is a limitation how the multiplayer works in that a headless server is just a characterless client with no GUI.

I'm not sure if this counts as a bug, feature request, or non-fixable issue, etc. My setup is uncommon but not unique. I know several folks who do this for some game hosting on spare PCs.

In short, either local people, or external people can connect, but not both.

[FishSandwich]

You can change your own client to use a different port in the config ini, and then forward that port to your computer.

That should work? Not sure.

[Boogalo]

Nope. Everyone seems to all want to talk on the same port. It also prevents running headless and a client on the same machine.

[TheMax]

confirmed. Same here.

[MF-]

Changing the port in the client definitely should work.
I would use the original port for the headless server.

If not, perhaps you could be running into https://forums.factorio.com/forum/vie ... =7&t=13634 ?

[Bisa]

Changing the port in the client definitely should work.
I would use the original port for the headless server.

Just to clarify; If you are behind a nat router, ie if multiple clients (I'm including the headless client here since it is by no means a server in this regard) on a local network attempt to connect to the headless client they can do that just fine - but as soon as you venture outside the lan and onto the internet, for example if you have a remote friend who wants to join you the nature of the peer-to-peer solution here prevents the remote client from "seeing" each individual lan client since these are exposed on the internet on the same ip - ie it is impossible for the router and or lan clients to know which packet to send to which lan client coming from the outside as all of them are interested in the remote clients traffic.

To circumvent this, ensure all client (including "the server") belong to the same network, ie have separate and individualy distinguishable ips.
For more advanced users, setting up a public vpn or using services like Evolve is the only feasable way to resolve this right now.

[FishSandwich]

That's the whole point behind using ports and port forwarding, so the nat router knows where to send the traffic.

I think the issue here is that Factorio itself doesn't deal with this very well.

[Bisa]

That's the whole point behind using ports and port forwarding, so the nat router knows where to send the traffic.

I think the issue here is that Factorio itself doesn't deal with this very well.

I'm by no means a networking guru - but, port forwarding is just that, a specific port forwarded to a specific host behind the router, there is no way for Factorio to distinguish between different hosts on a network behind a router unless it uses separate ports for each host. In the routers perspective so long as you forward a port:

Remote Client "A" :
- "I want to communicate with Client B" (the headless client, in this case accessible on LAN and behind a public ip/nat router)
- "I'm sending upd packets on port 34197 to [public ip]"
The Router:
- "I'm listening for traffic on [public ip]"
- "Hehy, a udp packet on port 34197 just arrived, where shall I send it? I'm configured to forward this to Client B"

So far so good, but lets introduce Client C and D, two hosts on the same local network as Client B (ie two friends having a lan party, playing on separate pc's + hosting Client B on a spare computer in the closet)

Client C & D:
- "I want to communicate with Client B"
- "I'm sending packets to 34197 on [lan ip]" (behind a router, you know where to go any way)
Client B:
- "Hi guys! Nice to see you, I'm playing with A over on the interwebz, nice of you to join us"
- "Hey A! Check out these new guys C & D"
Client A:
- "Sweet, more players! Where can I communicate with them?"
Client B:
- udp [public ip] 34197
Client A:
- "You are kidding right? That's your details..."
- "Oh well, giving it a try...Hello C & D at [public ip]"
Router:
- "udp traffic on 34197, sending you off to Client B"
Client A:
- "right, so how am I supposed to communicate with all 3 of you on the same port and ip?"

and that's the real question, unless peers have uniq ips they cannot communicate with eachother as each peer has no way of knowing which peer behind a shared ip they are spaking to and mostly the routers out there - just like this one - are configured to forward factorio traffic to a specific host on the local network.

EDIT*
Slightly simplified, I suspect it's actually client C & D who initiate the communication with A but the problem persists, all 3 B, C and D will tell A to communicate with them on the same ip and port

[FishSandwich]

Your scenario assumes that the port is a fixed number for all clients, which isn't the case. The port number is configurable.

[Bisa]

Your scenario assumes that the port is a fixed number for all clients, which isn't the case. The port number is configurable.

*mind blown* I thought every connecting client had to use the same port, if that is not the case simply change the configured port and port forward separately for the various clients
for example:

B: 34197
C: 34198
D: 34199

brb, going to verify this thank you

EDIT*
looks promicing, Im connecting to the server on my lan network and it lists the port I used in my client config despite me connecting to the headless on 34197
if anyone would like to try it from remote, please drop me a pm (else I might not have the server running but if it is I'm at bisa.no-ip.org)

[Boogalo]

Your scenario assumes that the port is a fixed number for all clients, which isn't the case.

Where are you getting this information? I still think it is incorrect. All clients (and the server because it is just a client) want to talk on the same port, and if they can't, it fails.

Just tried:
Server on local network at 34199 (external port forwarded to server)
Local client on another machine at config set to 34197 (external port port forwarded to corresponding machine)
Remote client with config set to 34197 (must connect by using ADDRESS:34199")

Remote client can try to connect to ADDRESS:34197 or ADDRESS:34199 (both are valid connection points since everything is peer to peer). I see the connection attempts in the server console window. If i connect form the local client first, the remote client can't connect. If remote connects first, the local client can't connect. Both fail with the same error, can't connect to peer. It fails the same if the ports are reversed with the server on 34197 and the clients set to 34199 (and corrected on the router).

All players try to talk on the same port, and if they can't, connection fails.

MF- has mentioned the only likely way around this...with private VPN, hamachi, etc.

[FishSandwich]

That brings us back to my second post here.

The ports are configurable, but Factorio itself doesn't deal with it very well.

[cube]

Soooo ... a bit of explanation:

Factorio (and the whole world with it) uses a ip address, port tuple to identify services programs running on servers. That result of this is that you can run multiple instances of Factorio (or Apache, or anything) on one computer without any problems, you just need them to use different port numbers.

Factorio by default uses port 34197, but as FishSandwich wrote, it can be changed in config. That is 34197 UDP -- a completely different thing than 34197 TCP.

Example:
1) server running on internal network with IP 10.0.0.1, Factorio at default 34197
2) internal network client with IP 10.0.0.2, Factorio at default 34197
3) second internal client on the same machine (to complicate stuff a little) with IP 10.0.0.2, port 34198

at this point both 2) and 3) should be able to just write "10.0.0.1" into the MP connect dialog and play on the server
or even connect 3) first, using "10.0.0.1", then connect 2) using "10.0.0.2:34198"

But now let's consider that you want to play over the internet.
4) is your router. It has public IP address 12.34.56.78 and forwards its port 34197 to 10.0.0.1:34197
5) is your remote friend

If the server is running and no one is connected, then 5) can connect to "12.34.56.78:34197" and start playing.
But if 2) or 3) was connected before, 5) will get kicked with the message you described.

The reason why this will happen is that everyone in game holds addresses it uses to communicate with other peers in game and everyone must be able to reach them.
The addresses are copied to the peer when he connects.
In our problematic scenario the server holds a list like this:

Code: Select all

10.0.0.1:34197 myself
10.0.0.2:34197 2)
10.0.0.2:34198 3)

But from 5)'s point of view the addresses don't make sense. He cannot reach any of the peers using addresses from this list.

This is to some extent a limitation of the P2P model we are using and to some extent a problem Factorio's implementation.
A workaround is for 2) and 3) to connect to the server using its public address "12.34.56.78:34197" as well. This way the router will change the addresses to its own external address and a random port (and it will keep the mapping while it is in use), and the list sent to 5) will be correct.

To play this way, only1) needs to have port forwarding set up. This trick is called NAT punchthrough and relies on the router allowing an incoming packets for some time after a outgoing packet was sent...

This all assumes that the router behaves the way we expect it. Which it may not. In that case I need to know what works, what doesn't, what configuration are you using and what workarounds help. There is a huge room for improvement in Factorio networking code :-)

[Boogalo]

I hadn't thought of trying through the external for the internal clients. Will give that a go tonight and report back. It will let us know if Comcast and DDWRT routers support that kind of networking.

My understanding of what's going on looks correct (and it seems to behave as expected), but I'm not great at putting it to text.

[Coelun]

I use the NAT loopback enabled routers.

Example)
server-192.168.x.1:11111(local IP),globalIP:9.8.7.6:11111 (forwarding)
myPC-192.168.x.2:11112(loacl IP),globalIP:9.8.7.6:11112(forwarding)
playerA-1.2.3.4:12345(global IP)

If don't use NAT loopback. use the local IP to server connection.　
can : myPC----->(local IP)server server:myPC=192.168.x.2:11112
can : playerA----->(global IP)((router)----->server) server:playerA=1.2.3.4:12345
can't : playerA(globalIP) <--x--> (loacl IP)myPC

###playerA's factorio-current.log###
24.159 Info Synchronizer.cpp:455: NetworkTick(517349) Requesting heartbeat for networkTick(517346) from peer(15). Drop detection state(600/600).
24.175 Error MultiplayerManager.cpp:107: MultiplayerManager failed: "192.168.x.2:11112 ~~~~~~~~~~~~~"
24.181 Info MultiplayerManager.cpp:848: networkTick(517349) mapTick(-1) changing state from(VerifyingConnection) to(Failed)

Now I use NAT loopback. I use a global IP to server connection.
can : myPC----->(global IP)((router)<----->server) server:myPC=9.8.7.6:11112 (*1)
can : playerA----->(global IP)((router)<----->server) server:playerA=1.2.3.4:12345
can : playerA(global IP)<----->(global IP)myPC

I bought a router that it can be.
As a result, I was able to connect to the playerA.

[selkathguy]

I have a router which i can use to test the scenario that Cube outlined with a reasonable amount of confidence, should Boogalo's setup not work.

[Bisa]

Thank you for the insider clarification Cube.
For those who are itnerested in:

A workaround is for 2) and 3) to connect to the server using its public address "12.34.56.78:34197" as well.

Please be aware that routers may or may not have built in protection for "NAT Loopback" essentially preventing LAN clients from accessing eachother via the routers public ip. According to the wiki article consumer routers should be fine but you never know - if you cannot access your headless client from the public ip if you are on the same LAN, NAT Loopback is probably what's messing with you as long as you've verified that the port forwarding works (ie your remote friends can join just fine)

[Boogalo]

server-192.168.x.1:11111(local IP),globalIP:9.8.7.6:11111 (forwarding)
myPC-192.168.x.2:11112(loacl IP),globalIP:9.8.7.6:11112(forwarding)
playerA-1.2.3.4:12345(global IP)

Using this as a framework we started experimenting. Port numbers are actual.

server-192.168.x.1:34199(local IP),globalIP:9.8.7.6:34199(forwarding)
myPC-192.168.x.2:34197(local IP),globalIP:9.8.7.6:34197(forwarding) (connecting to server at globalIP:34199)
playerA-1.2.3.4:55980(global IP) (connecting to server globalIP)

The above did not work. When either was connected, the 2nd could not connect.

server-192.168.x.135:54199(local IP),globalIP:9.8.7.6:54199(forwarding)
myPC-192.168.x.100:54197(local IP),globalIP:9.8.7.6:54197(forwarding) (connecting to server globalIP:54197)
playerA-1.2.3.4:55980(global IP) (connecting to server globalIP) (not forwarding)

If myPC was connected to the server first, playerA connected ok. If playerA was connected first, myPC could not connect. It maintained this behavior whether or not playerA forwarded his port. When myPC connected, playerA got the error as 192.168.x.1:54197 couldn't connect to peer (.1 is the local gateway) myPC got the error for 1.2.3.4:55980

I switched server and myPC back to the 34199 and 34197 respectively and updated the forwards as an additional test and the original failure mode returned.

Both of my machines are Win7 Pro x64. Router: asus rt-n66u running DDWRT. Comcast for internet, using my own modem.

We'll continue the test with playerA and him hosting on his equipment.


\/ \/ \/ is playerA in my case

[selkathguy]

After trying a myriad of complex hand-crafted NAT translations, routing table entries, access-lists and vlans, I am suggesting this functionality be officially supported.

Suggested fix:
When the server sends the list of client addresses to the new client (if the new client is remote): For each client address with a private IP address, send a static, predefined value instead (e.g. "LOCAL"). When the new client reads the list, any address that has that predefined string will be replaced by the address it used to connect to the server. For client, if the server you are attempting to connect to is a private address, choose a random port in the dynamic range to connect from.

This should enable having the server and clients local to the server be able to connect along with multiple remote users. However you would still be unable to have multiple players connecting from the same IP (remote to the server).

[Coelun]

Probably, Need a router selecting.
My router make the source IP change to the WAN IP.

http://gyazo.com/3e7cb31756a9db04aa1bfcbff237ad0b
image mistake:
x"Factorio server:11111"
o"Factorio server:11112"

But . I think that other router is not necessarily the same.
NAT is Fucking. Compatibility of NAT and P2P is bad.