TTL in Wireshark — Analyze Hop Distance and TCP RST Source

A TCP reset (RST) is a packet that aborts a connection immediately. Applications usually report it as "connection reset by peer". The reset may appear to come from the remote server because the RST uses the server's source IP. But a firewall, intrusion prevention system (IPS), proxy, or another device in the path (often called a middlebox) can generate that reset instead.

One clue is the packet's IPv4 TTL. Compare the TTL of normal server packets with the TTL of the suspicious RST. If they differ significantly, the reset may have been generated somewhere else on the path.

In this guide, we'll reproduce both cases, capture the packets, and use Wireshark to identify the difference.

Wireshark TTL display filters

Apply ip.ttl in the display filter bar, then add Time to Live as a column (right-click the field in the detail pane → Apply as Column). Compare the TTL on normal packets from the endpoint with the TTL on a suspicious RST. A large difference suggests the reset may not have followed the same routed path as the normal server traffic and may have been generated by a nearer device.

Do not confuse the IPv4 ip.ttl field with DNS record TTL or HTTP Cache-Control lifetime — this guide analyzes the IPv4 hop-limit field only.

What TTL tells you in a packet capture

Every IPv4 packet carries a TTL counter. Each router that forwards the packet subtracts one. When TTL reaches zero, the packet is dropped.

What you see in Wireshark is the observed TTL at your capture point:

Observed TTL = Initial TTL − routed hops

Example:

Sender starts with TTL 64
         ↓ router
63
         ↓ router
62
         ↓ router
61 observed in Wireshark

You normally do not know the sender's initial TTL. Common starting values are 64, 128, or 255, but operating systems and appliances can differ. TTL inference is therefore a likely-origin check, not proof of which device sent a packet.

In the lab captures below, server packets arrive at the client with TTL 45 (server initial TTL 46 minus one router hop). The injected RST shows TTL 64 — consistent with a packet generated by a nearby device and delivered to the client without crossing the same routed path as the real server traffic.

Show TTL in Wireshark

Open your capture with File → Open. The Wireshark window has three panes: the packet list at the top, the packet details in the middle, and the raw bytes at the bottom. Above the packet list is the display filter bar, the text box that says Apply a display filter.

Click in the display filter bar, type the filter below, and press Enter:

ip.ttl

The bar turns green when the filter is valid and red when Wireshark cannot understand it. To remove a filter, click the X at the right end of the bar.

To add TTL as a column:

1. Click any packet in the packet list.
2. In the details pane, click the arrow next to Internet Protocol Version 4 to expand it.
3. Right-click the Time to Live line and choose Apply as Column.

The packet list now shows TTL beside Source, Destination, and Info — the fastest way to spot an outlier during reset investigation. You can drag the column header to move it, or right-click the header and untick it to hide it later.

Establish the normal TTL baseline

Capture traffic while the application works. On the Wireshark start screen, double-click the network interface that carries the traffic, use the application normally, then click the red Stop button and save with File → Save As. In the lab, the client at 192.168.10.2 reaches an HTTP server at 192.168.20.2 through a router namespace.

Filter server-to-client traffic and read the TTL column. Replace 192.168.20.2 with the IP address of your own server:

ip.src == 192.168.20.2

Every server packet in this baseline carries TTL 45. That becomes your reference for what "normal" looks like on this path.

The detail pane on a typical server packet shows the same value:

Do not copy the TTL numbers from this lab. Your server may arrive with TTL 55, 117, 243, or another value. What matters is whether normal packets from the same endpoint have a consistent TTL and whether the suspicious RST suddenly differs.

Troubleshoot a TCP reset using TTL

Now capture the failure. In the lab, the middle router runs an nftables reject with tcp reset rule on established HTTP data from the client. The reset appears to come from the server IP, but the TTL tells a different story.

Filter resets:

tcp.flags.reset == 1

In the packet list, resets show [RST] or [RST, ACK] in the Info column. Wireshark's default colouring rules also draw them with a dark background and red text, so they stand out while scrolling.

On a busy capture, that filter may list resets from many unrelated sessions. Isolate the failed connection first, then inspect only the RST packets in that flow. Either method works:

• Conversation Filter — right-click any packet from the failed connection and choose Conversation Filter → TCP. Wireshark replaces the display filter with one that matches only that connection.
• Follow TCP Stream — right-click a packet from the connection and choose Follow → TCP Stream. A window opens showing the conversation as text. Close it, and the display filter stays set to tcp.stream eq N, where N is the stream number Wireshark assigned to that connection.

Then add the reset condition to the stream filter. && means "and", so both conditions must match:

tcp.stream eq 0 && tcp.flags.reset == 1

Replace 0 with the stream number shown in your display filter bar.

The pattern:

1. TCP three-way handshake completes — the server's SYN-ACK reply shows TTL 45
2. Client sends GET /
3. RST arrives from 192.168.20.2:8080 with TTL 64

