Port_Restricted Router, even after Port Forwarding. Only game I've ever had this issue with.

Isn't it the case that once I have forwarded the port, any attacker/activity on this port is considered legitimate?

Depending on the NAT there may be other rules in place that further limit what goes through, but if nothing is listening, it doesn't matter either way.

I could open the last 60k ports on this system and there is nothing any attacker could do with them, in and of itself.

What does port forwarding to instancing?

It allows peers to be directly connectable. Without this the game has to rely on workarounds like relaying (STUN/TURN) which increases complexity and adds latency. Particularly restrictive connections will simply prevent a connection all together (denying instancing).
 
Thanks, that's the answer I needed. Also answers why I still see other commanders in Open. Good enough for my low interest in PvP and Open and, as I said, not worth the hassle.

If you have UPnP enabled, which is turned on by default on a lot of routers, apps may be dynamically forwarding the ports they need themselves. Otherwise, relaying is probably being used.

You can see some of what's going on in the network menu between sessions...it will show successful connections and connection attempts on IPv4 and IPv6, as well as if TURN was being used:
xGLrEcs.jpg


Regardless, peer connection quality impacts anyone that could potentially be instanced with that peer and has relevance well beyond PvP. If one isn't going to take basic steps to ensure they are a good peer, they should try to avoid being a peer at all by selecting a more appropriate mode; it's quite easy for bad peers to harm the experience for others.
 
I've also tried to fly with UPnP enabled too but I never saw anything else than Port_restricted.

'Port restricted' won't necessarily prevent connections and doesn't mean ports haven't been forwarded, though it can be problematic for multiple machines on the same network.

Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.

Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can send a packet to the internal host
only if the internal host had previously sent a packet to IP
address X.

Port Restricted Cone: A port restricted cone NAT is like a
restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP
address X and source port P, to the internal host only if the
internal host had previously sent a packet to IP address X and
port P.

It's less open than full cone and possibly indicative of an enhanced security setting in the router.

I probably wouldn't worry about it, unless you have multiple accounts/players using a single external IP or if you note there are an excessive number of relaying attempts or connection failures.

But when I look at your horrible ping time above, I don't quite buy in your "harming the experience for others" when not using any form of port forwarding in Open. I guess your ping time above is almost crying for rubber banding and as such has a lot more potential to harm other player's experience (and yours as well).

Have enough connections with peers and the ping will almost always be high because peers can potentially be anywhere. The game will reject peers that don't meet certain criteria, and I'm certain ping is one of them. The time stamp on the original image was 3am EST on a weeknight, right after a session at a CG, so the majority of my peers were not on the same continent.

As for rubber banding, this game has heavy client side prediction/latency compensation and seeing rubberbanding usually doesn't have much of anything to do with ping...though there are certainly other potential negative effects, which is one of the reason why relaying is less than ideal.

Ultimately, I cannot limit the ping of peers without apply geolocation rules, which may well lead to issues with connections being rejected in ways the game cannot predict.

Just checked. With the new router UPnP is detected at least - which is a progress? It still says PORT_RESTRICTED, PORT FORWARDING OFF and no entry in IPV4 VIA TURN:

View attachment 203819

If UPnP is working, you don't need manual port forwarding.

You won't see if there are connection issues to peers until your client tries to connect to peers. You can connect to Frontier fine, but that's the only connection attempts there have been. This is also why the ping listed is so low, it's the average of all connections; play with a few Australians and check back.

Btw, I have no access to the network page in game (while in Open mode). I have to go back to menu. Is this normal?

Yes. The network page only works after quitting out to the main menu. Not sure why that is...but it is.
 
Thanks. When using UPnP, do I still have to determine the port number (5100)? I was assuming not, if it's possible at all with UPnP.

