ASA VPN configuration for Hub & Spoke using OSPF

Unanswered Question
Feb 1st, 2007

Dear all,

I'm planning to deploy the ASA VPN solution for more than 10 remote sites. Three of them are considered HUB sites. I want to know how to build-up the connectivity between the Spokes terminated to different Hub sites, is that possible running OSPF instead of fully mesh VPN?

Thanks

Tony

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 1 (1 ratings)
Loading.
ggilbert Thu, 02/01/2007 - 07:52

Tony,

Question before I give my thoughts.

Lets say A, B and C are your hub sites.

From your questions, I believe you will have only two or three sites connected to per hub, is that correct?

Cheers

Gilbert

laut Thu, 02/01/2007 - 19:57

Gilbert,

Yes.

For e.g.:

A is connecting to Spoke 1, 2

B is connecting to Spoke 3, 4, 5

C is connecting to Spoke 6, 7

Most of the Spokes' traffic flow is going to the Hub site, but may be required to do the communication between Spokes on the same Hub or different Hub sites. (1<->2 or 1<->6)

Thanks.

Tony

ggilbert Fri, 02/02/2007 - 06:23

Tony,

Thanks for clarifying. Here is what I would do.

The ASA can do U-turn traffic now. You might have to go back to the white board and carefully design the scenario.

The good news is - there is MIGHT be a solution. Look at the link given below

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00804675ac.shtml

Spoke 1 and Spoke 2 will talk to Hub A.

Lets say spoke 1 Network is 10.10.1.0

Spoke 2 network is 10.10.2.0 and the hub A is 20.20.1.0

This above given document will help you on that.

On Hub A, you need to create another tunnel to Hub B with the network lists of Spoke 1 and Spoke 2 going to spoke 3, 4 and 5.

So, when the packet from Spoke A comes to Hub A, destined for Spoke 3, it should go out to Hub B.

Note - I have not tested this out by myself

Thanks

Gilbert

Rate it, if this helps!

laut Sun, 02/04/2007 - 19:37

Gilbert,

Thanks your info.

Notice that the enhanced Spoke-to-Spoke can provide the connectivity for non-fully meshed VPN. But it is quite difficult to configure, also the customer don't want to pre-defined all the remote office network on every sites. For eg. If another spoke X will join to Hub B, it is required to change all the remote sites configuraion for interconnection.

Is that possible to use OSPF to provide the connectivity for differnet Spokes connecting to different Hubs? (Feature similar to GRE)

Thanks.

Tony

ggilbert Tue, 02/06/2007 - 07:22

Tony,

Sorry about the delay.

If you want to implement that kind of scenario, then ASA would not be a good choice.

You would need to configure ACL's for the proxies to match.

Have you looked into DMVPN or GET VPN.

Thanks

Gilbert

Rate it, if this helps.

laut Tue, 02/06/2007 - 23:20

Gilbert,

So what is the best solution in order to use ASA to form the IPsec tunnel to connect different remote offices? Most of the traffic flow will go to the directly connected Hub site from Spoke, only a fewer communication to the other Spokes connected to different Hubs. Is that still need to do the fully mesh VPN?

Please advise.

Thanks.

Tony

ggilbert Wed, 02/07/2007 - 07:59

Tony,

I was thinking about this and figured the solution would be...

For Hub A, where spoke 1 and spoke 2 are connecting, the internal networks for spoke1, spoke2 and hub A can be set as 10.10.1.x(hub)

10.10.2.x(spoke1) 10.10.3.x (spoke2)

And for hub B, spoke1b, spoke 2b, set the internal networks as 20.20.1.x (hub B) 20.20.2.x (spoke1b), 20.20.3.x (spoke2b)

When spoke1 wants to talk with spoke1b, then you can have tunnel built for 10.10.x.x going to 20.20.x.x from hub A to hub b, which will simply the number of ACL's to be inserted for the encrypting peers.

Hope this helps.

Thanks

Gilbert

laut Wed, 02/07/2007 - 18:10

Gilbert,