The RST source IP matches the server, but the TTL does not match the baseline. If this really came from the same server, why did its TTL suddenly jump from 45 to 64? That mismatch is the clue: the reset likely did not follow the same routed path as genuine server replies.

Click the RST packet, expand Internet Protocol Version 4 in the details pane, and read Time to Live:

What the TTL mismatch tells you

Treat the TTL difference as evidence, not a verdict.

In a real capture, you usually do not know the sender's initial TTL, so the exact numbers matter less than the change from the established baseline.

Vendor middleboxes (firewalls, IPS, proxies) often inject TCP resets when they block a session. SonicWall and Fortinet document TTL comparison as one way to tell whether a reset came from an intermediate device rather than the remote host.

TTL is one clue, not the only one. If you need stronger evidence, compare the suspicious RST with normal packets for TCP options, timestamps, IP ID behavior, and sequence/acknowledgment consistency, or capture on both sides of the suspected device.

Reproduce the failure (Linux network namespaces)

You do not need to reproduce this lab to use the troubleshooting method; the setup below only explains how the captures used in this article were generated.

The captures come from a three-namespace lab — no GNS3 routers and no hand-edited packet fields in Wireshark:

  client (192.168.10.2)
           |
      [ router / fw ]
           |
  server (192.168.20.2)

Why TTL 46? The lab deliberately changes the server's initial TTL to 46, so traffic crossing the router arrives at the client with an easy-to-recognize baseline of 45. Real hosts more commonly start at values such as 64, 128, or 255; the exact number is not important.

ip netns exec server sysctl -qw net.ipv4.ip_default_ttl=46

On the firewall namespace, nftables injects a TCP reset on established HTTP data from the client:

ip netns exec fw nft add rule ip filter forward ct state established \
  ip saddr 192.168.10.2 tcp dport 8080 tcp flags psh \
  reject with tcp reset

Captures were taken on the client namespace with tcpdump while curl fetched the HTTP page — once before the firewall rule and once after. The screenshots in this article use ttl-baseline-success.pcapng and ttl-rst-firewall.pcapng, with genuine TTL values and no hand-edited fields.

Optional: Verify TTL from TShark

TShark applies the same display filters when you need a quick terminal view of a large PCAP.

List TCP resets with source, destination, and TTL:

tshark -r ttl-rst-firewall.pcapng \
  -Y 'tcp.flags.reset == 1' \
  -T fields \
  -e frame.number \
  -e ip.src \
  -e ip.dst \
  -e ip.ttl

Sample output from the lab RST capture:

5	192.168.20.2	192.168.10.2	64

Summarize TTL values grouped by source address:

tshark -r ttl-rst-firewall.pcapng -q -z ip_ttl,tree

TShark is included with Wireshark on Windows, Linux, and macOS. For interactive comparison, the Wireshark GUI with a TTL column is usually faster.

When TTL cannot prove the source

TTL comparison is powerful but has limits:

• Different initial TTL defaults — Linux often uses 64; some network gear starts at 255
• Asymmetric routing — forward and return paths may decrement TTL differently
• Tunnels and MPLS — extra encapsulation can change what you observe at the capture point
• TTL modification — some devices rewrite TTL for visibility or policy reasons
• Capture location — a SPAN port or cloud vSwitch may not show the same hop count as the application host

Use TTL together with routing knowledge, TCP retransmission checks, and firewall logs. Treat a large TTL gap as strong evidence that the RST was not generated by the same endpoint under the same path conditions as the normal server traffic — not as automatic proof of a specific vendor or rule.

IPv6 Hop Limit

IPv6 does not have an IPv4 TTL field. The equivalent is Hop Limit:

Filter IPv6 hop limit with ipv6.hlim. The same baseline-versus-anomaly comparison applies to middlebox resets on IPv6 traffic.

TTL troubleshooting cheat sheet

Summary

TTL troubleshooting in Wireshark starts with ip.ttl and a TTL column on the packet list. Capture a healthy session first so you know the normal observed TTL for genuine server traffic. When a TCP reset appears, compare its TTL to that baseline.

In the lab, server packets consistently show TTL 45 while the injected RST shows 64 — strong evidence that the RST was not generated by the same endpoint under the same path conditions as the normal server traffic, even though the source IP matches the server. That pattern is common when a firewall or security appliance sends reject with tcp reset on a forwarded flow.

TTL alone cannot name the device, but together with reset filters and a known-good capture it quickly separates remote server behavior from middlebox interference. For more display filters, see the Wireshark tutorial and the IP filters cheat sheet.

References

• Wireshark IPv4 TTL display filter reference
• Wireshark Wiki — TCP
• RFC 791 — Internet Protocol (TTL field)
• Wireshark Q&A — TTL on RST vs normal server traffic