A particular port on my home raspberry pi results closed if connecting from external wifi, open when using my phone data, any explanation/workaround?

I have a raspberry pi at home and I have a small djangorest application running on it, very simple stuff for my personal use.

Today I wanted to access my pi from the library (using their public wifi, if at all important) and I couldn't; I then decided to switch to my phone data via tethering and it worked again.

I ran tests on nmap and the results confirmed what I just described.

Using wifi:

PORT     STATE    SERVICE
3000/tcp filtered sae-urn

While on tethering:

PORT     STATE SERVICE
3000/tcp open  sae-urn

I'm not very familiar with nmap and I was wondering whether that "filtered" meant that the firewall on my current network is filtering the connection or the firewall on the raspberry pi is filtering it.

Is there any possible workaround?

edit:

I also tried with a good old ping command and this is the result (while connected to wifi):

ping myip -p 3000
PATTERN: 0x3000
PING myip (myip) 56(84) bytes of data.
64 bytes from myip: icmp_seq=1 ttl=56 time=4.28 ms
64 bytes from myip: icmp_seq=2 ttl=56 time=4.33 ms
64 bytes from myip: icmp_seq=3 ttl=56 time=2.77 ms
64 bytes from myip: icmp_seq=4 ttl=56 time=3.82 ms

Solution 1:

I'm not very familiar with nmap and I was wondering whether that "filtered" meant that the firewall on my current network is filtering the connection or the firewall on the raspberry pi is filtering it.

"Filtered" only means the probes were completely ignored, with no response. ( If you run nmap with the --reason option , it will tell you roughly the same.) It doesn't really tell you where the connection attempts got blocked – it could really be anywhere along the path.

Now, public Wi-Fi networks (e.g. libraries, schools) very frequently block all uncommon ports (e.g. to discourage people from running BitTorrent there), so you can safely assume that's where the problem is.

The workaround is to use a more common port. For example, if it's a webapp, run it on the standard HTTPS port 443, if your home ISP allows that. (You can use Apache/Nginx in 'reverse proxy' mode to multiplex several webapps on the same port.)

However, if you were to guess purely from nmap's output, then it could be that the Pi's firewall is dropping them (unlikely if it works via tethering, but nevertheless technically possible), and it could be that your home router is dropping them (same), and it could be that the library's ISP is blocking the packets (this may happen with certain "commonly misused" ports), and it could be that your home ISP is unable to get any packets from the library's ISP, and it could be that the Pi receives your probes but the responses aren't getting through... In other words, a plain nmap scan doesn't give you enough information to locate the problem.

A traceroute program might provide more information, if you can tell it to specifically use TCP probes on this port (instead of the usual ICMP), such as traceroute --tcp --port=3000.

(Nmap has its own --traceroute option, but unfortunately it doesn't seem to have a way to specify the port used for traceroute probes, ignoring even the -p specification.)