VPN - Configure an Active Directory [AD] Server through a VPN tunnel

This article provides a detailed overview of how to configure an Active Directory (AD) server through an L2TP VPN tunnel using the USG FLEX/ATP VPN authentication method. Additionally, the guidance presented herein is applicable to IPsec IKEv2 and IKEv1 VPN configurations.

VPN tunnels are a critical component when establishing networks that are inherently expansive, such as global corporate networks or main sites interconnected with subsidiary locations.

A fundamental characteristic of corporate networks is the process of authenticating users to a server, thereby demonstrating trustworthiness and obtaining access to internal resources. This tutorial aims to equip you with the necessary tools to configure authentication to an authentication server via a VPN tunnel.

Two firewalls are connected via Site-to-Site VPN, and on the Main Site A, there is a RADIUS-Server within the LAN. On Site B, there might be several clients which want to authenticate toward the RADIUS server on Site A. On Site B, we either find local clients which need connection toward the RADIUS Server on Site A, or L2TP VPN Clients which require authentication toward Site A's RADIUS.

 

Here, we have to make an important differentiation between the VPN Client and the LAN Client on Site B - while it is very likely, that the Client from Site B can authenticate with no issue whatsoever toward RADIUS of Site A, the L2TP VPN clients most likely will not be able to do that. Why is that?

Site-to-Site VPNs are set up with a Local Policy  and a Remote Policy. These policies determine, which networking routes are created upon tunnel creating, meaning which networks are allowed to "talk to each other". In this case, we are assuming that routing between 192.168.10.0/24 and 192.168.20.0/24 is fine. The L2TP VPN, which inherently has to be a different subnet than the local subnets on Site B, are not allowed to communicate toward Site A because it's not included within the Local or Remote Policy.

That is, if we do not add additional policy routes. With the help of these kind of routes, we can force any authentication attempt coming from the L2TP VPN toward a destination on Site A. First, we need to define that authentications on Site B are directed to Site A's RADIUS.

Configure the AAA Server

Configuration > Object > AAA Server

and set up an authentication object toward the IP 192.168.10.100:

Test your AD authentication

Configuration -> Object -> AAA Server

Make sure to save your configuration before testing the configuration validation.

Good result	Bad result

Configure the Auth. Method

This AAA Server-Object now has to be combined to an authentication method, which in turn is set as the main authentication for our VPN. First, navigate to the menu

Configuration > Object > Auth. Method

and add the newly created AAA Server into the default Auth. Method:

Make the Firewall Join the AD Server

Then the USG needs to join the AD domain with the domain name of the AD server

Navigate to Configuration -> System -> Hostname

The Realm is the Domain name of the ad server and NetBIOS name is the domain.

To point the firewall to the AD server, we need to create a DNS record to successfully find the AD server via the AD server's IP address:

Configure the VPN 

Via IKEv2

Configuration -> VPN -> IPSec VPN -> VPN Gateway - Add/Edit

Click "Show Advanced Settings" and enable "Extended Authentication Protocol" and select Server mode. 

Then select the AAA Method (Auth. Method) and Allowed user

Via L2TP

After that, we select this Auth. Method to be used via the L2TP VPN via

Configuration > VPN > L2TP over IPSec VPN

(Please note, that the IP Address Pool does not correspond with the topology drawn above, since this is just an example on how to set up the L2TP-Tunnel)

Now that the L2TP VPN is set up with an authentication which should forward toward the RADIUS on Site A, we have to create policy routes:

The first policy route will push anything coming from any source, which wants to move toward the 192.168.10.100 IP, into the tunnel to Site A - meaning also the authentication attempt from our L2TP VPN. The second policy route will push anything meant for the L2TP VPN subnet back into the L2TP VPN.

On the other site, we now simply have to complement this through a corresponding rule, which will push anything from subnets differing from Site B LAN (like our L2TP VPN Subnet's attempt) back into the tunnel toward Site B, triggering our policy route which we have set on that site. 

Following this simple guide, you should now be able to authenticate your clients toward a RADIUS on another remote VPN location.

Configure DNS Forwarding for AD Domain (Recommended)

To ensure proper AD name resolution, configure DNS forwarding in addition to the local DNS entry:

• Go to Configuration → System → DNS → Domain Zone Forwarder, add your AD domain (e.g., company.local) and set the AD DNS server as forwarder.

• In VPN Connection → Client Settings, assign the AD DNS server (or the firewall’s LAN IP if forwarding is enabled) as First DNS Server.

• (Optional) Add a policy route if DNS queries must be forced through the VPN.

Verify with: nslookup dc1.company.local.

Troubleshooting & Test your result

Navigate to

Monitor -> Network Status -> Login Users

Navigate to

Monitor -> VPN Monitor -> IPSec

Troubleshooting

Navigate to the Web Console of the firewall or connect to the firewall via SSH and run this command

debug domain-auth test profile-name [ad profile name] username [username] password [password]

Replace ad profile name with the Active Directory "AD Server Summary" Name and use the username and password of the Domain Authentication via MSCHAP.

More articles found here: 

AD (active directory) user authenticate check

How to join an Active Directory Domain with USG/ATP/VPN

How to do Two-Factor Authentication with Active Directory Users