Technical Challenge
F5 like most large enterprises organizations require Two-Factor Authentication (TFA) for employee remote connectivity. To meet this requirement IT integrated BIG-IP Access Policy Manager with a third-party vendor that provides One-Time Passwords (OTP). After users successfully authenticate they are prompted to provide their OTP that is then verified against a Radius server. Most of the time this works great but occasionally the employees preferred Operating System or VPN Client doesn’t support multiple authentication methods.
BIG-IP Edge Client (Linux)
F5 VPN Client (Windows 10)
Inbox F5 VPN Client (Windows 8.1)
Traditionally to work around these limitations employees would be required to concatenate their Password + OTP. While BIG-IP Access Policy Manager is capable of supporting concatenated passwords there is a more graceful option, TFA through a Captive Portal
The Solution
To workaround the limitation mentioned above IT decided to configure BIG-IP Access Policy Manager to allow all clients to establish a VPN for remote connectivity regardless of the clients ability to preform TFA. An iRule is used to determine whether or not the employee successfully completed TFA.
Clients that natively support TFA are prompted to provide their username, password and OTP on initial connection. After they successfully authenticate and complete TFA they are granted access to the appropriate resources.
Clients that do not support TFA are prompted to provide a valid username and password, after the employee successfully authenticates all HTTP & HTTPS requests are intercepted and a custom login page is returned in response. This custom login page prompts the user to provide a valid OTP. Until the employee provides the correct OTP all traffic is rejected by an iRule applied. Once the employee provides the correct OTP the iRule updates an BIG-IP Access Policy Manager session variable to indicate that the employee should have the same network access as clients that natively support TFA.
Solution Caveat
This solution will leverage layered virtual servers and this could negatively impact network access tunnel layer 4 ACL
https://support.f5.com/kb/en-us/solutions/public/14000/200/sol14219.html?sr=48427459
Putting Everything Together
Step 1 – Update your “Remote Access” Access Policy
We need to differentiate the clients that either do or do not support TFA, IT did this by configuring the BIG-IP Access Policy Manager access policy to detect the Client Type or Operation System as seen below.
Step 2 – Create a Captive Portal Access Policy
Since clients that don’t support TFA will not be able to validate their OTP against the “Remote Access” policy we will need to create an alternative way to validate their tokens. To do this create a second Access Profile and configure the Access Policy to validate the OTP token using the preferred method in ITs case that was radius.
Step 3 – Upload the Captive Portal iFile
If you have questions on iFiles please see => Referencing External Files
Example Captive Portal HTML
Example Captive Portal Page
Step 3.1 – Upload your Captive Portal page as an External File that can be referenced in the iRule below
Step 3.2 – Assign your Captive Portal External File to an iFile that can be referenced in the iRule below
Step 4 – Create the Captive Portal iRule
The iRule listed below will be applied to a virtual that will be targeted with the virtual-to-virtual (V2V) function.
The iRule will disable SSL for HTTP traffic on TCP Port 80
Re-write the Captive_Portal iFile that was uploaded earlier to reference CSS and Images associated to your main login page
Checks to see if the request method is a POST or not
If it is NOT a POST then return the Captive_Portal page
If it is a POST then parse out the OTP token and validate it against the Captive_Portal access policy created earlier
If the Access Policy result is “allow” then update the last radius result value to 1 and redirect the user to the originally requested content
Step 5 – Create the Captive Portal Reject iRule
This iRule will be applied to the Layered Virtual Server that will be created later on. This iRule checks to verify that user traffic has PASSED TFA before allowing it to access network resources. It will also detect webtop traffic and allow that through.
If the employee has passed TFA or if they are requesting a proxied resource through the Portal Access
Take no action
ElseIF the employee has NOT passed TFA and they are NOT requesting a proxied resource and the request isn’t over UDP
Use the V2V function referenced earlier to direct traffic to the Captive_Portal Virtual
ElseIF the employee is requesting DNS traffic over TCP/UDP port 53
Take no action
If you are concerned with DNS tunneling we could create Layered Virtual Server listening on port 53 and apply a GTM iRule that will intercept DNS Requests
Else
Reject traffic until the employee completes TFA
Step 6 – Create the virtuals that will be used to handle traffic
Step 6.1 – Create the APM Layered Virtual
This virtual server listens on the “connectivity” vlan. The “connectivity” vlan is associated with the connectivity profile applied to the virtual server used to provide employee remote access.
It is commonly referred to as a Layered Virtual Server. For more information on Layered Virtual Servers (LVS) see => Common Deployment Examples for Single Sign-On
This LVS will match all traffic except TCP port 80, a more specific LVS (_tmm_apm_fwd_vip_http) embedded within BIG-IP Access Policy Manager is used to enforce L4 ACL. See below on steps to create a more specific LVS to capture port 80 traffic
Step 6.2 – Create the APM Layered Virtual that will match on TCP port 80 traffic
The virtual created above will match on all traffic except TCP port 80, to capture that traffic we need to create a more specific virtual.
Step 6.3 – Create the V2V Captive Portal Virtual
This virtual is used to display the Captive Portal created earlier and should NOT be assigned to any vlan.
Optional - SSL Forward Proxy
This example utilizes the SSL Forward Proxy functionality to display the prevent a certificate error from being displayed but is not required. For more information on SSL Forward Proxy see => Implmenting SSL Forward Proxy