RyanMcClain
asked on
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.
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.
What is the goal? Why do you want the DC's to replicate to DC's in other sites?
ASKER
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.
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?
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
so only the 515 would need to be modified? what would the syntax look like?
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?
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
● 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
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
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
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
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