DocLarge
Premium
join:2004-09-08
| reply to aryoba
Re: [Config] Configuring More Than 1 VPN Tunnel (871w)
Thanks for the response, guys...
Tom, the tunnel is fine, it's working, so my direction on this hairy vpn ride is good.  I'm just looking for the specific command required to allow more than one tunnel I've got separate policies (i.e., policy 10, policy 20) for both tunnels, I just need them to both run at the same time instead of just one at a time which is the issue at the moment. I'm ploughing through docs and haven't come across the command I need as of yet...
What is the specific syntax I'm looking for on the link you provided, Aryoba, regarding increasing the vpn tunnels?
'Preciate the help.
Jay |
|
aryoba
Premium,MVM
join:2002-08-22
| Multiple policy (for IPSec tunnel Phase 1 establishment) is used usually for encryption method compatibility. As example, one VPN device is VPN tunneling with another using 3DES and with the 3rd device using DES. If all of VPN devices are running the same encryption method, then a single isakmp policy should be sufficient.
On the other hand, multiple crypto map (for the IPSec tunnel Phase 2 establishment) is used specifically for each individual tunnel between two VPN devices.
Example
»www.cisco.com/en/US/products/sw/···78.shtml
The 2nd crypto map for the 2nd tunnel could look something like this
assuming
* all VPN devices are using the same encryption method for both Phase 1 and Phase 2
* the 3rd VPN device is in front of 172.16.3.0/24 network |
|
TomS_
debugger it
Premium,MVM
join:2002-07-19
Australia
| reply to DocLarge
DocLarge: Heres a practical example of multiple VPNs. This is probably what youre looking for:
That should do it for you :-)
I was feeling generous ;-)
Also, props go out to covenant for showing me how to do this quite a while ago :-) |
|
MSN
join:2004-05-15
Osgoode, ON
| This was all good advice. I talked to DocLarge last night and we sorted it out. I teach this stuff for Cisco and he and I arrived at a good analogy:
Essentially the crypto map is a virtual IPsec interface. All VPNs (both site-to-site and remote access) terminate on this virtual interface. If you think of the crypto map as the hub in a hub-and-spoke arrangement with the spokes being the VPN peers this makes sense. In the example above (thanks TomS_ !) the IPsec interface is identified as "ipsec-maps" The different VPN "spokes" are identified by their numbers. For example, "crypto map ipsec-maps 30 ipsec-isakmp" creates "spoke" 30, and the different components of the IPsec policy for moving traffic to/from the peer are grouped by that number:
The key, then, is remembering that you only have one IPsec interface tied to any one physical interface. Once you have created this crypto map, you link it to a "reall" interface like this:
In TomS_ 's config it is done with this command:
/Eric |
|
DocLarge
Premium
join:2004-09-08
4 edits | Thanks for the replies, gents...
As MSN said, we came to an understanding and all is running.
Where MSN calls it "hub and spoke," it (hub and spoke) can also be explained as the "anchor" crypto map (connectivity originates from it). Said differently, imagine the below map as my "first" crypto map:
crypto mapanchormap 110 ipsec-isakmp
Every other crypto map created needs to include the above crypto map as the "baseline" crypto map for vpn connectivity to take place (example given):
crypto map anchormap 111 ipsec-isakmp
set peer 22.33.44.55
match address 120 (Previously configured access-list)
etc...
crypto map anchormap 112 ipsec-isakmp
set peer 11.33.55.44
match address 140 (Previously configured access-list)
etc...
By approaching it from this standpoint, MSN helped bridge the gap
*Heh* it makes since now...
Jay |
|
