Are the ISPs justified in blocking reserved ports for dynamic IP consumers?

  • Thread starter Thread starter shrenik
  • Start date Start date
  • Replies Replies 10
  • Views Views 1,141
Messages
11
Location
Kolkata
ISP
Airtel
Is anyone aware of a contract term, that we sign with the ISP while ordering our connection, or a govt body guideline(s) that states that the ISPs are well within their rights to block reserved ports like 80, 443, 23 and may be some others too?

I have a dynamic IP and these ports are blocked. I have read multiple posts where some static IP users are also complaining about the same.

It is akin to the corporation supplying water to your house and then forcing you to only use it for bathing and not filtering and drinking because they would like to up-sell/cross-sell bottled drinking water to you separately.

This seems a sinister tactic to up-sell the static IP. IMO, this is so regressive a thought given that IPv4 addresses are already in short supply and should not be wasted upon home users most of whom can safely make do with dynamic dns services on a dynamic IP.

Key question: Doesn't this curb our freedom of using the internet as we would like within the legal realms of the law of the land?

I am trying to battle this out with my ISP.

The experience and progress thus far over the last 2+ months -
1. The ground level engineers think the ports should be open, hence they try with all their might to test everything and prove it to you. They and their managers are surprised when they realize that the ports are indeed blocked. Some engineers are using some local cable internet at their own residence and they have found that their ISP doesn't block the ports.
2. When escalated to NOC level, the engineering team there also try their might to check everything and eventually say that they don't support this feature on dynamic IP. They too are surprised that some reserved ports are blocked. Then they suggest that I purchase a static IP.
3. Upon escalation with the appellate authorities and persisting with them for around 2 months, someone from the "backend" team from Gurgaon calls and he too tries a lot of configuration combinations so that the ports can be opened but fails and eventually gives up. So it is beyond "backend's" control as well. But no one upfront had a negative answer for me, which also means that they were completely unaware of this limitation that has been systemically imposed upon us.
4. Eventually Kolkata circle team tells Appellate that "as per Airtel policy" they don't support opening of ports on dynamic IPs and only when I chase Appellate again, do they verbally convey the same to me. No one ever responds to my queries over emails apart from a stereotype/automated acknowledgement that lands up in my mailbox within a few hours of my sending the n'th mail to nodal, appellate and 121 id. When I quizzed the Appellate authorities about sharing the "Airtel policy" or the "contract terms" or any "govt authority's directive", they were clueless and they told that they shall dig through their ranks again and revert to me by next Wednesday.

What has been your battle experience in this regard? Do you think we should raise our voice in this regard?
 
How did you came to conclusion that these ports are blocked? Tried port forwarding?
If yes then are you sure the downstream device listening on that port?
 
@Trex Have configured the server machine to be accessed via DMZ. I have a pro setup with firewall and apache webserver, etc, that used to be accessible earlier and one fine day when I was traveling I realized that the services that were accessible are not longer so.
 
This is not sufficient. Please test it properly, absolutely make sure it's not a config issue or a issue in the router at your end before making posts like this.
 
@ishanjain28 Why is this not sufficient?

I'll try to explain in some detail.

ISP ZTE Router -> DMZ configured to pass on all incoming requests to the Linux server -> Linux server which is also my gateway/firewall server with Apache configured and services available on port 80 and 443 which are accessible over LAN and incoming firewall port 80 and 443 open.

And as I have said, this setup was working earlier and some odd day it stopped working which definitely seems to have been triggered by some config change at the backend because nothing has changed in my configuration for years.

And again as I have mentioned in the original post that this setup and one also with Windows with IIS server that was specifically setup upon request of Airtel engineer who was not confident working with Linux, was tested thoroughly by not only one but multiple Airtel engineers, at my site and via remote access.

They even tried replacing the ZTE router device with one from Nokia because in the ZTE device there is an explicit configuration of Remote Service ports where port 80, 443, 21 and 23 are configured. Those can be changed but still it did not work. But I have confirmed that despite these settings, FTP port 21 is accessible when I open the same in my incoming firewall. That is also a confirmation that my setup indeed does work.

There are other reserved (for e.g. 81 serving a webadmin service, SSH - 22) and non-reserved ports (OpenVPN, etc) as well on which I am able to access the respective services. It is just ports 80, 443 and 23 that I found to be blocked as these were needed by me.
 
DigitalOcean (and Linode etc ) block smtp port 25 to prevent email spam. you have to request it and verify you are legit.


i think there are safety reasons to keep some of these lower ports closed (<2000). these are constantly scanned by bots to look for vulnerabilities. once i opened my passworded router ssh port for like 10 seconds and there were already two requests trying to login as root.
 
@Trex Yes. Details in the previous post.

But are reserved ports 80 and 443 open for anyone in this forum on a dynamic IP?

I have read several posts wherein they have all stated that it doesn't work. So why are we discussing about the configuration? If these incoming ports were working for anyone over a dynamic IP, then there is a case to further scrutinize the configuration. :)
 
Back