ASA VPN tunnel-group config

Unanswered Question
May 22nd, 2007

Hello

I am about to configure a setup with a VPN network for a company. I will be using a ASA 5520 as the VPN concentrator and Cisco 800 series routers at the remote locations (about 200 remote locations).

Now, if i don't want to configure a tunnel group for each of these remote locations, I can use the "DefaultL2LGroup" tunnel-group on the ASA 5520, to specify a pre-shared-key.

This also works fine, but I'm not so confident with using the same pre-shared-key for all remote locations. So now my question is, whether it's possible to create a tunnel-group for a "group" of remote locations. For example if I wanted to use the same pre-shared-key for the first 10 remote locations, and then another pre-shared-key for the next 10 locations - and so forth - WITHOUT having to specify a tunnel-group for every remote location..

Are there any way to do this?

Thanks in advance...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
ggilbert Tue, 05/22/2007 - 01:09

Rasmus,

There are different ways to build an IPSec tunnel from the remote location to the head end site. You can build a L2L session or you can build an EzVPN (like a Hardware server/client) session to the ASA. EzVPN comes in two flavors, Network Extension Mode and Client Mode.

(http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801541d5.html#wp1046206)

You can't use pre-shared keys for 10 locations and use another pre-shared for the next 10 locations, etc.. on the same DefaultL2LGroup.

What you can do is, build an EzVPN session from the remote site to the head end side. In this case, you need to build a separate tunnel-group and use the same tunnel group for every location but, use XAUTH (user authentication) through an ACS server (RADIUS authentication) or so and lock the user to a different tunnel-group using a group-policy.

Every tunnel-group needs to a group-policy.

What you can do is, create multiple tunnel-groups but provide only one tunnel-group information to the remote client.

When they authenticate, you can use the user information on the ACS server and pass down a group-policy to which they need to authenticate with and use the group-lock feature on the group-policy and lock the user to a tunnel-group which they should belong to. In this way, the remote clients doesn't have to connect with different tunnel-group information.

Or if you are looking for implementation of different keys to multiple remote peers for security reason, then I would recommend using certificates.

Hope this helps, if I confused you, please let me know.

If it is clear, rate this post, if it helps!

Cheers

Gilbert

rasmusan1 Tue, 05/22/2007 - 01:33

Hello Gilbert

Thank you for fast reply !

TI have also considered EzVPN as a solution, but the problem (as I see it) with EzVPN is that it has to be the remote site, that initiates the traffic, for the tunnel to come up.

In my setup, it is the HQ who shall poll data from the remote locations. As I see it, that is not possible with EzVPN... or am I wrong ?

Best Regards

Rasmus

ggilbert Tue, 05/22/2007 - 01:44

Rasmus,

You are correct, its the client side that needs to initiate the connection.

Question for you:

If the HQ has to poll data from the remote locations, after the client establishes the connection, cant they poll the data?

The traffic going through the tunnel is bi-directional at that point.

Just curious!

Cheers

Gilbert

rasmusan1 Tue, 05/22/2007 - 01:51

Hello Gilbert

I actually haven't tried that, but i suppose the HQ would be able to poll the data, if the client had initiated the tunnel.

Well, I'll just have to choose whether to go the difficult way and create a tunnel-group for every remote site or use the DefaultL2LGroup.

but thanks for your help.

Best regards

Rasmus

ggilbert Tue, 05/22/2007 - 01:56

Rasmus,

Once the IPSec SA is created, then its all ball game...

Good luck in choosing.

Rate this post, if it helped.

Cheers

Gilbert

Actions

This Discussion