Jump to content
Sign in to follow this  

Test firewall not blocking traffic



In the environment I work in we have multiple firewalls in a path so the likely of your traffic being blocked is high.  Most of us use to troubleshoot using telnet which has many many flaws and not a great method of testing but it was all we had.

Here is an example of testing using telnet

telnet: Name or service not known Unknown host

The telnet results don't really give you anything to tell you if its successful or not. 

Then I discovered at a young age the power of nmap (which is probably why it was quickly blocked in most companys)

Here is an example of testing using nmap

nmap -p 80

Starting Nmap 6.40 ( http://nmap.org ) at 2019-07-10 10:58 EDT
Nmap scan report for wildweaselmi.thezah.com (
Host is up (0.000053s latency).
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

Just so you can see what it looks like to see a closed port

nmap -p 443

Starting Nmap 6.40 ( http://nmap.org ) at 2019-07-10 11:04 EDT
Nmap scan report for wildweaselmi.thezah.com (
Host is up (0.000047s latency).
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

nmap is super quick and very easy to use to get accurate results but it was quickly blocked by corporate security and is no longer an acceptable tool.


In researching I discovered what most people use which is netcat.

Here is an example of the same test using netcat

nc -zv 80
Connection to 80 port [tcp/http] succeeded!

Its very clear that port 80 is open on

And for clarity sake, here is an example testing a closed port using netcat

nc -zv 443
nc: connect to port 443 (tcp) failed: Connection refused

Yet again, its very clear that port 443 is not open on or its being blocked along the path by a firewall or some other device.

As with just about any corporation, you find tools that work and they get taken away.  Our company is now blocking the use of netcat due to security risks associated with the tool but not offering any other tool as a replacement.


Now I can use bash as a testing tool and here is that example

cat < /dev/tcp/

here is a test using bash for the successful connection shown above. It just comes back to the command line with no messages which means success

cat < /dev/tcp/

Here is the other test we did above with netcat that failed so you can see the message bash will show.

cat < /dev/tcp/
-bash: connect: Connection refused
-bash: /dev/tcp/ Connection refused

NOTE: using bash is very slow and not always reliable but it appears to be more reliable than telnet but not as good as netcat


I'm having to now test using tcpdump which is a very very painful way for me to test but security doesn't give a dang about how easy or difficult it is for you or me.

As a test scenario I can open a port up on a destination box using netcat while we still have it by running

nc -l 5678

Now on my source box I'll confirm that 5678 is open for testing

nc -zv 5678

Before we just jump into troubleshooting connection issues with tcpdump its important to understand the three way handshake needed for communication (SYN, SYN/ACK, ACK)


As long as the ports your client are trying to communicate are turned on and listening on the server its very easy and not complicated.

Below you will see two examples of the above. Client being and Server being

First tcpdump is capturing the open port 80 on the server.  You can see the entire SYN, SYN/ACK, ACK cycle in this successful communication.


Now let's look at a scenario where the port is just not turned on (or listening) on the server.  In this case does not have 443 on so what do we capture if we attempt to communicate to that port.


You can see you don't have the complete 3 way handshake. You see the SYN coming from the client but you don't get a SYN/ACK back but instead a RST/ACK from the server telling you that the port isn't listening.

Now let's try the same test but to a different server that is behind a firewall ( using the same client (

First you can see a success capture going through the firewall over port 443


Now here is a capture of the same client to the same server over 9300 which is on the server and listening which you can confirm by logging onto the server and running a quick netstat command

netstat -anp | grep "9300"

Now we perform a capture and see the communication doesn't get any further than a SYN, RST/ACK (no difference than above without a Firewall)





1 Comment

Recommended Comments

3 way Handshake Troubleshooting With tcpdump

We are able to confirm routing, firewall rules, and remote service response by looking at the type of packet that comes back:

tcpdump ‘tcp[13] & 2!=0’
SYN messages tell us that at least our client is sending it’s initial outbound message. If that’s all we see, then nothing is coming back and routing could be bad, or the remote server could be down.
tcpdump ‘tcp[13] & 16!=0’
ACK is the acknowledge message. We can see that the traffic is going all the way to and from the client/server and the server is responding.
tcpdump ‘tcp[13]=18’
SYN ACK packets shows active communication between client and server. Routes, ACLs, and Firewall rules are good.
tcpdump ‘tcp[13] & 4!=0’
RST packets. RST packets are sent back from the service, so at least you know the path is good and not blocked by an ACL or firewall.
tcpdump ‘tcp[13] & 1!=0’
FIN packets. FIN packets are sent back from the service, so you also know path and firewall or ACL rules are not blocking.

tcpdump Statistics

Often, on a network a few hosts will be infected, but it’s hard to tell which ones those hosts are. Here is a quick method to help you determine who is spewing the most traffic:

First, get a packet capture of the data that is of interest to you, you can get basic packets, or all of it if you want to review it later. In my example I want to review it later, so I’m capturing the entire packet, with a bit of detail:

#  tcpdump -i any -nn -X -vv -s 1514 -c 1000 -w packetcap.cap 

Next run it through awk to display some statistical information:

# tcpdump -nr packetcap.cap | awk '{print }' | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort -n
  • Like 1

Share this comment

Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing

    No registered users viewing this page.

  • Blog Comments

    • So last night they did get kates temp to stabilize with more anti-biotics and fluids.  Also our friend Kevin hooked us up with a great HVAC repair man which we will always use now.  He got us up and running (found a short). Now we work and wait for the request to go pick her up from the hospital.
    • Just dropped Kate off at the Emergency Room at Harper Hutzel hospital. Dr.Yang called at 8:42am after I left him a message and he recommended I bring her down for some antibiotics since her white blood cell count is so low it may not be enough to fight any infection. So now I need to find a trane furnace repair tech that will come out. Both Schutz and Affordable both don’t have appointments until end of next week. My backup plan is pull RV right next to house with generator and run the A/C
    • 8:31am 102.4 (we will continue to monitor for a little bit more. If not down in next 10min I have to get her dressed somehow and get her to the vehicle)
    • 8:21am 103.1 and called the radiologist and left a message as directed to do by paperwork she was given.  Pain medication isn’t working and she has a fever.  I predict us having to go to hospital. we double checked with two other thermometers and the Vick’s oral and Braun ear seem consistent. Our new infrared forehead thermometer IR 988 says she doesn’t have a fever. What a piece of garbage. Checking on a refund/return on this crap.
    • Today is a rough day for us. Last night our furnace went out so no A/C on a day that was up in the high 80s. Shutz Heating and Cooling is suppose to call me first thing this morning. Kate woke up with a fever of 102.8 at 7:52am so we have a wash cloth and Tylenol at 8am.  Checked it at 8:02am and it came down with a cool washcloth mainly to 101.3 Going to keep monitoring every 10min until it gets down. i need to get our A/C back. I think we have a blown thermostat (comfortlink ii
  • Upcoming Events

  • Create New...