The Port Forwarding thread: Minimizing multiplayer connection issues

[Groman]

Commanders,

I've been following this thread recently and wanted to ask a few questions and share my observations.
Context: I am a networking and cybersecurity professional who wants to understand and maybe improve my connection to other people playing the game.

Questions

Do any folks have a different "router type" than "port_restricted" and do they know what is special to their setup?
I'm asking because FDev support didn't want to disclose anything about this when I asked and when I tried putting my computer directly on the internet, with a public IP assigned directly to my computer and I would still get "port_restricted" even after disabling my Windows firewall.

What is your typical ratio of successful connection after a session? This is found under network settings from the main menu in-game.
I usually get around 40~50% except for "IPV4 TO SERVER" which doesn't seem great. I know this is also dependent on other people when I connect to them but I am curious to see a few other CMDRs stats.

Observations
I have been using the Resource Monitor in Windows to track Elite's connections by going to the network tab in the app and selecting Elite's process in the top part.
Because it uses UDP, there won't be any player connections there but you can see those in the Network Activity section and also check which ports are used by Elite in the Listening Ports section.

I noticed the "main" port, used in the settings and, if you have UPnP enabled, requested to your router, is bound to your local IP and not to an "unspecified" IP.
There are other ports in the list though and I am not sure how Elite uses them.

For example:

Image	PID	Address	Port	Protocol	Firewall Status
EliteDangerous64.exe	3952	REDACTED IPv6	56984	UDP	Allowed, not r ...
EliteDangerous64.exe	3952	192.168.1.10	59004	UDP	Allowed, not r ...
EliteDangerous64.exe	3952	IPv4 unspecified	59662	UDP	Allowed, not r ...
EliteDangerous64.exe	3952	IPv4 unspecified	63760	UDP	Allowed, not r ...
EliteDangerous64.exe	3952	IPv4 unspecified	63762	UDP	Allowed, not r ...

o7

 

[GroG79]

I am not sure what you are trying to do here. I do not understand your explanation.
I suggest using Upnp and nothing else. If you have a normal network setup it is not needed to port forward. Do you perhaps have something like carrier NAT @ your ISP? You can call your ISP and ask them why it is not working. They might have an explanation or more likely they can help you forward the port.

ED should show the port it uses in-game. You need to configure that port along with your computers Internal IP in your modem/router. You can not have multiple ports forwarded to multiple addresses.

And plz for the love of all your data, kids, wife, friends, neighbors and mommas. DO NEVER CONNECT YOUR PC DIRECTLY TO THE INTERNET (on a public IP) WITHOUT A FIREWALL

 

[Groman]

I am not sure what you are trying to do here. I do not understand your explanation.
I suggest using Upnp and nothing else. If you have a normal network setup it is not needed to port forward. Do you perhaps have something like carrier NAT @ your ISP? You can call your ISP and ask them why it is not working. They might have an explanation or more likely they can help you forward the port.

ED should show the port it uses in-game. You need to configure that port along with your computers Internal IP in your modem/router. You can not have multiple ports forwarded to multiple addresses.

And plz for the love of all your data, kids, wife, friends, neighbors and mommas. DO NEVER CONNECT YOUR PC DIRECTLY TO THE INTERNET (on a public IP) WITHOUT A FIREWALL

I added context to my previous message, thanks for pointing that out.

The direct connect to internet without firewall was just a test to see if I could get something else than port_restricted.

Can you contribute and share your in-game router type and connection stats?

 

[Dormant account - pls delete]

It looks like IPv6 is supported for you. Just disable IPv4. You don't need it. You'll spend a lonnnnng time troubleshooting it because in 2024 ISPs themselves do weird things to IPv4 traffic. The best you'll manage to achieve is you'll manage to prove the ISP is doing a bad job and when you raise it with them they will shrug and say "we don't have any addresses left" and ask you to use IPv6.

 

[Groman]

It looks like IPv6 is supported for you. Just disable IPv4. You don't need it. You'll spend a lonnnnng time troubleshooting it because in 2024 ISPs themselves do weird things to IPv4 traffic. The best you'll manage to achieve is you'll manage to prove the ISP is doing a bad job and when you raise it with them they will shrug and say "we don't have any addresses left" and ask you to use IPv6.

