Maybe it’s a stupid question but I’ve been wondering about it for a while without finding a proper answer.
Usually, you can either access your web apps remotely through APM or you can use a SSL VPN connection to have a full network access.
Recently when I was connected to the VPN (BigIP Edge Client), I tried to access different web apps through APM in order to test some APM workflows (vpe config) and I noticed I was somehow bypassing the APM logon pages : actually I was able to access the web apps without having the APM logon pages.
Maybe these were silly tests but still i’m wondering : what happened ?
I used an irule to have verbose logs, I saw that my vpn session ID were being used when accessing these web apps.
Is there any credential forwarding ? How does it work ?
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.
Hello PeteWhite, If I understand there is no way to change this behaviour, the Edge Client has no respect to the profile scope setting?
My usecase is that the new service I’m working on should be fully independent. Testers should be able to use the service the same way regardless where they are coming from, internal networks, VPN or the internet (in the future). Futhurermore the new service uses completely different preprod AAA thant the production VPN and the testers usually impersonate test users.
Users 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.
Hi 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.
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.
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.