Ping And Traceroute - Learning Module

Loading content...

0/228

TTL Manipulation: Controlling Packet Scope and Lifespan

The Packet Lifespan Controller

Every IP packet carries a countdown timer called the Time-To-Live (TTL)—a field that determines how far a packet can travel before routers are required to discard it. This seemingly simple mechanism, designed to prevent packets from circulating forever in routing loops, has become a powerful tool for network diagnostics, security reconnaissance, and traffic engineering.

We've already seen how traceroute exploits TTL to map network paths. But TTL manipulation goes far deeper:

OS Fingerprinting: Each operating system uses characteristic default TTL values, revealing system identity
Scoped Delivery: Limiting how far packets can travel (LAN-only, single-hop, N-hop radius)
Stealth Reconnaissance: Probing networks while appearing to be local traffic
Loop Prevention: The original purpose—ensuring misbehaving networks can't overwhelm the Internet
Debugging Asymmetric Paths: Understanding return path hop counts from TTL values

This page explores TTL in depth—from the mechanics of decrement-and-discard, through OS defaults and fingerprinting, to advanced manipulation techniques.

What You Will Master

By the end of this page, you will understand TTL mechanics in both IPv4 and IPv6, identify operating systems by their TTL values, manipulate TTL for scoped packet delivery, recognize security implications of TTL analysis, and apply TTL-based techniques in advanced network diagnostics.

TTL Mechanics: From Seconds to Hops

