UPnP? Are you serious!
https://www.grc.com/unpnp/unpnp.htm
http://www.ghacks.net/2013/02/12/test-if-your-routers-upnp-is-exposed-to-the-internet/
So no no UPnP for me thank you.

The way Ashes of the Singularity connects to other plays is the same as Elite: Dangerous does but you can set a port in the config for that game so I can firewall the setup. I will check again to be sure if the game connects to a dedicated server but I believe this game only connects to the server as a relay for you to connect to other players directly. 

Really its this simple make the game use a fixed source port or have the game use a range of ports for the game to use like 49200-49205, 59200-59205, 62200-62205 for a source port to connect from to other players/server so you only have to firewall 15 ports for UDP and not allow 49152 to 65535. This way of doing it also address different types of NAT for better support.  

As usual, the problem isn't necessarily the protocol but the implementation. Nonetheless if games are indeed moving away from UPnP fine, but they need to replace it with something that will work for the common user. FYI the common user doesn't know how to tweak their router for port forwarding, the most common scenario. Im not opposed to your suggestion, in fact I welcome it. But it is a solution for few people.

For the record you are misusing the "source" in "source port". In TCP and UDP communication the source port is generally a randomly selected ephemeral port (>= 1024).  Firewalls tend not to care what source port is used to establish communication as long as it is in the ephemeral range. What you probably mean is "service port". That is the port your computer is listening on and the port to which your firewall must be configured to forward.

That said I agree with restricting the port range more. If you need to establish communication with every node in a multiplayer match (complete graph), you need up to 12 ports, probably. To reduce conflicts with other applications, maybe a range of 100 ports makes more sense.

Even though your terminology is a little wonky, your point comes across fine. We don't need more than 100 ports, and more than that creates a hassle for firewall configuration. They probably won't tweak these ports until they start to really devote time to multiplayer in beta 2. I am in favor of legacyone's suggestion.

The reason I question your focus on the word "source" is that it confuses things. Firewalls generally don't care what the source port of a particular packet is, they usually care about the destination port. For example, when I set up port forwarding on my Comcast router, I specify the destination port, the one my inside system is listening on, not the source ports for any inbound packets. Furthermore, if you are behind a NAT, the NAT router is free to change the source port on packets headed outbound in order to ensure connections for two different inside hosts aren't confused. So the more accurate way to express what you are saying is "service port", "destination port", or just "port". "Source port" is definitely wrong.

The firewall rules that typical home routers will implement look like:

allow UDP any >=1024 -> IP1 20000-20100

Notice the source port is ephemeral. Restricting the source ports in such firewall rules is going to cause trouble, especially if the other end is using a NAT.

Your not getting how UDP Traversal works yes T-r-a-v-e-r-s-a-l so help me I will teach you.

Steam can't do anything their end its got to be done in the game.

Let starts with something simple like DNS and clear your mind of the vulnerability (by that I mean the DNS ones when we send gaming traffic by this) and keep a open mind as to what is a client and what is a server because with UDP Traversal it solves that.

Also to keep it simple no NAT just a firewall and the rules are outgoing UDP port 53, 3478 and 20000-20100

Two clients IP1 1.1.1.1 IP 2 2.2.2.2 and a server IP 3.3.3.3

The clients have DNS port 53 listening and each client wants to connect to each other now let us say the source port used for IP1 is 20000 and IP2 is 20033.

IP1 1.1.1.1 source port 20000 > IP2 2.2.2.2 = remote port 53 lookup google.com
IP2 2.2.2.2 source port 20033 > IP2 1.1.1.1 = remote port 53 lookup google.com

Yes it does not work because of the firewall WAIT there is more keep reading.

So how can we without making any more firewall rules get the other to reply on outgoing rules? The answer UDP Traversal.

So each  client connects to the server on port 3478 and the source port does not matter for that so here is what happens.

IP1 1.1.1.1 source port 59001 > IP3 3.3.3.3 remote port 3478 = my source port is 20000 tell IP2 at 2.2.2.2
IP2 2.2.2.2 source port 56777 > IP3 3.3.3.3 remote port 3478 = my source port is 20033 tell IP1 1.1.1.1

firewall state of outgoing that is allowed in because of the above made by IP1
IP3 3.3.3.3 source port 3478 > IP1 1.1.1.1 remote port 59001 = source port for IP2 2.2.2.2 is port 20033

