Is there a way to see what is actually filtering TCP port communication?

Solution 1:

Nmap provides several ways to get more information about what is causing the filtering:

• The --reason option will show the type of response that caused the "filtered" port state. This could be "no-response" or "admin-prohibited" or something else.
• The TTL of response packets is reported in the XML output as the reason_ttl attribute of the state element for the port. If the TTL for a filtered port is different from (usually greater than) the TTL for open ports, then the difference between the TTLs is the network distance between the target and the filtering device. There are exceptions, such as targets which use different initial TTLs for ICMP vs TCP packets, or a filtering device that falsifies or overwrites TTL information.
• The --traceroute function will show information about hops along your route, any of which could be filtering your traffic. In some cases, the reverse DNS name for one of the hops will even be something like "firewall1.example.com"
• The firewalk NSE script will send packets with initial TTLs that will time out at different hops along the route in an attempt to find where the packets are being blocked. This is something like a combination of the previous two techniques, and usually works quite well.

The currently-unreleased development version of Nmap also reports TTL for response packets in the normal text output with the -v --reason options. For now, though, you have to use the XML output to get this information.

EDITED TO ADD: Nmap 6.49BETA1 was the first release to show TTL for response packets in text output with -v --reason or -vv, and was released in June 2015.

Solution 2:

This is what the nmap docs say about the filtered state

filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software...

The only way to find out what is doing the filtering is to know what 'machines' are between you and the remote target.

This can be achieved using a route trace utility, which attempts to determine hosts between you and the target using special TCP packets. In your case the command might look something like:

traceroute 10.1.1.1

Once you know the machines between you and the target, you investigate the configuration of each to find out if it is filtering and if so how.

---

Solution 3:

Short answer - No, there is no way that you can see it.

Longer answer:

From: https://nmap.org/book/man-port-scanning-basics.html

"filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically."

You can try discover network topology with tools like traceroute. Usually ports are filtered on the host it self (i.e. ip tables), target network edge router, target network core router or top of the rack L3 switch.

If you are in the same subnet as target host almost for sure firewall is on target machine.

---

Solution 4:

Try comparing a result of tcptrace to one of the filtered ports with a tcptrace to an open port (or a standard traceroute). If the tcptraces are the same it means that there's something on the destination machine filtering the ports.

Update: I meant tcptraceroute, I have it aliased.