Solved

Site to Multi-Site VPN Design

Posted on 2006-07-12
10
471 Views
Last Modified: 2013-11-16
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.
0
Comment
Question by:RyanMcClain
  • 4
  • 3
  • 3
10 Comments
 
LVL 2

Expert Comment

by:just-one-it
ID: 17092814
What is the goal?  Why do you want the DC's to replicate to DC's in other sites?
0
 

Author Comment

by:RyanMcClain
ID: 17092886
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
 
LVL 2

Expert Comment

by:just-one-it
ID: 17092913
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
 

Author Comment

by:RyanMcClain
ID: 17092971
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
 
LVL 2

Accepted Solution

by:
just-one-it earned 250 total points
ID: 17093005
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
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:RyanMcClain
ID: 17093038
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
 
LVL 2

Expert Comment

by:just-one-it
ID: 17093063
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
 
LVL 11

Expert Comment

by:NetoMeter Screencasts
ID: 17095142
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
 
LVL 11

Expert Comment

by:NetoMeter Screencasts
ID: 17100188
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
 
LVL 11

Expert Comment

by:NetoMeter Screencasts
ID: 17100360
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

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Let’s list some of the technologies that enable smooth teleworking. 
Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now