Can an ISP block port forwarding?

I have been trying to setup SoftEther for a while now but when I try to connect using TCP connection it is failing. So I tried to run a external scan to determine which ports are open and it seems all the ports which I have opened on my router for port forwarding is shown as closed. I was wondering could the ISP somehow disable port forwarding? If this is the case how can I verify it?

Running home OpenVPN server with ISP blocking port forwarding

--Edit 1--

This is done on the laptop running the VPN server. As you can see in the bottom port 5555 is open.

The image below is on the router which connects to the ISP. As you can see port 5555 is not showing

The screenshot below is for the port forwarding page in the router as you can see port 5555 is being forwarded. But I am not able to use any of the other ports which are forwarded as well. Also with turning off the firewall

However for example if I try to log on using a local IP I am able to log in but cannot log in when I try to log in from outside the network. My ISP says they are not blocking any ports.

Solution 1:

"Port forwarding" is the wrong thing to focus on. Port forwarding is done by your router, with packets that have already arrived at the router, and the ISP can't disable that – but what they can do is prevent the packets from reaching your router at all. If they do this, what your router would do with them is just irrelevant – it can't do anything with packets that never arrive.

There are two basic ways an ISP can prevent inbound connections from reaching you:

• By setting up a stateful firewall that only allows inbound packets that belong to an already "known" connection, i.e. only replies but not new connections. (Home routers typically also have the same kind of firewall, for protecting your home network. It's unusual to see it done ISP-wide but certainly not impossible, e.g. an LTE operator here puts you behind a firewall unless you pay for a "static IP address".)

• As a side effect of using Carrier-Grade NAT, in other words, simply not giving you a public IP address that you could receive the connections at. Due to the increasing scarcity of IPv4 addresses, many home and mobile ISPs have deployed CGNAT causing all customers to only have some form of "private" IP address.

Take a look at the "WAN IP address" shown by your router. Normally it should be a public IPv4 address – if it's not, that means your whole router is behind yet another layer of NAT, possibly ISP-level CGNAT. (Here keep in mind that 100.64.0.0/10 is also a private range, specifically for CGNAT.) If you have a router and a separate modem or ONT, the latter could also be acting as a router and doing NAT.

If the address is public, the next step is to somehow have your router itself tell you whether it's receiving the inbound packets. This really depends on what kind of router you have, e.g. some have a packet-logging feature in their firewall, OpenWRT-based routers might even have the tcpdump tool installed. (In most cases, unfortunately, you have nothing.)

Solution 2:

Your ISP can disable a port. That is, they can have a rule in their networking equipment which prevents packets destined for certain ports from reaching your router.

Port-forwarding is a behavior of your router which maps between an external facing port and an internal address and port. To the outside world, your port forwarding is invisible.

The only way your ISP can interfere with port forwarding is if your router is actually their router: a piece of equipment under their administrative control that they remotely manage.

Solution 3:

Not only CGNAT, but the ISP can technically force your endpoint to be client-only, e.g. block any TCP SYN 0 directed to your endpoint, or in case of UDP block all UDP messages if no UDP datagram was seen on the reverse direction first.

An aggressive ISP can technically implement this to prevent you from running any kind of server. In the era of HTTPS social media, little to no customers will ever care.