The TTL field occupies 8 bits in the IPv4 header (and is renamed Hop Limit in IPv6's simpler header). Despite the name 'Time-To-Live,' modern implementations treat it as a hop counter, not a timer.

Historical Context: The Original Time-Based Design

RFC 791 (September 1981) defined TTL as:

"The time to live is an indication of an upper bound on the lifetime of an internet datagram. It is measured in units of seconds."

The original vision: routers would decrement TTL by the number of seconds a packet spent in their queues. A TTL of 64 meant the packet could survive 64 seconds of combined queuing and processing.

Why This Changed:

In practice, packets spent milliseconds (not seconds) at each router. Measuring actual time spent was complex and rarely exceeded 1 second. So implementations simplified:

Treat TTL as a hop counter
Decrement by 1 at each router (regardless of time spent)
Discard when TTL reaches 0

This simplification standardized behavior and made TTL predictable for tools like traceroute.

TTL Field in IPv4 Header

Text

┌─────────────────────────────────────────────────────────────────────┐
│                         IPv4 Header (20 bytes)                       │
├─────┬─────┬─────────────┬───────────────────────────────────────────┤
│ Byte│ Bits│    Field    │             Description                   │
├─────┼─────┼─────────────┼───────────────────────────────────────────┤
│  0  │ 0-3 │   Version   │ Always 4 for IPv4                         │
│  0  │ 4-7 │     IHL     │ Header Length in 32-bit words             │
│  1  │ 0-7 │     ToS     │ Type of Service / DSCP                    │
│ 2-3 │ 0-15│ Total Length│ Entire packet size                        │
│ 4-5 │ 0-15│ Identifier  │ Fragmentation ID                          │
│  6  │ 0-2 │    Flags    │ DF, MF bits                               │
│ 6-7 │3-15 │ Frag Offset │ Fragment position                         │
│  8  │ 0-7 │   *** TTL ***│ ← TIME TO LIVE (hop counter)            │
│  9  │ 0-7 │  Protocol   │ Next protocol (1=ICMP, 6=TCP, 17=UDP)     │
│10-11│ 0-15│  Checksum   │ Header checksum                           │
│12-15│ 0-31│  Source IP  │ Sender's IP address                       │
│16-19│ 0-31│   Dest IP   │ Recipient's IP address                    │
└─────┴─────┴─────────────┴───────────────────────────────────────────┘
 
IPv6 equivalent:
┌─────────────────────────────────────────────────────────────────────┐
│                      IPv6 Header (40 bytes)                         │
├─────┬─────┬─────────────┬───────────────────────────────────────────┤
│ Byte│ Field           │             Description                    │
├─────┼─────────────────┼────────────────────────────────────────────┤
│ 0-3 │ Ver/TC/Flow     │ Version(4b), Traffic Class(8b), Flow(20b)  │
│ 4-5 │ Payload Length  │ Size of data following header              │
│  6  │ Next Header     │ Type of next header (like Protocol in v4)  │
│  7  │ *** Hop Limit ***│ ← RENAMED from TTL, same function        │
│ 8-23│ Source Address  │ 128-bit source IPv6 address                │
│24-39│ Dest Address    │ 128-bit destination IPv6 address           │
└─────┴─────────────────┴────────────────────────────────────────────┘

Router TTL Processing:

When a router receives a packet:

Check TTL: If TTL ≤ 1, do NOT forward
Decrement TTL: Subtract 1 from TTL value
Recompute checksum: TTL change invalidates header checksum
Forward or Discard:
- If TTL became 0: Discard packet, send ICMP Time Exceeded
- If TTL > 0: Forward to next hop

The ICMP Time Exceeded Message:

ICMP Time Exceeded Message Fields
Field	Value	Meaning
Type	11	Time Exceeded
Code 0	TTL exceeded in transit	Packet expired during forwarding
Code 1	Fragment reassembly time exceeded	Not all fragments arrived in time
Payload	Original IP header + 8 bytes	Helps sender identify which packet expired

Maximum TTL Value

TTL is an 8-bit field, so maximum value is 255. This limits packets to at most 255 hops. In practice, the longest Internet paths are typically under 30 hops, making 255 far more than sufficient. Setting TTL=255 effectively means 'no hop limit within normal networks.'

Default TTL Values by Operating System

Different operating systems use different default TTL values. This variance, while seemingly arbitrary, has become a reliable indicator for identifying remote operating systems—a technique known as OS fingerprinting.

Default TTL Values by Operating System
Operating System	Default TTL (IPv4)	Default Hop Limit (IPv6)	Notes
Windows (all modern versions)	128	128	Consistent since Windows NT
Linux (kernel 2.4+)	64	64	Changed from 64 in older kernels
macOS / iOS	64	64	BSD heritage
FreeBSD / OpenBSD / NetBSD	64	64	Traditional BSD value
Cisco IOS	255	255	Maximum for network equipment
Juniper JunOS	64	64	FreeBSD-based
Solaris	255	255	Legacy Sun value
HP-UX	255	255	Legacy HP value
AIX	60	60	Unique IBM value
Android	64	64	Linux-based
IoT devices (varies)	64 or 255	64 or 255	Depends on embedded OS

OS Fingerprinting from TTL:

When you ping a remote host, the TTL in the reply reveals information:

# Calculate original TTL from observed TTL
Original TTL = observed_TTL rounded up to nearest standard value (64, 128, 255)
Hops traversed = Original TTL - observed TTL

Real-World Examples:

OS Fingerprinting from TTL
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# Ping reply with TTL=56
# Analysis: 
#   56 is close to 64 (within 8 hops) → Likely Linux/BSD/macOS
#   Hops = 64 - 56 = 8 hops away
 
# Ping reply with TTL=116
# Analysis:
#   116 is close to 128 (within 12 hops) → Likely Windows
#   Hops = 128 - 116 = 12 hops away
 
# Ping reply with TTL=246  
# Analysis:
#   246 is close to 255 (within 9 hops) → Likely Cisco/Solaris
#   Hops = 255 - 246 = 9 hops away
 
# Ping reply with TTL=52
# Analysis:
#   Could be Linux (64-12=52) or AIX (60-8=52)
#   Need additional fingerprinting to distinguish
 
# Practical fingerprinting script:
identify_os() {
    ttl=$1
    if [ $ttl -le 64 ]; then
        if [ $ttl -le 60 ]; then
            echo "Possibly AIX (original TTL 60) or Linux (64, many hops)"
        else
            echo "Likely Linux/BSD/macOS (original TTL 64)"
        fi
        echo "Estimated hops: $((64 - ttl)) (if Linux/BSD)"
    elif [ $ttl -le 128 ]; then
        echo "Likely Windows (original TTL 128)"
        echo "Estimated hops: $((128 - ttl))"
    else
        echo "Likely network equipment or Solaris (original TTL 255)"
        echo "Estimated hops: $((255 - ttl))"
    fi
}
 
# Usage:
# identify_os 116
# Output: Likely Windows (original TTL 128), Estimated hops: 12

Fingerprinting Caveats

TTL fingerprinting is not definitive: (1) Administrators can change default TTL values, (2) Firewalls and routers can normalize TTL, (3) Asymmetric routing means hop count may differ from traceroute, (4) VPNs and tunnels add hidden hops. Use TTL as one data point among many, not a conclusive identification.

Modifying TTL Values: Platform-Specific Techniques

TTL can be modified for individual packets (using tool options) or system-wide (for all outgoing traffic). Let's examine both approaches:

Per-Packet TTL Setting (Diagnostic Tools):

Ping TTL Options by Platform
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# === PING TTL OPTIONS ===
 
# Linux: Use -t option
ping -t 10 google.com        # Set TTL to 10
ping -t 1 google.com         # Only reaches first hop (like traceroute)
 
# Windows: Use -i option (confusingly named)
ping -i 10 google.com        # Set TTL to 10
 
# macOS: Use -m option
ping -m 10 google.com        # Set TTL to 10
 
# BSD: Use -T ttl option (note: -T has different meaning on Linux!)
ping -T 10 google.com        # Set TTL to 10 (BSD)
 
# === TRACEROUTE TTL OPTIONS ===
 
# Start at specific TTL (skip early hops)
traceroute -f 5 google.com   # First TTL is 5, not 1
 
# Set maximum TTL (stop early)
traceroute -m 15 google.com  # Stop at hop 15, don't go to 30
 
# Combined: test only specific hop range
traceroute -f 8 -m 12 google.com  # Only test hops 8-12
 
# === NETCAT / SOCAT TTL ===
 
# Linux netcat with TTL (requires recent versions)
# Not directly supported - use raw sockets or iptables
 
# === NMAP TTL OPTIONS ===
 
# Set TTL for all probe packets
nmap --ttl 64 192.168.1.0/24
 
# Use TTL for OS detection
nmap -O --osscan-guess 192.168.1.1

System-Wide TTL Modification:

Changing the default TTL for all outgoing packets from a system:

System-Wide TTL Configuration
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# === LINUX: sysctl interface ===
 
# View current default TTL
cat /proc/sys/net/ipv4/ip_default_ttl
# Typical output: 64
 
# Temporarily change default TTL (reverts on reboot)
sudo sysctl -w net.ipv4.ip_default_ttl=128
 
# Verify change
cat /proc/sys/net/ipv4/ip_default_ttl
# Output: 128
 
# Permanently change (survives reboot)
echo "net.ipv4.ip_default_ttl=128" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
 
# IPv6 hop limit
cat /proc/sys/net/ipv6/conf/default/hop_limit
sudo sysctl -w net.ipv6.conf.default.hop_limit=128
 
# === WINDOWS: Registry modification ===
 
# Open Registry Editor (regedit)
# Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
# Create/modify DWORD value: DefaultTTL
# Set to desired value (e.g., 64 to mimic Linux)
 
# Via PowerShell (run as Administrator):
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "DefaultTTL" -Value 64 -Type DWord
 
# Verify:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "DefaultTTL"
 
# Reboot required for change to take effect
 
# === macOS: sysctl interface ===
 
# View current default
sudo sysctl net.inet.ip.ttl
# Output: net.inet.ip.ttl: 64
 
# Temporarily change
sudo sysctl -w net.inet.ip.ttl=128
 
# Persistent change: add to /etc/sysctl.conf (may need to create)
echo "net.inet.ip.ttl=128" | sudo tee -a /etc/sysctl.conf

Why Change System TTL?

Common reasons to modify default TTL: (1) Security through obscurity—make Linux appear as Windows or vice versa, (2) Testing—verify application behavior with constrained packet lifetimes, (3) Compliance—some networks require specific TTL values, (4) Tunneling—compensate for hop overhead in VPN/tunnel encapsulation.

Scoped Packet Delivery: Controlling Reach

TTL provides a powerful mechanism for limiting how far packets can travel—a technique called scoped delivery. This is particularly useful for:

Local-only services: Ensuring traffic never leaves the LAN
Hop-limited discovery: Finding only nearby devices
Preventing accidental Internet exposure: Services that should never be routed
Multicast TTL scoping: Controlling multicast propagation radius

TTL Scoping Levels
TTL Value	Scope	Typical Use Case
1	Local link only	Link-local discovery, mDNS/Bonjour, OSPF hello
2	Same network segment	Services for adjacent devices
15	Site-local (historically)	Campus/building-wide services
32	Regional	Metro-area services
64	National	Default for most systems
128	Continental	Cross-region Services
255	Unrestricted	Global, no hop limit concern

TTL=1: Link-Local Only

The most restrictive scope. With TTL=1, packets expire at the first router—they can only reach devices on the same network segment:

TTL=1 Link-Local Scoping
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Discover only devices on local network segment
# (won't traverse any routers)
 
# Ping scan with TTL=1 (Linux)
for ip in 192.168.1.{1..254}; do
    ping -t 1 -c 1 -W 0.1 $ip 2>/dev/null | grep "64 bytes" &
done
wait
 
# nmap with TTL=1
nmap --ttl 1 -sn 192.168.1.0/24
 
# Protocols that use TTL=1 by design:
# - OSPF Hello packets (link-local discovery)
# - RIP (should only reach adjacent routers)
# - VRRP/HSRP (router redundancy)
# - mDNS/Bonjour (local service discovery)
# - IGMP (multicast group management)
 
# Example: Send multicast with TTL=1 for local-only
socat - UDP-DATAGRAM:224.0.0.1:5000,ttl=1

Multicast TTL Scoping:

Multicast traffic uses TTL to define propagation scope. This is critical for preventing local traffic from flooding the Internet:

Multicast TTL Scoping Thresholds (RFC 2365)
TTL Range	Scope Name	Meaning
0	Same host	Loopback only
1	Same subnet	Link-local
< 32	Same site	Organization-local
< 64	Same region	Regional scope
< 128	Same continent	Continental scope
< 255	Global	Worldwide (unrestricted)

Multicast TTL Control
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Python: Send multicast with specific TTL
import socket
 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
 
# Set TTL for multicast (using IP_MULTICAST_TTL)
TTL = 1  # Link-local only
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, TTL)
 
