The Port Forwarding thread: Minimizing multiplayer connection issues

Then that router is either UPNP enabled or you are benefiting from FDev's turn servers 🤷‍♂️
edit: even without the above, you can still enjoy multiplayer in ED if other people in your group have some sort of proper port forwarding or UPNP (usually it's the UPNP) since you will be connecting to their sessions and not the other way around
I don't use uPnP either - and I have teamed up with three other people who also had port forwarding and uPnP disabled, without issue.
The clients do not have public-facing IP addresses, nor public ports. Their routers do, but the clients don't know anything about those.
Again, many people's routers don't have public IP addresses - there aren't enough IPv4 addresses to go around, so if a given ISP even offers public-facing IP addresses, it often comes with an extra fee that most people won't pay because they don't need it.

The port that the clients use to communicate with the server will not be the same one used when they try to communicate with each other (see below), so this method is doomed to fail.
If it's doomed to fail, then networking experts have been having hallucinations for decades, because it has actually been working for decades. The routers along the path worry about the ports, the clients only need to worry about sending to the correct IP address. The rest is buried in the headers and worked out dynamically by each node along the route.

The router associates an external port with a local IP+port and a remote IP+port. If a non-matching remote IP tries to send a packet to that port, it will be rejected (ICMP destination unreachable).
Likewise, this is why it's impossible for Frontier's server to determine which client port should be used for peer-to-peer connections - the only client port they hear from is the one associated with the connection to their IP; when the client attempts a connection to a peer, it will be through a completely different port on the router because it's a different remote IP+port.
If your assertion was correct, the entire internet would not work without every port being explicitly opened and advertised. Routing protocols are designed to figure a lot of it out on the fly - as a packet traverses a given router, the router stores temporary routing information and updates the outgoing header so that replies know how to traverse that specific leg of the route on the way back. No single node knows anything about the route beyond the directly connected nodes in either direction - that's an awful lot of port assignements that they don't know about, that your assertion would suggest they would have to know about.

And this is exactly what happens when a router implements port-restricted NAT, which is the most common type because it's cheap and nasty / the most basic to implement.
No, this is what happens on any modern, secure network hardware. Ports left open are ports that could be exploited, which is the entire reason they aren't just all left open all the time. It's not about being cheap, it's about being secure.

I've watched your streams, and indeed the amount of issues you experience when trying to play with others is far worse than most people. And if you're behind a CG-NAT with no control over the public interface, it's any wonder you think port-forwarding makes no difference - because in your case it won't.
I've watched numerous people struggle a lot more than me, and they have port forwarding enabled. I've even convinced a couple people to disable it and check a few other things instead, and seen their connection issues go away after fixing things like MTU size.

I've also seen connection issues accompanying the same people on multiple occasions, while I have had no problem connecting to any of the other people in the instance until one of those specific people showed up and everyone started having problems. And then that person leaves again, and the issues go away.

The reason I say port forwarding isn't needed is because I play all the time, and have never had a connection that would allow port forwarding. It's not that I tried it and saw no difference - it's that I understand what it actually does. I assert that the connection issues you've seen me have are more likely to be caused by other people I'm instanced with than by my own connection. I've had multiple passengers on board at the same time on multiple occasions and only lost one of them - if my connection had been the issue, I would have lost all of them.

Do a basic tracert (or traceroute on Linux) to any public URL and you'll see that the packets traverse several nodes along the way - if your assertion was correct, then we couldn't simply navigate to google.com; we would have to explicitly state which ports to connect to on each of those hops along the way. NAT (Network Address Translation) handles all of this automatically, and it does so very well, or the entire internet would never have succeeded. Port forwarding is only needed at the public facing router that the server is behind, because we can only point at the public IP address - the rest of the route beyond that point has to be defined in the NAT tables, and if there is no outgoing packets to cause NAT to establish that mapping automatically, as is the case with a dedicated server but not with a client, then it must be pre-defined. But for client to client communication, both clients send packets out first, affording them the opportunity to establish temporary port mappings as needed.
 
I don't use uPnP either - and I have teamed up with three other people who also had port forwarding and uPnP disabled, without issue.

UPNP On is the implicit setting in ED networking
Even without UPNP or PortForwading you could be lucky enough to get a session on FDev's TURN servers, but as i said, they have their own reliability issues and they add a certain degree of latency

Again, many people's routers don't have public IP addresses - there aren't enough IPv4 addresses to go around, so if a given ISP even offers public-facing IP addresses, it often comes with an extra fee that most people won't pay because they don't need it.

And even more people are absolutely oblivious to internet connectivity issues - so the UPNP protocol was developed, it' s working and is usually enabled by default on each game and on each router too
 
UPNP On is the implicit setting in ED networking
Even without UPNP or PortForwading you could be lucky enough to get a session on FDev's TURN servers, but as i said, they have their own reliability issues and they add a certain degree of latency
No software can override the settings on the router, where I explicitely disable UPnP ;)

