Firewalls should reply with an ICMP message when they block a request. However, this is not necessarily the case (you will be interested in this nice article).
You can test from the outside to see whether a port is accessible through a firewall and, if so, whether anything is listening on it. Here's three different scenarios involving a tcp request which you can observe with
wireshark, or some other packet sniffer, and what you'll see:
1) Firewall rejects request
You get an ICMP message back, and the tool making the request should immediately tell you something to this effect ("unreachable, admin prohibited" etc). By "tool" I mean the client you are using to send the request (I used
"No route to host" may indicate this, but it may also indicate more subtle routing issues.
2) Firewall drops packet
There is no reply, so the tool waits until it times out or you get bored.
3) Firewall allows packet (or there is no firewall), but nothing is listening on the port.
You get a TCP RST/ACK message back. I presume the TCP protocol requires this. In other words, if nothing is listening on the port, the OS itself sends this reply. It may be difficult to distinguish this from #1 just based on what a tool reports, because it may say the same thing in both cases (however, most probably do distinguish this as "connection refused" vs. #1, "network unreachable"). Observed in a packet sniffer on the client machine, scenario #1 (ICMP reject message) and #3 (TCP RST/ACK message) are clearly distinct.
The only other option here is that the packet is allowed through by the firewall and something is listening, so you get a successful connection.
In other words: presuming your networking in general works properly, if you get #1 or #2, it means a firewall is actively preventing access to the port. #3 will happen if your server is not running but the port is accessible, and of course (the implicit) #4 is a successful connection.