The Frustrating Silence of ICMP
I recently spent a long weekend troubleshooting a connectivity issue between two microservices in a hardened VPC environment. The classic tools failed me. Running a standard ping resulted in 100% packet loss, yet the application logs insisted the connection was being refused, not timed out.
In modern infrastructure, ICMP (the protocol behind ping) is often the first thing security teams disable. When you’re staring at a “Request timed out” message from traceroute, you aren’t getting the full story. You don’t know if the server is down, if a firewall is dropping your packets, or if a specific port is just being stubborn.
This is where I’ve found hping3 to be an absolute lifesaver over the last six months of production operations. While nmap is fantastic for discovery and tcpdump is great for sniffing, hping3 occupies a unique space: it is a command-line oriented TCP/IP packet assembler and analyzer. It allows you to craft almost any packet you can imagine, making it indispensable for testing firewall rules and performing deep network diagnostics that standard tools simply can’t touch.
Understanding the hping3 Philosophy
Standard networking tools are often “high-level.” curl tests the application layer, ping tests the network layer (ICMP), but hping3 lets you manipulate the transport layer directly. You can send TCP SYN packets to a port, toggle specific flags like ACK, FIN, or RST, and even spoof source IP addresses to see how a firewall reacts from a different perspective.
In my real-world experience, this is one of the essential skills to master. Being able to speak the language of the TCP stack allows you to distinguish between a “Drop” (firewall silently discarding a packet) and a “Reject” (firewall or host actively sending a RST/ACK back). Most importantly, it lets you perform diagnostics using the same protocol and port your application uses, ensuring that what you’re testing actually matches production traffic.
Getting Started with hping3
Most Linux distributions don’t include hping3 by default, but it’s readily available in the standard repositories. On Ubuntu or Debian, I usually get it running with a quick:
sudo apt-get update
sudo apt-get install hping3Since hping3 requires raw socket access to craft packets, you’ll need to run most commands with sudo. If you just run hping3 --help, you’ll see a massive list of options. Don’t let that overwhelm you. Most of the time, I only use a handful of flags to get the job done.
Hands-on: Common Diagnostic Scenarios
1. Testing TCP Connectivity When ICMP is Blocked
If a server isn’t responding to ping, I immediately switch to a TCP SYN probe. This mimics the start of a standard TCP connection. If I want to test if a web server is reachable on port 443, I use:
sudo hping3 -S -p 443 -c 4 1.2.3.4-S: Sets the SYN flag.-p 443: Targets the specific port.-c 4: Sends only 4 packets (otherwise it runs indefinitely like ping).
If the port is open, you’ll see a response with flags=SA (SYN/ACK). If it’s closed, you’ll likely see flags=RA (RST/ACK). If there’s no response at all, a firewall is likely dropping your packets.
2. TCP Traceroute to Bypass Firewalls
Standard traceroute uses UDP or ICMP. If a firewall along the path blocks these, you’ll just see a row of asterisks (* * *). I prefer using hping3 to perform a traceroute over TCP port 80 or 443, which are much more likely to be allowed through intermediate routers.
sudo hping3 --traceroute -V -S -p 80 itfromzero.comThe --traceroute flag increments the TTL (Time to Live) for each packet, allowing you to see exactly which hop is dropping your traffic. Using -V (verbose) gives you more detail about the headers, which is useful when you’re looking for subtle misconfigurations.
3. Testing Firewall Rules with ACK Probes
One of the more advanced techniques I’ve used to map out firewall behavior is the ACK scan. By sending a packet with only the ACK flag set (and no established connection), I can see how the stateful inspection behaves. Simple stateless firewalls might let these through, while modern stateful ones will usually drop them or send a RST.
sudo hping3 -A -p 80 1.2.3.4If you receive a RST (Reset) packet back, it often means the port is unfiltered but the connection isn’t recognized. If there is no response, it’s a strong indicator of a stateful firewall filtering the traffic.
4. Measuring Latency Under Load
Sometimes the network isn’t “down,” it’s just slow. I’ve used hping3 to test how a system handles a high volume of connection requests. By using the --fast or --flood flags, you can generate significant traffic to see when latency starts to spike.
# Send 10 packets per second
sudo hping3 -S -p 80 -i u10000 1.2.3.4Note: Be extremely careful with --flood. It will send packets as fast as your CPU can generate them and can easily look like a DoS attack to your security team. I only use this in controlled, internal environments to test local load balancer performance.
Analyzing the Output
The beauty of hping3 lies in the details of the response. When you get a reply, pay close attention to the flags and the window size. A window=0 response might indicate that the remote host is receiving your packets but its buffer is full, implying an application-level bottleneck rather than a network issue. Seeing inconsistent TTL values in responses from the same IP can also tip you off to load-balancing or asymmetric routing issues that you would never notice with a standard ping.
Final Thoughts on Network Visibility
Reflecting on the last half-year of using this tool, it has fundamentally changed how I approach connectivity problems. Instead of guessing why a connection is failing, I can prove exactly where the breakdown occurs. Whether it’s a misconfigured security group in AWS or a buggy internal router, hping3 provides the empirical evidence needed to fix the issue rather than just reporting it.
If you’re moving into a senior engineering or SRE role, don’t rely solely on high-level tools. Spend an hour playing with hping3 in a lab environment. Craft some weird packets, watch how your local firewall reacts, and get comfortable reading the raw output. When the next “impossible” network bug hits production, you’ll be glad you have this in your toolkit.