And even more people are absolutely oblivious to internet connectivity issues - so the UPNP protocol was developed, it' s working and is usually enabled by default on each game and on each router too
And plenty of people are absolutely oblivious to the correct purpose of port forwarding, so they use it in ways it's not meant to be used, and sometimes they see an improvement, other times it's purely placebo effect. And sometimes, things seem better on their end, but another client in the instance starts having issues because the server sees a client with port forwarding enabled and prioritizes that client as a potential instance host even if that client's connection is sub-par

If your connection is less than ideal, enabling port forwarding often increases the odds that other clients will suffer because of your unresolved network issues
 
No software can override the settings on the router, where I explicitely disable UPnP ;)

you said you have no access to the router having the public IP address which is/was upstream - in which case, what you do on your router has little to no significance



And plenty of people are absolutely oblivious to the correct purpose of port forwarding

Read that article i quoted above, from the XB support
 
you said you have no access to the router having the public IP address which is/was upstream - in which case, what you do on your router has little to no significance
I can confirm that. UPnP does not work in CGNAT environments. For that, Port Contol Protocol (which is rarely supported by ISPs) has been introduced. However, Elite Dangerous (and many routers, for a fact) does not support PCP.
 
In addendum however, it's rare, but possible, for a router to translate UPnP requests into PCP requests (such as this Cisco article explains, see PCP Interworking with UPnP IGD), if such router and the respective ISP supports that. Depending on the implementation, ED might or might not be aware of the final assigned port and public IPv4 address. UPnP untranslated will not work in CGNAT because UPnP itself is not designed to be forwarded.

The german Fritzbox (Such as the Fritzbox 7590) does support PCP, however, I know of no german ISP that implements PCP.
 
Last edited:
you said you have no access to the router having the public IP address which is/was upstream - in which case, what you do on your router has little to no significance
And a router upstream from mine, having UPnP enabled, is irrelevant when mine has it disabled - the attempts to use UPnP from the client would never make it out of my own LAN. Every router sees its WAN interface as the public interface from it's point of reference, regardless of whether it's actually the outer-most router on a private LAN.

UPnP is a convenience that comes with cybersecurity risks - I know how to configure my devices as needed, so the convenience is of far less value to me than the security I would have to give up for it.
 
Do a basic tracert (or traceroute on Linux) to any public URL and you'll see that the packets traverse several nodes along the way - if your assertion was correct, then we couldn't simply navigate to google.com; we would have to explicitly state which ports to connect to on each of those hops along the way. NAT (Network Address Translation) handles all of this automatically, and it does so very well, or the entire internet would never have succeeded.
You lack basic understanding of how TCP/IP works and this shows it very well - how NAT operates and how packets are forwarded at each hop are completely different things.
 
You lack basic understanding of how TCP/IP works and this shows it very well - how NAT operates and how packets are forwarded at each hop are completely different things.
Funny, I'd say the same thing to you (and anyone else who insists that port forwarding is meant for anything other than allowing access to a dedicated server on a private LAN from outside that LAN)

And one of us is correct ;)

Port forwarding used for anything else does work sometimes, but as a hacky workaround, to avoid properly addressing a problem. And too many times, it fails to address the problem, but manages to hide the symptoms of the problem from that client, convincing them that they've solved a problem that they've actually just offloaded onto another client.

And then the other client has a problem they actually can't solve, and they go around blaming Frontier for problems that Frontier can't solve, either, and everybody carries on complaining and blaming the wrong things with undue confidence.

Not that the TCP part of the TCP/IP stack is relevant when UDP is in use (check out your netlogs sometime ;) )

1692568241311.png
 
Last edited:
Given you tried to claim ping (i.e. ICMP - a protocol that is part of TCP/IP) uses ports, you really should not be nitpicking.
No, I stated that the ping command can be used to test for the ideal MTU size, which it can. The game does attempt to detect the correct MTU size automatically, and most of the time it does fine, but I have seen entries in the netlogs showing that sometimes the adjustment doesn't happen fast enough to avoid connection loss
 