I recently got IPv6 enabled, I had to work with my ISP to get it troubleshooted actually.
I've been monitoring my in-game network stats every time I finish playing and this morning, I finally saw one successful IPv6 connection!
In perspective, I have about a hundred successful IPv4 connections and a dozen via IPv4 TURN.
I am curious what makes you think IPv4 is not needed? How do I connect to people that don't have IPv6 enabled?

Can you also contribute your in-game router type and stats?

Thank you.

 

[GroG79]

Can you contribute and share your in-game router type and connection stats?

I just have a modem/router from my ISP. It is setup to use Upnp

I have a public Ipv4 and ipv6 adres. I believe services like Tv are using the Ipv6. Internal there is a Ipv4 network using 192.168.1.x

... How do I connect to people that don't have IPv6 enabled?

That is the job of your ISP

 

[Groman]

I just have a modem/router from my ISP. It is setup to use Upnp

I have a public Ipv4 and ipv6 adres. I believe services like Tv are using the Ipv6. Internal there is a Ipv4 network using 192.168.1.x


That is the job of your ISP

I meant what is your router type in-game and how many success/total connections you see on average in the main menu, network settings.

True, I could let my ISP handle IPv6 to IPv4 conversion and I might try it, for science, thanks for the suggestion
I'm still thinking on the long run to keep IPv4 enabled so I don't rely on ISP conversion which introduce another point of potential problems.

 

[GroG79]

Your ISP knows a lot more about networks. That is what you pay them for. I would leave default settings like they are. At default.
Disabling your ipv6 address in windows settings does not impact how your ISP is handling traffic going out from the router/modem

I can not check my in-game settings atm

 

[Wisho]

That is the job of your ISP

Not exactly - as far as I understood this is the job of FDev's TURN service.

The main difference between IPv4 and IPv6 is the address size : 4 bytes vs 16 bytes, which makes all pesky tricks like NAT used in IPv4 to extend the number of available endpoints useless in IPv6. As of 2024, there are way enough available IPv6 addresses worldwide for every single connected thing to have its own.

Therefore your ISP will do what you (=your computer) tell them to, provided the demanded protocol is available. If your E: D client is configured to use IPv6, it will ask to connect to FDev's IPv6 address, and P2P interactions will default to UDP/IPv6. Now if IPv6 is disabled on your ISP's level, packets will just be dropped by your router and the connection will appear as failed. The client will then try with IPv4 and if both fail, give you a "Rainbow Cyclops" or something error.
When ingame you meet another player, P2P connection is attempted based on the IP version in use by each player to connect to FDev's game server. If they match and chat then it's all good, if they don't match or if it fails somehow then each player connects to FDev's TURN service which will be in charge of "bridgeing" the data transfer between both.

 

[Dormant account - pls delete]

I'm still thinking on the long run to keep IPv4 enabled so I don't rely on ISP conversion which introduce another point of potential problems.

To be clear, carriers converting IPv4 to IPv6 - and also tunnelling IPv4 in horrific ways - is exactly what causes most carrier problems.

So if you want less of that going on, use IPv6. Using IPv4 introduces those, it does not remove them.

 

[Groman]

Your ISP knows a lot more about networks. That is what you pay them for. I would leave default settings like they are. At default.
Disabling your ipv6 address in windows settings does not impact how your ISP is handling traffic going out from the router/modem

I can not check my in-game settings atm

Understood, it is your choice to go that route. Personally, I want to test, understand and be able to explain how this all works.

Not exactly - as far as I understood this is the job of FDev's TURN service.

The main difference between IPv4 and IPv6 is the address size : 4 bytes vs 16 bytes, which makes all pesky tricks like NAT used in IPv4 to extend the number of available endpoints useless in IPv6. As of 2024, there are way enough available IPv6 addresses worldwide for every single connected thing to have its own.

Therefore your ISP will do what you (=your computer) tell them to, provided the demanded protocol is available. If your E: D client is configured to use IPv6, it will ask to connect to FDev's IPv6 address, and P2P interactions will default to UDP/IPv6. Now if IPv6 is disabled on your ISP's level, packets will just be dropped by your router and the connection will appear as failed. The client will then try with IPv4 and if both fail, give you a "Rainbow Cyclops" or something error.
When ingame you meet another player, P2P connection is attempted based on the IP version in use by each player to connect to FDev's game server. If they match and chat then it's all good, if they don't match or if it fails somehow then each player connects to FDev's TURN service which will be in charge of "bridgeing" the data transfer between both.

I confirmed IPv6 is mostly used for client to server via the Resource Monitor. It looks like FDev's servers are all hosted in Amazon when you check who owns those IPs.
TURN is indeed used as a backup if direct connection fails (source: ED support article)

To be clear, carriers converting IPv4 to IPv6 - and also tunnelling IPv4 in horrific ways - is exactly what causes most carrier problems.

So if you want less of that going on, use IPv6. Using IPv4 introduces those, it does not remove them.

Whether it is done properly or not, I believe we should try to reduce those conversions as much as possible.
To me, that means having your client being able to connect with most clients in any scenarios, whether they use IPv4, IPv6, UPnP, etc...

I appreciate everyone's feedback but can we get back on topic of in-game router type and connections stats?

Thank you.

 

[Dormant account - pls delete]

The topic of this thread is "Minimizing multiplayer connection issues."

"Port_restricted" is one of four possible treatments within NAT; it means FDev can only talk back to your client if the client has already sent out a request to the exact external IP address and port that the client nominated. Essentially this treatment says "speak to me in this exact way on this exact port on the outside of the firewall and it will get through to me inside the firewall. The other treatments are broader and essentially say "if you shout in the general direction of me the firewall will probably figure it out if it decides to trust you, good luck!"

If you see "port_restricted" it means the client has figured out that's the mode the Cmdr's router wants to use, and it's therefore sending some specific traffic out to FDev as part of the negotiation, to ensure FDev can then find a way to return the traffic and get it through the firewall. It's the most specific and narrow way of working so it's guaranteed to work on almost any router, but it also makes FDev do extra work to maintain the connection, so I'd guess the client tries quite hard to use one of the "easier" treatments where any traffic sent to the mapped IP will get through to the PC.

If your mini-survey was to try and work out what port_restricted means, don't bother, it's part of the standard and you can read that in RFC 3489. It means your IPv4 client is trying to do things with the perfectionist standard rather than the generalist standard, and that's probably because the generalist standard was rejected by your firewall as looking a bit too vague and therefore not to be trusted.

If you use IPv6 you will not need NAT at all and you can ignore this entire mess.

If you want more background on the intimate details of how NAT works you can PM me.

 

[GroG79]

Not exactly - as far as I understood this is the job of FDev's TURN service.

The main difference between IPv4 and IPv6 is the address size : 4 bytes vs 16 bytes, which makes all pesky tricks like NAT used in IPv4 to extend the number of available endpoints useless in IPv6. As of 2024, there are way enough available IPv6 addresses worldwide for every single connected thing to have its own.

Therefore your ISP will do what you (=your computer) tell them to, provided the demanded protocol is available. If your E: D client is configured to use IPv6, it will ask to connect to FDev's IPv6 address, and P2P interactions will default to UDP/IPv6. Now if IPv6 is disabled on your ISP's level, packets will just be dropped by your router and the connection will appear as failed. The client will then try with IPv4 and if both fail, give you a "Rainbow Cyclops" or something error.
When ingame you meet another player, P2P connection is attempted based on the IP version in use by each player to connect to FDev's game server. If they match and chat then it's all good, if they don't match or if it fails somehow then each player connects to FDev's TURN service which will be in charge of "bridgeing" the data transfer between both.

I am sorry

Fdev does not decide how an ISP should route its traffic. Neither does it care if you use Ipv4 or 6. That is for Amazon to resolve.
What you are describing is a setup Fdev uses to connect players via P2P.

 

[Groman]

The topic of this thread is "Minimizing multiplayer connection issues."

Indeed and that is why I am doing this investigation. A 50% ratio of successful connections in my case, is not great, compared to FDev article mentioning 1:1 (100%) is very good.

"Port_restricted" is one of four possible treatments within NAT

That is where the issue lies for me.
I will likely publish another post with the detailed steps of testing.
My experience so far has only yielded an empty router type if I block all outbound UDP ports.
Otherwise, I get port_restricted whether I forward the correct port, use UPnP or put my computer directly on the internet with a public IP and disable the firewall.
Given that, it seems either the test done by the game is not working properly or I am missing something. I did test my ports from an external website so it seems the issue is on the game side. Having people sharing a different router type could help find what is the difference.
I will continue testing as some scenarios are still untested.

