ptunnel: A tool to create a tunnel over ICMP for bypassing firewalls

Every time I’ve been on an engagement where a client’s network egress filtering looked airtight — every TCP and UDP port locked down except maybe DNS — I’ve checked one thing first: is ICMP echo (ping) allowed out? More often than I expected early in my career, it is. That’s the exact gap ptunnel exploits. It wraps arbitrary TCP traffic inside ICMP echo request/reply packets, so from the firewall’s point of view, all it sees is what looks like ordinary ping traffic, while what’s actually flowing through is a full TCP tunnel — SSH sessions, RDP, whatever you point it at.

ptunnel is old but the concept remains extremely relevant, because ICMP is still commonly left open in networks that otherwise heavily restrict egress, precisely because network teams assume “it’s just ping” is harmless.

How ptunnel Works Internally

The mechanism is conceptually simple once you see it laid out:

1. Client side runs locally and opens a listening TCP port. Any application (e.g., your SSH client) connects to this local port as if it were the real destination.
2. ptunnel client takes the TCP payload from that local connection, and instead of sending it as normal TCP/IP, it wraps the payload inside the data portion of an ICMP echo request packet, and sends it toward the proxy (the ptunnel server).
3. ptunnel proxy/server, running on a machine with a real route to the actual destination, unwraps the ICMP payload, extracts the TCP data, and forwards it over an actual TCP connection to the real destination (e.g., an SSH daemon).
4. Replies flow back the same way — wrapped in ICMP echo reply packets, which any stateful firewall permits back through since they correlate to allowed outbound echo requests.

Essentially, an ICMP echo request/reply pair becomes a bidirectional data-carrying pipe, with ptunnel handling sequencing, reliability (since ICMP itself has no delivery guarantee, ptunnel adds its own ack/retransmission logic), and multiplexing multiple TCP streams over the single ICMP channel if needed.

Installation

sudo apt update
sudo apt install ptunnel

Or build from source if you need a specific patched version:

git clone https://github.com/utoni/ptunnel-ng.git
cd ptunnel-ng
./autogen.sh
./configure
make
sudo make install

Note: the actively maintained fork today is ptunnel-ng, since the original ptunnel project has been dormant. Command syntax is nearly identical between them.

Verify:

ptunnel -h

Expected (abbreviated) output:

ptunnel: A tool for reliably tunneling TCP connections over ICMP echo request/reply packets.
usage: ptunnel [-x password] [-lhrv] [-p <proxy addr>] [-l <listen port>]
               [-r <remote host>] [-R <remote port>] [-w <chksum type>]

Syntax and Command Examples

On the proxy/server side (a box with normal internet/network access, ideally outside the restricted network segment):

sudo ptunnel -x mysecretpassword

This starts ptunnel in proxy mode, listening for incoming ICMP-wrapped connections and using a shared password to authenticate/obfuscate the tunnel traffic.

On the client side (inside the restricted network where only ICMP egress is allowed):

sudo ptunnel -p 203.0.113.10 -lp 8000 -da 198.51.100.20 -dp 22 -x mysecretpassword

Breaking this down:

• -p 203.0.113.10 — the proxy server’s address
• -lp 8000 — local port to listen on
• -da 198.51.100.20 — the destination address the proxy should forward to
• -dp 22 — the destination port (SSH in this case)
• -x — shared password matching the proxy

Then, from the client machine:

ssh -p 8000 user@127.0.0.1

That SSH session is now travelling entirely as ICMP echo packets until it reaches the proxy, which unwraps it and forwards a normal TCP connection to the real SSH server.

Sample output during use

ptunnel: Starting ptunnel v0.72
ptunnel: Sending queries to 203.0.113.10
ptunnel: Detected remote ptunnel version 0.72
ptunnel: Tunnel established (kernel icmp id: 54321)
ptunnel: Forwarding local port 8000 -> 198.51.100.20:22

Real-World Use Cases in Authorized Engagements

