No, the problem is not to connect to the other ASA, but to use resources behind it. I can go through the ASA to PIX, and we can use resources behind the ASA if we do not pass through an ASA before. Somehow I believe the UDP encapsulation is different with the ASA tunnel as opposed to the PIX tunnel. Below is the script we run on all ASA devices, and something is not perfect yet.

configure factory-default 192.168.20.1 255.255.255.0

!

! appliance restarts here

!

domain-name mydomain.local

dhcpd auto_config outside interface inside

hostname fw

http 192.168.0.0 255.255.0.0 inside

logging enable

logging asdm informational

access-list outside_access_in extended permit icmp any 192.168.0.0 255.255.0.0 echo-reply

access-list outside_access_in extended permit icmp any any source-quench

access-list outside_access_in extended permit icmp any any unreachable

access-list outside_access_in extended permit icmp any any time-exceeded

access-list outside_access_in extended permit icmp any interface outside

access-list outside_access_in extended permit udp any any eq isakmp

access-list outside_access_in extended permit udp any any eq 4500

access-group outside_access_in in interface outside

!

! Crypto settings for VPN-Clients

!

crypto isakmp enable outside

access-list inside_nat0_outbound line 1 extended permit ip 0.0.0.0 0.0.0.0 192.168.0.0 255.255.255.0

ip local pool vpnclients 192.168.0.10-192.168.0.19 mask 255.255.255.0

group-policy MyPolicyGroup internal

group-policy MyPolicyGroup attributes

vpn-tunnel-protocol IPSec

dns-server value 192.168.20.2

default-domain value mydomain.local

configure terminal

tunnel-group MyPolicyGroup type ipsec-ra

tunnel-group MyPolicyGroup general-attributes

default-group-policy MyPolicyGroup

address-pool vpnclients

tunnel-group MyPolicyGroup ipsec-attributes

pre-shared-key MyPassword

crypto isakmp policy 10 authen pre-share

crypto isakmp policy 10 encrypt 3des

crypto isakmp policy 10 hash md5

crypto isakmp policy 10 group 2

crypto isakmp policy 10 lifetime 86400

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto dynamic-map outside_dyn_map 20 set pfs group2

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map interface outside

nat (inside) 0 access-list inside_nat0_outbound tcp 0 0 udp 0

!

! VPN Users below

!

username MyUserName password MyPassword

username MyUserName attributes

vpn-group-policy MyPolicyGroup

!

! Make config permanent.

!

write mem

reload noconfirm

Thank you - thank you!, that did the trick.

Maybe you can also solve my local lan access?

With the above config, using the Cisco VPN-client, set allow local lan access, but the local lan vanishes. This is due to that the local routing table gets a new default gateway, namely the dynamicly VPN IP assigned. But over the years, I've never managed to solve this.

Below is the routing table before and after establishing the Client VPN connection (it's in swedish) - but you'll see that the rout for the local lan (192.168.1.0) is routed to the VPN IP, but shouldn't it be left alone to the normal default?

Routes before VPN:

Nätverksadress Nätmask Gateway-adress Gränssnitt Mått

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.179 25

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.1.0 255.255.255.0 192.168.1.179 192.168.1.179 25

192.168.1.179 255.255.255.255 127.0.0.1 127.0.0.1 25

192.168.1.255 255.255.255.255 192.168.1.179 192.168.1.179 25

224.0.0.0 240.0.0.0 192.168.1.179 192.168.1.179 25

255.255.255.255 255.255.255.255 192.168.1.179 3 1

255.255.255.255 255.255.255.255 192.168.1.179 192.168.1.179 1

255.255.255.255 255.255.255.255 192.168.1.179 10005 1

Standard-gateway: 192.168.1.1

===========================================================================

Routes with VPN:

Nätverksadress Nätmask Gateway-adress Gränssnitt Mått

0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.1 1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 25

192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 25

192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 25

192.168.1.0 255.255.255.0 192.168.1.179 192.168.1.179 25

192.168.1.0 255.255.255.0 192.168.0.1 192.168.0.1 25

192.168.1.1 255.255.255.255 192.168.1.179 192.168.1.179 1

192.168.1.179 255.255.255.255 127.0.0.1 127.0.0.1 25

192.168.1.255 255.255.255.255 192.168.1.179 192.168.1.179 25

217.209.119.167 255.255.255.255 192.168.1.1 192.168.1.179 1

224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 25

224.0.0.0 240.0.0.0 192.168.1.179 192.168.1.179 25

255.255.255.255 255.255.255.255 192.168.0.1 10005 1

255.255.255.255 255.255.255.255 192.168.0.1 3 1

255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1

255.255.255.255 255.255.255.255 192.168.1.179 192.168.1.179 1

Standard-gateway: 192.168.0.1

===========================================================================

OK add the below access list - you can change the name if you want to:-

access-list local_LAN_access standard permit host 0.0.0.0

And in the Group policy attributes for the remove VPN add:-

split-tunnel-policy excludespecified

split-tunnel-network-list value local_LAN_access

So the config would look something like:-

access-list local_LAN_access standard permit host 0.0.0.0

group-policy MyPolicyGroup attributes

split-tunnel-policy excludespecified

split-tunnel-network-list value local_LAN_access

HTH.

Hmmm, I've had troubles with split tunnel ACLs before, but then mainly when combining Client VPN and fixed site-to-site VPN-tunnels. This was some years ago, and as far as I remember, they needed separate ACLs for it to work.

But what you say, is that the remote ASA needs to have a split tunnel configured for the vpn-client to set the proper local routes.

In any case, I have to test this when I'm much closer to one of the remote ASAs (which is tomorrow).

Thanks for your help so far, I'll report back when I have something to report.

cheers / Peter