If you see "port_restricted" it means the client has figured out that's the mode the Cmdr's router wants to use

I might do some packet capture with this as I am not getting the expected result when my computer is directly on the internet.
I wonder if the game is confused because there is actually no NAT, I will have to test that scenario.

If your mini-survey was to try and work out what port_restricted means, don't bother

I will bother and I do not understand your explanation of perfectionist versus generalist. What are you referring to?

If you use IPv6 you will not need NAT at all and you can ignore this entire mess.

Yes but not everyone uses IPv6 unfortunately. Granted, if everyone made that effort we would probably not be discussing this although I could still see firewall issues in the mix.
In my experience, IPv6 connections in the game are quite rare compared to IPv4. It does make me wonder what takes priority if a client support both.

If you want more background on the intimate details of how NAT works you can PM me.

Thanks but as a network and security professional, I believe I have a fairly good understanding of NAT.
I've had many successful and complex NAT setups working over the years.
Given that FDev support do not want to discuss the router type and has no real documentation on how the game processes connections, I am left with testing to guess how it works.

 

[Dormant account - pls delete]

Given that FDev support do not want to discuss the router type

The log literally tells you that the client has chosen to use the Restricted Port treatment. I don't know what you expect them to discuss beyond that unless you're expecting them to redesign NAT?

and has no real documentation on how the game processes connections,

Pretty comprehensive logging though, which answers all your questions, as far as I can see...

The game client doesn't really do anything special in terms of listening on connections anyway; the only part where there is some magic is how it calls the servers in the first place to set those up, because a good firewall fails closed and will not open a pinhole for you unless it is really convinced you need to see the traffic. Once that's happened once, away you go.

I am left with testing to guess how it works.

No, it tells you it is using the Restricted Port treatment and you can go and read the standard to see how it works, if you have not had any previous experience of using that treatment within the wider landscape of patterns that NAT offers.

 

[Groman]

I did a couple more tests and ironically, I was finally able to get full_cone for my in-game router type, yay!
There were a few confusing things though, which I will highlight here.

1. There is a setting on my router that achieve the full_cone status, it is called DMZ which is confusing since DMZ usually refers to a zone in a network, not a feature. When I tried this feature previously, I did not get full_cone in the game. I assume the router "bugged" but maybe the NAT/router test in-game didn't run properly. I then marked this router feature as not helpful and moved on to my next test.
2. If you achieve an equivalent of full_cone by exposing your computer directly to the internet (using a public IP), the game still report port_restricted. This part really confused me!
   I have to test this scenario again using https://www.checkmynat.com/ as a reference so I can compare with the game.
3. If you have both IPv4 and IPv6 enabled, the netlogs DO NOT report the line we are looking for, e.g. "TURN detect NAT". This seems like an oversight to me as IPv4 is still in the mix and it seems, is preferred to IPv6 when both are enabled. This is based on my tests when only enabling IPv6 (Thanks Markov for suggesting this!)
4. There is no specific router type when you are able to forward a single port, like UPnP would do on your behalf. This would be a nice addition so that you can verify the game acknowledge your port forwarding.

The log literally tells you that the client has chosen to use the Restricted Port treatment. I don't know what you expect them to discuss beyond that unless you're expecting them to redesign NAT?

See point 3, when I first looked at the logs for clues, I had IPv4 and IPv6 enabled, thus this line would not appear in my logs.
Also it still doesn't explain what it does e.g. ED server sending test packet on port X to IP Y, packet received by client.
I realize I did not activate the debug mode so I will definitively try that.

Pretty comprehensive logging though, which answers all your questions, as far as I can see...

I need to check the debug mode but the normal netlogs are pretty basic otherwise.

No, it tells you it is using the Restricted Port treatment

I think what was confusing was the FDev support article saying "This is advanced but may be of interest to those who are familiar with NAT types" which literally meant router type WILL BE one of those 4 type in that external article, although I don't know how to test the two other types.

Also I've never really heard those NAT terms before at least in a professional environment.
We usually use 1:1, 1 to many, many to 1, static source/destination NAT, dynamic source/destination.
Maybe it is because this article merge NATing and filtering as opposed to a professional grade firewall that would NAT and filter separately?

Anyway, thanks for replying to my post and on to more testing :-D

 

[Dormant account - pls delete]

