Set up a lean Branch Office Network without any Servers and DCs inside by using an IPSec S2S VPN Tunnel connected with the Headquarters Network
If you want to set up a network in a branch office and don’t want to deploy any servers inside this network, even no domain controller, for several reasons like:
- minimize hardware costs
- no maintenance
- enhance security -> no risk regarding access to the physical servers, especially writeable domain controllers
- no place to install the servers and rack
the only two things you need to implement this, is an firewall appliance like pfSense in both sites and of course an proper company internet access. Regarding the internet access, you should prefer a full duplex synchronous connection, so that users can download and upload data in a fast manner at once.
Nowadays many smaller businesses even had no on-premises network and will using a Cloud only solution like Microsoft 365 with Azure Active Directory, but this is not the topic of this post.
To connect the branch office to our main headquarters network, we first need to configure the IPSec S2S VPN tunnel between both sites, in my case I will using an IPSec dynamic route-based S2S VPN tunnel with pfSense.
Because the headquarters network consists of multiple subnets, which I need to connect with the subnet(s) from the branch office, I prefer a dynamic route-based S2S tunnel over a policy-based.
With a dynamic route-based tunnel, I only need to configure one phase 2 tunnel on each sites which will be the transit network over all other subnets will be routed.
In contrast for the policy-based tunnel, I need to configure for each subnet in the headquarters network an phase 2 tunnel on both sites.
Below you will find for both types a post how to configure the IPSec S2S VPN tunnel by using pfSense.
We further need to configure the DHCP server on the router appliance in the branch office, to be sure that the clients get an IP for the subnet we route to our headquarters network.
The main point here is, to set for the DHCP pool DNS servers from our headquarters network.
In this case the clients in the branch office can request the domain controllers from your network and will get logged on directly against one of the domain controllers into your headquarters network and group policies and network scripts will be applied.
How Clients locate a domain controller
On the client (the computer that’s locating the domain controller), the Locator is started as a remote procedure call (RPC) to the local Netlogon service.
When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. So clients find a domain controller by querying DNS for a record of the form:
After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client.
More about this process you will find in the following Microsoft article:
Therefore as domain controller identifies in which site a client is, based on the IP subnet of that client, we also need to configure the subnet from the branch office under Active Directory Sites and Services on one of our domain controller in the headquarters network.
Therefore the clients in the branch office will get in response to their DNS query a domain controller from the headquarters network resp. from the site you assigned the subnet to.
Below you will see the Active Directory Sites and Services console from my lab environment braintesting.de. Here I only had one site with Frankfurt and therefore the clients anyway will get a domain controller from that site.
But if you had multiple sites, you should assign the branch office subnet, to a site it is connected through the IPSec VPN tunnel in order to avoid latency by using a domain controller from a site it is not directly connected to.
For each subnet you create here, you need to assign a site.
Finally we also need to configure for servers and routers in the headquarters network, the route to our new branch office subnet.
How domain controllers are located in Windows
IPSec dynamic route-based S2S VPN Tunnel between two pfSense Appliances
Set up Dynamic Routing with FRR (Free Range Routing) in pfSense – OpenBGPD now Depricated
IPSec policy-based S2S VPN Tunnel between pfSense and an Azure VNet