No, I stated that the ping command can be used to test for the ideal MTU size, which it can. The game does attempt to detect the correct MTU size automatically, and most of the time it does fine, but I have seen entries in the netlogs showing that sometimes the adjustment doesn't happen fast enough to avoid connection loss

Always worked for me

HTH
 

Always worked for me

HTH
Nothing to do with port forwarding really but thanks for that fantastic tip to the TCP Optimizer link. I upgraded from Virgin Media's 500Mbps Volt service to their 1Gigabit service a couple of months back but have only averaged around 560Mbps download and 104Mbps upload since then. I am running with the VM superhub 5 box in modem mode through a TP-Link Archer GX90 router. I downloaded the TCP Optimizer from the link above and set it to optimize my 2.5GB Realtek NIC card and got 760Mbps d/l and 98Mbps u/l on my first try at Speedtest at 1800hrs which is a busy period for VM broadband users.
 
I'm not in Australia.
While I had the aDSL internet access, I do remember when the subject came up; that my successes in playing were likely due - at least in part - to other players' settings. I wasn't really fond of that scenario, preferring to be a part of the success rather than a reliant party.

I then began looking at the numbers reported in the game's network settings, then configured the port-forwarding all the way through my double-NAT setup.* I remember being more pleased with the resulting numbers. Unfortunately I can no longer remember the details of those number comparisons. That may not matter, of course.

One thing I'm glad you brought up again, @styles784, is the concept of MTU. I had always intended to do the test and optimize that setting, if necessary. With all of the changes, setup work, and other details, this simply got lost in the shuffle and slipped my mind.
I'm not certain what to expect, especially in the context of playing ED, but (again) I prefer to be part of the success, so I'm completely willing to do the work and see what the results show. I have seen another article in the past (from TP-Link perhaps) outlining the steps, so it's not a difficult procedure.


* A long story which I don't believe deserves repetition here. I did post about it earlier in this thread but it is longer relevant because my network configuration has changed. The main opinion I came away with is that the difficulty of port-forwarding is vastly overemphasized. It really is not a complex concept, nor is it hard to implement manually. I had to do it through essentially three routers (then reduced to two) and it really wasn't a big deal.
 
* A long story which I don't believe deserves repetition here. I did post about it earlier in this thread but it is longer relevant because my network configuration has changed. The main opinion I came away with is that the difficulty of port-forwarding is vastly overemphasized. It really is not a complex concept, nor is it hard to implement manually. I had to do it through essentially three routers (then reduced to two) and it really wasn't a big deal.
It's certainly not difficult if you have enough of a foundation of technical knowledge - I think the reason it is generally presented as difficult is because the type of user who is most likely to be given the advice to port forward doesn't have that solid foundation. Those users are harder to assist, because they can't answer many of the questions a tech would need to ask in order to actually troubleshoot the problem. And that's why port forwarding became such a popular approach - it's sort of the "turn it off and on again" of networking, in that it's a lazy way to dodge the problem for now without actually solving it.

And that sort of approach is fine, as long as people remember that that's all it is - that way, if the problem persists, or presents in a different way, they're more likely to accept that the workaround isn't working and that more effort is needed, instead of insisting that they've already done all they can do when they haven't, and that someone else needs to do something when nobody else can do what actually needs to be done.
 
It's certainly not difficult if you have enough of a foundation of technical knowledge - I think the reason it is generally presented as difficult is because the type of user who is most likely to be given the advice to port forward doesn't have that solid foundation. Those users are harder to assist, because they can't answer many of the questions a tech would need to ask in order to actually troubleshoot the problem.
Can't agree more. I ecounter this all the time.
 
Indeed, it's a clear case of Sour Grapes.
Due to their network topology they cant use Port Forward, so Port Forward is bad and it's not needed anyways 😂
 
This indeed.
I never said it makes no difference - I said that port forwarding does not solve the problem. It might hide the problem from you, but might fail to hide the problem from those you instance with - but then there's nothing they can do, because the problem is still on your end but "there's nothing I can do - I've already set up port forwarding!"

Indeed, it's a clear case of Sour Grapes.
Due to their network topology they cant use Port Forward, so Port Forward is bad and it's not needed anyways 😂
"Sour grapes" is a weird way to spell "knowledge of networking protocol" - sounds more like the defenders of port forwarding are unwilling to hear that their "miracle cure" is actually perpetuating the problems by putting them out of sight for the only people who could make any adjustments that might actually improve things ;)
 
Back
Top Bottom