08-25-2009 09:33 AM - edited 02-21-2020 03:38 AM
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
Solved! Go to Solution.
08-27-2009 02:36 PM
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
08-25-2009 06:54 PM
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.
08-26-2009 06:04 AM
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
08-26-2009 10:47 AM
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.
08-27-2009 01:50 AM
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.
08-27-2009 05:50 AM
I am not sure you can do it with this VPN configuration.
You have to use DMVPN or VTI to do this because they create Tunnel interfaces and can be routed. I would recommend DMVPN as it can establish direct connection between spokes.
08-27-2009 02:36 PM
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
08-27-2009 05:14 PM
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
08-28-2009 12:25 AM
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!!
11-17-2009 12:26 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide