Forum Discussion
AltostratusIs network access bypassing APM logon pages?
If APM is being the gatekeeper then if you have a VPN session then you are authenticated. If you then want to access the app then you are already authenticated with APM.
EmployeeUsers coming in from a VPN that is terminated on a BIG-IP are already APM-scoped into their existing Access session on that BIG-IP. They may not create another separate user session through that connection.
On the one hand, it allows BIG-IP to apply any user data to a network flow, such as inserting SSO information gathered during authentication or authorization inside of the VPN connection so that users can have completely transparent L4 SSO. Other interesting things are also possible with iRules.
On the other hand, it means that a user cannot connect to the VPN and then login to a webtop where both belong to the same BIG-IP.
AltostratusHi Lucas_Thompson, Thanks for the clarification! I've found that if the second access policy is in an other route domain than the VPN it can maintain a separate APM session so it could be one way to work around this.
- Lucas_Thompson
These results are interesting! Thanks for the info.
When you configure APM services on a BIG-IP, APMD compiles the access policies and stores this information inside of TMM's sessiondb, which is indeed scoped so that the data are separated. However, APMD ordinarily will only operate on policies that belong to a single route domain and ignore other policies.
Can you share how you're setting up the administrative partitions, route domain, and VLANs in your environment, and what version you're using? Additionally if you're declaring route domains explicitly on your APM-profile vips, or inferring them from an admin partition. I'd like to try to reproduce this in a lab to examine what's happening more closely.
- Bazsi
The customer has three separate partitions: VPN, EXT, and INT. VPN and EXT share the same route domain, while INT uses a different one. We rely on the partition's default route domain setting, so we do not explicitly use the %[RD] style postfix for the VIPs.
The VPN partition—as the name suggests—is only used for the RA VPN access policy and its related configurations, such as the VS and iRules.
In the EXT, the F5 usually acts as a reverse proxy and WAF. This is where we planned to place the second access policy with the web authentication.
In the INT partition, there are mostly just Performance L4-type VSs for load balancing in the internal DC. This is where I've moved the second access policy, and with that change, it has also moved to INT's default route domain.
The traffic always goes through a EXT VS, regardless of its source, which has an INT VS as its node. Strict isolation is in place, so this traffic goes through the network between EXT and INT. The flow looks something like this: Client - ExtFW -> EXT F5 VS - IntFW -> INT F5 VS -> Servers.
The conclusion is that network access-type resources do not respect the profile scope setting. The partition as a logical separation is also not enough, but route domains solve the issue.
The software version at the moment is still 14.1, but we will upgrade to 17.1 by the end of this year, so it will be interesting to see if this behavior changes.
