Securing Remote Access Users and Devices

The Genian NAC Built-In RADIUS Server is capable of performing Authentication, Authorization and Accounting functions for Enterprise and SMB/SME networks. This capability not only applies to On-Perm users and devices, but can be extended to remote VPN connections as well by integrating with Firewalls and VPN Concentrators/Servers.

In this configuration example, RADIUS AAA integration with VPN is leveraged to authenticate users, deny access to users with valid credentials but not authorized to use the VPN and assign privileges on the internal network to authorized VPN users. Unauthorized devices will also be blocked using the Global Mirror option. This ensures that no person or device without expressed permission to utilize the VPN can connect and also ensures lease privileged access when connected. Authorized Devices will also be forced to comply with Endpoint Security Policies.

Global Config (Genian NAC, Cisco ASA)

RADIUS Server Configuration Example

The example below shows the the Genian NAC RADIUS Server configured with several key settings. First, the VPN Network Device to be integrated with (in this case a Cisco ASA) must be added as a RADIUS client. In this example, the ASA has an internal IP address of 192.168.50.3 so falls under the second Client entry. Additionally, other enabled configurations include the authentication port, EAP Authentication, and both Local and AD User Authentication enabled.

Cisco ASA RADIUS Configuration Example

In this example, a Cisco ASA 5520 is configured to use the Genian NAC RADIUS Server at IP 192.168.50.200 as the RADIUS Authentication Server. Note – the Secret configured here must match the Secret configured in the RADIUS server.

Cisco ASA Client VPN Configuration Example

Using the standard Wizard, an AnyConnect Connection Profile was created and then pointed to the Genian NAC RADIUS Server Group.

Use Case 1: Controlling Remote VPN Users

User Group Configuration Example

Defining User Groups that will include users authorized to connect via VPN is the first step. In this example, we have created both a Local User Group and an Active Directory User Group to demonstrate how VPN can be permitted or denied by User Group regardless of whether it is a locally defined user in the Genian NAC database or a user defined in Active Directory. Once tied to the correct policy, the group criteria can be matched on, ensuring only VPN authorized users will be able to successfully authenticate.

Unauthorized accounts that will also be tested or referenced during validation and testing.

802.1X Policy Configuration Example

In the 802.1X policy example below, we have leveraged the two User Groups referenced earlier and have configured a REJECT Access Policy if the user attempting to authenticate is not in either of those groups. Note that prior to this condition, we are also matching on the NAS-Port-Type of “Virtual”. This will ensure this policy only applies to users attempting RADIUS authentication via VPN and will not apply to users attempting RADIUS authentication locally (on-prem).

Authorized User Test

To validate the configuration, we will connect with with an authorized Active Directory user account “techeng1”. The AnyConnect client should respond with “Connected”. Note the authorized Local user account “vpnuserlocal” would also be permitted to connect.
In the screenshot below, the Genian NAC Policy and RADIUS Server shows a RADIUS Start packet indicating a successful authentication as well as a RADIUS Interim-Update packet which shows the VPN IP assigned to the remote user’s device.

Unauthorized User Test

To confirm that unauthorized users are not able to connect, we will attempt to connect with with an unauthorized Active Directory user account “sales1”. The AnyConnect client should respond with “Login failed”. The same results should be observed if testing with an unauthorized Local account such as “nonvpnuserlocal”.

In this scenario (failed authentication), the Genian NAC Policy and RADIUS Server will not log a RADIUS Start packet as Start packets are only received upon a successful authentication. To see the unauthorized login attempt, we need to review the RADIUS debug log. Below we will see the login failure and reason.

Use Case 2: Authorization (Privilege/Access Assignment)

Users that are authorized to connect via VPN should be assigned the least amount of privileges or access required. This can be accomplished through RADIUS Authorization. RADIUS attributes such as Downloadable ACLs (dACLs) can be applied based on various conditions such as Identity or Group. In the example below, any user account that is a member of this particular “Engineer” Group will only be allowed access so a single IP on the network (perhaps a server or network device for example). After successful Authentication, Authorization takes place and the dACL is applied to the user’s VPN session, restricting access based on the rule.

802.1X Policy Configuration Example

Authorization Test

To validate the configuration, we will connect with the “techeng1” user account which is a member of the “Engineer” group. Before performing the test, here is the access that the “techeng1” has without the Assing VPN Privileges 802.1X Policy enabled. Note that multiple internal hosts can be reached while connected.
Next, we will connect using the “techeng1” with the Assign VPN Privileges 802.1X Policy enabled and perform the same ping test. Note that this time only the internal host authorized by the dACL is reachable.
Reviewing the RADIUS Server debug log, we can see the Access-Accept message that was sent to the ASA after Authentication had successfully completed included the Authorization dACL attributes configured in the 802.1X Policy.
By issuing a “show access-list” command on the ASA, we see that a dynamic ACL has been created matching attributes sent back in the Access-Accept message above. This ACL is applied to the VPN client’s session as noted by the hit count numbers incrementing.

Use Case 3: Controlling Remote VPN Devices

With only authorized users allowed to connect and with the appropriate privileges assigned to those users, the final use case example is how to block unauthorized devices from accessing internal network resources. This is accomplished by utilizing the Genian NAC Global Mirror option.

Since MAC address information is not included with VPN RADIUS Accounting, the Global Mirror option is utilized for Enforcement instead of RADIUS. Corporate/Organization issued devices will be deployed with the Genian NAC Agent. Any device that does not have an Agent installed will be denied access to internal network resources.

Enforcement Policy Configuration Example

In the example below, the VPN IP Pool subnet is listed as a condition for the policy. When operating in Global Mirror mode, any node generating traffic from this subnet that does not have an Agent installed will be denied access. An optional Captive Web Portal message may also be displayed.

Unauthorized Device Test

The example below will show a user connecting with valid credentials, but the connection is being initiated from a device with no Agent installed.

Here we see a successful RADIUS authentication for the user account in the RADIUS logs:

However, if the user attempts to navigate to an internal resource on the network, the session will be redirected and a Captive Web Portal message will be displayed.

The message above can be customized including removing the Install Agent option if the desire is just to display a message that advises non-Corporate devices are not permitted to connect through VPN. Their key is to customize the message as much as possible to either allow the user to connect if personal devices with Agents are permitted, or to ensure the appropriate security policy is displayed as well as Help Desk contact information if needed.

Use Case 4: Endpoint Security for VPN Devices

With only authorized users and devices being permitted and only the proper privileges and access permitted, Endpoint Security must also be validated and enforced. With the Genian NAC Agent deployed, administrators can ensure that not only basic requirements are met (Windows Updates, OS Patches, etc) but can also mandate or prohibit specific applications or even implement hardware policies such as prohibiting USB devices. When users are connected to the network remotely, the same security policies that are in place on the corporate or organization’s network should still be adhered to.

Policy Configuration Example

In the example below, the VPN IP Pool subnet is listed as a condition for the policy. When operating in Global Mirror mode, any Windows VPN connected node that does not have updated definitions for Windows Defender will be denied access. An optional Captive Web Portal message may also be displayed.

Policy Test:

If the user attempts to navigate to to an internal resource on the network, the session will be redirected and a Captive Web Portal message will be displayed.

This is only one example of an Endpoint Security policy available. For the complete list of Agent plug-ins and detailed explanations of each, see the Agent documentation page.

Scroll to Top

We use cookies to help improve this website and enhance your browsing experience You can change your cookie settings at any time. • Privacy • Terms