In this lab, you will start by learning how to create and apply a basic Access Policy on F5 BIG-IP APM.
From there, the focus will shift to how session management is handled through cookies, and why these cookies are mandatory for consistent policy enforcement.
Finally, you’ll explore the impact of modifying an existing policy and learn best practices for applying changes with minimal disruption to active users.
Objectives
Pre-requisites
Task 1 : Create a simple APM Policy
The IT Director has recently learned about F5 APM policies and wants to enhance access to the company’s website. Before users can proceed, he wants to display a message stating that the website is for authorized personnel only. This will serve as an initial notice to inform visitors about access restrictions before they enter the website.
To achieve this, we will configure an APM policy that presents a simple message box before granting access to the application. This will ensure that all users acknowledge the restriction before proceeding.
Create the policy
Navigate to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies).
Click Create to start a new profile.
Set the Profile Type to LTM-APM.
Make sure to select an appropriate language for the policy (e.g., English), as it’s required for proper rendering of messages and prompts.
The APM Policy is created but not attached to any virtual server.
Attach the APM policy to the HTTPS_vs virtual server. What is missing on the Virtual Server ?
To begin applying your APM policy, navigate to the configuration of the virtual server handling HTTPS traffic:
-
Go to Local Traffic ›› Virtual Servers : Virtual Server List.
-
Locate and select the virtual server named
HTTPS_vsfrom the list.
In the virtual server screen, select the APM_Policy in the field Access Profile.
When attempting to update the virtual server, you encounter an error. Since the APM policy operates at the HTTP layer, the virtual server must be configured to handle HTTP traffic. To resolve this, you need to enable HTTP on the virtual server by adding an HTTP profile. Simply attach the default HTTP profile to the virtual server and proceed with the update.
Try to access the virtual server at https://192.168.110.105/ using the webviewer VM. Are you able to view the website ? Why ?
Accessing the HTTPS_vs using the webviewer, the user gets an error indicating that the access is denied.
By default, an APM policy is empty and only direct to a deny ending.
Task 2 : Modify the APM Policy to Display an Access Notice
We begin with a new and empty APM policy that currently leads directly to a deny statement. To align with the IT Director’s requirements, we will modify the policy to display a decision box informing users that the website is restricted to authorized personnel only before they proceed.
Steps to Update the APM Policy:
-
Open the Visual Policy Editor (VPE)
- Navigate to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies)
- Locate APM_Policy and select Edit under the Per-Session Policy column
-
Modify the Policy to Include a Decision Box
- Inside the VPE, insert a decision box before the default deny statement
- Click the “+” and select the general tab. The decision box is the first element.
- Configure the message to display:
“Access to this website is restricted to authorized personnel only.”
- Inside the VPE, insert a decision box before the default deny statement
- Change the first ending to “allow”
Without applying the Access Policy, try to access the HTTPS_vs on the webviewer ( https://192.168.110.105/ ).
Access the virtual server at https://192.168.110.105/ using the webviewer VM. Are you prompted with the message ? Are you able to access the website ?
No, without applying the policy the user is not prompted with the message and is denied the access as before.
Modification made inside a policy are only taken in account once the policy is applied.
Apply the policy be clicking on the yellow link on the visual policy editor, or on the main Web UI on the top left corner.
On the new screen, select the policy and click on apply to deploy the changes made on the policy.
Access the virtual server at https://192.168.110.105/ using the webviewer VM. Are you prompted with the message ? Are you able to access the website ?
Once the policy is correctly applied, the user is prompted with the notice message and is able to access the website.
Perform multiple hard-refresh of the page (CTRL-R).
Is the notice displayed on each access of the website ? Why ?
Doing hard refresh do not display the notice message. An Access Policy is executed once and each subsequent access are allowed.
Task 3: The Never-Ending Story of Cookies
Your colleague is puzzled about why the notice doesn’t appear on every page refresh. He wonders why the policy is not evaluated at each request made to the virtual server.
What mechanism is responsible for keeping track of whether the policy has been completed or not?
What tracks your progress within the Access Policy is the session cookie, which is issued at the beginning of the policy evaluation. When the policy is successfully evaluated and ends with an “Allow” action, the session ID in the cookie is marked on the F5 as a session that has completed the policy. On subsequent requests, F5 BIG-IP APM checks this session ID to recognize that the user has already completed the policy, and thus, doesn’t need to re-evaluate it. This ensures a seamless user experience, as the user won’t be prompted to go through the policy again during the session.
The SOC team detected that new cookies are used on the access of the company website. They want you to validate the necessary cookie for the functionning of the website.
What are the name of the 2 cookies used by the APM Policy to keep track of accesses ? What are their purpose ?
F5 APM uses two key cookies to manage and track user sessions: MRHSession and LastMRH_Session.
-
MRHSession:
This cookie represents the active session ID for a user. Its value is made up of digits that rotate with each step in the access policy, adding a layer of security by preventing replay or session hijacking. Once the access policy completes (typically at an Allow ending), the value ofMRHSessionstabilizes and no longer changes during the session. -
LastMRH_Session:
This cookie contains the last 8 digits of theMRHSession. These digits remain constant throughout the session and make it easier for F5 administrators to track and correlate user sessions for troubleshooting or auditing purposes.
To avoid re-evaluation of the access policy on each request, the user must consistently send these cookies with every interaction to the virtual server. If the cookies are missing or altered, the session is not recognized, and the access policy will be triggered again.
Using developper tools, display the cookies as you access the virtual server.
Using developper tools (F12) on the network tab, we can view that the F5 is setting 2 cookies at the begining of the policy evaluation :
the cookie LastMRH_Session and MRHSession are assigned.
Here the LastMRH_Session has value 8a29c5d5 while the MRHSession is b1f6e2d96dc1d6d79ebcd4ef8a29c5d5.
We can verify that the LastMRH_Session correctly correspond to the last 8 digits of the MRHSession.
Let’s verify that the MRHSession rotate during the policy. To observe this behavior, add a new text box to the policy.
Apply the policy.
Navigate to Access ›› Overview : Active Sessions and terminate any active sessions to reset the current session state.
Open developper tools and inspect the value of MRHSession and LastMRH_Session at each stage of the policy.
Verify that the LastMRH_Session doesn't change while MRHSession change at each stage of the policy
Open dev tools (F12) on the network tab.
Open the browser and get to https://192.168.110.105.
At this stage, the MRHSession and LastMRH_Session gets setted by the F5 big IP. Locate the my.policy webpage in the network log to verify the value. In my example :
The LastMRH_Session gets the value 906febc9 while MRHSession gets 6ec95bc47a72aca9291a24f5906febc9. I click continue to get to the decision box screen :
We can check that the LastMRH_Session doesn’t change and stays 906febc9, however, the MRHSession changes (except the last 8 digits).
This correctly display that a rotation of the value of the MRHSession is in place while keeping the LastMRH_Session intact to easily follow an user session.
You are warned by the supervision team that the monitoring is not working anymore. They are using a script to fetch the website.
What is the probable reason that the script is not working ? Use command line to verify
The most likely reason is that scripts or applications often do not store or resend cookies, nor do they properly follow the full APM policy flow—such as progressing through message boxes or decision points. This behavior can pose a challenge when automating access, as scripts must be able to maintain session cookies and fully complete the policy to gain access.
Task 4: Managing the APM Policy
Your manager is pleased with the improvements and the newly implemented APM policy, and already envisions extending its use to manage additional applications.
However, a question arises: How do changes to the policy affect users who are already authenticated?
Will modifying the policy impact users who have already completed it, or will they need to re-evaluate the policy from the beginning?
Complete the policy using the Web Viewer VM. Then, modify the policy (change one of the text) and apply your modifications. When refreshing the web page, are you prompted with the new policy ?
Complete the policy using the Web Viewer :
Open the Visual Policy Editor and modify a text :
Then apply the policy.
Refreshing the page on the Web Viewer still display the website without prompting the user again for the policy.
Modifying an existing policy won’t affect user that already completed the policy.
You discovered that modifying a live policy in production doesn’t disrupt active user sessions—users who already completed the policy are not immediately impacted. However, this approach carries risks: changes are permanent, and there’s no built-in rollback mechanism if something goes wrong.
As a best practice, you now create a copy of the existing policy, apply your changes to the copy, and only then assign it to the virtual server once validated.
To illustrate this process:
-
Navigate to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies).
-
Select the original policy and click Copy.
-
Open the copied policy and make a small modification (for example, change the displayed message text).
-
Save and apply the changes.
Now that you’re satisfied with the updated policy, it’s time to prepare for deployment.
Before switching the active policy:
-
Open the WebViewer VM.
-
Access the virtual server and complete the existing policy, confirming your session is active.
This sets the stage to observe the behavior when switching policies—especially how existing sessions are (or aren’t) affected by the change.
Modify the policy in place on the virtual server. Do users that already completed the policy prompted with your modification ?
Go to HTTPS_vs and update the assigned APM policy from APM_Policy to APM_Policy2 :
Then, refresh the page on the WebViewer VM.
You’ll notice that—unlike directly modifying the original policy—switching to a different policy on the virtual server forces all users to re-evaluate the policy, even if they had previously completed it. This is because the session is tied to the original policy, and changing the policy reference invalidates the session for that user.
You reported both methods of updating the APM policy to your manager.
Based on your findings, he decided to adopt a balanced approach:
-
Minor changes can be made directly to the active policy during business hours, as they don’t impact users who have already completed the policy.
-
For larger updates or structural changes, he recommends creating a copy of the current production policy, making the necessary modifications, and replacing the policy on the virtual server during off-peak hours. This minimizes disruption, as all users will be required to re-evaluate the policy when it’s swapped.
Conclusion
During this lab, you explored the fundamentals of an APM policy on F5. You began by learning how to create a policy and apply it to a virtual server.
You also discovered that an access policy is evaluated only once per session, as long as the user continues to send the associated session cookie. This highlights the importance of cookies in session tracking—scripts or CLI-based operations must handle cookies properly, which can pose a challenge in automated environments.
Finally, you practiced how to safely make changes to an access policy and understood their impact on active users. As a best practice, minor changes can be made directly within the existing policy without affecting current sessions. However, for major updates, it’s advisable to copy the existing policy, test your changes, and switch to the updated version during off-peak hours, since doing so will require users to re-authenticate.
