Loading...

VONDS ©

Lab 133: Investigate Port 443 Failure (Path + Firewall)

Back to Lab Index

Troubleshoot why HTTPS works from other hosts but fails from this one. Prove DNS and IP reachability are healthy, isolate the failure to TCP/443, fix local firewall policy, and verify end-to-end HTTPS.

networking troubleshooting firewall https core

Scenario

From this host only, https://checkout.lab.example fails while other servers can reach it. Your job is to isolate the failing layer and correct local policy so outbound HTTPS works again.

Operator context

Do not guess. Prove each layer: DNS, then IP reachability, then TCP/443. If ICMP works but TCP/443 times out, treat it as a local policy or state issue until proven otherwise.

Objective

  • Confirm the hostname resolves to an IP.
  • Confirm basic reachability to the resolved IP.
  • Prove TCP/443 is failing from this host.
  • Identify the active firewalld zone and allowed services.
  • Allow HTTPS in the correct zone and apply the change.
  • Verify HTTPS connectivity succeeds.

Concepts

  • Separate layers: name resolution, IP reachability, and transport ports fail independently.
  • ICMP success does not prove TCP/443 is allowed or reachable.
  • A host-specific failure often points to local firewall rules, zone binding, or stateful filtering.
  • Change control starts with identifying the active zone before modifying rules.
  • Verify closure by re-running the same tests after each fix.

Walkthrough

Step 1 : Confirm the hostname resolves to an IP.
Command 
getent hosts checkout.lab.example
# OR
dig +short checkout.lab.example

If resolution fails, stop and fix DNS. If it resolves, use the returned IP to test the network without mixing layers. 

203.0.113.20   checkout.lab.example
# OR
203.0.113.20
Step 2 : Confirm basic reachability to the resolved IP.
Command 
ping -c 2 203.0.113.20

ICMP success narrows the problem space, but it does not prove TCP/443 will work. 

PING 203.0.113.20 (203.0.113.20) 56(84) bytes of data.
64 bytes from 203.0.113.20: icmp_seq=1 ttl=52 time=18.4 ms
64 bytes from 203.0.113.20: icmp_seq=2 ttl=52 time=18.1 ms

--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
Step 3 : Test TCP connectivity to port 443.
Command 
nc -vz checkout.lab.example 443
# OR
nc -vz 203.0.113.20 443

A timeout here while ping works points to policy or state: local firewall rules, routing policy, or upstream filtering scoped to this host. 

nc: connect to checkout.lab.example (203.0.113.20) port 443 (tcp) failed: Connection timed out
Step 4 : Identify the active firewalld zone for the interface.
Command 
sudo firewall-cmd --get-active-zones

Identify the active zone before making any changes. Fixing the wrong zone is a common operational mistake. 

public
  interfaces: eth0
Step 5 : Check what is allowed in that zone.
Commands 
sudo firewall-cmd --zone=public --list-services
sudo firewall-cmd --zone=public --list-ports

If https is missing and there is no equivalent port allowance, this host may be blocking the traffic you need. 

ssh dhcpv6-client
# ports: (none)
Step 6 : Allow HTTPS in the active zone and reload.
Commands 
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

Permanent changes survive reboot. Reload applies the updated configuration to runtime immediately. 

success
success
Step 7 : Verify TCP/443 works now.
Command 
nc -vz checkout.lab.example 443
Connection to checkout.lab.example 443 port [tcp/https] succeeded!
Step 8 : Verify HTTPS end-to-end with curl.
Command 
curl -I https://checkout.lab.example

This is your closure check. The goal is “HTTPS works again from this host,” not “a firewall rule exists.” 

HTTP/2 200
server: nginx
content-type: text/html

Common breakpoints

DNS resolves, but ping fails

Pivot to routing and path checks: default route, gateway reachability, and upstream ACLs/security groups. If other hosts can reach the target, compare routes and NAT policy.

nc to 443 still times out after firewall changes

Confirm you modified the correct active zone. Check for rich rules, direct rules, and any local egress policy. If local policy is clean, suspect upstream filtering scoped to this host or source IP.

nc succeeds but curl fails

TCP is open. Pivot to TLS and application causes: CA trust, SNI/hostname mismatch, proxy requirements, or application-side blocks. Use verbose curl and compare with a known-good host.

Cleanup checklist

This lab changes firewall policy. If you need to revert, remove the https service from the same active zone and reload.

Commands 
sudo firewall-cmd --zone=public --remove-service=https --permanent
sudo firewall-cmd --reload
Success signal

firewall-cmd --zone=public --list-services no longer shows https, and your TCP/443 test fails again as expected in the reverted state.

Reference

  • getent hosts <name> : Resolves names through NSS using the system-configured order.
  • dig +short <name> : Queries DNS and prints only the answer section.
    • +short : Prints concise results (one record per line).
  • ping -c <n> <ip> : Tests basic IP reachability (ICMP).
    • -c <n> : Sends a fixed number of echo requests.
  • nc -vz <host> <port> : Tests whether a TCP port is reachable.
    • -v : Prints verbose connection output.
    • -z : Scans without sending data.
  • firewall-cmd --get-active-zones : Shows active zones and bound interfaces.
  • firewall-cmd --zone=<zone> --list-services : Lists allowed services in a zone.
    • --zone=<zone> : Targets a specific zone (for example public ).
  • firewall-cmd --zone=<zone> --list-ports : Lists allowed ports in a zone.
  • firewall-cmd --zone=<zone> --add-service=https --permanent : Allows the https service permanently in a zone.
    • --permanent : Writes the change to disk so it persists across reboot.
  • firewall-cmd --zone=<zone> --remove-service=https --permanent : Removes the https service permanently from a zone.
  • firewall-cmd --reload : Applies permanent configuration to runtime rules.
  • curl -I https://<host> : Validates HTTPS response headers.
    • -I : Requests headers only.