How to Diagnose Firewall and Port Blocking Issues: A Step-by-Step Guide (2026)

Key takeaways

• Read the error first: connection refused means nothing is listening or a REJECT rule applies, while a timeout means packets are silently dropped.
• Test from the service outwards: ss -tlnp on the host, then locally, then from the same network, then from outside.
• Check cloud security groups and network ACLs as well as the host firewall, and remember carrier-grade NAT can block inbound ports at home.

Most port problems are found in minutes once you test in the right order. This guide gives you that order, the commands for Linux and Windows, and the fixes for each layer, including the carrier-grade NAT problem that catches many home and small-office users in India.

Only scan and test systems you own or are authorised to test. Port scanning someone else's network without permission can breach your ISP's terms and India's IT Act.

What does each connection error tell you?

The error message is your first clue, because each one comes from a different layer.

That last row matters. If a TCP connection completes, stop looking at firewalls and start looking at the application.

What do open, closed and filtered mean in Nmap?

Nmap reports a port as open when an application accepts the connection, closed when the host answers but nothing listens, and filtered when it gets no useful reply because something is filtering the probes. The Nmap reference guide also defines three less common states:

• unfiltered: reachable, but Nmap can't tell open from closed (seen with ACK scans).
• open|filtered: no response, common for UDP, where silence can mean either.
• closed|filtered: rare, seen with specialised scan types.

A practical rule: closed means the network path works and the problem is on the server. Filtered means something in the path is dropping traffic.

The step-by-step method

Test each layer in this order. Move to the next step only when the current one passes.

