VPN tunnel are a key-factor when setting up networks which are expansive by nature, e.g. global corporate networks, main sites interconnected with subsidiaries etc.
Another major attribute of corporate networks is the nature of authenticating yourself toward a server, showing your trustworthiness and therefore being granted permission to internal resources.
In the wake of the coronavirus pandemic, which started 2019, the demand for networks combining both of these attributes have risen in demand drastically, whether it being rooted through more home-office jobs, or by closely interconnecting remote sites to each other to lower personal contact between people. In this tutorial, we want to give you the tools at hand to set up an authentication toward an authentication server through a VPN Tunnel.
The topology could look something like this:
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. For this, we first have to define that authentications on Site B go toward Site A's RADIUS. For this, we navigate to
Configuration > Object > AAA Server
and set up an authentication object toward the IP 192.168.10.100:
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:
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.