LFCE 33 🐧 IPIP Tunnels
IPIP (IP-in-IP) is the simplest tunnel protocol the Linux kernel supports. It encapsulates an IPv4 packet inside another IPv4 packet, adding exactly one outer IP header and nothing else. There is no GRE header, no UDP header, and no key field. The result is the lowest overhead of any IP tunnel: 20 bytes on a standard IPv4 underlay . The trade-off is equally simple: IPIP carries only IPv4 unicast traffic. It cannot transport multicast, IPv6, or routing protocols like OSPF that depend on multicast for adjacency formation .
For the LFCE candidate, IPIP is the baseline tunnel. GRE and VXLAN are more capable, but IPIP is the one that does the least and does it most efficiently. It appears in simple site-to-site connectivity scenarios where the requirement is strictly IPv4-over-IPv4 and the performance cost of additional headers matters. The configuration is nearly identical to GRE, with the mode changed from gre to ipip and the feature set reduced to the minimum.
Key point: IPIP adds 20 bytes of overhead, the size of the outer IPv4 header. On a 1500-byte underlay, the tunnel interface MTU is automatically set to 1480 bytes . IPIP uses IP protocol number 4, not 47 (GRE) or 17 (UDP). A firewall that blocks protocol 4 will silently drop the encapsulated traffic, and the tunnel will appear to be up while carrying nothing.
Why IPIP tunnels exist
The minimal-overhead problem.
GRE adds a 4-byte header on top of the outer IP header, bringing the overhead to 24 bytes. VXLAN adds 50 bytes. For applications where every byte of payload matters and the traffic is strictly IPv4 unicast, IPIP provides the smallest possible encapsulation. The difference between 20 and 24 bytes is negligible for most workloads, but in high-throughput scenarios or when the underlay MTU is already constrained, the minimal header is the correct choice .
The simplicity problem.
IPIP has no key field, no sequence numbers, no checksums, and no peer discovery. The configuration is a pair of endpoint addresses and an overlay address. There is nothing else to negotiate, no FDB to populate, and no multicast group to join. For a point-to-point link between two routers that need IPv4 connectivity, IPIP is the configuration with the fewest moving parts .
The compatibility problem.
IPIP is not a Linux-specific protocol. It is implemented by Cisco IOS, FreeBSD, and other network operating systems. A Linux router using IPIP can establish a tunnel with a Cisco router using the same mode. This interoperability makes IPIP a viable choice in mixed-vendor environments where GRE might also work but IPIP is simpler to configure on both sides .
a. Creating a point-to-point IPIP tunnel
An IPIP tunnel is created with ip tunnel add mode ipip. The local and remote parameters specify the underlay endpoints, exactly as they do for GRE .
# Load the ipip kernel module if it is not already loaded
modprobe ipip
# On Router A (local underlay 203.0.113.1, remote underlay 198.51.100.1)
ip tunnel add ipip1 mode ipip remote 198.51.100.1 local 203.0.113.1 ttl 255
# Assign an overlay IP address
ip addr add 10.0.0.1/30 dev ipip1
# Bring the tunnel up
ip link set ipip1 up
# Add a route for the remote private network
ip route add 192.168.2.0/24 dev ipip1The ttl 255 parameter sets the outer header’s TTL. Without it, the kernel inherits the TTL from the inner packet, which can cause the encapsulated packet to expire before reaching the remote endpoint if the underlay path is long . The /30 prefix provides the two addresses needed for the point-to-point overlay link.
The remote side mirrors the configuration with the local and remote addresses swapped.
# On Router B (local underlay 198.51.100.1, remote underlay 203.0.113.1)
ip tunnel add ipip1 mode ipip remote 203.0.113.1 local 198.51.100.1 ttl 255
ip addr add 10.0.0.2/30 dev ipip1
ip link set ipip1 up
ip route add 192.168.1.0/24 dev ipip1Once both sides are configured, the overlay addresses (10.0.0.1 and 10.0.0.2) are reachable through the tunnel. The private networks behind the routers can communicate if the routers forward traffic between the private interface and the tunnel interface.
b. Verifying the tunnel and its limitations
The ip -d link show command confirms the tunnel mode and endpoints. The output includes the ipip mode and the local and remote addresses, along with the automatic MTU reduction.
# Verify the tunnel configuration
ip -d link show ipip1
# Output includes: ipip remote 198.51.100.1 local 203.0.113.1 ttl 255
# MTU is 1480 (1500 minus 20 bytes of overhead)
# Confirm the MTU
ip link show ipip1 | grep mtu
# Output: mtu 1480The MTU reduction is automatic and reflects the 20-byte outer IP header. Unlike GRE, which reduces the MTU by 24 bytes to 1476, IPIP leaves four more bytes for payload . This difference is small but measurable in throughput-sensitive applications.
IPIP’s limitations become visible when the tunnel attempts to carry traffic it cannot encapsulate.
# Multicast traffic cannot traverse an IPIP tunnel
# OSPF, which uses multicast for hello packets, will not form an adjacency
ip netns exec routerA ping -c 1 224.0.0.5
# The ping fails because IPIP does not carry multicast
# IPv6 cannot be encapsulated in IPIP
# An IPv6 packet sent through the tunnel is droppedThese are not configuration errors. They are the protocol’s boundaries. A tunnel that needs to carry multicast or IPv6 must use GRE instead .
c. Firewall and protocol considerations
IPIP uses IP protocol number 4. A firewall that permits only TCP, UDP, and ICMP will drop the encapsulated packets without any indication. The tunnel interface will report itself as up, the routes will be present, and ping across the overlay will fail with no obvious cause.
# Allow IPIP protocol 4 on both endpoints
iptables -A INPUT -p 4 -j ACCEPT
iptables -A OUTPUT -p 4 -j ACCEPT
# For nftables
nft add rule ip filter input ip protocol 4 accept
nft add rule ip filter output ip protocol 4 acceptThe ping to the remote overlay address is the definitive test. If the underlay routes between the endpoint addresses but the overlay ping fails, the firewall is the first place to check. If the underlay itself cannot route between the endpoints, the tunnel will not work regardless of the firewall configuration.
Complete Example Session
# ============================================
# PART 1: LOAD THE IPIP MODULE
# ============================================
modprobe ipip
lsmod | grep ipip
# ============================================
# PART 2: CREATE THE TUNNEL INTERFACE
# ============================================
ip tunnel add ipip1 mode ipip remote 198.51.100.1 local 203.0.113.1 ttl 255
# ============================================
# PART 3: ASSIGN THE OVERLAY ADDRESS
# ============================================
ip addr add 10.0.0.1/30 dev ipip1
# ============================================
# PART 4: BRING UP THE TUNNEL
# ============================================
ip link set ipip1 up
# ============================================
# PART 5: VERIFY THE CONFIGURATION
# ============================================
ip -d link show ipip1
# Output confirms ipip mode and endpoints
ip link show ipip1 | grep mtu
# Output: mtu 1480
# ============================================
# PART 6: ALLOW PROTOCOL 4 IN THE FIREWALL
# ============================================
iptables -A INPUT -p 4 -j ACCEPT
iptables -A OUTPUT -p 4 -j ACCEPT
# ============================================
# PART 7: CONFIGURE THE REMOTE ENDPOINT
# ============================================
# On Router B:
# ip tunnel add ipip1 mode ipip remote 203.0.113.1 local 198.51.100.1 ttl 255
# ip addr add 10.0.0.2/30 dev ipip1
# ip link set ipip1 up
# iptables -A INPUT -p 4 -j ACCEPT
# ============================================
# PART 8: TEST OVERLAY CONNECTIVITY
# ============================================
ping -c 2 10.0.0.2
# ============================================
# PART 9: ADD A ROUTE FOR THE REMOTE PRIVATE NETWORK
# ============================================
ip route add 192.168.2.0/24 dev ipip1
ip route get 192.168.2.10
# Output confirms the route uses ipip1
# ============================================
# PART 10: VERIFY ENCAPSULATION AND LIMITATIONS
# ============================================
tcpdump -i eth0 -n proto 4
# Output shows outer IP headers with protocol 4
# Multicast is not carried
ping -c 1 -W 1 224.0.0.5
# Fails, confirming IPIP's multicast limitationThe ten parts demonstrate the complete IPIP lifecycle: module loading, tunnel creation, overlay addressing, MTU verification, firewall configuration, remote endpoint setup, connectivity testing, route configuration, and limitation confirmation. The critical verifications are Part 5 (MTU is 1480) and Part 10 (multicast fails, confirming the protocol boundary).
Quick Reference
IPIP Configuration Commands
| Task | Command |
|---|---|
| Load module | modprobe ipip |
| Create tunnel | ip tunnel add <name> mode ipip remote <peer> local <self> ttl 255 |
| Show tunnel | ip tunnel show <name> |
| Verify mode | ip -d link show <name> |
| Assign overlay IP | ip addr add <addr>/30 dev <name> |
| Bring up | ip link set <name> up |
| Add route | ip route add <network> dev <name> |
| Delete tunnel | ip tunnel del <name> |
IPIP vs GRE
| Property | IPIP | GRE |
|---|---|---|
| Protocol number | 4 | 47 |
| Overhead | 20 bytes | 24 bytes |
| MTU (1500 underlay) | 1480 | 1476 |
| IPv4 unicast | Yes | Yes |
| IPv6 payload | No | Yes |
| Multicast | No | Yes |
| Key field | No | Yes |
| Complexity | Lowest | Medium |
MTU Overhead
| Underlay MTU | IPIP MTU | Overhead |
|---|---|---|
| 1500 | 1480 | 20 bytes |
| 9000 | 8980 | 20 bytes |
Best Practices
✅ Do This:
# Set a fixed TTL for the outer header
ip tunnel add ipip1 mode ipip remote <peer> local <self> ttl 255 # ✅
# Use a /30 for the point-to-point overlay
ip addr add 10.0.0.1/30 dev ipip1 # ✅
# Allow IP protocol 4 in the firewall
iptables -A INPUT -p 4 -j ACCEPT # ✅
# Verify the MTU is 1480 on a 1500-byte underlay
ip link show ipip1 | grep mtu # ✅
# Use GRE if multicast or IPv6 is required
# IPIP cannot carry either # ✅
# Configure both endpoints with mirrored addresses
# One-sided configuration produces a dead tunnel # ✅❌ Don’t Do This:
# Expect IPIP to carry OSPF or other multicast protocols
# IPIP is IPv4 unicast only # ❌
# Try to tunnel IPv6 through IPIP
# Use GRE or SIT for IPv6 # ❌
# Forget the firewall rule for protocol 4
# The tunnel appears up but carries no traffic # ❌
# Set the MTU to 1500 on the tunnel
# The encapsulated packet becomes 1520 bytes on the underlay # ❌
# Assume IPIP provides encryption
# IPIP is plaintext; combine with IPsec for confidentiality # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Tunnel up but no traffic | Firewall blocks protocol 4 | iptables -A INPUT -p 4 -j ACCEPT |
| Multicast routing fails over tunnel | IPIP does not carry multicast | Use GRE |
| IPv6 traffic dropped | IPIP cannot encapsulate IPv6 | Use GRE or SIT |
| Fragmentation on underlay | MTU not reduced | Verify MTU is 1480 |
| Tunnel disappears after reboot | ip tunnel add is not persistent | Configure through network manager |
Real-World Examples
1. Basic IPIP tunnel
ip tunnel add ipip1 mode ipip remote 198.51.100.1 local 203.0.113.1 ttl 2552. Assign overlay IP
ip addr add 10.0.0.1/30 dev ipip13. Verify tunnel mode
ip -d link show ipip14. Check MTU
ip link show ipip1 | grep mtu
# Output: mtu 14805. Firewall rule for protocol 4
iptables -A INPUT -p 4 -j ACCEPT6. Route remote network
ip route add 192.168.2.0/24 dev ipip17. Capture IPIP traffic
tcpdump -i eth0 -n proto 48. Delete tunnel
ip tunnel del ipip19. Load module
modprobe ipip10. Test overlay connectivity
ping -c 2 10.0.0.2Visual
IPIP Encapsulation
┌──────────────────────────────────────────────────────────────┐
│ IPIP ADDS ONLY ONE OUTER IP HEADER │
│ │
│ Original packet (private network): │
│ ┌──────────┬──────────┬───────────────────────────────┐ │
│ │ IP Header│ TCP/UDP │ Payload │ │
│ │ (private)│ Header │ │ │
│ └──────────┴──────────┴───────────────────────────────┘ │
│ │ │
│ ▼ │
│ IPIP encapsulated packet: │
│ ┌──────────┬──────────┬──────────┬───────────────────────┐ │
│ │ Outer IP │ Inner IP │ TCP/UDP │ Payload │ │
│ │ Header │ Header │ Header │ │ │
│ │ (public) │ (private)│ │ │ │
│ └──────────┴──────────┴──────────┴───────────────────────┘ │
│ │
│ Overhead: 20 bytes (outer IP header only) │
│ No GRE header, no UDP header, no key field. │
│ Underlay sees protocol 4. │
└──────────────────────────────────────────────────────────────┘IPIP vs GRE Header Size
┌──────────────────────────────────────────────────────────────┐
│ IPIP HAS THE SMALLEST TUNNEL HEADER │
│ │
│ IPIP (20 bytes overhead): │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Outer IP (20) │ Inner IP + Payload │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ GRE (24 bytes overhead): │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Outer IP (20) │ GRE (4) │ Inner IP + Payload │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ VXLAN (50 bytes overhead): │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Outer IP (20) │ UDP (8) │ VXLAN (8) │ Inner Eth (14) │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ IPIP leaves 4 more bytes for payload than GRE. │
└──────────────────────────────────────────────────────────────┘IPIP Limitations
┌──────────────────────────────────────────────────────────────┐
│ WHAT IPIP CANNOT CARRY │
│ │
│ ✅ IPv4 unicast: Supported │
│ ❌ IPv4 multicast: Not supported (no OSPF, no PIM) │
│ ❌ IPv6 payload: Not supported │
│ ❌ GRE key field: Not applicable (IPIP has no header) │
│ │
│ If the tunnel must carry multicast or IPv6: │
│ → Use GRE (mode gre) │
│ │
│ If the tunnel must carry Layer 2 frames: │
│ → Use VXLAN or GRETAP │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Protocol | IP-in-IP (IPIP) |
| Encapsulation | IPv4-in-IPv4 |
| Overhead | 20 bytes |
| Protocol number | 4 |
| MTU (1500 underlay) | 1480 |
| Configuration | ip tunnel add mode ipip |
| Multicast | Not supported |
| IPv6 payload | Not supported |
| Key field | Not supported |
| Encryption | None |
Key takeaways:
- IPIP is the simplest tunnel protocol. It adds one outer IP header and nothing else. The overhead is 20 bytes, the lowest of any IP tunnel the Linux kernel supports .
- IPIP carries only IPv4 unicast. It cannot transport multicast, IPv6, or routing protocols that depend on multicast for adjacency. If these are required, GRE is the correct choice .
- The MTU is automatically reduced to 1480. On a standard 1500-byte underlay, the 20-byte overhead leaves 1480 bytes for payload. This is four bytes more than GRE .
- IP protocol 4 must be permitted. A firewall that blocks protocol 4 will drop the encapsulated packets silently. The tunnel appears up, but no traffic flows.
- Both endpoints must be configured. The local and remote addresses are mirrored on each side. A one-sided configuration produces a dead tunnel.
- IPIP provides no encryption. The encapsulated packets are plaintext. For confidentiality, IPIP must be combined with IPsec, or replaced by a protocol that includes encryption.
Remember: IPIP is the baseline tunnel. It does the least, adds the smallest header, and carries only IPv4 unicast. Configure it with mirrored local and remote addresses, assign a /30 overlay, set the TTL, and permit protocol 4 in the firewall. Verify the MTU is 1480 and test with ping across the overlay. If the tunnel needs to carry multicast or IPv6, use GRE instead. IPIP is the correct choice only when the requirement is strictly IPv4 connectivity with the absolute minimum overhead.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!