Site to Multi-Site VPN Design

Hi, I'm trying to reorginize our companies VPN structure and I need some smarter ways to do some things.

We have 1 windows 2000 domain
we have a corporate site with a pix 515
we have 18 remote sites with various speed internet dsl's with pix 506's
Each remote site has a DC and there are 2 DC's at Corp.
Most services are at Corp. Exchange financial programs etc.
All of the remote sites need to access thier own internet as well as the VPN

Currently the all the sites have VPN pointing to the Corp PIX.
So when a server (DC) wants to replicate with another it can only replicate to the corporate DC's and not any others. The main part of my question is that I want to change this so that all DC's can replicate to each other, but not allow any client pc's in the sites to see other sites. How can I accomplish this with the least amount of headache and administration. I do not need basic step by step pix configs, mainly just a smart layout and any tricky command spots. Thanks in advance.
RyanMcClainAsked:
Who is Participating?
 
just-one-itConnect With a Mentor Commented:
It is true that changes made on one DC would take time to replicate, but you really shouldn't be making changes on the remote DC's anyway.  All changes should happen on the central servers which will then replicate accross to the remote sites.  That being said, you could simply build an ACL on your Pix 515 that allows all RPC, Netbios, and kerberos traffic exclusively from the DC's on your remote sites to flow through to each other.  This way they could communicate but the clients wouldn't be able to see the other sites.
0
 
just-one-itCommented:
What is the goal?  Why do you want the DC's to replicate to DC's in other sites?
0
 
RyanMcClainAuthor Commented:
Mainly for proper replication. right now its very hit or miss the way it is. Also AD sites are setup, they are trying to replicate with there partners and creating Event errors.
0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
just-one-itCommented:
Well, I'm not a windows guru, but I don't see why you would need to replicate between DC's in the remote sites.  As log as all of the remote DC's can replicate to the corp DC's then you should be fine.  Are you having specific issues with information not being replicated?
0
 
RyanMcClainAuthor Commented:
yes and I'm not a AD master but I have been under the impression that its preferable and even recommended to have all DC's in the domain be able to see each other on the network. Plus if you were to make a change on a DC in a remote site it would take a very long period of time to be replicated throughout the domain.
0
 
RyanMcClainAuthor Commented:
So all the VPN's as they sit now connecting to the 515 from all the sites could stay the same.

so only the 515 would need to be modified? what would the syntax look like?
0
 
just-one-itCommented:
Presuming that you are already allowing traffic through the 506's, then yes.  Can you post the config from your 515 here so I can get a better idea how your network is layed out?
0
 
NetoMeter ScreencastsCommented:
Hi!
● If your current configuration is Hub-and-Spoke type – traffic flows through Site-to-Site VPN tunnels only between the central site and the remote sites, this means that KCC (Knowledge Consistency Checker) has generated an InterSite replication topology based on the connectivity between the Domain Controllers (Bridgehead servers) in the sites. Effectively this means that in each remote site KCC should generate only one connection objects for InterSite replication between the Remote and Central Bridgehead server. You can check this in the Sites and Services snap-in. In the central bridgehead you should see 18 connection objects for InterSite replication – one for each site. Please, let us know if this is not so as this would mean some other problem.
● Based on that the DCs in remote sites should never try to replicate between each other – the replication flow should be only between the central and remote DCs which significantly reduces the replication traffic.
● How can you speed up replication? If you change an object in a remote site and want to speed up the replication to another remote site you can do it in two steps (Ping-Pong procedure):
- Step1 – right-click the inbound replication object in the central site which corresponds to the remote site where the change is done and choose “replicate now”.
- Step2 - right-click the inbound replication object in each remote site which points to the central server and choose “replicate now”.

Generally there are two approaches for enabling traffic between the remote sites:
● Allowing the traffic through the central site.
● Creating Full/Partial mesh between the remote sites

I don’t think that the first one will give you the redundancy which you need and which I guess it the main reason for changing the design of your network.
My personal opinion is that the second approach is the way to go. I would suggest choosing a couple of sites for Sub-hubs (for example 3). You can configure full mesh between them. Then each of the Sub-hubs will have 6 connections to the lower level sites. KCC will recalculate automatically the replication topology based on the connectivity and speed between the sites.
Finally allowing the intersite traffic only to DCs can be achieved by applying the corresponding ACL for interesting traffic for the VPN tunnels (the DCs have static addresses).

I hope this post was helpful.

Dean
0
 
NetoMeter ScreencastsCommented:
DISCLAIMER from the Moderators: the links in this post require a paid registration to view.

You might find helpful the following Cisco document - “Configuring PIX-to-PIX-to-PIX IPSec (Hub and Spoke)”:
http://www.netometer.net/books/pixhubspoke.pdf

Dean
0
 
NetoMeter ScreencastsCommented:
DISCLAIMER from the Moderators: the links in this post require a paid registration to view.

As you can read in the introduction of the document the problem is that Cisco PIX 6.35 and earlier does not support routing traffic received on one interface back out the same interface. So applying ACL won’t allow VPN traffic from the remote sites through the central PIX.
You have to configure hairpinning in a VPN environment which is a new feature introduced with PIX version 7.0:
http://www.netometer.net/books/enhance-vpn-pix70.pdf 

Dean
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.