• Egress filtering bypass testing. In scoped pentests, I specifically test whether ICMP tunneling can smuggle data or a shell out when the client believes their firewall only allows ping (harmless, they think) and blocks everything else. Demonstrating a working SSH session over “just pings” is a strong, easy-to-explain finding for a client report.
• Command-and-control channel during red team exercises. If direct TCP C2 gets blocked mid-engagement, ICMP tunneling is a documented fallback to maintain a foothold while staying within the authorized scope and rules of engagement.
• Testing IDS/IPS ICMP anomaly detection. ptunnel traffic has a distinct signature (abnormally large or frequent ICMP echo payloads, non-standard payload patterns, sequential IDs that don’t match normal OS ping behavior). I use it in lab settings to validate whether a client’s Snort/Suricata rules actually catch ICMP tunneling, rather than just assuming “ICMP is fine because it’s not TCP.”

Integration with Other Tools

• SSH is the most common payload — ptunnel gives you the raw pipe, SSH gives you encryption, authentication, and the ability to layer -D SOCKS proxying on top for full traffic routing.
• proxychains4 — once SSH’s SOCKS proxy is running on top of the ptunnel tunnel, route arbitrary tools through it.
• tcpdump/Wireshark — essential for both attackers wanting to confirm the tunnel is working and defenders wanting to see what ptunnel traffic actually looks like on the wire (icmp filter, then inspect payload sizes/patterns).

Troubleshooting and Common Mistakes

• Tunnel doesn’t establish. Check that ICMP isn’t rate-limited or fully blocked somewhere in the path (some routers rate-limit ICMP even if they don’t outright block it, which will make ptunnel painfully slow or unstable).
• Mismatched passwords. If -x differs between client and proxy, the handshake silently fails in some versions — always double check both sides use the exact same string.
• Confusing proxy vs. destination. The proxy is the relay; the destination (-da/-dp) is where traffic actually needs to end up. New users sometimes point ptunnel at their final target as if it were the proxy.
• Running without root/sudo. ICMP raw sockets require elevated privileges on both ends.

Performance and Optimization Notes

ICMP tunneling is inherently slower and less reliable than native TCP — expect noticeably higher latency and lower throughput, especially over lossy links, since every echo/reply round trip adds overhead. I never rely on it for large data transfers; it’s a control-channel and shell-access tool, not a bulk exfil pipe. If speed matters more than stealth, this isn’t the right tool for that job.

FAQ

Is ptunnel still maintained? The original project is dormant; use ptunnel-ng for active development and bug fixes.

Will this work if ICMP is completely blocked? No — it fundamentally requires ICMP echo request/reply to be permitted somewhere along the path.

Is ptunnel traffic encrypted? Not by itself — the password option obfuscates/authenticates the tunnel setup, but for real confidentiality you should tunnel something like SSH through it rather than relying on ptunnel’s own protocol for encryption.

How is this different from a DNS tunnel like iodine? Same broad idea (data smuggled inside an allowed protocol), different carrier protocol (ICMP vs. DNS). ICMP tunnels tend to be faster than DNS tunnels but ICMP is more commonly filtered/rate-limited on well-managed networks.

Lab Example

# Proxy/server (outside restricted segment)
sudo ptunnel -x labpass123

# Client (inside restricted segment, TCP egress blocked, ICMP allowed)
sudo ptunnel -p 10.10.10.5 -lp 2222 -da 10.10.10.50 -dp 22 -x labpass123

# From client machine
ssh -p 2222 labuser@127.0.0.1

Validate detection: run tcpdump -i eth0 icmp -X on an intermediate router in the lab and confirm you can visually spot the tunneled payload pattern, then write detection rules based on what you see.

Summary

ptunnel demonstrates a persistent blind spot in network security: teams filter TCP/UDP aggressively but leave ICMP wide open because it “seems harmless.” As a pentester, that assumption is exactly what you’re paid to test. It’s slow and not encrypted on its own, but it’s an effective, well-documented technique for both offensive egress-bypass testing and defensive detection-engineering exercises.

References

• GitHub (maintained fork): https://github.com/utoni/ptunnel-ng
• Original project page: https://www.cs.uit.no/~daniels/PingTunnel/ (historical reference)
• Kali Linux tool listing: https://www.kali.org/tools/ptunnel/