Why Does My Corporate VM Block ICMP (Ping)?
One day at work, I was handed a freshly provisioned VM and wanted to do a quick sanity check does this thing have internet access?
$ ping google.com
# ... silence. Request timeout.
No response. I assumed the VM was isolated. But wait, I need internet access to download some software. Something felt off, so I tried:
$ curl www.google.com
# <!doctype html><html ...
It worked instantly. The VM had internet access all along, so why couldn't I ping 🤔?
This small inconsistency sent me down a rabbit hole that turned out to be a genuinely interesting piece of network security. Let's unpack it.
First difference I've learnt is ping uses the ICMP protocol whereas curl did an HTTP/HTTPS call. So why is my VM blocking ICMP requests?
What Even Is ICMP?
ICMP is short for Internet Control Message Protocol. Unlike HTTP or TCP, it is not designed to transfer application data, it's mostly used as a diagnostic and control protocol used by network devices to communicate operational information about the network itself.
It lives at Layer 3 (the Network Layer) of the OSI model, right alongside IP. When you run ping, your OS sends an ICMP Echo Request to the target (Google in our case), and if everything is healthy, the target replies with an ICMP Echo Reply. That round-trip time is what you see printed in your terminal.
ICMP is also what powers tools like traceroute, it's a foundational tool for understanding what's happening on a network.
How Ping Works Under the Hood
When you run ping, your OS opens a raw socket (SOCK_RAW) (or SOCK_DGRAM). Unlike a regular TCP or UDP socket that handles connection state and data streams, a raw socket gives the application direct access to the IP layer, with this you construct and read packets yourself, without the OS abstracting the protocol for you.
This is why ping typically requires elevated privileges (or specific capabilities on Linux) raw sockets are powerful, and handing them to any process would be a security risk.
The ICMP Echo Request is then wrapped in an IPv4 datagram and sent out. The IPv4 header + ICMP header + payload together can be up to 65,535 bytes in total. By default, ping sends a small payload of just 56 bytes of data (64 bytes with the ICMP header) but there is nothing technically stopping a crafted packet from being much larger.
The Attacks That Gave ICMP a Bad Reputation
1. Ping of Death
The Ping of Death is a classic vulnerability from the 1990s. Here's how it works:
As we discussed previously, the IPv4 specification allows datagrams up to 65,535 bytes. When a packet is too large for the network's MTU (Maximum Transmission Unit), it gets broken into smaller pieces at the Data Link layer and then reassembled by the receiving OS.
An attacker can craft a malicious ICMP packet that, when its fragments are reassembled, exceeds the 65,535 byte limit. Older operating systems didn't properly validate this during reassembly, which led to a buffer overflow, memory corruption that could crash or freeze the system entirely.
Modern operating systems are patched against this. But it was a real, widespread vulnerability, and it established a precedent: ICMP packets can be weaponized.
2. Ping Flood (ICMP Flood)
This is a different class of attack, it's less clever, more brute-force. The attacker simply floods the target with a massive volume of ICMP Echo Requests, consuming its bandwidth and CPU cycles trying to respond to all of them.
A basic ping flood:
# (Do NOT run this against systems you don't own)
$ ping -f target.com
At scale, with spoofed source IPs or a botnet, this becomes a straightforward DDoS attack. The target spends all its resources responding (ECHO reply) to fake pings instead of serving real traffic.
So Why Block ICMP Entirely?
Patching against Ping of Death is one thing, but corporate firewalls often block all ICMP traffic, not just oversized packets. That seems heavy-handed. Why?
There are several legitimate reasons:
Reason 1: Network Reconnaissance
ICMP is an attacker's best friend when mapping an unknown network. A ping sweep will send ICMP Echo Requests to every IP in a subnet, instantly revealing which hosts are alive. Tools like nmap use this as their first step.
$ nmap -sn 192.168.1.0/24
# Discovers every live host on the subnet in seconds
If ICMP is blocked, this reconnaissance becomes significantly harder. An attacker probing your network gets silence instead of a map.
Reason 2: ICMP Tunneling (Data Exfiltration)
This one is subtle and clever. Because ICMP packets can carry a data payload, an attacker who already has a foothold inside your network can use ICMP to exfiltrate data or tunnel arbitrary traffic, even bypassing firewalls that only inspect TCP/UDP.
Tools like ptunnel and icmptunnel can encapsulate a full TCP connection inside ICMP echo request/reply packets. From the firewall's perspective, it just looks like someone pinging, but a full data channel is hidden inside.
Blocking ICMP closes this exfiltration channel entirely.
Reason 3: ICMP Flood as an Amplification Vector
ICMP can also be used in Smurf attacks, it is a technique where an attacker sends ICMP Echo Requests with a spoofed source IP (the victim's IP) to a network broadcast address. Every host on that network replies to the victim, amplifying the attack traffic significantly.
While most modern routers disable directed broadcast by default, blocking ICMP at the corporate perimeter removes the risk altogether.
Reason 4: Least-Privilege Network Policy
In a corporate environment, the principle of least privilege applies to network traffic too. The question isn't "why block ICMP?" but "why allow it?" If no business application requires ICMP, the safest posture is to block it by default and only allow what's explicitly needed.
This is especially true in environments following zero-trust architecture, where no traffic is implicitly trusted and everything must be explicitly permitted.
The Trade-off
Blocking ICMP entirely isn't without cost. It makes network debugging harder, tools like traceroute, mtr, and even some MTU path-discovery mechanisms rely on ICMP. A common middle ground is:
- Allow ICMP Echo Reply (so outbound pings can complete)
- Allow ICMP Type 3 (Destination Unreachable — block this and Path MTU Discovery breaks, which causes an MTU black hole where big transfers silently stall)
- Block ICMP Echo Request inbound to prevent reconnaissance and floods
But many corporate firewalls opt for the nuclear option: block it all and let the network team deal with the debugging inconvenience.
Back to the Original Mystery
So why did curl work but ping didn't?
curluses TCP port 443 (HTTPS) — a protocol the firewall doesn't block because business applications need it.pinguses ICMP — a protocol the firewall explicitly blocks because the risk/reward ratio doesn't justify allowing it.
My VM had full internet access all along. It just couldn't make an ICMP ECHO request.
A single failed ping led to: raw sockets, fragmentation, buffer overflows, network reconnaissance, and covert data exfiltration channels. That's what I love about computers that there's always a lot to learn from previous mistakes, reasons behind obscure decisions, etc.
If you want to go deeper, the ICMP Wikipedia article is surprisingly detailed, and this Security StackExchange thread has a good discussion on the nuances of ICMP firewall policy.
Keep digging, and stay curious.