I checked again and the answer is no. With UPnP I can't specify a port number.
One way to check it whether it works is using a UDP connection tool (such as: https://check-host.net/check-udp ) on your WAN IP address while the game is running in Open or Private. You should see a message like this in the netlog:
{17:17:57GMT 41.038s} packet of just 0 bits from IP4:<Test server IP>:<Test server port>,0
{17:17:57GMT 41.038s} ShortPacket

Thanks. I guess you have not seen my latest update, so here it's again:

When I start the game with UPnP active and then look at my router's admin page, I can see what port has been opened: it's UDP 52127.
Does this tell something to you? Is this working as intended?
Yes, that's the port ED chose to run on. Any incoming connection on that port is now forwarded to your game until the game is shut down.
 
When I start the game with UPnP active and then look at my router's admin page, I can see what port has been opened: it's UDP 52127.
Does this tell something to you? Is this working as intended?

I don't recognize the port, but UPnP can often use a random port, so that wouldn't be unusual. The game does use UDP and if the says the game in the description of that forwarded port, I think it's working as intended.

Issues, beyond the normal oddities with Frontier and their network moddel, usually only happen when people disable UPnP in their routers (a common security precaution) and/or in the game's config file, then don't manually forward any ports.
 
My (very limited) understanding is that manual port forwarding is more secure than UPnP. What do you think?

You certainly have more control over it. Random applications can't just ask the router to open ports for them.

I personally prefer to disable it and manually forward everything myself, but if you're careful about what's being run (easier said than done if there are multiple devices with a broad array of apps) UPnP is fine.
 
The FAQ for my router mentions that if my router connects to another router to gain access to the internet, Port Forwarding may not work for a couple possible reasons, including double-NAT going on. This brings up a couple of questions (and I won't include in this post the one about considering making a change to the network setup)...
1) Is there a way to make it work? (forward the relevant port number on both routers)
2) Is it then also true that UPnP won't function properly?
 
The FAQ for my router mentions that if my router connects to another router to gain access to the internet, Port Forwarding may not work for a couple possible reasons, including double-NAT going on. This brings up a couple of questions (and I won't include in this post the one about considering making a change to the network setup)...
1) Is there a way to make it work? (forward the relevant port number on both routers)
In case of Elite Dangerous, this is covered by the adjudicator. If instancing fails due to NAT, a reverse connection will be attempted (the instance host spanning outgoing connections). If that also fails (i.e. due to CGNAT/DSLite), IPv6 may be attempted, otherwise a TURN server hosted by Frontier will be used to relay it similar to how a VPN works. TURN might also be used if one CMDR supports IPv6 only while the other only supports IPv4.

2) Is it then also true that UPnP won't function properly?
UPnP can fail if a requested port for incoming connections is a) already in use, b) the UPnP request (port 1900) is either ignored or blocked or c) the last router before going into the internet doesn't support UPnP and/or has no static port mirroring (often the case with CGNAT/DSLite connections)

See also:
 
Last edited:
Thank you for the reply and references. It's a bit beyond my networking knowledge so it will take some work before I attempt to improve 'things.'.

The main reason that I asked isn't because things aren't working. As far as I can tell, things are working. I'd like to be a 'good neighbor' and not hamper the ability of the game to work well.

In a number of threads such as this, I often see remarks from players that they 'can see others but not as many as they should be able to see.' Whenever I see remarks like that, I always wonder: how can you tell?
I encounter other CMDRs in OPEN now and then (quite many when at Jameson, for example). If I send a greeting, which I usually do, I get responses. Using Jameson as an example once again, I don't get a response from everyone that I can see on my scanner (predictably). Ok, sot how am I supposed to know if I'm seeing everyone that's there?
 
@Morbad , if I have UPNP enabled but it still shows port restricted router type, will I still be able to host in an instance? If I decide to forward the port instead of using UPNP and it is still port restricted, will I be able to host? I've been trying to get a "full cone" NAT type and I'm running into difficulties. I thought I was doing fine just forwarding the port, but I guess "full cone" is the best? Does it matter if my internal IP is set by DHCP?
 
@Morbad , if I have UPNP enabled but it still shows port restricted router type, will I still be able to host in an instance? If I decide to forward the port instead of using UPNP and it is still port restricted, will I be able to host? I've been trying to get a "full cone" NAT type and I'm running into difficulties. I thought I was doing fine just forwarding the port, but I guess "full cone" is the best? Does it matter if my internal IP is set by DHCP?
I suggest using manual port forwarding, enabling the netlog and use a UDP port test tool to verify, one of these:

If it works, you should find this entry (or similar) in your log:
{17:17:57GMT 41.038s} packet of just 0 bits from IP4:<Test server IP>:<Test server port>,0
{17:17:57GMT 41.038s} ShortPacket
 
