[c-nsp] EzVPN drops packets after first data burst

[Frank Bulk - iNAME]

Anything to do with packet size?

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kristofer Sigurdsson
Sent: Tuesday, January 22, 2008 7:42 AM
To: Cisco NSP
Subject: [c-nsp] EzVPN drops packets after first data burst

Hi list,

I have a Cisco 1841 router, IOS 12.4(12), Adv. IP Services.  I'm using it
for an EzVPN server where clients can VPN into a VRF which contains a local
network.  Clients can connect and start to use eg. Remote Desktop to a
computer on the inside network, but as soon as some traffic starts flowing
(like opening a browser in Remote Desktop), the session hangs and, according
to the show crypto session remote <peer> detail, no new outbound (from the
VPN server) packets come and I start seeing dropped inbound packets
(dec'ed).  Sample output:

Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: x.x.x.x port 4406 fvrf: (none) ivrf: xx
      Phase1_id: xxxx
      Desc: (none)
  IKE SA: local x.x.x.x/4500 remote x.x.x.x/4406 Active
          Capabilities:CXN connid:233 lifetime:07:58:49
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 10.10.210.158
        Active SAs: 2, origin: dynamic crypto map
        Inbound:  #pkts dec'ed 279 drop 69 life (KB/Sec) 4587796/86332
        Outbound: #pkts enc'ed 432 drop 0 life (KB/Sec) 4587562/86332

Whatever the user tries to do on the VPN, the only thing that changes (apart
from time) is the dec'ed drop packets.  The number of packets dec'ed/enc'ed
is not exactly consistant, but this always happens at the first burst of
data across the link.  The counters go to a few hundred, then this happens.
The VPN connection stays up, nothing unusual in the client.  It says
"transparent tunneling: active on UDP port 4500", so it probably doesn't
matter that the client is behind NAT, right?

The problem only depends on data going over the link, not time.  If I'm just
using ping, traceroute and SSH terminal access, there is no problem.  As
soon as I put a burst on the link, it hangs and does not recover.  We have a
few customers on the router, each using a different profile (pretty much
same configuration) and different VRFs for inside networks.  Same problem
for all of them.

Thanks in advance,
Kristo

Here's the relevant configuration:

aaa group server radius RADIUS-XX
 server-private x.x.x.x auth-port 1645 acct-port 1646 key xxxxxxx
 ip vrf forwarding xx

aaa authentication login AAA-XX group RADIUS-XX

aaa authorization network vpn local

ip vrf xx
 description xx
 rd 65365:7
 route-target export 65365:7
 route-target import 65365:7
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
 lifetime 28800
!
crypto isakmp policy 20
 encr 3des
 authentication pre-share
 group 5
!
crypto isakmp policy 30
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp client configuration group xxxx
 key xxxxxxxxx
 dns x.x.x.x
 pool xx
 acl xx
 group-lock
 save-password
 max-users 50
 netmask 255.255.255.255
!
crypto isakmp profile xxxx
   vrf xx
   self-identity address
   match identity group xxxx
   client authentication list AAA-XX
   isakmp authorization list vpn
   client configuration address respond
   initiate mode aggressive
   local-address FastEthernet0/0
!
crypto ipsec security-association lifetime seconds 86400
crypto ipsec security-association idle-time 86400
!
crypto ipsec transform-set vpn esp-3des esp-md5-hmac
!
! dynamic-map vpn 1-6 and 8-... are other customers who also have the same
problem
!
crypto dynamic-map vpn 7
 set transform-set vpn
 set isakmp-profile xxxx
 reverse-route
!
crypto map vpn 65535 ipsec-isakmp dynamic vpn
!
interface FastEthernet0/0
 description Uplink
 ip address x.x.x.x 255.255.255.128
 duplex auto
 speed auto
 crypto map vpn
!
interface FastEthernet0/1.930
 encapsulation dot1Q 930
 ip vrf forwarding xx
 ip address 10.9.8.2 255.255.255.252
!
! The RIP is to advertise the host routes to the VPN clients to another
router on the inside (and receive routes from there)
!
router rip
 version 2
 !
 address-family ipv4 vrf xx
 redistribute connected
 redistribute static
 network 10.0.0.0
 network 192.168.0.0
 network 192.168.124.0
 no auto-summary
 version 2
 exit-address-family
 !
ip local pool xx 10.10.210.100 10.10.210.200 group xx
!
ip access-list extended xx
 (lots of networks)
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/