Not really as for most applications they have their specific outbound port to use. Right now it is only Storj that wants unrestricted access on all ports. Anything else runs fine under this setup.
I think for a network, where firewall control per device is naturally limited, it is not unsusual to restrict outgoing traffic generally.
As the firewall is not on the same machine permissions based on process will indeed not work and I am not going to completely open the network for unrestricted outbound access.
I wasnât saying you should. You could give your uplinks machine an exception and even block any other process on that machine. Itâs a bit more of a hassle, but it would get you to specifically only allow this process to make outbound connections to any port.
I guess that is too much of a hassle just for being able to upload to Storj. That is not worth it.
What I will do is to set it to use only the default port.
Nodes that use a different port are simply out of luck then.
Coming from the operator side, mentalities like this will lead operators to implement solutions that will seriously mess with your data placement. If I know that some of my nodes that are on the same IP address but use different external ports due to being on the same external IP address, then it would make more sense for my nodes to be using remote proxies and VPN tunnels so I can have more systems on the default port. This also results in them having IPs in different /24 subnets meaning that they will also not be competing for pieces to the detriment of your data residing on the same failure domain.
This is ultimately what it will come down to, just being open and honest about it. If that is an acceptable trade-off for not implementing network policies to support using Storj properly, then go for it.
I think that having completely restricted outgoing ports would be considered a fringe case. The majority of people who want to use the tardigrade service will have no outgoing port restrictions.
Itâs a waste of time for SNOs to optimize for this case as it will indeed be very fringe.
@jammerdan You can go this route, but youâll have to deal with the consequences yourself. The network ensures there are enough pieces to recreate your uploaded files, but it does not ensure there are enough pieces on nodes that use the default port. Over time after nodes change their setup or repair puts more and more pieces on nodes you didnât initially upload to, the chances of not enough pieces being available on default ports get higher and higher. And at some points certain segments may no longer be retrievable with your setup. You can still fix it at that time by opening the outgoing ports. Just keep in mind that itâs your own blocking thatâs causing these issues.
I think SNOs do that already to bypass the single ip limit.
I have not found any docs from Storj that said it would require specific network policies to make this service work. It should at least be stated that outbound connections to all ports must be allowed otherwise it could happen that you lose access to your files. I have never seen this written anywhere.
I donât know if that is a fringe case. The more clients you have on your network the more likely is it to deny all. Just think of the IOT devices and everything like that phoning home. In fact I have devices in the network that constantly want to connect to the outside on some proprietary ports. This is perfectly blocked with such a rule.
Thatâs true and it is a good point. But at the end Storj has to deal with the consequences: As a user who loses access to his files will no longer use this service.
I still think it is weird for not enforcing the default port. I mean there is all the regular internet services like http, https, ftp etc usually bound to standard port. Nobody would access websites if they would have to constantly switch to different ports. In fact an opening traffic on a single port 80 guarantees that I can access the majority of websites. Opening the default port for storj instead will guarantee successful uploads probably, but as you said it can happen that you lose access to your files when SNOs change their settings or repaid action takes place. I really donât know if that is wise to have SNOs and the network to make such a decision. I am not familiar with S3 but I read Storj compares itself a lot to it. Does S3 require opening all outbound ports as well?
All what would be required for Storj is a standard port like any normal internet service has. I think that should be the way it should be, not the other way around.
Itâs simply not possible. SNOs need the ability to use different ports in case something else is already using the default port or they run more than one node on a public IP. The comparison with S3 breaks down as youâre not connecting to a single end point but to each individual node. This is what makes it so fast. Though using the S3 gateway gives the client the same experience as S3 with a single port. The gateway itself still needs to be able to make outbound connections to all nodes.
But thatâs what I am saying. Nobody questions port 80 as standard port for http. You would not find a website owner running a webserver on some arbitrary port and then complain about not getting any visitors. This is how it should be. The standard port should be the rule and be enforced and if SNO need this port otherwise then they need to find ways to remain reachable. I mean at the end it is the customer who actually pays the SNOs not the other way around.
I will see if using the gateway could be a way to go but it remains weird. In the past I have been running all kinds of public services from Tor to Cryptonodes and this is the first one that requires an unrestricted access on all ports.
Itâs probably also the first one that makes connections to tons of independently managed nodes. Itâs inherent in the nature of decentralization. You can say that it shouldnât be that way, but youâre not providing any solutions to the scenarios I mentioned. Outbound ports are generally not blocked by default. And there are ways around that if you still want to manage it that way. All I can say is what impact it would have on using tardigrade.
Of course not, why should I? I am not the engineer of this.
All I am providing is my personal user perspective. And from that I can say, when it is advertised as S3 substituion but I have to change my network setup to use it or I risk losing my files, then I would rather stick with S3. At the end it is as simple as that.
I guess it would be possible to only use a standard port and either enforce one node per public IP or have a âproxyâ on standard port that serves all nodes behind that port. That would also make it harder for people to just use those VPN proxies to get around the IP filtering because then there are a lot less ip:port pairs.
However this would require quite some changes in the storagenode software.
I think there is a slight misunderstandment at work here. The exact SN port cannot and should not be enforced, because SNOs might have something else running on the default port. However, there should be nothing stopping the uplink from using only a single defined port on its side. This way you can still filter outgoing traffic by local port, while allowing Storj traffic to go through.
I do not know if there are any issues with this from Storj protocolâs perspective but this should be the correct solution. Assuming, of course, the uplink does not need multiple simultaneous connections to the same SN and itâs currently being handled by using different local ports. I donât know the exact way Storj works but Iâm sure thereâs people here who can enlighten us in this aspect.
If Iâm not mistaken, bittorrent clients usually have this exact configuration available.
The default behavior of any tool to connect to the service is to use a random local port for outgoing connection. I donât remember any tool which can work with only one outgoing port.
Even bittorent uses a different local outgoing ports to establish connection. But it can use the one target port, if the other side is ready to listen it.
The author wants exactly this feature, which will limit all storagenodes to one default port, that is, only one node on the IP.
The first part of your post is not compatible with the second part. Since the uplink connects directly to the storagenode a it transacts with, it by definition has to connect to the port they are using. There is nothing in between that can do any port translation. This is what makes transfers so fast. Multiple direct connections to independent nodes serve the data simultaneously.
Your reply is not compatible with my mine! Uplink would still connect directly to the storage node on a precisely defined port. There is no port translation. Only difference is that the uplink operator would be able to choose their own port. This would cause all traffic to be funneled through a single port, thereby complying with firewalls that have outbound rules.
So, lets say I run my uplink exclusively on port 28967 outbound and only allow that port. I want to directly connect to a node listening on port 28968. How do you suppose my outbound request ends up at that different port number without doing any port mapping in between?