I did a couple more tests and ironically, I was finally able to get full_cone for my in-game router type, yay!
There were a few confusing things though, which I will highlight here.

1. There is a setting on my router that achieve the full_cone status, it is called DMZ which is confusing since DMZ usually refers to a zone in a network, not a feature.

It's a zone which is the target of a feature - port-forwarding - and pf is not NAT. When you put your PC (or a range of ports on it) into a DMZ you are presenting your PC directly to the internet as if there were no firewall. That's why the "Full Cone" pattern will suddenly start working - there's no NAT happening, so when the client uses multiple different ports in the flow, FDev can send back on any old port too, and it will look like you have Full Cone NAT available. Actually you are not using NAT. You are only using port address mapping. (Yeah mapping, it's not even translation.)

In general (in a desperate attempt to stay on-topic) when you're troubleshooting connectivity you have to remember separation of concerns and the layer model; the ED client does not know what the firewall is doing, the firewall does not know what client or server are doing, it just deals with traffic blindly according to rules you give it, and FDev's servers does not know what the firewall will do either.

Fortunately, the client and the server DO know what each other should do, because FDev wrote both of them... so between them they have to work out a way to smuggle things past the firewall based on what they know about the firewall's blind spots.

The NAT standards provide a way for the ED client to say "I am going to use NAT's Port Restricted pattern," the firewall will see traffic and translate it, and ED's servers have to know the client wants traffic back that matches the Port Restricted pattern.

There is no specific router type when you are able to forward a single port, like UPnP would do on your behalf. This would be a nice addition so that you can verify the game acknowledge your port forwarding.

The point of Port-Restricted is that it translates one and only one port for one and only one use case. Port forwarding is a much broader technique and it's pretty opaque because it relies on the firewall to spoof everything and it also hides the fact that there is NAT present, which can be bad news for anything which makes assumptions about client IPs. It's really best avoided completely. It isn't NAT, which is why there's no NAT type.

Also it still doesn't explain what it does e.g. ED server sending test packet on port X to IP Y, packet received by client.

No, well, it's a game, not a professional network probe. (Have you thought about using WireShark?)

I think what was confusing was the FDev support article saying "This is advanced but may be of interest to those who are familiar with NAT types" which literally meant router type WILL BE one of those 4 type in that external article, although I don't know how to test the two other types.

It's not an article, it's the literal standard from the standards body. FDev might not even have implemented the other two, because Port-Restricted is the most precise implementation anyway and needs the least intelligence from the firewall. If that's available there's not much point trying to let the firewall guess because all you're doing then is letting bad guesses into the equation and it looks like an ED problem even though it's the firewall's problem really.

Also I've never really heard those NAT terms before at least in a professional environment.

They are from the standard. BUT in general working practice I agree practitioners never really look at the standard until it all goes horribly wrong. Everyone takes this quite complex stuff for granted now (which is how ISPs get away with giving everybody terrible implementations of it...)

We usually use 1:1, 1 to many, many to 1, static source/destination NAT, dynamic source/destination.

Those aren't the same thing; those terms talk about how the mapping of numbering and ports is chosen and maintained. In the discussion about the ED client, we are discussing how a UDP connection is established and maintained.

Maybe it is because this article merge NATing and filtering as opposed to a professional grade firewall that would NAT and filter separately?

Kind of, yes, although usually then "firewall" is used to refer to a specific logical component and there will be half a dozen components to what is then called the "security boundary." Sometimes these don't implement NAT in the IP layer at all and you use an application-layer or session-layer reverse proxy instead.

 

[Groman]

I will reply to you as a private message so we don't clog the topic here.

 

[npcostes]

Edit: NM

 

[Groman]

It looks like IPv6 is supported for you. Just disable IPv4. You don't need it. You'll spend a lonnnnng time troubleshooting it because in 2024 ISPs themselves do weird things to IPv4 traffic. The best you'll manage to achieve is you'll manage to prove the ISP is doing a bad job and when you raise it with them they will shrug and say "we don't have any addresses left" and ask you to use IPv6.

So I did try that and can say this actually make things worse because for any player that doesn't have IPv6, the game will use TURN to connect them to you, drastically increasing the latency and complexity of the connection having to do deal with the STUN/TURN server as the middle man.

I've checked using the game logs and statistics after a game session. I mostly had IPv4 TURN connections instead of a majority of direct IPv4 previously.