# Send to multicast group
sock.sendto(b"Hello local network", ("224.0.0.1", 5000))
 
# TTL thresholds are often configured on routers:
# interface GigabitEthernet0/1
#   ip multicast ttl-threshold 32      # Block TTL < 32
 
# This prevents site-local multicast from leaving the organization

Application-Level TTL Control

Many applications set TTL explicitly. Docker containers often use TTL-based health checks with TTL=1 to verify local connectivity. Kubernetes pod-to-pod communication may use low TTL values. Service mesh proxies like Envoy can manipulate TTL for traffic scoping. Understanding TTL helps debug why certain cross-network traffic mysteriously fails.

TTL-Based Security Techniques

TTL manipulation plays important roles in both offensive security (reconnaissance) and defensive security (protection). Understanding both perspectives is essential for network security professionals.

Offensive: TTL-Based Network Reconnaissance

Attackers use TTL for stealthy network mapping:

TTL Reconnaissance Techniques
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Technique 1: OS Fingerprinting from TTL
# Already covered - determine target OS from TTL values
 
# Technique 2: Distance Mapping
# Determine how many hops between you and the target
# Useful for understanding network topology
 
# Technique 3: TTL-based Firewall Evasion
# Some firewalls only inspect packets with TTL > threshold
# Send probes with TTL that expires just past the firewall
 
