AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL)

By Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007, 2010 & 2013, Exchange 2013, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Updated 12/12/2013


Ace here again with something I really would like to discuss, since this topic comes up from time to time.

To properly designed an AD multi-site infrastructure, there are a few things that need to be taken into account. I won’t bore you with all the background techno babble, rather I’m going to discuss a no-nonsense, get down to business on why you need to either keep Auto Site Link Bridging enabled, or why you need to disable it, both of which depends on your physical routed topology design.

AD Sites

First, a basic understanding of Active Directory Sites is important to understand before I go further.

Some of the biggest questions I hear about AD Sites are:

  • What are AD Sites?
  • What are AD Sites for?
  • Why can’t I create an AD Site without a domain controller in the Site?

These are all valid questions. A little research will usually result in an answer, but you may have to dig through piles of technical details to get to it. Let’s address each one:

What are AD Sites?

An AD Site defines a highly-connected, physical network locations in Active Directory. We define them by IP subnet or subnets. And yes, you can have multiple subnets that are highly-connected by routers within a location. In some cases, for example, if you have a very high-speed backbone, such as an OC-1 (51.84Mbps or higher), between locations, you can put all those subnets in one AD Site. However, in many cases, we probably don’t want to do that. Hang in there, I’ll be getting to that in a few minutes.

What are AD Sites for?

AD sites are basically used for two things:

  1. To facilitate service localization. In simple English, this means to control logon and authentication traffic to DCs in a specific location, or Site. After all, we don’t want a client in NYC to pick a DC in Seattle, Japan, or somewhere else, to send its logon or authentication request (such as when accessing a folder), do we? Nope. The client side DC Locator process will find a DC in its own Site by using the client’s IP address.
  2. To manage DC replication traffic. In simple English, this means to control DC replication traffic across WAN links between the bridgeheads (the DCs in a Site that communicate with DCs in other Sites). By default, replication between Sites are compressed down to 15% of total traffic. And with Sites, we can control frequency of replication, and when we’re allowing it to happen.’

Why can’t I create an AD Site without a DC in the Site?

Good question. If you look at what AD Sites are for, then it should be pretty obvious that you need a DC in it. After all, if there is no DC in it, and a client picks a Site based on its IP subnet, then looks for a DC, it won’t find any, will it? Nope, so it may wind up randomly picking a DC in another location, such as that DC in Seattle or Japan.

DC Locator Process

I don’t want to dwell on this, but I will briefly mention it because this is part of the reason why we want to create AD Sites anyway.

There is a process that a client uses to pick a DC. Here’s a quick view of how a client picks a DC. I should add a #9 to the list in a scenario when no DC exists in the Site, then it uses Automatic Site Coverage, and this ONLY if you created an IP Site link to another Site that you want the DCs to cover that site.

If you didn’t create an IP Site link for a Site that has no DCs, then it will pretty much become a random process, sort of, by using other factors, such as subnet netmask ordering and Round Robin. If you want to read up on this subject, here are two good TechNet Forum discussions on it:

Briefly, here are the DC Locator process steps, and these steps were directly quoted from How Domain Controllers Are Located in Windows XP

  1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
  2. DNS server returns list of DC’s.
  3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
  4. DC returns…
    1. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
    2. The site that the current domain controller is in.
    3. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
  5. The client decides whether to use the current DC or to look for a closer option.
    1. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
    2. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.

Brief overview:

For a full-sized image, click on the images.

Let me point out again, that if there are no DCs in a Site, then Automatic Site Coverage will take over.

To me, it’s a process to “find” a DC that will authenticate a user in a Site without a DC. However, my take on it is I would rather associate the location’s subnet to a current Site so as to not make the client go through this process. Besides, there may be scenarios that not having a DC in a Site can directly affect directory enabled applications and services such as DFS site referrals, SCCM or Exchange with it’s high dependency on GCs and DSAccess.

Here’s the DC Locator process, directly quoted from the Technet article, “How DNS Support for Active Directory Works:”

  1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
  2. Build a list of candidate sites — sites that have domain controllers for this domain.
  3. For every target site, follow these steps:
    1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
    2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
    3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
    4. If more than one, break ties by choosing the site that is first alphabetically.
    5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

If there are no DCs in a Site, you can use PowerShell to figure out which DC in which Site will be picked. If you like, you can further read up on the commands used to figure this out in Sean Ivey’s blog:

Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE

So wouldn’t you want your clients to pick a DC in its own Site?

Moving forward, do we really want a client to pick a DC in some other site or go through the Automatic Site Coverage process? Would you want that? I ‘m sure you already know the answer to that.

Therefore, if you have a location that have no DCs, then simply create an IP subnet object, and associate the subnet object to an existing AD Site that you want those users to use. In this case, you may base your own pick on a site linked by the fastest WAN link, or the only WAN link.

And if there are any subnets that are not associated with an AD site, then any DC is game to authenticate a client, as seen in the process above. To check for clients which subnets are not configured to AD Sites & Services, among other things, enable Netlogon logging, and check the system32\config\netlogon.log file. Here’s more info:

Enabling debug logging for the Net Logon service, Last Review: May 3, 2011 – Revision: 11.0, Applies to: all operating systems.

Auto Site Link Bridging

This now brings us to bridging, what it is, etc.

Within an AD Site, the KCC (Knowledge Consistency Checker) will automatically assume that all DCs can directly reach each other, and create Intrasite replication partnerships between the DCs in the Site. The one point that I want to be clear about that no matter how many DCs are in a Site, and there can be hundreds of DCs in a Site, the KCC will make sure that the  partnerships created are done so that all DCs in a Site will have an updated replication set for any changes by any of the DCs in the site, within 15 minutes. If you add a new DC to the Site, the KCC jumps in and evaluates the new guy and adds it so it gets updated data from other DCs under 15 minutes. How does it do that? It follows a set algorithm, but that is beyond this discussion.

When there are multiple Sites, and more specifically three or more Sites, and keeping in mind that by default AD automatically assumes that all the Sites have direct physically connectivity and communications between each other. This means you can literally ping a DC from in any Site to any other Site.

Here’s where the ISTG (Intersite Topology Generator) kicks in. The ISTG is a component of the KCC. It evaluates the overall topology, and builds connection objects between servers in each of the sites to enable Intersite replication— DC replication between sites.

Here’s a fully routed infrastructure, For the full-sized image, click here.


If remote sites cannot directly communicate with each other and only to the hub site

However, if your physical network topology is designed where each site does not have direct communications with each other, and you leave all the default “Auto Site Link Bridge” setting enabled as is, then lots of things will go wrong, such as replication problems, duplicate AD integrated zones, and more … keep reading. But I won’t address duplicate zones. You can click the link in the previous sentence for more on that.

If the network topology was a hub and spoke and BASL wasn’t disabled and individual sites links between the hub and each site weren’t created until recently, then there may be replication problems. This is a whole different subject. What I can say, besides checking to see if there are duplicate zones, as I mentioned in the previous paragraph, I would also run the Active Directory Replication Status Tool to check replication status. It will provide a report, and anything amiss will show up in Red. Pretty cool tool. Download it here:

Download The Active Directory Replication Status Tool (ADREPLSTATUS):
     Note: This tool requires .Net Framework 4. If it’s not installed, download and install it:
       Microsoft .NET Framework 4 (Web Installer)

Remember, by default, the KCC assumes all sites can directly communicate, therefore it will create partnerships between Bridgeheads in all sites. And any DC in a site can automatically become a bridgehead.

So if corporate headquarters is in NYC, and you have three remote locations, Miami, Chicago and Seattle, and direct communications does not exist, meaning that each remote location can only communicate with headquarters, and IP routing has not been configured between the remote locations, and the KCC creates a connection object (partnership) between a DC in Miami and a DC in Seattle, what will happen?

Since they can’t directly communicate, then replication fails. And if the Seattle partnership is the only connection object Miami may have, but Seattle happens to have one to NYC, and keeping in mind, replication is a PULL request, then Seattle will receive replication from NYC, but Miami can’t pull anything from Seattle, because there is no direct or indirect communications. So Miami winds up being in a secluded island.

In Miami’s DC’s view, it thinks no one wants to talk to it, so it will complain (you will see multiple event log errors) that others having replicated with it. And according to the DCs in the other sites, they will all think the same thing about Miami.

So who’s right? Of course, they all are. If the lack of replication goes beyond the AD Tombstone, then Miami would need to be demoted. Then again, you can’t even do that because it doesn’t have direct communications with its partner. Then if it does pick a DC in headquarters to demote, you will see an error stating that the headquarters DC already thinks the DC no longer exists. In the case of trying to demote it, or even forcedemoting it beyond the Tombstone, then your only option is to unplug it, run a metadata cleanup and re-promote it. But wait, then the same thing will occur if you don’t disable BASL.

So is it right that we do the same thing over and over and expect different results? Nope. Let’s configure AD to make sure it will not happen again, by disabling BASL.

Here’s a non-fully routed infrastructure. For the full-sized image, click here.

Disable BASL

Simply put, what we need to do is disable BASL (Bridge All Site Links) in a non-fully routed infrastructure to tell the KCC to only partner DCs across a specific site link.

Yes, that means you also have to create specific IP site links between headquarters in NYC to each site, as the image above shows.

And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, otherwise the KCC will partner with a DC that it may not have direct communications with.

How to disable BASL. For the full-sized image, click here.


If you want to make sure your AD infrastructure is properly purring along and doing its job, then by all means let’s design it properly, make the necessary modifications, and other changes, to get it going in the right direction.

Oh, and you can’t forget to bone up on your DNS knowledge and how it supports AD. All Sites get registered in DNS by the netlogon service. Read more:

How DNS Support for Active Directory Works

And to understand the DNS SRV records registered by a DC’s Netlogon service, read Sean Dubey’s blog, with DNS SRV records examples, once again, I refer you to Sean Ivey’s blog:

Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE


Designing the Site Topology

Detailed branch office deployment guide (downloadable doc)

Best Practice Active Directory Design for Managing Windows Networks

You may want to take a look at the design IPD guide (Infrastructure Planning and Design) for AD – Download Details: IPD guide for Active Directory Domain Services – version 1.0

Download the complete Infrastructure Planning and Design (IPD) Guide Series v2.0 including links for AD IPD, SCCM IPD, and more.

Comments & Corrections are welcomed.

Ace Fekay

Active Directory Firewall Ports – Let’s Try To Make This Simple


Ace here again. I thought to clean up and re-publish my blog on AD ports requirements. Yes, they are extensive, to the dismay of the network group in your organization. But it is what it is, and it is what we need to follow to make AD work.

RPC server not available? Replication errors in the Event viewer? Sound familiar?

If so, you’ve been succumbed to the fact and realization there are possibly necessary ports being blocked causing these familiar AD communications errors. Whether between locations with firewall/VPN tunnel port blocks, Windows Firewall (which is usually not the culprit because they will auto-configure for the role of the machine and it’s current network location), or even security software or antivirus apps with some sort of “network traffic protection” feature enabled that is causing the problem.

Simply speaking, if there are replication or other AD communication problems, and you have an antivirus software installed on the endpoints or installed on all of  your DCs, disable it, or better yet, uninstall it. Uninstalling it is the best bet, so you know there are no traces of other subcomponents that are active that may still be causing the block. If after uninstalling it, and you find replication now works, well there you have it. At that point, you’ll need to contact your antivirus vendor to ask them the best way to configure it to allow AD communications and replication.

If it’s not your antivirus or security app, and disabling the Windows firewall doesn’t do the trick, then it’s obvious it’s an outside factor – your edge/perimeter firewalls.