1. Is the service running and listening? On Linux, run ss -tlnp (TCP) or ss -ulnp (UDP) and look for your port.
2. Which address is it bound to? If you see 127.0.0.1:8080, only the machine itself can connect. It needs 0.0.0.0:8080 (or the server's IP) to accept outside connections.
3. Does it work locally? Run curl -v http://127.0.0.1:8080 or nc -zv 127.0.0.1 8080 on the server.
4. Does it work from another machine on the same network? If not, the host firewall (or SELinux) is the prime suspect.
5. Does it work from outside? If it works on the LAN but not from the internet, check router port forwarding, the cloud security group, CGNAT and ISP blocks.
6. Do packets actually arrive? Capture on the server while you test. If nothing shows up, the block is upstream.

# Steps 1-2: what is listening, and on which address
sudo ss -tlnp | grep 8080

# Step 3: local test
curl -v http://127.0.0.1:8080
nc -zv 127.0.0.1 8080

# Step 6: watch for incoming packets while testing from another machine
sudo tcpdump -ni any tcp port 8080

Which tools should you use to test a port?

Use Nmap when you need port states and reasons, netcat or PowerShell for a quick yes/no, and tcpdump when you need proof that packets arrive.

In Nmap, -Pn skips the ping check, which matters because many firewalls block ICMP and Nmap would otherwise report the host as down. --reason shows why each state was chosen, such as syn-ack, reset or no-response. For a fuller walkthrough of scan types, see our beginner's guide to Nmap network scanning.

Testing UDP ports

UDP testing is harder because UDP has no handshake, so silence can mean "open" or "dropped". Use sudo nmap -sU -p 53,123 host and expect some open|filtered results. Netcat does support UDP (nc -zvu host 53), but its "succeeded" message is not proof the service is there. The reliable test is a real request, for example dig @host example.com for DNS.

How do you check the Linux host firewall?

Find out which firewall manager the server uses, then list its rules for your port.

# firewalld (RHEL, Rocky, AlmaLinux, Fedora)
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

# ufw (Ubuntu)
sudo ufw status verbose
sudo ufw allow 8080/tcp

# nftables / iptables directly
sudo nft list ruleset
sudo iptables -L -n -v --line-numbers

Common mistakes:

• Forgetting --permanent or --reload with firewalld. The rule works now and disappears after a reboot, or the reverse.
• Adding the rule to the wrong zone. Check which zone your interface is in with --get-active-zones.
• Running two firewall tools at once. Mixing ufw or firewalld with hand-written iptables rules leads to rules that override each other.

Our guide to configuring iptables and firewalld covers zones and rule design in more depth.

Don't forget SELinux on RHEL-based systems

On RHEL and its rebuilds, SELinux can stop a service from binding to a non-standard port even when the firewall allows it. The service usually fails to start, with a permission error in the logs. Check and fix the port label:

sudo semanage port -l | grep http_port_t
sudo semanage port -a -t http_port_t -p tcp 8081
sudo ausearch -m avc -ts recent

How do you check Windows Firewall?

On Windows, confirm the listener first, then the firewall rule.

netstat -ano | findstr :8080
Get-NetFirewallRule -Enabled True -Direction Inbound | Where-Object DisplayName -like "*8080*"
New-NetFirewallRule -DisplayName "Allow 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

Check the network profile too. A rule created only for the Domain or Private profile won't apply if Windows has classed the network as Public. For a full walkthrough, see our practical guide to Windows Firewall rules.

Cloud servers: security groups and network ACLs

On AWS, Azure or Google Cloud, a cloud-level firewall sits in front of the server, and a missing rule there produces a timeout even when the server's own firewall is open. Check:

• Security group or NSG inbound rules for the port and the correct source range.
• Network ACLs (AWS) or subnet-level rules. AWS security groups are stateful, but network ACLs are stateless, so they need rules for return traffic as well.
• The IP you are testing. Make sure you are using the instance's public IP or load balancer address, not a private one.

Works on the LAN but not from the internet: NAT, CGNAT and ISP blocks

If the service works inside your network but not from outside, the problem is almost always at the edge: router port forwarding, carrier-grade NAT, or an ISP block.

Check router port forwarding

• Forward the external port to the server's current internal IP. Give the server a DHCP reservation so the IP doesn't change.
• Test from a genuinely outside network, such as a phone on mobile data. Many routers don't support "hairpin" NAT, so testing your public IP from inside the LAN can fail even when forwarding works.

Check for carrier-grade NAT (CGNAT)

Many Indian broadband and mobile connections sit behind CGNAT, which means you don't have your own public IPv4 address, and port forwarding on your router cannot work. To check, compare the WAN IP shown on your router's status page with the address a "what is my IP" site shows. If they differ, or the router's WAN IP is in 100.64.0.0/10 (the range reserved for CGNAT), you are behind CGNAT. Your options are to request a public or static IP from your ISP, use IPv6 if your ISP provides it, or use a VPN or tunnel service instead of inbound port forwarding.

Check for ISP port blocks

Some ISPs block common abuse targets such as outbound port 25 (SMTP) and inbound 445 (SMB). If one specific port fails but the same service on another port works, an ISP block is likely. Ask your ISP, or move the service to a different port.

New to address translation? Our explainer on how NAT works covers the basics.

Worked example: SSH works on the LAN but not from outside

You can SSH to a home lab server at 192.168.0.100 from your laptop on Wi-Fi, but not from your phone on mobile data.

1. ss -tlnp | grep :22 shows 0.0.0.0:22, so sshd listens on all addresses.
2. From the laptop, nmap -Pn -p 22 192.168.0.100 shows open, so the host firewall is fine.
3. From the phone hotspot, a scan of your public IP shows filtered. Something at the edge is dropping it.
4. The router's WAN IP is 100.72.x.x, which is inside the CGNAT range. Port forwarding cannot work on this connection.
5. Fix: use a VPN-based remote access tool or ask the ISP for a public IP. If you do expose SSH directly, use key-based login only, disable password and root login, and consider a non-default port to cut log noise.

Habits that prevent port problems

• Change one thing at a time and re-test, so you know which change fixed it.
• Avoid "temporarily" disabling the firewall. If you must, do it on an isolated test machine and re-enable it immediately.
• Open ports only to the source ranges that need them, not to 0.0.0.0/0.
• Keep firewall and port-forwarding rules documented and reviewed, because forgotten open ports are a common cause of breaches.

Next step: practise this on two virtual machines. Block a port with firewalld, diagnose it using only the commands above, then fix it. If you want structured, hands-on Linux administration practice with firewalld and SELinux, the RHCSA training course covers both in exam-style labs.

Related reading

• Top 20 Common Network Ports and Their Functions | Complete Guide for Beginners
• What Are the Top 10 Networking Tools Every Techie Should Know? Complete Guide for Beginners and Experts
• What are the most essential Linux firewalls in 2026 and how do they protect your systems?