# Example: Firewall at hop 3, target at hop 5
# Normal scan: Firewall blocks at hop 3
nmap 192.168.10.50  # Blocked
 
# TTL-crafted scan: Set TTL=5 (enough to reach target)
# But ICMP Time Exceeded from firewall reveals it exists
nmap --ttl 5 192.168.10.50
 
# Technique 4: Discover Hidden Hops
# Send packets with incrementing TTL, map each response
# Can reveal firewalls, load balancers, proxies that might 
# otherwise be transparent
 
# Technique 5: Fragment/TTL Combined Attacks
# Send first fragment with low TTL (expires, reveals router)
# Send second fragment with normal TTL (bypasses stateless filter)

Defensive: TTL-Based Protection

Network defenders can use TTL to enhance security:

Defensive TTL Techniques

•Generalized TTL Security Mechanism (GTSM): RFC 5082 specifies setting TTL=255 for BGP peers. If received TTL < 254, the packet traversed at least one hop and likely came from an attacker, not an adjacent peer. Protects against spoofed BGP session attacks.
•TTL Normalization: Firewalls can reset all outgoing packets to a fixed TTL value, preventing OS fingerprinting based on TTL variations.
•TTL Threshold Filtering: Block packets with TTL below a threshold to prevent certain reconnaissance techniques or limit multicast scope.
•Anomaly Detection: Sudden changes in TTL values from known hosts may indicate spoofing, routing changes, or man-in-the-middle attacks.
•Anti-Traceroute: Set routers to not decrement TTL or not generate Time Exceeded, obscuring network topology from attackers.