But we still need to define the additional acl for the traffic 10.10.2.x to 20.20.2.x on the tunnel HubA<->spoke1 and HubB<->spoke1b. And also the private IP address assignment is not in hierarchical format.

Any other solution to deploy the easiest operation & management IPsec VPN for ASA?

rgds,

Tony

ggilbert Thu, 02/08/2007 - 05:29

Tony,

With ASA, thats the best option you have.

Otherwise you can use Routers and implement DMVPN solution.

Cheers

Thanks

Rate it, if it was helpful.

laut Thu, 02/08/2007 - 19:42

Gilbert,

Thanks for your information.

Regarding the enhanced spoke to spoke configuration. Based on the following URL, it just stated the ACL configure for spoke1 source to spoke2 destination through the Hub A. Is that means the traffic should be initialed from spoke1 to form the VPN tunnel via the Hub? How the Hub to cater the request come from spoke2 to spoke1?

Hub - 10.10.10.x

Spoke1 - 10.20.20.x

Spoke2 - 10.30.30.x

access-list 100 extended permit ip 10.10.10.0 255.255.255.0 10.30.30.0 255.255.255.0

access-list 100 extended permit ip 10.20.20.0 255.255.255.0 10.30.30.0 255.255.255.0

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00804675ac.shtml

Thanks.

Tony

laut Mon, 02/12/2007 - 18:47

Gilbert,

Any update of this. The Hub site will be connected to more Spokes in the future. I need to provide the right approach on how to deploy the VPN solution.

Tony

ggilbert Tue, 02/13/2007 - 07:11

Tony,

The access-list 100 you have mentioned above, where does it go?

To answer your question, even the spoke 2 can initiate the tunnel to spoke 1. The hub will pass the traffic through to spoke 1.

It should not be a problem.

Rate it, if this helps.

Cheers

Gilbert

ggilbert Wed, 02/14/2007 - 06:20

Tony,

In the example given to you, one of the spoke was a dynamic Lan to Lan tunnel and the other one was a static Lan to LAN tunnel

Taking your example into account

Hub - 10.10.10.x

Spoke1 - 10.20.20.x

Spoke2 - 10.30.30.x

Here is how the ACL's should look like.

Hub:

Access-list for tunnel between Hub and Spoke1

access-list 110 per ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0

access-list 110 per ip 10.30.30.0 255.255.255.0 10.20.20.0 255.255.255.0

Access-list for tunnel between Hub and Spoke 2

access-list 120 per ip 10.10.10.0 255.255.255.0 10.30.30.0 255.255.255.0

access-list 120 per ip 10.20.20.0 255.255.255.0 10.30.30.0 255.255.255.0

Access-list for nonat (NAT exemption)

access-list nonat per ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0

access-list nonat per ip 10.10.10.0 255.255.255.0 10.30.30.0 255.255.255.0

Spoke 1:

access-list 101 per ip 10.20.20.0 255.255.255.0 10.10.10.0 255.255.255.0

access-list 101 per ip 10.20.20.0 255.255.255.0 10.30.30.0 255.255.255.0

Spoke 2:

access-list 102 per ip 10.30.30.0 255.255.255.0 10.10.10.0 255.255.255.0

access-list 102 per ip 10.30.30.0 255.255.255.0 10.20.20.0 255.255.255.0

Rate this topic, if it helps.

Cheers

Gilbert

laut Thu, 02/15/2007 - 17:54

Gilbert,

Thanks. It's clear.

One more thing about the command "management-access", is that possible to use this command for the remote Spoke1 to send trap back to the Hub site via VPN tunnel? Based on the command reference, it just list-out the following feature support (no snmp trap):

?SNMP polls to the mgmt_if

?HTTPS requests to the mgmt_if

?PDM access to the mgmt_if

?Telnet access to the mgmt_if

?SSH access to the mgmt_if

?Ping to the mgmt_if

Rgds,

Tony

laut Thu, 02/22/2007 - 23:57

Gilbert,

Any information regarding the snmp trap back to the core via VPN tunnel?

Tony

Actions

This Discussion