Important Multi-player connecting requirement please.

Most games utilize UPnP to open firewall holes since most home routers can do UPnP. Are you saying your config cannot do this?

Also, I thought games were hosted on dedicated servers, but your post implies the dedicated servers are just for creating matches. Stardock/Oxide, what are your intentions?

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.  

Just did a test and I do think this game does try to connect you directly to the player (someone on a comcast IP I was sending traffic on a random source port the game picked to their random port and they where trying to connect to my random source port from their port) and the ports are a mess their really needs to be this option of a fixed source port or set range of ports for a source port for the game to use based on the Session Traversal Utilities for NAT (STUN) or Simple Traversal of (UDP) Through NAT (STUN) to work better.

However their seems to be a backup connection which I have not allowed yet where it goes to a VALVE IP range on remote ports 4379-4380 UDP (which might be random not sure yet) likely as a packet relay backup should connecting directly to the player fail.

With the way its being done now port forwarding would not help you would have to DMZ that how bad this method is on a given NAT type they really are not changing much to make this work even for NAT type thats would not need port forwarding on a all open outgoing UDP firewall by just limiting game to use a fixed source port or set range of ports for a source port and then you can firewall because I know with Elite: Dangerous the only way I could get that to work is by allowing all UDP ports but because you can set the source port I only have to allow that port on a firewall.

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.

So Devs pretty, pretty please.

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.

The source port is the port the other player will try to connect too you can read my post on how UDP Traversal works.
http://steamcommunity.com/app/228880/discussions/2/496880203079122049/
 

With UDP you don't need a port per player this applies to well behaved NAT but NAT types that don't behaved well with a fixed source port range and this does apply to random ones too you can port forward just that range and not 49152 to 65535 if on win 7 and in win XP its 1024 to 5000 and that will get around NAT problems some people may have with UDP Traversal.

 

On one fixed UDP port say 20000 with say 5 other players using that same source port this happens and works.

IP 1 source port 20000 > IP2 remote port 20000
IP 1 source port 20000 > IP3 remote port 20000
IP 1 source port 20000 > IP4 remote port 20000
IP 1 source port 20000 > IP5 remote port 20000
IP 1 source port 20000 > IP6 remote port 20000

IP 2 source port 20000 > IP1 remote port 20000
IP 2 source port 20000 > IP3 remote port 20000
IP 2 source port 20000 > IP4 remote port 20000
IP 2 source port 20000 > IP5 remote port 20000
IP 2 source port 20000 > IP6 remote port 20000

and so on...

Its UDP and with UDP you can send and receive to and from any other IP on one port.

Now if you can do a fixed source port range of say 20000-20100 I will be happy with that because then thats all I need to firewall so this happens.

IP 1 source port 20000 > IP2 remote port 20033
IP 1 source port 20000 > IP3 remote port 20044
IP 1 source port 20000 > IP4 remote port 20055
IP 1 source port 20000 > IP5 remote port 20066
IP 1 source port 20000 > IP6 remote port 20077

IP 2 source port 20033 > IP1 remote port 20000
IP 2 source port 20033 > IP3 remote port 20044
IP 2 source port 20033 > IP4 remote port 20055
IP 2 source port 20033 > IP5 remote port 20066
IP 2 source port 20033 > IP6 remote port 20077

and so on...

Thanks

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.

 

 

I'm pretty sure we just call Steamworks and they do their thing. This would be a Valve request.

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

I've been schooled. Thanks for the lesson. I'm usually in TCP-land where this wouldn't work. You mixed up the ports in a section in the middle, but I knew what you meant.

Now say again why the ports have to be restricted? Does your firewall restrict the destination port on outbound UDP packets? Because from your description you can punch holes for arbitrary ports. Holes are punched from inside on the reverse path, and most consumer firewalls don't restrict which ports those can be. Perhaps you're not talking about consumer firewalls. I'd guess most corporate networks are not going to allow outbound UDP packets on 100 ports, let alone thousands. Mine wouldn't.

Also, have you confirmed that Ashes/Steam definitely uses the hole punching method instead of UPnP? Or are you just requesting that it be a supported method?

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.

Here's some specifics from Valve on what ports are required for Steam's networking to function:

Link

I'm security minded as well so I sympathize with what you're trying to accomplish. Unfortunately UPnP is the standard almost every game expects to have available. One solution would be to get a second IP from your ISP and put a separate "low security" router in place where you enable UPnP while keeping your current "high security" setup.

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?

Legacyone, he seems to be saying Ashes uses the Steam connection methodology. If you want to complain to someone about the insecurity of UPnP, maybe you should complain to Valve and ask them to implement UDP traversal. Then Ashes would support it.

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!

Its not Valve problem the game sends the port to Valve wait...let me say that again The Game Sends The Port To The Valve Server...am I make that clear there is nothing, Nothing, NoThInG Valve can do the Game setup the port.

 

Yes we get it now why do you think Elite: Dangerous that uses the same connection method has a option in the game config to set a fixed port?

 

I mean come bloody on your posting without checking how the connection method works because saying a lie here and now will show you didn't check.

Using the Steam API, games can simply say "Send this data to this Steam ID". Networking details - IP addresses, NAT traversal, TCP, UDP, and port numbers - are completely abstracted from the developer. It is very convenient so this is how we (and many other developers) handle multiplayer via Steam. Using this method the source and destination port are randomly selected by Steam's API code within the range specified in the Steam networking document I referenced earlier.

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

 

Fine Steam API is limited (putting it nicely) I could use netsh int ipv4 set dynamicport udp to limit the port range to not lets just use any port 49152- 65535 when you can do that with changes to API for that app you say can't do a range can't do a fixed port in the API you added in your game.

 

And you want me to explain this to Valve...they are not interested in what I think, I have to go through the game dev for you to ask them they are interested in what you have to say about the API you use in your game.

 

So sorry stuff is never done right its why we can't have nice things because its not down to people like me it is the order of things along with ones ability and the position your in to ack or be listened to.

You decided you don't want to use UPnP, the standard solution for this sort of thing. Furthermore you decided you won't forward the UDP ports to your computer, which is the standard backup solution. Finally, you don't want to create a second, less secure network for network gaming. It's unfortunate that none of these proposals is what you want.

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

Got you. I said YeSe lets Quote me “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.” HaPpY or do you think port forwarding 49152 to 65535 UDP ports IN is in a word acceptable to you? For a game? please say yes I want everyone to hear it or read it.

 

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

 

I don't know how long you been captured for when the internet was moving forward and you are trying to take a interest in thinking you have the solution and its that easy and security was not a thing back then, but its 2015 it is a god dam blessing to have one WAN IP so bring yourself up to speed with todays problems will you please the past does not apply to the here and now.

 

And what you seem to think I don't know which I do is let say I did get Valve to make changes and add a option it still does not help me or anyone else because you got to add the option in the game for me and anyone else which will you? Or dare I say give me a straight answer? Even when you asked me to ask Valve for this option regardless of them doing it you regardless at any point do not have to add the option for me or anyone else to use it.

 

But none of that matters because you know as I'm sure others are thinking that Valve is on the low end of listening to me vs the game dev and thats all there is to it.

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.

Nope this problem has nothing to do with IPv6 its about how UDP Traversal works the fact that the people who came up with it knew how it could be made firewall friendly and gets ignored by one implementing it without the options that is past to the game dev using that implementation that is then pasted to all of us. Like I said Valve is on the low end of listening to me or others vs the game dev using that implementation.