firewall state of outgoing that is allowed in because of the above made by IP2
IP3 3.3.3.3 source port 3478 > IP2 2.2.2.2 remote port 56777 = source port for IP1 1.1.1.1 is port 20000

So each client now knows the source port of each other but how does that help us watch.

firewall state of outgoing for UDP
IP1 1.1.1.1 source port 53 > IP2 2.2.2.2 = remote port 20033 = Punch!
blocked by firewall at IP2 2.2.2.2 WAIT keep going there is more and it is where it gets interesting.

Then IP2 tries to do the lookup at IP1
firewall state of outgoing for UDP
IP2 2.2.2.2 source port 20033 > IP1 1.1.1.1 = remote port 53 lookup google.com
ALLOWED by IP1 1.1.1.1 under the firewall state of outgoing to allow IN because of the above connection made by IP1

firewall state of outgoing for UDP
IP2 2.2.2.2 source port 53 > IP1 1.1.1.1 = remote port 20000 = Punch!
blocked by firewall at IP1 1.1.1.1

Then IP1 tries to do the lookup at IP2
firewall state of outgoing for UDP
IP1 1.1.1.1 source port 20000 > IP2 2.2.2.2 = remote port 53 lookup google.com
ALLOWED by IP2 2.2.2.2 under the firewall state of outgoing to allow IN because of the above connection made by IP2.

So now do you see how UDP Traversal works by the source port because thats whats clever about it.

Edit wrong source port listing fixed! typo

Whats the point in having a firewall if I'm going to have to allow 49152 to 65535 all out (or it would work all IN too) if not more for UDP I just don't see the point in a connection method thats all over the place I can not think why it even needs to be a mess in the first place when there are ways of doing it simpler to achieve the same goal.

UPnP will not help the idea of UDP Traversal is to not need port forwarding but lets say I would be happy to do port forwarding the problem is their is no way to know what port that might be it can be  49152 to 65535.

Not going to work its what the game uses as a source port.

You clearly don't get when you say while keeping your current "high security" setup lets do doubt NAT connect my PC to a dumb NAT with UPnP then connect that to my "high security" setup....how do a firewall what the dumb NAT with UPnP is doing on my "high security" setup? I can't I would have to allow incoming 49152 to 65535 UDP.

For crying out load there is a simple bloody fix and Elite: Dangerous a game that uses the same connection method has a fix for this for making it firewall friendly its been done, its been proven will you care about security to add the option in you game please?

Yes, Ashes uses the Steam API for its network layer. If you want fixed UDP support you'll need to talk to Valve about it.

As for my security suggestion I was saying:

1. Get a second IP from your ISP.
2. Put a second router on your Internet connection using the second IP.
3. Enable UPnP on the second router.
4. Switch your computer to the second router's network when you want to play games.

The reason I suggested this is because - bluntly - what you're asking for is unlikely to be addressed by most developers. To use an analogy, rather than fighting the current I'm trying to give you a way to swim with it safely.

Best of luck whatever you decide!

Other developers can use the Steam API in other ways; for example using Steam lobbies but their own network stack. Some developers don't use Steam's API at all for multiplayer games and have their own network code. I suspect that's why there's confusion about how Steam networking works and who's responsible for selecting port numbers.

-Adrian

When I have an opportunity to suggest to Valve that the Steam network API could be improved for the small percentage of their customers who refuse all of the above answers I will do so. I don't think Valve will prioritize the change. If you want to play Ashes (or any of the vast number of other Steam games using the Steam network API) consider how to live with one of the above solutions or come up with another way.

Best of luck!

-Adrian

If there's nothing listening on those UDP ports on your computer there's minimal risk to having them forwarded. Many other non-gaming applications (video chat apps for example) use that port range for certain features so it's not just games that benefit from having that port range forwarded. The only concern I'd have is that an application I didn't realize was listening would be able to use those ports. If that's a concern an application (outbound) firewall on the computer is a more thorough solution anyway.

Once again, if the second option bothers you I offered the 3rd choice of a separate gaming network as well. I think we're going in circles at this point so I'm bowing out of the conversation.

-Adrian

legacyone, from which native language are you translating, and which translation service? The wording is coming out grumpy so you might want to explore a different happier translation service?

There is a point to what you are saying in applicability to IPv6. NAT is not the preferred addressing solution for IPv6, which will make all devices Internet addressable, requiring an actual firewall to protect them. In that case Valve and game devs are going to have to rethink things by necessity. I'm guessing we are still years away from that, though.