Why Traceroute Cannot Show Where a VPN Is Blocked

Traceroute cannot show the physical or administrative location where a VPN is blocked. It reveals replies triggered as probes expire at particular hop limits, plus a final response if the chosen probe reaches something willing to answer. Missing replies, changing hops, or a stopped trace do not identify a filtering device, its owner, the return path, or the VPN handshake stage.

The complete VPN guide maps the full connection. This article isolates traceroute because its compact hop list is easy to overread as a literal path and a blocking verdict.

Key Takeaways

• Traceroute manipulates IP TTL or IPv6 Hop Limit and observes resulting control messages.
• A displayed router is usually the device that generated a reply, not proof that the next device dropped the VPN.
• Stars mean no reply was matched before the timeout; they do not mean “blocked here.”
• Forward and return paths can differ, and load balancing can change the visible sequence.
• Pair route observations with exact transport, server, and application evidence before assigning a failed stage.

What does traceroute actually measure?

Traceroute sends probes with progressively larger TTL values. An IPv4 router normally reduces TTL while forwarding. When TTL reaches zero, the router discards the packet and may return an ICMP Time Exceeded message. RFC 792 defines that message; it also defines Echo and Echo Reply, which are separate ICMP functions.［1］

The first probe is intended to expire near the first router, the next near the second, and so on. The tool matches responses to probes and prints an address and round-trip timing. Different implementations may use UDP, ICMP Echo, TCP, or other probe forms, so two traceroute tools can exercise different policy paths.

RFC 1812 requires IPv4 routers to handle TTL during forwarding and describes when ICMP errors are generated or suppressed.［2］ The word “may” matters operationally: the absence of a visible response is not a receipt proving that the router dropped the application flow.

Traceroute measures a control-plane side effect of selected probes. It does not observe every device that forwards silently, and it does not automatically recreate the VPN protocol’s packet sequence.

Why does a star not locate a block?

A star usually means the tool did not receive a matching response before its timer expired. The expiring router might rate-limit ICMP, suppress errors, place replies in a lower-priority queue, use a private or unreturnable source address, or send a response along a broken return path. The probe itself may also have been lost.

Later hops sometimes reply after an earlier row shows stars. That alone proves that the silent hop forwarded at least some probes. Conversely, a trace that ends after one router does not prove the next router performed the filtering. The last visible device is simply the last device that answered this measurement.

Some networks deliberately filter traceroute probe types while allowing production traffic. Others allow ICMP control messages but block the VPN transport or application behavior. RFC 8095 explains that ICMP provides control and diagnostic functions rather than a general transport service for applications.［3］ A responsive ICMP path is therefore not an application reachability guarantee.

Why is the displayed path incomplete?

Internet forwarding is directional. A probe can travel outward through one set of routers while the Time Exceeded reply returns through another. Traceroute normally reports only the address that sourced the response and one round-trip measurement; it does not enumerate the response route.

Equal-cost multipath routing can send probes from the same run across different next hops. Per-packet or per-flow hashing, address translation, tunnels, provider backbones, and routing changes can all alter the list. The apparent sequence is not necessarily one physical cable path or one stable administrative chain.

Router addresses are also interfaces, not ownership declarations. A visible address may be assigned to a loopback or another interface different from the ingress where the probe arrived. Geolocation and reverse DNS names are hints maintained by separate data sources, not authenticated proof that a device sits in the named city or belongs to the named policy operator.

If the route changes on repeated VPN connections, distinguish ordinary routing variability from changes in tunnel behavior before drawing a conclusion.

Can traceroute test the VPN port or protocol?

Some implementations can send TCP SYN probes toward a chosen port, and UDP traceroute can choose a destination port range. That makes the probe closer to one transport question, but it still does not complete TLS, WireGuard, OpenVPN, IKEv2, or another authenticated VPN exchange.

A TCP SYN-ACK can show that a TCP listener or intermediary answered. A TCP RST shows that something explicitly rejected the segment. An ICMP error can report an IP-layer condition. None proves that the server accepted the VPN identity, agreed on cryptographic parameters, installed tunnel state, or carried protected data.

UDP makes the gap wider because a silent application can be healthy, a firewall can drop unsolicited probes, and the actual VPN handshake may require valid protocol bytes before responding. A server response is not a completed VPN handshake, and traceroute responses are even earlier evidence.

What can common traceroute results prove?

Observation	What it can support	What it cannot prove
Several early hops reply	Those probes elicited matched responses	Every production packet used the same route
One row is all stars	No matched reply arrived in time for those probes	The router at that row blocked the VPN
Later hops appear after stars	At least some probes passed the silent point	The silent device has no filtering policy
Trace reaches the destination address	The probe type reached a responding endpoint or network	The VPN port, handshake, authentication, or tunnel works
Trace stops near the destination	No later matching response was observed	The destination network intentionally blocked it
Paths differ between runs	Routing or response selection differed	A blocker moved or changed ownership
TCP and ICMP traces differ	Probe types experienced different handling	Deep packet inspection identified the VPN