GTSM Configuration Examples
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Cisco IOS: Enable GTSM for BGP peer
router bgp 65001
  neighbor 10.0.0.1 ttl-security hops 1
  # Packets from 10.0.0.1 must have TTL >= 254
  # (255 - 1 hop = 254)
 
# Juniper JunOS: GTSM equivalent
protocols {
    bgp {
        group external-peers {
            neighbor 10.0.0.1 {
                multihop {
                    ttl 1;  # Expect neighbor to be 1 hop away
                }
            }
        }
    }
}
 
# iptables: TTL-based filtering (Linux)
# Accept only packets from directly connected hosts (TTL=64 or 128)
iptables -A INPUT -m ttl --ttl-gt 127 -j ACCEPT
iptables -A INPUT -m ttl --ttl-lt 64 -j DROP
iptables -A INPUT -j ACCEPT  # TTL 64-127 also accepted
 
# iptables: TTL normalization 
# Reset all outgoing TTL to 64 (obscure OS fingerprint)
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64

GTSM: Critical BGP Protection

GTSM is considered essential for BGP security. Without it, attackers anywhere on the Internet can attempt to hijack BGP sessions by spoofing the source address of your BGP peer. With GTSM enabled, packets must have TTL=255 (only possible if they truly originated one hop away), making remote spoofing impossible.

Advanced TTL Diagnostics

Beyond basic ping and traceroute, TTL enables sophisticated diagnostic techniques:

Asymmetric Path Detection

If forward and return paths differ, TTL values can reveal this:

Asymmetric Path Analysis
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Step 1: Traceroute shows forward path has 12 hops
$ traceroute -n target.example.com
 1  192.168.1.1      ...
 ...
12  target.example.com   25.3 ms
 
# Step 2: Ping shows received TTL=116
$ ping -c 1 target.example.com
64 bytes from target.example.com: icmp_seq=1 ttl=116 time=25.4 ms
 
# Analysis:
# Forward path: 12 hops (from traceroute)
# Return path TTL: 128 - 116 = 12 hops (assuming Windows target)
# 
# Paths appear symmetric (both 12 hops)!
 
# Now consider this scenario:
$ traceroute -n server2.example.com
 ...
 8  server2.example.com   45.2 ms
 
