Cisco 877 VPN - two remote routers connecting to head office

Answered Question
Aug 25th, 2009

Hi all.

Our head office has an 877.

Our two remote sites also have 877's and they have a permanent tunnel into the head office 877 which works OK.

My issue is that the two remote sites cannot talk to each other - but they can talk to head office fine.

I take it I have some sort of NAT issue - so i'll post the relevant configs and if someone could take a look and point me in the right direction i'd be very pleased!!

Head office config is txt file 192.168.16.5

Remote site 'Riversdale' is text file 192.168.17.1

Remote site 'Tynewydd' is text file 192.168.18.1

I have this problem too.
0 votes
Correct Answer by sunsrini about 7 years 4 months ago

How did you check with pings ? Is that from an internal host to internal host ?

Can you verify with pings between spokes ? Please use internal interface of spokes for both source/destination addresses. And send me "show crypto session detail" from all routers both before and after you send pings.

One thing I overlooked in your spokes (both) config is about NAT as well. Please rearrange both deny entries first followed by permit entry.

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.16.0 0.0.0.255

access-list 100 permit ip 192.168.17.0 0.0.0.255 any

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.18.0 0.0.0.255

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
sunsrini Tue, 08/25/2009 - 18:54

Spoke to spoke will not work with plain crypto maps in IOS. If you are having only 2 remote sites, you can add another crypto map in both spokes directly. Similar to the config in hub side, you will have separate crypto map for the hub and the other spoke.

davieshuw Wed, 08/26/2009 - 06:04

OK - i dont mind routing the traffic back to head office and back out again - would that be possible?

so basically what i'd have is:

on router 192.168.17.1

ip route 192.168.18.0 255.255.255.0 192.168.16.5

and on router 192.168.18.18.1

ip route 192.168.17.0 255.255.255.0 192.168.16.5

sunsrini Wed, 08/26/2009 - 10:47

In that case, routing is just not enough, there should be matching entries in the crypto acl also.

From the hub side, I see you currently have this.

access-list 100 permit ip 192.168.16.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 102 permit ip 192.168.16.0 0.0.0.255 192.168.18.0 0.0.0.255

Please add the following in the hub for above acls.

access-list 100 permit ip 192.168.18.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 102 permit ip 192.168.17.0 0.0.0.255 192.168.18.0 0.0.0.255

Please note this will put additional overhead for Hub side, as it needs to decrypt from one spoke and encrypt again for the other spoke.

davieshuw Thu, 08/27/2009 - 01:50

Hi - thanks for the reply.

I added the routes suggested - unfortunatley the two spokes still cant talk via the head office hub - both pings and telnet to each location does not seem to work

The reason im not too bothered about going via 192.168.16.5 is that there'll be the bare minimal amount of traffic point to point - the odd CCME RTP stream.

Correct Answer
sunsrini Thu, 08/27/2009 - 14:36

How did you check with pings ? Is that from an internal host to internal host ?

Can you verify with pings between spokes ? Please use internal interface of spokes for both source/destination addresses. And send me "show crypto session detail" from all routers both before and after you send pings.

One thing I overlooked in your spokes (both) config is about NAT as well. Please rearrange both deny entries first followed by permit entry.

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.16.0 0.0.0.255

access-list 100 permit ip 192.168.17.0 0.0.0.255 any

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.18.0 0.0.0.255

Mozhzhukhin Thu, 08/27/2009 - 17:14

In first file:

access-list 101 deny ip 192.168.18.0 0.0.0.255 192.168.16.0 0.0.0.255

access-list 101 deny ip 192.168.18.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 101 permit ip 192.168.18.0 0.0.0.255 any

Remove:

ip route 192.168.17.0 255.255.255.0 192.168.16.5

In last file:

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.16.0 0.0.0.255

access-list 100 deny ip 192.168.17.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 100 permit ip 192.168.17.0 0.0.0.255 any

Remove:

ip route 192.168.18.0 255.255.255.0 192.168.16.5

davieshuw Fri, 08/28/2009 - 00:25

hi there - pings are successful now - rearranging the nat statements as you suggested worked - so thanks very much for your help! i'll try a voice call over it to see what the latency is like but should be OK. Agreed DMVPN would be a better solution - but for the odd 1 minute phonecall per day I should be able to get away with this setup.

Thanks!!

davieshuw Tue, 11/17/2009 - 00:26

ok odd... the issue is now back since I added a new remote VPN site that terminates onto the router 192.168.16.5 (i cannot ping between remote sites any more)

the new remote sites internal ip is 192.168.19.1

the access list on the head office router seems to have grown some random access list entries (104,105,106 and 107)

access-list 1 remark SDM_ACL Category=2

access-list 1 permit 192.168.16.0 0.0.0.255

access-list 100 remark SDM_ACL Category=4

access-list 100 remark IPSec Rule

access-list 100 permit ip 192.168.16.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 100 permit ip 192.168.18.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 101 remark SDM_ACL Category=2

access-list 101 remark IPSec Rule

access-list 101 deny ip 192.168.16.0 0.0.0.255 192.168.19.0 0.0.0.255

access-list 101 remark IPSec Rule

access-list 101 deny ip 192.168.16.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 101 remark IPSec Rule

access-list 101 deny ip 192.168.16.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 101 permit ip 192.168.16.0 0.0.0.255 any

access-list 102 remark SDM_ACL Category=4

access-list 102 remark IPSec Rule

access-list 102 permit ip 192.168.16.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 102 permit ip 192.168.17.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 103 remark SDM_ACL Category=4

access-list 103 remark IPSec Rule

access-list 103 permit ip 192.168.16.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 104 remark SDM_ACL Category=4

access-list 104 remark IPSec Rule

access-list 104 permit ip 192.168.16.0 0.0.0.255 192.168.19.0 0.0.0.255

access-list 105 remark SDM_ACL Category=4

access-list 105 remark IPSec Rule

access-list 105 permit ip 192.168.16.0 0.0.0.255 192.168.17.0 0.0.0.255

access-list 106 remark SDM_ACL Category=4

access-list 106 remark IPSec Rule

access-list 106 permit ip 192.168.16.0 0.0.0.255 192.168.18.0 0.0.0.255

access-list 107 remark SDM_ACL Category=4

access-list 107 remark IPSec Rule

access-list 107 permit ip 192.168.16.0 0.0.0.255 192.168.19.0 0.0.0.255

no cdp run

Actions

This Discussion