Simple. You establish an outbound connection from your port 28967 to the storage node, on port 28968. The only port mapping happening is if SNO, for example, maps their WAN port 28968 to their internal LAN port number 30000 and then runs the node on port 30000 internally. Otherwise no port mapping.
Thatās not how ports work
Enlighten me. Congratulations on having a minimum of 20 characters to post.
For a direct connection, if you want to connect to a remote port 28968, that is the port that is used for the connection and so itās also your outbound port. If you want to change that there needs to be something in between that listens to port 28967 and forwards it to 28968 on the other end. And since the uplink makes direct connections to nodes, there is no such thing in between that can do that translation.
I guess you could set up an external proxy, which would put something in between. And Iām not sure itās possible to route traffic from uplink through a proxy. VPN is also an option. But regardless, there is no way Storj could solve this issue and maintain direct connections.
You need to realize that there are two ports here, there is a local port and there is a remote port. These two have nothing to do with each other and are usually different.
This is the normal way that connections are usually discriminated. You open a connection in your browser by connecting to the web server on port 80, this is the serverās port. Your port will be something different.
Ahh, I got ya. Weāve been misunderstanding each other. It may be true that the (usually) ephemeral port used on the client end is different than the port of the target server, thatās not the port firewalls block. They block based on targeted ports. So in this case the port the storagenode is listening on. Otherwise pretty much any outgoing TCP connection wouldnāt work as they tend to use ephemeral ports in the high ranges.
Exactly, thatās what Iāve been taking about. More advanced firewalls are very flexible and allow you to specify pretty much anything. I can filter outgoing connections based on the originating port but I havenāt had a reason to use it (yet). There might be a legitimate reason to do this in some high security settings. Whether this is a place to use Storj is another story. It shouldnāt be hard to add (just) this functionality to uplink, whether this breaks something because it needs to establish multiple connections to the same node simultaneously, I donāt know. This can be handled internally, however that might complicate things if it is the case.
Yes, but it seems thatās not the kind of filtering that @jammerdan has in place. And Iād argue that filtering based on originating ports would break almost everything.
Honestly if your network is that security sensitive you probably want to run a gateway outside of that firewall and connect to that using a known port. The gateway can then handle the connections to nodes. Of course if you host that gateway on a cloud platform you may run into the danger of having to pay for egress twice.
Well at least in my case not everything is broke, not even almost. In fact any other application is working on its specified port but Storj. And it turns out that the problem is not that up- or downloading on the standard port does not function (it does) itās more that in the long run access to the files once uploaded might get lost if due to background repair action or SNOs changing ports, the files are no longer available for download via standard port.
The problem is that Storj does not have a standard port. There is suggested port but nobody has to use it. This is a peer to peer network so all ports are available for use.
1 Like