Write conclusions at the same strength as the row. “No replies after hop 8 for UDP probes” is accurate. “Hop 9 is the censor” is not supported by that output.

What evidence can narrow the failed VPN stage?

Start with the actual client attempt, not traceroute. Record the endpoint name and current addresses, address family, transport, destination port, exact error category, and timestamp. If you administer the endpoint, check whether the same attempt reached its network interface and application logs.

Then separate milestones: DNS answer, basic IP route, transport response, protocol reply, authenticated handshake, tunnel interface and routes, DNS through the tunnel, and protected data. The VPN connection test covers post-connection evidence; the general VPN-not-connecting checklist covers failures without a narrow hypothesis.

Use traceroute as context for route change, broad loss, or a comparison between two permitted networks. Keep the probe method identical and change one variable at a time. If a route trace changes while the VPN result does not, the trace may not be causal. If the VPN result changes while the displayed route does not, an invisible policy or endpoint state may differ.

How do you run a bounded diagnostic safely?

First preserve the failing client error. Run the smallest traceroute variant allowed by the device and network. Record the command or app mode, probe protocol, destination, address family, start time, and timeout. Do not interpret reverse DNS names as verified ownership.

Next, perform one authorized control, such as the same destination from another permitted network or the same transport to a server you administer. Avoid broad scanning, random port changes, unknown certificates, or attempts to bypass an organization’s access rules. Stop if the network owner prohibits active diagnostics.

Correlate both ends when possible. A server capture showing no matching packets narrows the break to the path before the server, but still does not locate the device. A server log showing a valid request and an explicit rejection moves the diagnosis to the application or policy recorded there.

Instead of reading meaning into stars, use AethoVPN as a controlled transport test: keep the failing client's error, then connect to one in-app location on the same network and, if permitted, on a second network, recording start time, location, and connection state for each attempt. A connection that succeeds on one network and fails on the other narrows the problem to that network's path, which is evidence you can give to its owner. The app's connection states are context, not attribution, and cannot identify a blocking device, operator, or motive. Start the 3-day free trial to add that comparison to your record.

Why do ping and traceroute tell different stories?

Ping normally sends ICMP Echo requests with a regular TTL and waits for Echo Replies. Traceroute deliberately expires probes and usually depends on ICMP errors generated along the path. A firewall or router can treat those message types differently. RFC 792 defines both, but their purposes and triggering conditions are not the same.［1］

Even a successful ping reaches only an ICMP responder. A VPN may use UDP or TCP on another port and require a valid handshake. A failed ping may merely show that Echo is disabled. Neither result replaces application evidence.

Latency values also need restraint. Traceroute times include the return path and router response scheduling. A high number at one hop followed by lower numbers later often reflects control-message priority, not a persistent bottleneck at that router.

Summary

• Traceroute observes hop-limit expiration responses, not a complete map of every forwarding and filtering decision.
• Stars, a last visible hop, and route changes do not locate a VPN block.
• Probe type, ICMP policy, load balancing, and asymmetric return paths change what appears.
• A destination response still does not prove the VPN handshake or data path.
• Use exact client/server milestones and one controlled comparison before assigning cause or ownership.

FAQ

Does the last visible hop block the VPN?

Not necessarily. It is only the last device that returned a matched response. The next device, a later device, the destination, or the return path may be silent or failing.

What do three stars in traceroute mean?

They mean no matching replies arrived within the tool’s timeout for those probes. Rate limiting, suppression, loss, private addressing, or return-path problems are all possible.

Can TCP traceroute prove a VPN TCP port is open?

It can provide transport evidence if the expected TCP response arrives, but it does not complete the VPN’s TLS or application handshake and cannot prove a usable tunnel.

Why do later hops appear after a row of stars?

The silent device forwarded some probes but did not return or successfully deliver its own expiration messages. Forwarding and diagnostic replies are separate behaviors.

Can traceroute identify the ISP or country doing the blocking?

No. Interface addresses, geolocation, and reverse DNS can be clues, but traceroute does not authenticate device ownership, location, policy author, or enforcement intent.

Is ping better than traceroute for checking a VPN server?

No single ICMP test is sufficient. Ping asks whether an Echo exchange works; traceroute samples hop-limit behavior. The VPN transport and authenticated handshake require their own evidence.

When is traceroute useful in VPN troubleshooting?

It is useful as supporting context when comparing route reachability, broad packet loss, or two controlled network paths. It should be paired with timestamped client and server observations.

Disclaimer: This article provides general technical information. Run diagnostics only on systems and networks where you have permission, and follow the network owner’s policy.

Sources:

1. IETF, "RFC 792: Internet Control Message Protocol": https://www.rfc-editor.org/rfc/rfc792
2. IETF, "RFC 1812: Requirements for IP Version 4 Routers": https://www.rfc-editor.org/rfc/rfc1812
3. IETF, "RFC 8095: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms": https://www.rfc-editor.org/rfc/rfc8095

Sources checked 12 September 2026.

---

Related Articles:

• The complete VPN guide
• What happens when a network blocks UDP
• Why a server reply is not a completed VPN handshake
• How to test a VPN connection
• VPN not connecting: a broader checklist