02-17-2011 07:55 AM - edited 02-21-2020 05:10 PM
I have a hub and spoke network, the hub is a 3845 router. We use ipsec vpn tunnels for communication from the spokes to the hub, spokes can't see each other. There is an offsite DR location that also has a 3845 that talks to my main sites 3845 for a couple of things; 1. Our secondary DNS server is at that site and needs to be able to talk to the stores and the main site for AD to work properly. Also the DR site is located inside one of our spokes, a retail store.
My question is this;
Since the DR router is setup with the same ipsec vpn connections, I can see in the spoke routers that it's trying to establish vpn connectivity, will that interfere with the vpn connectivity from the spoke to the main site?
02-17-2011 08:23 AM
Richard,
If you're using plain IPsec Site-to-Site, then you manually define the peer to talk to and the routers should not attempt to bring up a tunnel that is not explicitly defined.
If you're using other VPN method as DMVPN, then depending on the configuration, the router might try to negotiate a tunnel.
You should not have any problem, if you feel you're having a problem please post back to discuss.
Thank you,
Federico.
02-17-2011 09:13 AM
You are correct, unfortunatly the original designer of this network included the vpn connections from the DR site to all spokes in the same crypto map that defines the connection from the retail side of the DR site to the main site. The simple solution in my opinion would be to simply remove all the peers for the spokes and leave the peer that allows the retail side of the location to operate then save the DR peers to a text file for copy/paste as needed. What I need to do is establish whether or not the current setup could even cause a problem, if so then the owner will more than likely let me cut those peers and save them in a text file, if not then I can move on to troubleshoot another area.
Thanks for the reply!
02-17-2011 09:27 AM
Richard,
If all the peers are defined under the same crypto map, then the routers will attempt to establish the IPsec tunnel.
Now... if there's no traffic flowing between the protected networks between the spokes, the tunnel will not establish.
I would suggest that if there's no need for this tunnels, to remove the peers from the crypto map.
If there's no traffic flowing, there's no harm in leaving the configuration.
Hope it helps.
Federico.
02-17-2011 10:50 AM
but will the tunnels trying to be established from the DR site, inturupt, or effect vpn connectivity between the remote site and my main hub?
02-17-2011 10:58 AM
Richard,
The reason it will not affect the VPN traffic between your hub and spokes is because the ''interesting traffic'' between the DR site and the Hub is not the same.
In other words, when the spokes want to send traffic to the hub site, they will use as destination x.x.x.x (assuming x.x.x.x is the LAN side of the hub site)
x.x.x.x is not the LAN on DR side, so it will not interfere.
However, if the spokes attempt to connect to y.y.y.y (assuming y.y.y.y is the LAN on the DR site), then the tunnel will establish.
If there's no need for this traffic spoke-to-DR consider removing the crypto information is a good recommendation.
Hope it helps.
Federico.
02-17-2011 01:24 PM
So lets assume the tunnel does establish to the DR site from all the spokes, will that disrupt the vpn connectivity of my main site to the spokes, or can the routers handle that situation without problems?
02-18-2011 06:10 AM
Richard,
The only way that I can see that causing a problem is if you have overlapping IPs on your network and the DR side.
This might cause traffic to try to be sent across a tunnel established to the DR side instead of the hub side.
Just make sure the valid tunnels have priority and there are no IP address conflicts.
Federico.
02-18-2011 07:13 AM
How do I set priority? That seems like a very good idea.
02-18-2011 11:30 AM
Richard,
If you have 3 crypto map instances for example:
crypto map maymap 10...
.
crypto map mymap 20...
.
crypto map mymap 30...
Then the crypto maps are checked in sequential order.
This means that traffic will always be checked against crypto map 10, then 20 and finally 30.
If the valid peers are specified in a higher priority crypto map, you should be good to go.
Federico.
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