GRE Tunnel Is UP, But Network Traffic Is Not Passing — Real-World Cisco Troubleshooting

Your GRE tunnel shows UP/UP. Your WAN links are healthy. Your routers can reach each other. But users still cannot access applications at the remote site. What went wrong?

This is one of the most important troubleshooting scenarios network engineers encounter when working with GRE tunnels.

A tunnel interface displaying up/up does not necessarily prove that packets can travel successfully between the branch LAN and the data center LAN.

In this practical Cisco troubleshooting case study, we will investigate an enterprise GRE connectivity problem, identify its root cause, implement the correction, and verify service restoration using Cisco IOS XE commands.

This is a realistic simulated incident created for networking education, not a report of an actual production outage.

1. The Network Incident

An enterprise uses a GRE tunnel to connect a branch office to its primary data center across an ISP network.

The branch users depend on applications hosted in the data center.

One morning, users report:

• Data center applications are unreachable.

• Internal servers cannot be accessed from the branch.

• The network monitoring system reports the branch WAN connection is operational.

• The GRE tunnel interface is showing up/up.

The network engineering team begins investigating.

Network Environment

2. Enterprise GRE Network Topology

The physical WAN path is called the underlay, while the logical GRE connection between R1 and R2 is called the overlay.

The ISP forwards GRE-encapsulated traffic using the outer IP addresses. It does not need routes to the internal branch and data center networks.

3. Step 1 — Check the GRE Tunnel Status

The engineer first checks R1.

R1# show ip interface brief
Interface               IP-Address       Status  Protocol
GigabitEthernet0/0/0     10.10.10.1       up      up
GigabitEthernet0/0/1     198.51.100.1     up      up
Tunnel0                  172.16.12.1      up      up

Everything initially appears healthy.

The engineer checks the detailed tunnel configuration:

R1# show interfaces Tunnel0

Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.12.1/30
  Tunnel source 198.51.100.1
  Tunnel destination 203.0.113.2
  Tunnel protocol/transport GRE/IP

What Does This Tell Us?

The interface is administratively enabled, has valid GRE tunnel settings, and satisfies the local conditions for its line protocol to be up.

However, basic GRE is a largely stateless mechanism. Without suitable keepalives or additional detection, the local router might not immediately recognize a remote tunnel failure.

Troubleshooting lesson: Never conclude that the entire network path is healthy based only on Tunnel0 status.

4. Step 2 — Verify the Physical Underlay

Before investigating the logical GRE tunnel, confirm that the physical network can reach the remote tunnel destination.

On R1:

R1# ping 203.0.113.2 source 198.51.100.1
Sending 5, 100-byte ICMP Echos to 203.0.113.2
!!!!!
Success rate is 100 percent (5/5)

The physical WAN path is reachable.

Next, verify routing:

R1# show ip route 203.0.113.2
Routing entry for 203.0.113.2/32
  Known via "static"
  Next hop: 198.51.100.2

This confirms that R1 reaches R2's tunnel destination through ISP-RTR.

Why This Check Matters

A GRE tunnel depends on IP reachability between its source and destination.

If the remote tunnel destination is unreachable, normal GRE traffic cannot successfully traverse the underlay.

In this case, the physical path is working, so the investigation continues.

5. Step 3 — Verify GRE Tunnel IP Connectivity

The engineer now tests communication between the logical tunnel IP addresses.

On R1:

R1# ping 172.16.12.2 source 172.16.12.1
Sending 5, 100-byte ICMP Echos to 172.16.12.2
!!!!!
Success rate is 100 percent (5/5)

The result confirms that GRE-encapsulated ICMP packets can reach the remote tunnel endpoint and receive responses.

At this stage, we know:

• Physical WAN connectivity works.

• The GRE tunnel is configured.

• Tunnel-to-tunnel communication works.

But the branch LAN still cannot reach the data center LAN.

This narrows the investigation to routing, forwarding, or endpoint policies beyond the tunnel endpoints.

6. Step 4 — Verify the Branch-to-Data Center Route

The engineer checks how R1 forwards traffic toward the remote LAN.

R1# show ip route 10.20.20.0

Routing entry for 10.20.20.0/24
  Known via "static"
  Next hop: 172.16.12.2

The relevant R1 static route is:

ip route 10.20.20.0 255.255.255.0 172.16.12.2

R1 knows that the data center network is reachable through the GRE tunnel.

Next, the engineer sends a test with a source address from the Branch LAN.

R1# ping 10.20.20.1 source 10.10.10.1

Sending 5, 100-byte ICMP Echos to 10.20.20.1
Packet sent with a source address of 10.10.10.1
.....
Success rate is 0 percent (0/5)

The result is significant.

The tunnel IP ping succeeds, but communication using a source IP from the branch LAN fails.

This suggests that the problem may involve the remote LAN's routing or the return path.

7. Step 5 — Investigate Return Routing on R2

The engineer connects to the data center router and checks its routing table.

R2# show ip route

C 10.20.20.0/24 is directly connected, GigabitEthernet0/0/0
L 10.20.20.1/32 is directly connected, GigabitEthernet0/0/0
C 172.16.12.0/30 is directly connected, Tunnel0
L 172.16.12.2/32 is directly connected, Tunnel0
C 203.0.113.0/30 is directly connected, GigabitEthernet0/0/1
L 203.0.113.2/32 is directly connected, GigabitEthernet0/0/1
S 198.51.100.1/32 via 203.0.113.1

Notice something important.

The route to the branch network 10.10.10.0/24 is missing.

The engineer verifies this directly:

R2# show ip route 10.10.10.10

In this simulated configuration, R2 has no matching route, including no default route.

What Happens to the Return Packet?

