ASA as an EZVPN Server Behind NAT

pavel.stefanov · ‎05-25-2010

Hello all,

I am trying to get an ASA running v7 OS working as an easy vpn server behind NAT in the following scenario:

ASA(EZVPN_Server)-----Gateway----Internet-----Gateway-----Router(EZVPN_Client in NEM mode)

There is a static nat entry on the gateway connected to the ASA so all traffic is forwarded from a public address to a private one configured on the firewall. When I connect the ASA directly to the Internet with a public address, it all works fine. However, when it is behind NAT, it gets stuck and cannot negotiate IPSec SAs. I can see on the ezvpn client that an isakmp sa is successfully established (QM_IDLE). However, no SAs can be created. Here's the relevant config on the ASA:

group-policy EZVPN internal
group-policy EZVPN attributes
vpn-tunnel-protocol IPSec
password-storage enable
ipsec-udp enable
split-tunnel-policy tunnelall
secure-unit-authentication disable
user-authentication disable
nem enable
webvpn
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set TS esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map EZVPN 10 set transform-set TS
crypto dynamic-map EZVPN 10 set security-association lifetime seconds 28800
crypto dynamic-map EZVPN 10 set security-association lifetime kilobytes 4608000
crypto map STATIC 10 ipsec-isakmp dynamic EZVPN
crypto map STATIC interface inside
isakmp identity address
isakmp enable inside
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
isakmp nat-traversal 10
tunnel-group DefaultRAGroup general-attributes
address-pool (inside) VPN_POOL
authentication-server-group (inside) LOCAL
tunnel-group AP_VPN_GROUP type ipsec-ra
tunnel-group AP_VPN_GROUP general-attributes
address-pool (inside) VPN_POOL
address-pool VPN_POOL
authentication-server-group (inside) LOCAL
authorization-server-group LOCAL
default-group-policy EZVPN
tunnel-group AP_VPN_GROUP ipsec-attributes
pre-shared-key *
peer-id-validate nocheck

I suspect it has something to do with NAT-T or UDP encaps, but can't figure it out. Full access is allowed on the gateways between the client and the server. Any ideas?

Pavel

m.kafka · ‎05-25-2010

First I'm a little bit confused, that you apply the crypto map to the inside interface but I assume that there is a reason.

If so, where is the "inside network" of the VPN server which communicates with the "inside network" of EZVPN client? I understand it runs in network extension mode.

verify the ipsec sa with

sh crypto ipsec sa

the (QM_IDLE) is a hint that phase 2 has completed

If in doubt do a debug crypto ipsec on the responder if the system is not loaded heavily, that should give you confidence whether SA can or can't be established and give you a reason if IPsec SAs are rejected.

Are you positive, that IPsec SAs are not established?

rgds, MiKa

pavel.stefanov · ‎05-26-2010

Hi Mika,

There is only one interface that is used on the ASA and that is why I configured its name as inside. The ipsec SAs are definitely not established and I checked the sh crypto ipsec sa many times. The debugs give me some messages about retransmissions happening and that usually is a hint that these packets (udp 4500) get dropped somewhere. I will do some more troubleshooting today and post some debugs.

Regards,

Pavel