ipsec vpn w/ DR vpn site issue

[ubuntu_guy]

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?

[Federico Coto Fajardo]

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.

[ubuntu_guy]

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!

[Federico Coto Fajardo]

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.

[ubuntu_guy]

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?

[Federico Coto Fajardo]

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.

[ubuntu_guy]

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?

[Federico Coto Fajardo]

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.

[ubuntu_guy]

How do I set priority? That seems like a very good idea.

[Federico Coto Fajardo]

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.