[c-nsp] ASA "NEM" tunnel problems

[Peter Rathlev]

This is possibly just because I'm dense, but we're having some strange
problems with some Network Extension Mode clients at home offices.

The hub is an ASA 5550 running 8.2(5)33 and the spokes are ASA 5505
running plain 8.2(5) but with about a third running something else. The
problem has been observed on 7.2(4) also.

Most of the HW clients succeed in establishing the NEM tunnel without
problems, but a few clients don't. It has recently come to our attention
that this is an actual problem; it has so far been obscured by people
turning their ASA off when unused rendering our monitoring almost
uselsess.

What we see by debugging is that the ones failing never seem to send the
"ID_IPV4_ADDR_SUBNET" ID payload with their remote LAN network. They
just send "ID_IPV4_ADDR" with their "outside" address (RFC1918 behind a
NAT router, we use NAT-T) and the NEM tunnel never establishes. After 30
minutes the tunnel is torn down by the hub with reason "IPSec SA Idle
Timeout" and no bytes transmitted or received.

The "normal" way for working devices seems to be that they initially and
only send "ID_IPV4_ADDR_SUBNET". We have a few though that start by
sending "ID_IPV4_ADDR" and only after phase 2 completion sends
"..._SUBNET". They seem to work fine.

We haven't yet been able to reproduce the problem ourselves, of course,
and have not yet had the chance to have remote hands look at debug logs.

Suspecting a NAT ALG problem of some kind we contacted the ADSL provider
but they can't find anything wrong with their equipment. I'm inclined to
think their right. Almost all our home offices of this kind use the same
provider and have the same router (Netopia), though different firmware
versions on the routers could explain this.

We've previously experimented with "vpnclient management clear" on the
clients and also suspected this, but all clients use it.

Configuration below. Anything that stands out as wrong? Anyone heard of
a similar problem? Are we just doing this all wrong? :-)

(I'd really like to replace everything with routers but that's not an
option right now.)


! *** Spoke configuration ***
vpnclient server <hub>
vpnclient mode network-extension-mode
vpnclient vpngroup <group> password <key>
vpnclient username <user> password <pass>
vpnclient management clear
vpnclient enable
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 172.19.68.49 255.255.255.248 
!
interface Vlan2
 nameif outside
 security-level 0
 ip address dhcp setroute 
!


! *** Hub configuration ***
tunnel-group <group> type remote-access
tunnel-group <group> general-attributes
 default-group-policy <policy>
tunnel-group <group> ipsec-attributes
 pre-shared-key <ps-key>
 isakmp keepalive threshold 600 retry 2
!
group-policy <policy> internal
group-policy <policy> attributes
 dns-server none
 vpn-tunnel-protocol IPSec l2tp-ipsec
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value <acl>
 user-authentication disable
 nem enable
!
username <user> password <enc-pass> encrypted
username <user> attributes
 group-lock value <group>
 service-type remote-access
!
access-list <acl> remark -- Split tunnel ACL for "<group>"
access-list <acl> extended permit ip any 172.19.66.0 255.255.255.0 
access-list <acl> extended permit ip any 172.19.67.0 255.255.255.0 
access-list <acl> extended permit ip any 172.19.68.0 255.255.255.0 
!

Full but sanitized spoke configuration at http://pastebin.com/SEvTXajp

-- 
Peter