VPN Tunnel Up But Remote Network Not Reachable
Presenting Symptom
The VPN tunnel is up and Phase 2 is established, but hosts on the remote network cannot be pinged from the local network.
Network Context
A small branch office (192.168.1.0/24) connects to a corporate headquarters (10.1.1.0/24) via an IPsec site-to-site VPN over the internet. Both sites use Cisco ISR routers running IOS 15.9. The tunnel shows as up/up and Phase 2 security associations are present, yet traffic from the branch LAN to the corporate LAN fails.
Diagnostic Steps
Check VPN tunnel status and Phase 2 SAs
show crypto isakmp saIPv4 Crypto ISAKMP SA C-id local remote state status 1 192.168.1.1 203.0.113.1 QM_IDLE ACTIVE
Confirm IKE Phase 1 is active. If not, check pre-shared keys or IKE policies.
Verify IPsec Phase 2 SAs
show crypto ipsec sainterface: Tunnel0
Crypto map tag: CMAP, local addr 192.168.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0Check that the local and remote identities match the actual subnets. If #pkts encaps is increasing but #pkts decaps is 0, traffic is being sent but not received. If both are 0, traffic is not matching the crypto map.
Check routing table for remote network
show ip route 10.1.1.0Routing entry for 10.1.1.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.2, via Tunnel0
Route metric is 0, traffic share count is 1Ensure there is a route to the remote network pointing to the tunnel interface. If no route exists, traffic will be sent out the default route (internet) and not encrypted.
Verify crypto map is applied to the correct interface
show crypto mapCrypto Map "CMAP" 10 ipsec-isakmp
Peer = 203.0.113.1
Extended IP access list 101
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
Current peer: 203.0.113.1
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={TSET}
Interfaces using crypto map CMAP:
Tunnel0Confirm the crypto map is applied to the tunnel interface and the ACL matches the correct source/destination subnets. If the ACL is missing or incorrect, traffic will not be encrypted.
Check for NAT interference
show ip nat translationsPro Inside global Inside local Outside local Outside global --- 192.168.1.1 192.168.1.10 10.1.1.1 10.1.1.1
If VPN traffic is being NATed, it may not match the crypto ACL. Ensure VPN traffic is exempt from NAT using a route map or ACL. Look for translations of the VPN source/destination.
Root Cause
The branch router has no route to the remote corporate network (10.1.1.0/24) pointing to the tunnel interface. Traffic destined for 10.1.1.0/24 is sent out the default route (WAN interface) instead of being encrypted and sent through the VPN tunnel.
Resolution
Verification
Run `show ip route 10.1.1.0` to confirm the route exists via Tunnel0. Then ping from a branch host (e.g., 192.168.1.10) to a corporate host (e.g., 10.1.1.10). The ping should succeed. Also check `show crypto ipsec sa` to see packet counters incrementing for both encaps and decaps.
Prevention
1. Always configure static routes for remote VPN networks pointing to the tunnel interface. 2. Use dynamic routing protocols (e.g., EIGRP, OSPF) over the tunnel to automatically propagate routes. 3. Document and verify routing before and after VPN configuration.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where the VPN tunnel is up but connectivity fails. The exam tests the candidate's ability to identify missing routes as a common cause. A typical question might present a 'show crypto ipsec sa' output with packet counters and ask why traffic is not reaching the remote network. The key fact is that a tunnel being up does not guarantee routing; a route pointing to the tunnel interface is required.
Exam Tips
Remember that 'show crypto ipsec sa' packet counters indicate whether traffic is being encrypted (encaps) and decrypted (decaps). If encaps is incrementing but decaps is not, the remote side is not receiving the traffic, often due to routing issues.
The exam may show a routing table without a route to the remote network. Always check the routing table when troubleshooting VPN connectivity.
Know that static routes for VPN must point to the tunnel interface, not the next-hop IP, to ensure traffic is encrypted.
Commands Used in This Scenario
show crypto ipsec sa
Displays the current state and statistics of IPsec security associations (SAs) to verify VPN tunnel establishment and monitor encrypted traffic.
show crypto isakmp sa
Displays the current state of Internet Key Exchange (IKE) Security Associations (SAs) used for IPsec VPN tunnels, allowing verification of Phase 1 tunnel establishment.
show crypto map
Displays the configured crypto map entries, including their match criteria, peer addresses, and transform sets, used to verify IPsec VPN policy configuration.
show ip nat translations
Displays the current active Network Address Translation (NAT) translations on the router, used to verify NAT operations and troubleshoot connectivity issues.
show ip route
Displays the current IP routing table on a Cisco router, used to verify routes, check next-hop addresses, and troubleshoot connectivity issues.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions