Remote Access VPN - Partial/No Reachability

Unanswered Question
Mar 20th, 2010

Hello all,

I've spent the whole day on Friday troubleshooting this issue, but have not figured out what the problem is yet and was hoping you could help me out. I tested the config on different platforms using different IOS so I suspect a configuration mistake on my end.

Basically, I've got a VPN server (1941 ISR running 15.0(1)M2) connected to Internet with a public IP address. Clients are able to establish a tunnel and ping all addresses belonging to the server except the public address of the server. They cannot ping any of the networks behind the VPN server either. It's not a s split-tunnel config and I tried using both reverse-route/manually configured static routes, etc, but none of them work. The VPN client routes are propogated to the internal network and routing seems to be okay. I took all the ACLs off on all interfaces just to make sure it's not filtering anything. The client also has the default route changed when I do a route print. The show crypto ipsec sa does not show any errors and pings to hosts that are behind VPN serever or to the public IP address do not hit the counters for encrypted/decrypted, verified/not verified, etc. Here is the relevant config on the VPN server:

aaa new-model
aaa authentication login default local
aaa authentication login vpnusers local
aaa authorization exec default local
aaa authorization network default local
aaa authorization network vpnusersauthor local

ip local pool RA_VPN_POOL 10.160.23.96 10.160.23.127

crypto isakmp policy 10
encr aes
authentication pre-share
group 2

crypto isakmp key xxxxx address xxxxx no-xauth // this is for a site-to-site VPN tunnel

crypto isakmp client configuration group Management-Users
key xxxxxxxxx
dns xxxx xxxx
wins xxxx xxxx
domain xxxxx
pool RA_VPN_POOL
include-local-lan
max-users 50
netmask 255.255.255.224

crypto ipsec transform-set TS ah-sha-hmac esp-aes
crypto ipsec transform-set RA_VPN_TS esp-aes esp-sha-hmac
crypto dynamic-map RA_VPN_MAP 10
set transform-set RA_VPN_TS

crypto map STATIC local-address GigabitEthernet0/1
crypto map STATIC client authentication list vpnusers
crypto map STATIC isakmp authorization list vpnusersauthor
crypto map STATIC client configuration address respond
crypto map STATIC 10 ipsec-isakmp
set peer xxxxxx
set transform-set TS
set pfs group2
match address GRE
crypto map STATIC 65535 ipsec-isakmp dynamic RA_VPN_MAP


interface GigabitEthernet0/1
description Connected to the Internet$ES_LAN$
ip address xxxxxxx  255.255.255.248
duplex auto
speed auto
crypto map STATIC

I'd really appreciate some help.

Pavel

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jennifer Halim Sat, 03/20/2010 - 03:28

What about NAT? Do you exempt the traffic between your internal networks towards the ip pool subnet?

pstefanovpavel Sat, 03/20/2010 - 04:02

I have not configured NAT as users in the customer network access external resources via a proxy server.

Jennifer Halim Sat, 03/20/2010 - 04:08

From your original question, you mentioned that the "show crypto ipsec sa" doesn't show any increment in the encaps and decaps value?

Can you please share those outputs? And also from your vpn client statistics, can you also share the screenshot of the stats. Thanks.

pstefanovpavel Sat, 03/20/2010 - 06:49

When I try to ping from the client side to a network behind the VPN server, the counters do not increment. However, when I try to ping from that network to the client, the encrypt counter increments, but ping is unsuccessful.

#show crypto ipsec sa detail
interface: GigabitEthernet0/1

protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (10.160.23.99/255.255.255.255/0/0)
   current_peer x.x.x.x port 4001
     PERMIT, flags={}
    #pkts encaps: 11, #pkts encrypt: 11, #pkts digest: 11
    #pkts decaps: 123, #pkts decrypt: 123, #pkts verify: 123
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
     current outbound spi: 0xF169F35E(4050252638)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xDCF3FDF3(3706977779)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2059, flow_id: Onboard VPN:59, sibling_flags 80000046, crypto map: STATIC
        sa timing: remaining key lifetime (k/sec): (4475688/3368)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xF169F35E(4050252638)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2060, flow_id: Onboard VPN:60, sibling_flags 80000046, crypto map: STATIC
        sa timing: remaining key lifetime (k/sec): (4475712/3368)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Here are some debugs from debug ip packet detailed with an ACL matching icmp only.

Mar 20 13:08:39.350: pak xxxxxx consumed in input feature , packet consumed, MCI Check(66), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:49.346: pak xxxxxx consumed in input feature , packet consumed, MCI Check(66), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:49.822: IP: s=0.0.0.0 (local), d=10.160.23.98, len 100, local feature
Mar 20 13:08:49.822:     ICMP type=8, code=0, SSLVPN bandwidth check Local(11), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:49.822: FIBipv4-packet-proc: route packet from (local) src 0.0.0.0 dst 10.160.23.98
Mar 20 13:08:49.822: FIBipv4-packet-proc: packet routing succeeded
Mar 20 13:08:49.822: IP: s=y.y.y.y (local), d=10.160.23.98 (GigabitEthernet0/1), len 100, sending
Mar 20 13:08:49.822:     ICMP type=8, code=0
Mar 20 13:08:49.822: IP: s=y.y.y.y (local), d=10.160.23.98 (GigabitEthernet0/1), len 100, output feature
Mar 20 13:08:49.822:     ICMP type=8, code=0, SSLVPN bandwidth checking with eval license(18), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:49.822: IP: s=y.y.y.y (local), d=10.160.23.98 (GigabitEthernet0/1), len 100, output feature
Mar 20 13:08:49.822:     ICMP type=8, code=0, IPSec output classification(27), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:49.822: pak xxxxxx consumed in output feature , packet consumed, IPSec: to crypto engine(57), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:51.822: IP: s=0.0.0.0 (local), d=10.160.23.98, len 100, local feature
Mar 20 13:08:51.822:     ICMP type=8, code=0, SSLVPN bandwidth check Local(11), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Mar 20 13:08:51.822: FIBipv4-packet-proc: route packet from (local) src 0.0.0.0 dst 10.160.23.98
Mar 20 13:08:51.822: FIBipv4-packet-proc: packet routing succeeded
Mar 20 13:08:51.822: IP: s=y.y.y.y (local), d=10.160.23.98 (GigabitEthernet0/1), len 100, sending
Mar 20 13:08:51.822:     ICMP type=8, code=0

y.y.y.y is my public address on the VPN server

Cheers,

Pavel

pstefanovpavel Sat, 03/20/2010 - 06:52

Just FYI, I am still using a trial SSLVPN license and a permanent Security license. The router is providing support for both AnyConnect clients and RA VPN IPSec clients. The AnyConnect client works perfectly.

pstefanovpavel Mon, 03/22/2010 - 16:50

Hello again,

A few days later I was finally able to figure out what the problem is. It is something that I suspect to be a bug, but I will open a case with Cisco's TAC to make sure. CEF is causing drops for some reason and doing a no ip route-cache on the interfaces solved the problem. This is not documented in the Bug Toolkit, but I believe it is a bug, and actually a serious one. Thanks a lot to the guy who wrote this post and had a similar problem as that reminded me to look more deeply into CEF: http://pete.reluctantgreenie.com/blogs/2009/01/07/unable-to-route-packets-and-cef-fastswitching/

xxx#sh cef drop
% Command accepted but obsolete, see 'show (ip|ipv6) cef switching statistics [feature]'

IPv4 CEF Drop Statistics
Slot  Encap_fail  Unresolved Unsupported    No_route      No_adj  ChkSum_Err
RP             0           0        7547           0           0           0 ///////////// the unsupported counter increments when IPSec traffic is sent
xxx#show ip cef sw stat

       Reason                          Drop       Punt  Punt2Host
RP LES Packet destined for us         30753      40019        614
RP LES Incomplete adjacency               4          0          0
RP LES TTL expired                        0          0       4317
RP LES Discard                          162          0          0
RP LES Features                         589          0       3230
RP LES Neighbor resolution req           59          0          0 ///////// the counter for drops increments when IPSec traffic is sent
RP LES Total                          31567      40019       8161

All    Total                          31567      40019       8161

Cheers,

Pavel

vpersaud001 Thu, 10/14/2010 - 09:51

Hello... I have the same problem with VPN between a 2901 remote VPN router and a 7206 core VPN router. The remote router is not receiving any traffic from the 7206 but the 7206 is receiving and sending traffic to the 2901. I have many other site-to-site VPNs on the 7206 that work fine.

I already added "no ip route-cache" to both interfaces on both routers but didn't help.

Any other suggestions from anyone? Thanks.

Vincent

vpersaud001 Thu, 10/14/2010 - 12:45

Please ignore my previous post. There was a typo in the firewall ACL for ESP.

Thanks.

Vincent

Actions

This Discussion