Also to point out, when testing for port blocks, tools such as telnet is not a good tool to test AD/DC to DC connectivity, nor is any sort of standard port scan, such as using nmap, or a simple ping, resolving with nslookup (although resolving required records is a pre-requisite), or other tools. The only reliable test is using Microsoft’s PortQry, which tests specific AD ports and the ephemeral ports, and the required responses from the services on the required AD ports it specifically scans for.

AD through a NAT? Nope. Period.

Oh, and don’t expect to get this to work through a NAT. NATs cannot translate the encrypted RPC traffic therefore bonking LDAP communications.

Description of Support boundaries for Active Directory over NAT

How to configure RPC dynamic port allocation to work with firewalls”
AD communications won’t work through a NAT port translation, such as you cannot use DCOM through a NAT firewall that performs address translation (e.g. where a client connects to virtual address, which the firewall maps transparently to the server’s actual internal IP address of, say, This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it will not work.”
Quoted from:

Windows 2000 NAT Does Not Translate Netlogon Traffic (this applies to all DCs)
Quoted: “Windows 2000 NAT does not support Netlogon and translate Kerberos. If you have clients that are located behind a Windows 2000-based NAT server and need access to domain resources, consider creating a Routing and Remote Access virtual private network (VPN) tunnel for Netlogon traffic, or upgrade the clients to Windows 2000.”
Quoted from:


Ok, let’s find out if the ports are being blocked

Now you’re thinking that your network infrastructure engineers know what they’re doing and opened up the necessary ports, so you’re thinking, this can’t be the reason? or is it? Well, let’s find out. We can use PortQry to test it. And no, you don’t want to use ping, nslookup, nmap or any other port scanner, because they’re not designed to query the necessary AD ports to see if they are responding or not.

So let’s run PortQry:

First, download it:

       PortQryUI – GUI – Version 2.0 8/2/2004

Then run the “Domains & Trusts” option between DCs, or between DCs and any machine (other servers you want to promote, or even from a client machine), or from the bridgeheads in each site to the other bridgehead in the other site., pretty much anywhere that you want to test if there are any blocked AD ports.

The point is, you’ll want to run it in any scenario where a DC must communicate to another DC or to a client.

If you get any errors with “NOTLISTENING,” 0x00000001, and 0x00000002, that means there is a port block. Take note on which ports they are.

You can ignore UDP 389 and UDP 88 messages. If you see TCP 42 errors, that just means WINS is not running on the target server.

PortQry References

Knock Knock Is That Port Open?
By Mark Morowczynski [MSFT] 18 Apr 2011, Quick tutorial about PortQry GUI version.

“At times you may see errors such as The RPC server is unavailable or There are no more endpoints available from the endpoint mapper …”

How to use Portqry to troubleshoot Active Directory connectivity issues

If you want to use the command line only version:

Download details: PortQry Command Line Only Port Scanner Version 2.0

Understanding portqry and the command’s output: New features and functionality in PortQry version 2.0

Description of the Portqry.exe command-line utility

Portqry Remarks


DC to DC and DC to client communications Require Numerous ports

There’s no secret to this. That’s the simplest I can put it.

And, the list of ports required is long, to the dismay of network infrastructure engineering teams that must bequest ports to allow AD to communicate, replicate, etc., these ports must be opened. There really isn’t much that can be done otherwise.

Here’s the list with an explanation of each port:

Protocol and Port
AD and AD DS Usage Type of traffic 
TCP 25 Replication SMTP
TCP 42 If using WINS in a domain trust scenario offering NetBIOS resolution WINS
TCP 135 Replication RPC, EPM
TCP 137 NetBIOS Name resolution NetBIOS Name resolution
TCP 139 User and Computer Authentication, Replication DFSN, NetBIOS Session Service, NetLogon
TCP and UDP 389 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP
TCP 636 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP SSL
TCP 3268 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP GC
TCP 3269 Directory, Replication, User and Computer Authentication, Group Policy, Trusts LDAP GC SSL
TCP and UDP 88 User and Computer Authentication, Forest Level Trusts Kerberos
TCP and UDP 53 User and Computer Authentication, Name Resolution, Trusts DNS
TCP and UDP 445 Replication, User and Computer Authentication, Group Policy, Trusts SMB, CIFS, SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc
TCP 9389 AD DS Web Services SOAP
TCP 5722 File Replication RPC, DFSR (SYSVOL)
TCP and UDP 464 Replication, User and Computer Authentication, Trusts Kerberos change/set password
UDP 123 Windows Time, Trusts Windows Time
UDP 137  User and Computer Authentication NetLogon, NetBIOS Name Resolution
UDP 138 DFS, Group Policy, NetBIOS Netlogon, Browsing DFSN, NetLogon, NetBIOS Datagram Service
UDP 67 and UDP 2535 DHCP (Note: DHCP is not a core AD DS service but these ports may be necessary for other functions besides DHCP, such as WDS) DHCP, MADCAP, PXE

And We Must Never Forget the Ephemeral Ports!!

And most of all, the Ephemeral ports, or also known as the “service response ports,” that are required for communications. These ports are dynamically created for session responses for each client that establishes a session, (no matter what the ‘client’ may be), and not only to Windows, but to Linux and Unix as well.

See below in the references section to find out more on what ‘ephemeral’ means.are used only for that session. Once the session has dissolved, the ports are put back into the pool for reuse. This applies not only to Windows, but to Linux, Unix and other operating systems, as well. See below in the references section to find out more on what ‘ephemeral’ means.

The following chart shows what the ephemeral ports are depending on the OS version, and what they are used for.

Window 2003, Windows XP, and Windows 2000


1024-5000 Ephemeral Dynamic Service Response Ports
Windows 2008/Vista and newer TCP & UDP 49152-65535 Ephemeral Dynamic Service Response Ports
TCP Dynamic Ephemeral Replication, User and Computer Authentication, Group Policy, Trusts RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS
UDP Dynamic Ephemeral Group Policy DCOM, RPC, EPM

If the scenario is a Mixed-Mode NT4 & Active Directory scenario with NT4 BDCs, then the following must be opened:

TCP & UDP 1024 – 65535 NT4 BDC to Windows 2000 or newer Domain controller PDC-E communications RPC, LSA RPC, LDAP, LDAP SSL, LDAP GC, LDAP GC SSL, DNS, Kerberos, SMB

See, wasn’t that simple?


The Short list without port explanations:

Protocol Port
TCP 25
TCP 42
TCP 135
TCP 137
TCP 139
TCP and UDP 389
TCP 636
TCP 3268
TCP 3269
TCP and UDP 88
TCP and UDP 53
TCP and UDP 445
TCP 9389
TCP 5722
TCP and UDP 464
UDP 123
UDP 137
UDP 138
UDP 67
UDP 2535
TCP & UDP 1024-5000
TCP & UDP 49152-65535

If the scenario is a Mixed-Mode NT4 & Active Directory scenario with NT4 BDC:

The following Ephemeral ports must be opened (yes, it’s pretty much the whole range):

TCP & UDP 1024-65535


Restricting Ports Across a Firewall

You also have the ability to restrict DC to DC replication traffic, and DC to client communications, to a specific ports. Keep in mind, it also depends on what ports and services you’ll want to restrict. When choosing this option, you must specify the correct ports for the correct service.

It depends on what ports and services you want to restrict?

1. Method 1

This is to used to set the specific AD replication port. By default it uses dynamic port to replicate data from DC in one site to another.

This is applicable for restriction AD replication to a specific port range.

Procedure:  Modify registry to select a static port.

Restricting Active Directory replication traffic and client RPC traffic to a specific port

2. Method 2

This is for configuring the port range(s) in the Windows Firewall.

Netsh – use the following examples to set a starting port range, and number of ports after it to use

netsh int ipv4 set dynamicport tcp start=10000 num=1000
netsh int ipv4 set dynamicport udp start=10000 num=1000

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008

3. Modify the registry

This is for Windows services communications. It also affects AD communications.

How to configure RPC dynamic port allocation to work with firewalls

Here are some related links to restricting AD replication ports.

Reference thread:

RODC Firewall Port Requirements

Active Directory Replication over Firewalls


RODC – “Read only Domain Controllers” have their own port requirements

Type of Traffic
TCP Static 53248  FRsRpc

TCP and UDP Dynamic
1025 – 5000
Windows 2000, Windows 2003, Windows XP Ephemeral Ports
TCP and UDP Dynamic 49152 – 65535 Windows 2008, Windows Vista and all newer operating systems Ephemeral Ports

Designing RODCs in the Perimeter Network

Restricting Active Directory replication traffic and client RPC traffic to a specific port

Good discussion on RODC and firewall ports required:

Further info on how RODC authentication works will help understand the ports:
Understanding “Read Only Domain Controller” authentication



How to configure a firewall for domains and trusts

Active Directory and Active Directory Domain Services Port Requirements, Updated: June 18, 2009 (includes updated new ephemeral ports for Windows Vista/2008 and newer). This also discusses RODC port requirements. You must also make sure the ephemeral ports are opened. They are:
   TCP & UDP 1025-5000
   TCP & UDP 49152-65535

Windows 2008, 2008 R2, Vista and Windows 7 Ephemeral Port range has changed from the ports used by Windows 2003 Windows XP, and Windows 2000. Default ephemeral (Random service dynamic response ports) are UDP 1024 – 65535 (See KB179442 below), but for Vista and Windows 2008 it’s different. Their default start port range is UDP 49152 to UDP 65535 (see KB929851 below).

Quoted from KB929851 (link posted below): “To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections in Windows Vista and in Windows Server 2008. The new default start port is 49152, and the default end port is 65535. This is a change from the configuration of earlier versions of Microsoft Windows that used a default port range of 1025 through 5000.”

Windows Vista, Windows 7, Windows 2008 and Windows 2008 R2 Service Response Ports (ephemeral ports) have changed.

Active Directory and Firewall Ports – I found it hard to find a definitive list on the internet for what ports needed opening for Active Directory to replication between Firewalls. …

Active Directory Replication over Firewalls, Jan 31, 2006. (includes older pre-Windows Vista/2008 ephemeral ports)

How Domains and Forests Work
Also shows a list of ports needed.

Paul Bergson’s Blog on AD Replication and Firewall Ports


Exchange DS Access ports

Configuring an Intranet Firewall for Exchange 2003, April 14, 2006.
Protocol ports required for the intranet firewall and ports required for Active Directory and Kerberos communications


Additional Reading

Restricting Active Directory replication traffic and client RPC …Restricting Active Directory replication traffic and client RPC traffic to a … unique port, and you restart the Netlogon service on the domain controller. …

How to restrict FRS replication traffic to a specific static port – How to restrict FRS replication traffic to a specific static port … Windows 2000-based domain controllers and servers use FRS to replicate system policy …

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based or Windows Vista-based computers
This KB indicates Checkpoint firewalls having an issue with AD communications.



Checkpoint Firewall and AD, DNS and RPC Communications and Replication traffic

Checkpoint firewalls have a known issue if you are running version R55 or older. You will need to make a registry entry to allows traffic to flow between the 2 sites via the vpn. The preferred solution is to upgrade the Checkpoint firewall.

More info:

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based or Windows Vista-based computers
(This link relates to and helps resolve the Checkpoint issue)

Note from one poster on the internet with a Checkpoint firewall:
For Windows 2003 R2 and non-R2 remote domain controller we added the Server2003NegotiateDisable entry in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc



I know you’ve enjoyed reading this.

Well, whether you did or not, at least you now know what to do to make it work.

Comments, suggestions and corrections are welcomed!



I hope this helps!

Original Publication Date: 11/1/2011
Updated 11/4/2014

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image00262 clip_image00462 clip_image00662 clip_image00862 clip_image01062 clip_image01262 clip_image01462

Complete List of Technical Blogs:

This posting is provided AS-IS with no warranties or guarantees and confers no rights.