[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