$ ping -c 1 server2.example.com  
64 bytes from server2.example.com: icmp_seq=1 ttl=50 time=42.1 ms
 
# Analysis:
# Forward path: 8 hops
# Return path: 64 - 50 = 14 hops (assuming Linux target)
#
# ASYMMETRIC! Return path has 6 more hops than forward path
# This explains why RTT might be higher than expected

Hidden Hop Detection

Some network devices are 'invisible' to traceroute but still decrement TTL. Comparing expected vs actual TTL can reveal their presence:

Hidden Hop Detection
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Traceroute shows 5 hops to destination
$ traceroute -n 10.20.30.40
 1  192.168.1.1    0.5 ms
 2  10.0.0.1       8.2 ms
 3  172.16.0.1    12.3 ms
 4  203.0.113.1   15.6 ms
 5  10.20.30.40   18.2 ms   # Destination at hop 5
 
# But ping shows TTL=57
$ ping -c 1 10.20.30.40
64 bytes from 10.20.30.40: icmp_seq=1 ttl=57 time=17.9 ms
 
# Analysis: TTL=57 means 64-57 = 7 hops on return path
# But we only saw 5 hops in traceroute!
#
# Conclusion: 2 hidden hops exist (possibly):
# - Transparent firewall
# - Load balancer
# - NAT device
# - MPLS label switch router
 
# Advanced technique: TTL-vary ping
# Send pings with different TTL to find hidden hops
for ttl in $(seq 1 10); do
    echo "TTL=$ttl: $(ping -t $ttl -c 1 -W 1 10.20.30.40 2>&1 | grep -E 'From|bytes')"
done

TTL Variance as Health Indicator

In stable networks, TTL values from a given host should be consistent. Variations may indicate problems:

TTL Variance Interpretation
TTL Pattern	Possible Cause	Action
Consistent TTL (e.g., always 56)	Stable routing, healthy network	Normal - no action needed
Alternating TTL (56, 57, 56, 57...)	Load balancing with unequal paths	Investigate if problematic for application
Gradual TTL decrease over time	Route change, path lengthening	Check for routing issues or BGP changes
Sudden TTL jump	Failover event, route change	May indicate link/router failure
Random TTL variations	Severe instability, multiple routes flapping	Urgent: investigate routing problems

TTL Monitoring Script

For production monitoring, log TTL values over time and alert on variance. A simple 'while ping... | grep ttl' loop piped to a file provides a TTL timeline. More sophisticated monitoring systems (Prometheus, Grafana) can graph TTL as a metric for path stability visualization.

TTL in Tunneling and VPNs

Tunneling and VPN technologies create interesting TTL scenarios. Understanding how TTL behaves across tunnels is essential for diagnosing connectivity issues in overlay networks.

TTL Handling in Tunnels:

When a packet enters a tunnel, the original packet (with its TTL) is encapsulated inside a new outer packet (with its own TTL). Two key questions arise:

What TTL does the outer packet get?
How does the inner TTL change?

TTL Handling by Tunnel Type
Tunnel Type	Outer TTL Source	Inner TTL Behavior	Notes
GRE (default)	Copied from inner	Unchanged	Traceroute works across tunnel
GRE (ttl set)	Configured value	Unchanged	Tunnel hops visible in traceroute
IPSec Tunnel Mode	New (usually 64)	Hidden until decapsulation	Hides internal topology
VXLAN	Fixed (typically 64)	Unchanged	Overlay hops mostly hidden
Wireguard	Configured or default	Unchanged	Single hop visible to traceroute

