cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
643
Views
0
Helpful
5
Replies

Which one to choose: EasyVPN or DMVPN ??

egonzalez
Level 1
Level 1

Hello,

I'm a little lost here, I have the following set:

(2) Cisco 827-4v ADSL, w/voice, pppoe, DYNAMIC internet address, IOS 12208YN IP/ADSL/VOX/PLUS IPSEC 3DES, intented to be the VPN's clients

(1) Cisco 1760, same: ADSL, pppoe, but STATIC IP for the internet connection, pretended to be the server,

IOS 12208YN <--- Using this IOS because of the 4 port FXS/DID interface card.

Using NAT on the 3 sites, with a NONAT route for

sharing the internet connection.

Couln't config the EzVPN solution,

I'm using dynamic maps with pre-shared keys and both

spokes can pass traffic TO the HUB, but I cannot

sent traffic between the spokes even thru the HUB, when I try this, the SH CRYPTO IPSEC SA shows: "Send errors: 5" (Trying to ping spoke to spoke even specifying source interface)

Read about DMVPN but I cannot deploy this because of

the IOS and additional hardware needed on the 1700.

HAVE READ LOTS OF DOCUMENTS !!!

So, Can I get to communicate the 2 spokes thru the hub having them both dynamic IP's peering to the 1760 and still using NAT????

Any help will be deeply appreciated.

Thanks-

1 Accepted Solution

Accepted Solutions

Your access-list needs to include entries for the spoke-to-spoke traffic in each direction, like this:

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.8.0 0.0.0.255

access-list 115 permit ip 192.168.6.0 0.0.0.255 192.168.8.0 0.0.0.255

You might have to use a separate crypto dynamic-map set for each spoke, but since both spokes are working to the hub site now the above might also work (dynamic maps are a bit odd). If the above doesn't work, I'd try creating a separate list for each spoke site like this:

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 116 permit ip 192.168.100.0 0.0.0.255 192.168.8.0 0.0.0.255

access-list 116 permit ip 192.168.6.0 0.0.0.255 192.168.8.0 0.0.0.255

If you do this you'll also need a second crypto dynamic-map clause with "match address 116" for the second access-list, since you only get a single "match address" in one crypto map set.

Let us know how it goes.

View solution in original post

5 Replies 5

You can only use TED if the LAN IP addresses you want to get to across the VPN are routable, which I suspect they aren't in this case or they probably wouldn't be doing NAT.

If you can't do DMVPN then you'll have to configure additional access-list entries in all the devices so that spoke-to-spoke traffic is included. So, at each spoke the access-list referenced in the "match address" command will have to include the LAN of the other spoke site as a destination in addition to the LAN of the hub site. The hub site will need to update both access-lists to reflect that the valid sources for traffic to each spoke include the LAN of the other spoke (I hope that makes sense). The down side of this is that the hub router will have to decrypt then re-encrypt traffic between the spokes in both directions, so the CPU load of that router could be an issue if you don't have VPN accelerator hardware.

Good luck!

Thank you for taking time and help !!!

I DO HAVE a VPN accelerator hardware installed on the hub,

I added the following lines to the access list :

On the hub....

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.8.0 0.0.0.255

Spoke1

access-list 115 permit ip 192.168.6.0 0.0.0.255 192.168.100.0 0.0.0.255

access-list 115 permit ip 192.168.6.0 0.0.0.255 192.168.8.0 0.0.0.255

Spoke2

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.100.0 0.0.0.255

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.6.0 0.0.0.255

If I try to ping from one spoke to the other there is NO echo and the SA shows:

local ident (addr/mask/prot/port): (192.168.6.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.8.0/255.255.255.0/0/0)

current_peer: xxx.xx.xx.xxx:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 5, #recv errors 0

local crypto endpt.: xxx.xx.xx.xxx, remote crypto endpt.: xxx.xx.xx.xx

path mtu 1500, media mtu 1500

current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

As you can see, no packets are sent and the 5 pings are showed in the: " #send errors 5, #recv errors 0"

What am I doing wrong???

I have great results from spoke to hub and hub to spoke traffic, but cannot

make the spoke to spoke....

Any comments will be appreciated...

Your access-list needs to include entries for the spoke-to-spoke traffic in each direction, like this:

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.8.0 0.0.0.255

access-list 115 permit ip 192.168.6.0 0.0.0.255 192.168.8.0 0.0.0.255

You might have to use a separate crypto dynamic-map set for each spoke, but since both spokes are working to the hub site now the above might also work (dynamic maps are a bit odd). If the above doesn't work, I'd try creating a separate list for each spoke site like this:

access-list 115 permit ip 192.168.100.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 115 permit ip 192.168.8.0 0.0.0.255 192.168.6.0 0.0.0.255

access-list 116 permit ip 192.168.100.0 0.0.0.255 192.168.8.0 0.0.0.255

access-list 116 permit ip 192.168.6.0 0.0.0.255 192.168.8.0 0.0.0.255

If you do this you'll also need a second crypto dynamic-map clause with "match address 116" for the second access-list, since you only get a single "match address" in one crypto map set.

Let us know how it goes.

IT WORKED !!!!

The best result I got was using 1 Crypto dynamic-map clause for each spoke at the

hub, using one access list for each one (115 and 116), it worked really nice.

Thanks a lot. !!!