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.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
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 clients do not have public-facing IP addresses, nor public ports. Their routers do, but the clients don't know anything about those.
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 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 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.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.
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.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.
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 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 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.