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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