@Morbad , if I have UPNP enabled but it still shows port restricted router type, will I still be able to host in an instance? If I decide to forward the port instead of using UPNP and it is still port restricted, will I be able to host? I've been trying to get a "full cone" NAT type and I'm running into difficulties. I thought I was doing fine just forwarding the port, but I guess "full cone" is the best? Does it matter if my internal IP is set by DHCP?

Likely a firewall or lacking equipment that is in the way
 
I suggest using manual port forwarding, enabling the netlog and use a UDP port test tool to verify, one of these:

If it works, you should find this entry (or similar) in your log:
{17:17:57GMT 41.038s} packet of just 0 bits from IP4:<Test server IP>:<Test server port>,0
{17:17:57GMT 41.038s} ShortPacket
I just forwarded the port and used check-host.net and it shows "open or filtered" however on my own firewall's logs it shows result=DROP_INPUT. GRC shows the port as being in stealth mode. In game it still shows port_restricted but it does show my internal IP and external WAN ip correctly with the correct port. I believe I have some underlying security where I'm not able to easily enable full_cone. Like the OP, I'm not new to forwarding ports
 
In a number of threads such as this, I often see remarks from players that they 'can see others but not as many as they should be able to see.' Whenever I see remarks like that, I always wonder: how can you tell?

You can't, at least not with a high degree of confidence on a per encounter basis.

What you can do is pay attention to patterns. If you are in Open in a high traffic system that only has a few likely CMDR destinations and few people seem to be around, despite system chat being populated, something could well be interfering with instancing. Likewise, if you play for a while, then quit to main menu, you can look at your networking stats. In general, about half or more of your connection attempts should be successful, and the number of connections via TURN should be low. If you are seeing well under half of connection attempts succeed, or a number of connections via TURN that approaches standard connections, something is probably wrong. Only seeing TURN connections, or no connections, when there obviously should be, is also possible if there is a major issue.

Ok, sot how am I supposed to know if I'm seeing everyone that's there?

This would be even more of an approximation, unless you know the people involved and have good reason to expect them to be in your instance, or there are other oddities, like people who can see your CMDR, but you cannot see theirs, etc.

@Morbad , if I have UPNP enabled but it still shows port restricted router type, will I still be able to host in an instance? If I decide to forward the port instead of using UPNP and it is still port restricted, will I be able to host?

I want to say yes, but I don't know enough about how the matchmaking sever pairs peers to be confident in that answer. I expect that the game being able to check for this means it can compensate for it, but I'm not 100% on that.

As mentioned earlier, less than "full cone" requires your network to initiate connection with a given IP/port before being able to receive packets from that IP/port. This may potentially cause issues with hosting other "port restricted" peers.

I've been trying to get a "full cone" NAT type and I'm running into difficulties. I thought I was doing fine just forwarding the port, but I guess "full cone" is the best? Does it matter if my internal IP is set by DHCP?

Full cone should be the most connectable. It should not matter if your internal IP is set by DHCP or not, as long as ports are being forwarded to the correct IP.

I believe I have some underlying security where I'm not able to easily enable full_cone.

Many routers have NAT security settings that control this. What router are you using?

I suggest using manual port forwarding, enabling the netlog and use a UDP port test tool to verify, one of these:

If it works, you should find this entry (or similar) in your log:
{17:17:57GMT 41.038s} packet of just 0 bits from IP4:<Test server IP>:<Test server port>,0
{17:17:57GMT 41.038s} ShortPacket

Interestingly, I cannot get any web based port scanners to say my open ports are actually open, but the game client does correctly report connection attempts in the netlog when doing this.
 
It's a Linux based firewall appliance using iptables, essentially netfilter. It appears full cone may be a limitation of netfilter.

I did a search and came up with some conflicting information.

This individual claims that a full cone NAT can be achieved with iptables by adding a second rule: https://www.joewein.net/info/sw-iptables-full-cone-nat.htm

Others claim that you need a third party kernel module: https://github.com/Chion82/netfilter-full-cone-nat

Shouldn't be much work to test the first option to see if it's viable without further modification.
 
Back
Top Bottom