• Reset a computer account
•  

12.3. Connection status "Unreachable" on your VPN servers

Only once the computer accounts of your VPN servers created in Active Directory have been replicated to all your Active Directory domain controllers, restart your 2 VPN servers (in our case: brux-vpn and paris-vpn).

Upon logging in, you'll see that these are indeed joined to your Active Directory domain.
Log in as an administrator to access the Routing and Remote Access console.

Note: if you receive an error when trying to log in here (on Windows Server) with an Active Directory account, it's likely because the computer account corresponding to this VPN server isn't located on the AD domain controller through which authentication was attempted.

Open the "Routing and Remote Access" console and go to the "Network Interfaces" section.
As you can see, the connection status on your first VPN server (the "BRUX-VPN" VPN server in this case at Site 1 (Brussels)) is "Unreachable".

To find out the reason, right-click "Reason for unreachability" on this on-demand connection.

As you can see, Windows Server is informing you that the credentials used are incorrect or that the authentication protocol used is not authorized on the remote server.

In this case, this is simply because the "paris" on-demand connection from your "BRUX-VPN" server is using a local connection (with a local user on the remote VPN server), even though the remote VPN server is now linked to an Active Directory domain.
This results in the creation of new user accounts in your Active Directory infrastructure instead of the local accounts previously used.

On the remote VPN server (in our case, PARIS-VPN), you'll see the same problem.
The connection status for the "brux" request has changed to "Unreachable".

If you right click "Reason for inaccessibility" on it, you will see the same warning.

12.4. Reconfigure login credentials on demand (from AD join)

12.4.1. Reconfigure the login credentials on demand on site 1 (Brussels)

On the VPN server "BRUX-VPN" of site 1 (Brussels), go to the "Network interfaces" section and right-click "Define credentials" on your "paris" on-demand connection.

In the small "Interface Credentials" window that appears, enter the credentials of the VPN server attempting to connect.
In our case, this is the user "VpnUserBrux" that allows the "BRUX-VPN" server to authenticate to the Paris VPN server.

Warning : in the "Domain" box, you must enter the NETBIOS domain name of your Active Directory domain (in our case, "INFORMATIWEB").
This is the NETBIOS domain name defined when your Active Directory forest was created.
Note that it is recommended to enter the NETBIOS domain name (e.g., INFORMATIWEB) and not the DNS domain name (e.g., informatiweb.lan).

Next, right-click "Connect" on the on-demand connection whose credentials you changed.

Wait a few seconds while trying to connect to the remote VPN server (in our case: PARIS-VPN).

Normally, the connection status will change to "Connected."

Note: if this isn't the case, right-click on "Reason for inaccessibility".
If you see an error message regarding incorrect credentials, make sure you've typed the username, password, and NETBIOS domain name correctly.
Then, make sure the Active Directory user account you're using has been replicated to all your AD domain controllers (to avoid this kind of random error).

12.4.2. Reconfigure the login credentials on demand on site 2 (Paris)

Similarly, now go to the "Network Interfaces" section of the "PARIS-VPN" VPN server at Site 2 (Paris).
Then, right-click "Set Credentials" on your "brux" on-demand connection.

This time, enter the credentials for the Active Directory user account "VpnUserParis," since the Paris VPN server will attempt to connect to the Brussels VPN server (BRUX-VPN).
Again, don't forget to enter the NETBIOS domain name of your Active Directory infrastructure.

Then, right click "Connect" on this "brux" on-demand connection.

Please wait while connecting to the remote VPN server.

As expected, the connection status also becomes "Connected" on your VPN server "PARIS-VPN" at site 2 (Paris).

12.4.3. Allow ping (ICMP) on your Active Directory domain controllers

To test if your VPN tunnels are still working, you can use the Windows "ping" command.
However, by default, ping is blocked on Windows Server.

To allow ping on Windows Server, enable these two firewall rules:

• File and printer sharing (Echo Request - Inbound ICMPv6).
• File and printer sharing (Echo Request - Inbound ICMPv4 traffic).

12.4.4. Connected site-to-site VPN tunnels

12.4.4.1. Site-to-site VPN tunnel connected between site 1 (Brussels) and site 2 (Paris)

On the VPN server "BRUX-VPN", you can see that the connection status on demand "paris" is connected.

You can see that the Paris site connected to the VPN server "BRUX-VPN" (from Brussels) with the Active Directory user account "VpnUserParis".

In the "Ports" section of the "BRUX-VPN" VPN server, you can see that the "L2TP" VPN protocol is used.

As you can see below, our AD domain controller "brux-dc1" is able to communicate with itself (10.0.1.11) and the remote AD domain controller "paris-dc1" (10.0.2.11).

12.4.4.2. Site-to-site VPN tunnel connected between site 2 (Paris) and site 1 (Brussels)

Similarly, go to the "Network Interfaces" section of your remote VPN server "PARIS-VPN" and check that the status of the "brux" on-demand connection is "Connected".

On this remote VPN server "PARIS-VPN", you can see that it is the Brussels site that connected to it with the AD user account "VpnUserBrux".

In the "Ports" section, check that the active VPN ports are those for "L2TP" (because it is more secure and stable under Windows Server than PPTP).

Below, you can see that our AD domain controller "paris-dc1" is able to communicate with the remote AD domain controller "brux-dc1" (10.0.1.11) and with itself (10.0.2.11).