Solved: Multiple dynamic crypto maps on interface

Colin Higgins · ‎01-08-2014

I have a ASA 5540 running 8.2 code. The firewall has VPN tunnels, a standard IPSec remote-access VPN on it, and a clientless SSL VPN.

I have Cisco 1921 routers with 4G wireless cards that need to open dynamic VPNs with the ASA 5540, so it looks like I need to implement a EzVPN solution here.

My question is, are mutliple dynamic crypto maps supported on one interface?

For instance, the current config lists

crypto dynamic-map outside_dyn_map 20 set pfs group 1

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

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map interface outside

in addition to the crypto maps for the static L2L tunnels.

I assume that when I add the EzVPN I will need to create a new dynamic map. After doing this, can I simply add something like this?

crypto map outside_map 65534 ipsec-isakmp dynamic outside_new_map

Basically a different sequence number and map name?

m.kafka · ‎01-09-2014

Hi Colin,

this is basically correct, you will run into some issues about incoming connections matching the two dynamic crypto map entries on the outside interface.

One possibility would be to include a match address statement for you EZ-VPN, e.g. generously describing the remote lans as a destination of the crypto access-list.

E.g. if your remote LANs are all within the range 10.66.0.0/16 configure an access-list like:

access-list outside_new permit ip [local LAN] [local mask] 10.66.0.0 255.255.0.0

and include it in you dynamic crypto map outside_new_map

crypto dynamic-map outside_new_map 20 set pfs group 1

crypto dynamic-map outside_new_map 20 set transform-set ESP-3DES-SHA

crypto dynamic-map outside_new_map 20 set match address outside_new

See also:

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/ike.html#wp1042880

Colin Higgins · ‎01-09-2014

Thanks for the help!

OK, so it looks like I need to do ths--can you take a look and see if it looks correct?

Central Servers:

172.25.32.182 & 183

Remote networks:

172.30.201.0 /28

172.30.201.16 /28

Step One: Define traffic

access-list ezvpn extended permit ip 172.25.32.182 255.255.255.255 172.30.201.0 255.255.255.240

access-list ezvpn extended permit ip 172.25.32.182 255.255.255.255 172.30.201.16 255.255.255.240

access-list ezvpn extended permit ip 172.25.32.183 255.255.255.255 172.30.201.0 255.255.255.240

access-list ezvpn extended permit ip 172.25.32.183 255.255.255.255 172.30.201.16 255.255.255.240

Step Two: NAT exemptions

access-list inside_nat0_outbound remark No NAT Fuel Kiosk Tunnel Traffic

access-list inside_nat0_outbound extended permit ip host 172.25.32.182 172.30.201.0 255.255.255.240

access-list inside_nat0_outbound extended permit ip host 172.25.32.183 172.30.201.0 255.255.255.240

access-list inside_nat0_outbound extended permit ip host 172.25.32.182 172.30.201.16 255.255.255.240

access-list inside_nat0_outbound extended permit ip host 172.25.32.183 172.30.201.16 255.255.255.240

nat (inside) 0 access-list inside_nat0_outbound

Step Three: Encryption policies

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto dynamic-map outside_new_map 20 set pfs group 1

crypto dynamic-map outside_new_map 20 set transform-set ESP-3DES-SHA

crypto dynamic-map outside_new_map 20 set match address ezvpn

crypto map outside_map 65534 ipsec-isakmp dynamic outside_new_map

isakmp identity address

crypto isakmp policy 40

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

m.kafka · ‎01-09-2014

Looks (as far as I understand your setup) quite reasonable.

You wouldn't need to be as specific with the access-lists, you can summarize src and dst to an extend so that they wouldn't collide with any other nat(0) or crypto policy.

I would use a single line with a shorter mask for both src and dst, something like

access-list ezvpn extended permit ip any 172.30.201.0 255.255.255.224

As far as I remember an ezvpn client will set its remote ident to 0.0.0.0/0.0.0.0/0/0 and its local ident to the local LAN unless you configure split tunneling. If you specify the local ident on the ezvpn server with a /31 mask the incoming phase2 proposal from the ezvpn client will be denied.

If want to do filtering you should use access-lists instead of overly detailed crypto policies.

The incoming proposals from the ezvpn clients will produce dynamic, more specific ipsec SAs when an incoming proposal matches (both src and dst fall within ip/mask). But the match address will prohibit that the remote access vpn connections would match on sequence number 65534, instead the next sequence will be tried...

Just another thing, where did you configer the ezvpn server on the client, couldn't see that in you config.

m.kafka · ‎01-09-2014

Sorry, just noticed:

the match address is of course without the keyword "set"

Colin Higgins · ‎01-09-2014

Nice catch on the unnecessary "set" command

I will give this a shot and see how it goes--thanks for your help!

Colin Higgins · ‎02-14-2014

Well it doesn't seem to be working

the crypto map with the higher sequence number is being used

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

and the new one

crypto map outside_map 65534 ipsec-isakmp dynamic outside_new_map

isn't getting hit (according to show crypto ipsec sa)

So I am having weird behavior on the Ez VPN

Is there some way to correct this?