1. R1 sends an ICMP Echo Request sourced from 10.10.10.1.

2. The packet travels through Tunnel0 and reaches R2.

3. R2 processes the request addressed to its LAN interface 10.20.20.1.

4. R2 generates an ICMP Echo Reply destined for 10.10.10.1.

5. R2 performs a routing-table lookup for that source address.

6. No matching route exists, so R2 cannot deliver the reply.

This is the root cause of the simulated incident: a missing return route on the data center router.

8. Step 6 — Implement the Fix

The engineer adds the missing static route on R2.

R2# configure terminal
R2(config)# ip route 10.10.10.0 255.255.255.0 172.16.12.1
R2(config)# end

This route tells R2 that the branch LAN is reachable through the remote GRE tunnel IP address.

Verify the Route

R2# show ip route 10.10.10.0

Routing entry for 10.10.10.0/24
  Known via "static"
  Next hop: 172.16.12.1

The return path is now configured.

Retest from R1

R1# ping 10.20.20.1 source 10.10.10.1

Sending 5, 100-byte ICMP Echos to 10.20.20.1
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5)

Retest from the Branch PC

PC1> ping 10.20.20.10

Expected Result: Successful connectivity, assuming the data center PC is operational, has the correct default gateway, and permits ICMP.

The engineer can now confirm successful routing in both directions.

9. Understanding the Root Cause

The problem was not GRE encapsulation or the physical WAN.

It was asymmetric routing information: R1 had a route to the remote LAN, but R2 did not have a route back to the source LAN.

Before the Fix

After the Fix

A GRE tunnel provides the logical connection, but routers still need correct routes for the networks transported through the tunnel.

The lesson: Always verify both the forward and return paths.

10. Five Additional GRE Problems Every Network Engineer Should Know

The missing return route was the root cause in this example, but several other problems can cause GRE communication failures.

Problem A — GRE Protocol 47 Is Blocked

GRE uses IP protocol number 47.

This is not the same thing as TCP or UDP port 47.

If a firewall permits ICMP but blocks GRE, WAN endpoint ping tests may succeed while GRE traffic fails.

Verify the firewall rules along the underlay path.

Problem B — Recursive Routing

A GRE tunnel can become unstable when the route to its tunnel destination is resolved through the same tunnel.

Cisco routers may generate a message similar to:

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

To prevent this, maintain a route to the remote tunnel destination through the physical underlay rather than through the GRE overlay.

Problem C — MTU and Fragmentation

Basic GRE over IPv4 typically introduces at least 24 bytes of encapsulation overhead:

Outer IPv4 Header: 20 bytes
GRE Header:         4 bytes
----------------------------
Minimum Overhead:  24 bytes

For a physical IP MTU of 1500 bytes, a basic GRE IPv4 tunnel commonly has an effective IP MTU of 1476 bytes.

Packets larger than the supported path MTU may require fragmentation or trigger Path MTU Discovery behavior.

Use:

show interfaces Tunnel0
show ip interface Tunnel0

For suitable TCP-over-GRE deployments, TCP MSS adjustment and tunnel MTU configuration may help prevent fragmentation problems, but they must be calculated for the actual encapsulation and path.

Problem D — Missing GRE Keepalives or Failure Detection

Because basic GRE does not inherently maintain remote endpoint state, a failed remote peer might not immediately cause the local tunnel to go down.

Where supported, GRE keepalives can improve failure detection.

For example:

interface Tunnel0
 keepalive 10 3

Validate compatibility before using GRE keepalives, particularly when GRE is combined with IPsec.

Problem E — GRE Does Not Encrypt Data

GRE encapsulates traffic but does not provide confidentiality.

For sensitive enterprise communication across untrusted networks, consider GRE protected by IPsec or another suitable encrypted transport.

11. GRE Troubleshooting Checklist

The correct troubleshooting sequence is:

Physical Connectivity → Underlay Routing → GRE Tunnel → Overlay Routing → Return Path → Application Connectivity

Following this order helps network engineers isolate failures without making unnecessary configuration changes.

12. How to Prevent Similar GRE Outages

A production-ready GRE design should include complete bidirectional routing, endpoint reachability independent of the tunnel, suitable failure detection, and documented tunnel source and destination addresses.

For deployments using dynamic routing over GRE, ensure that the routing protocol does not accidentally advertise or select a path to the tunnel destination through the tunnel itself.

Also monitor tunnel traffic, routing adjacencies, physical WAN utilization, packet loss, and MTU-related behavior. For encrypted deployments, include IPsec security-association status and encryption/decryption counters.

Where available, automated pre-change and post-change validation can identify missing routes and tunnel reachability problems before users report an outage.

13. Final Takeaway

A GRE tunnel showing UP/UP does not guarantee end-to-end application connectivity.

In this example, physical connectivity and GRE encapsulation were operating correctly. The outage occurred because the data center router had no route back to the branch LAN.

The solution required one correctly placed static route and complete validation of both directions.

Remember This Troubleshooting Principle

"Connectivity is not confirmed when the tunnel comes up. Connectivity is confirmed when the packet reaches its destination and the response returns successfully."

Learn Real-World Networking with Network Guide Academy

Want to move beyond memorizing Cisco commands and develop practical troubleshooting skills?

At Network Guide Academy, explore hands-on networking lessons, realistic enterprise topologies, complete Cisco configurations, verification commands, and troubleshooting exercises.

Whether you're preparing for CCNA, CCNP, or a production network engineering role, practical learning helps you understand not just what to configure, but why networks work—and why they fail.

Explore more tutorials: https://networkguideacademy.com/

Network Guide Academy — Learn Networking. Build Skills. Troubleshoot with Confidence.