Tunnel TTL Behavior
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Scenario: Host A → Tunnel → Host B
# 
# Without tunnel: A ──(5 hops)──> B
#   Packet TTL: 64 → 59 at destination
#
# With GRE tunnel (copy inner TTL):
#   A ──(2 hops)──> Tunnel Entry ══(3 hops)══> Tunnel Exit ──(1 hop)──> B
#   Inner TTL: 64 → 62 → 59 → 58 at B (all hops counted)
#   Outer TTL: 62 → 59 (only tunnel transit counted)
#
# With IPSec tunnel mode (new outer TTL):
#   A ──(2 hops)──> Tunnel Entry ══(3 hops)══> Tunnel Exit ──(1 hop)──> B  
#   Inner TTL: 64 → 62 → stays 62 inside tunnel → 61 → 60 at B
#   Outer TTL: 64 (new) → 61 at tunnel exit
#   Result: Only 4 hops counted (not 6!) - tunnel hops "hidden"
 
# GRE TTL configuration (Cisco)
interface Tunnel0
  ip address 10.0.0.1 255.255.255.0
  tunnel source GigabitEthernet0/0
  tunnel destination 203.0.113.1
  tunnel ttl 64  ! Set outer TTL to 64 instead of copying
 
# IPSec TTL behavior
# Most IPSec implementations:
# - Outer TTL: Fresh value (64 or 128)
# - Inner TTL: Decremented only when entering/exiting tunnel (2 decrements)
# This is why VPN connections "hide" hop count

Traceroute Through Tunnels:

Traceroute behavior depends on tunnel TTL handling:

# GRE with TTL copy (transparent tunnel):
1  local-router         0.5 ms
2  isp-router            8.2 ms
3  gre-peer1            15.3 ms   # First tunnel hop
4  gre-peer2            18.7 ms   # Second tunnel hop  
5  tunnel-exit          22.1 ms
6  destination          25.6 ms

# IPSec tunnel mode (opaque tunnel):
1  local-router          0.5 ms
2  isp-router             8.2 ms
3  ipsec-gateway         15.3 ms   # Tunnel entry
4  remote-ipsec-gateway  45.6 ms   # Tunnel exit (huge jump!)
5  destination           48.2 ms

# The 30ms 'jump' at hop 4 represents ALL tunnel transit combined

VPN TTL Implications

Corporate VPNs typically use IPSec tunnel mode, which hides internal hops. This is good for security (attackers can't map internal topology) but complicates troubleshooting. If you observe a large RTT jump at a single hop, you may be seeing a tunnel encapsulating multiple physical hops. The real path is hidden inside.

Summary: Mastering TTL Manipulation

We've explored TTL from basic mechanics to advanced security and diagnostic applications. Let's consolidate the essential knowledge:

Key Takeaways

•TTL is a hop counter, not a timer: Despite the name 'Time-To-Live,' modern implementations decrement by 1 at each router regardless of time spent.
•Default TTL reveals operating systems: Windows uses 128, Linux/BSD/macOS use 64, network equipment typically uses 255. This enables OS fingerprinting.
•TTL can be modified per-packet or system-wide: Tools like ping and traceroute have TTL options; sysctl/registry changes affect all traffic.
•Low TTL enables scoped delivery: TTL=1 restricts traffic to the local network segment—essential for protocols like OSPF and mDNS.
•GTSM uses TTL for BGP security: Requiring TTL=255 ensures BGP packets come from directly connected peers, preventing remote spoofing attacks.
•TTL variance indicates routing problems: Stable networks show consistent TTL; variations suggest load balancing, route changes, or path instability.
•Tunnels interact with TTL in complex ways: GRE copies inner TTL (transparent); IPSec uses new outer TTL (hides topology). Understanding this aids VPN troubleshooting.

What's Next:

With TTL mastered, we'll complete this module with Diagnostic Usage—a comprehensive guide to applying ping, traceroute, and TTL techniques in real-world troubleshooting scenarios. You'll learn systematic methodologies used by professional network engineers to diagnose connectivity, performance, and routing issues efficiently.

Page Complete

You now understand TTL at an expert level—from its historical origins and mechanical operation, through OS fingerprinting and scoped delivery, to security applications like GTSM and tunnel interactions. This knowledge transforms TTL from a simple header field into a powerful diagnostic and security tool in your network engineering arsenal.