How to detect if a network is blocking outgoing ports?

How do I confirm if my network is blocking outgoing ports?

I'm having issues accessing services on servers running on ports other than port 80 and 443. For example, I cannot ssh into any of my servers where ssh is running on ports 22, 2222, 32415, etc.

Moreover, other programs that I need for work are failing, such as openvpn.

Ideally, I'd like to determine a list of the ports that the network is not blocking.

I'm on a public access point at a library.

Solution 1:

tl;dr

Run this command to test a specific port (fast).

time nmap -p 22 portquiz.net

Run this command to test popular ports (slow).

time nmap portquiz.net

Run this command to test all ports (extremely slow).

time nmap -p- portquiz.net | grep -i open

Source: https://tech.michaelaltfield.net/2018/07/03/detect-outgoing-port-blocking-with-nmap-and-portquiz-net/

Solution Explained

To test if a given outgoing port is blocked on your network by some malicious middlebox, you can try to telnet into a server that has a service running on that port.

In this example, we use portquiz.net--which is a public service designed for this purpose. It uses iptables' nat table and has all tcp ports open.

# first we verify that we _can_ connect over port 443, which >99% of
# networks won't block; it works
user@personal:~$ time echo 'exit' | telnet portquiz.net 443
Trying 178.33.250.62...
Connected to portquiz.net.
Escape character is '^]'.
Connection closed by foreign host.

real    0m0.069s
user    0m0.002s
sys 0m0.043s
user@personal:~$ 

# next we try to connect over a port that's suspected of being blocked; it fails
user@personal:~$ time echo 'exit' | telnet portquiz.net 22
Trying 178.33.250.62...
telnet: Unable to connect to remote host: Connection timed out

real    2m10.635s
user    0m0.004s
sys 0m0.035s
user@personal:~$ 

Note that the first command exited immediately with the message Connected to portquiz.net, which indicates that the outgoing port 443 is not being blocked by the network.

The second command, however, says Unable to connect to remote host: Connection timed out. This shows that--unless there's an issue at portquiz.net--the outgoing port 22 is probably being blocked on your network.

You can take this a step further using nmap to get a list of all the ports that are not blocked by the network. For example:

user@personal:~$ time nmap -p- portquiz.net | grep -i open
21/tcp   open   ftp
53/tcp   open   domain
80/tcp   open   http
143/tcp  open   imap
443/tcp  open   https
465/tcp  open   smtps
587/tcp  open   submission
993/tcp  open   imaps
1935/tcp open   rtmp
4070/tcp open   unknown
 
real    3m48.324s
user    0m18.885s
sys 0m29.077s
user@personal:~$ 

In the above command, we can see that all outgoing ports are blocked except 21, 53, 80, 143, 443, 465, 587, 993, 1935, and 4070. In a normal/uncensored network, this list would be much, much longer (probably showing all 65535 ports)

Solution 2:

This question is a bit vague and thus difficult to answer - and ironically something I hit my head against this morning. It is impossible to fully do this without the help of your ISP.

The first thing to do is to check your router is allowing all this through - that is the default state for a typical SOHO router though. Depending on your router, you might be able to run tcpdump on it looking at the external interface (eg if its running dd-wrt) and see if packets are leaving your network. If you can't do this, your options are very limited here - a switched on ISP may be able to tell you if they are seeing the packets entering their network - but I would not expect this for your run-of-the-mill home user connection. Alternatively if you can disconnect everything extraneous from your network, you MIGHT be able to get a hint of if traffic is leaving it based on the PPP Interface packet count, or looking at the lights flashing on the modem/router when you attempt to make connections.

Next, if you are able to get onto a server/virtual server which you know is not having connectivity issues, and which has its own "real" IP address or is answering on the server, you can log into that remote box and use tcpdump on the interface to check if it is receiving packets from your machine. If not, then packets are being dropped - if they are being received, then it could be a firewall or issue on the return path.

If you have access to a remote (unfirewalled) server you can do a tcpdump on it while using nmap or netcat to generate traffic to that server and seeing what tcpdump sees.