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 a firewall appliance like pfSense in both sites and of course a 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 use 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.
By using a dynamic route-based tunnel, you only need to configure one phase 2 tunnel on each sites which will be the transit network over all other subnets will be routed.
One pitfall I had by using a route-based S2S IPSec VPN tunnel with pfSense, the wireless clients couldn’t connect to the access points by using a WPA2/3-Enterprise WLAN which authenticates the user’s by using the RADIUS server in the headquarters network.
More about that pitfall you will find in my following post.
More about how to set up a RADIUS server on Windows for 802.1X wireless connections you will find here.
In contrast, for the policy-based tunnel, I need to configure for each subnet in the headquarters network a 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.
Normally you would deploy DHCP Relay Agents in your subnets, which will receive and forward the DHCP broadcasts from your clients and transmits it to one or more DHCP servers by using unicast.
As we do not want to deploy any servers in the subnet from our branch office, we need to configure either the DHCP server daemon or if available the DHCP Relay daemon on the router appliance in the branch office, pfSense btw. supports both of them, to be sure that the clients get a valid IP for the subnet we route to our headquarters network.
The main point here is, to set for the DHCP pool the DNS servers from our headquarters network.
In that case the clients in the branch office can request and determine the domain controllers for 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 to the clients.
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:
_LDAP._TCP.dc._msdcs.domainnameAfter 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:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/how-domain-controllers-are-located
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 on the servers and routers in the headquarters network, the network route to our new branch office subnet.
Links
How domain controllers are located in Windows
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/how-domain-controllers-are-located
pfSense
https://www.pfsense.org/
IPSec dynamic route-based S2S VPN Tunnel between two pfSense Appliances
https://blog.matrixpost.net/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
https://blog.matrixpost.net/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
https://blog.matrixpost.net/ipsec-policy-based-s2s-vpn-tunnel-between-pfsense-and-an-azure-vnet/
