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

David Freedman david.freedman at uk.clara.net
Tue Jan 22 12:32:13 EST 2008


I dont see your "crypto isakmp nat-keepalive" statement.

See

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tsr/sec_c2gt.htm#wp1203839

Dave.


Kristofer Sigurdsson wrote:
> 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/
> 



More information about the cisco-nsp mailing list