VPN important !!

illusion_rox · ‎03-04-2008

hi guys, we have a hub (3640) and 40 spokes (1841), our requirement is, whenever a server at branch wants to communicate with any1 in the network it should go through HUB through VPN. at branch site the configuration is simple

crypto isakmp enable

crypto isakmp key abc123 address 10.56.56.2

crypto isakmp policy 10

auth pre

enc des

has md5

group 1

ip access-list extended S2S_VPN_HUB

per ip host 10.1.1.27 10.0.0.0 0.255.255.255

crypto ipsec transform-set abc_SET esp-des esp-md5-hmac

crypto map ABC_MAP 10 ipsec-isakmp

match address S2S_VPN_HUB

set peer 10.0.152.2

set transform-set abc_SET

applied to the tunnel interface

int tun 1

crypto map ABC_MAP

similar configuration was done on 4 other spokes, this was the configuration done on HUB

crypto isakmp enable

crypto isakmp key abc123 address x.x.x.x ! Spoke 1 link

crypto isakmp key abc123 address x.x.x.x ! spoke 2

crypto isakmp key abc123 address x.x.x.x ! spoke 3

crypto isakmp policy 10

auth pre

enc des

has md5

group 1

10.0.0.0 0.255.255.255 10.0.0.27 0.255.255.0 ( servers at each branch has last octet 27, like 10.1.1.27, 10.1.2.17 etc )

ip access-list extended spoke1

per ip 10.0.0.0 0.255.255.255 host 10.1.1.27

ip access-list extended spoke2

per ip 10.0.0.0 0.255.255.255 host 10.1.2.27

ip access-list extended spoke3

per ip 10.0.0.0 0.255.255.255 host 10.1.3.27

crypto ipsec transform-set XYZ_SET esp-des esp-md5-hmac

crypto map XYZ_MAP 10 ipsec-isakmp

match address XYZ-Crypto-Acl

set peer x.x.x.x

set transform-set XYZ_SET

crypto map XYZ_MAP 20 ipsec-isakmp

match address XYZ-Crypto-Acl

set peer x.x.x.x

set transform-set XYZ_SET

crypto map PNSC_MAP 30 ipsec-isakmp

match address XYZ-Crypto-Acl

set peer x.x.x.x

set transform-set XYZ_SET

now as you can see that i have to make different ACL for every spoke, is there a workaround ?? i used a generic access-list stating

per ip 10.0.0.0 0.255.255.255 10.0.0.27 0.255.255.0

but the problem with this access-list is that it always get matches in the first XYZ_MAP 10 statement and tries to form VPN with spoke 1 even if the traffic should be going to spoke 2, means when traffic from spoke 2 wants to go to spoke 3 the first statement in crypto map matches this traffic ( 10.0.0.0 --> 10.1.3.27 ) so it tries to form VPN with Spoke1 which should have been made with correct spoke3, so do i have to make seperate access-list for all the spokes ?? or do you guys prefer going for CA ?? we dont want to make our configuration large until its a last choice,

So what do you guys prefer ?? if CA then which 1 ??

ivillegas · ‎03-10-2008

Using the statement " per ip 10.0.0.0 0.255.255.255 10.0.0.27 0.255.255.0 " would mean trying to estabish VPN with the first available ip address which would be 10.1.1.27. So I would prefer to use seperate statement for each though it is tedious.

joe19366 · ‎03-10-2008

First a 3640 is end of sale/life/support or all 3. its way too old and slow to be used for any encryption these days... as a matter of fact, the 1841 is more suitable to be a vpn hub, than a 3640.

I recommend you get a 2811 for the vpn hub, or at least use a 1841.

then I recommend you configure this network to be a dmvpn (dynamic multipoint vpn)

You can see my wikipedia page for dmvpn.

thanks,

http://en.wikipedia.org/wiki/Dynamic_Multipoint_Virtual_Private_Network

illusion_rox · ‎03-11-2008

Dear Joe, DMVPN has some issues, first it requires that out of 2 sites one should have a static statement, so if i give static statement at spoke, traffic from spoke to hub will go through a vpn tunnel, but what if traffic initiates from the hub ?? since it doesnt have any static statement how will it form tunnel with a specific spoke ??

Herbert Baerten · ‎03-12-2008

With DMVPN, the tunnels are always up (unless there is a connectivity issue of course).

More detailed answer: the spokes register themselves to the hub using NHRP. This NHRP traffic will bring up the tunnel and keep it up, and will cause the hub (the NHS in NHRP terminology) to learn the mappings between transport network ip address (physical ip) and overlay network ip address (tunnel ip) of the spokes.

That said, if you really want you can also define static NHRP entries on the hub. I've never seen anyone do this though.

Herbert Baerten · ‎03-12-2008

If the 3640 is sufficient for the task, depends on whether it has a hardware crypto accelerator installed, how many tunnels it needs to terminate, and more importantly how much traffic it needs to encrypt/decrypt.

For a few Mbps of traffic and not too many spokes connecting at once, it should do the job.

But as Joe mentioned, it will be EoL on December 31, 2008 so don't expect software updates or TAC support after that.

illusion_rox · ‎03-13-2008

Hebaerte, 3640 is not of an issue, we are replacing it with either 3845 or 2821, currently i am worried about which design shall i follow, Static Site-to-Site VPN, or DMVPN ? we sure have connection issues with links going down so will it gonna cause much trouble even when the link is up ? ( like vpn not forming correctly and requires tough troubleshooting) so i am asking of your guys experience here to help me choose a better design .

Thanks