[c-nsp] EzVPN drops packets after first data burst
Kristofer Sigurdsson
kristo at kristo.is
Tue Jan 22 08:42:25 EST 2008
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)
More information about the cisco-nsp
mailing list