Forum Discussion
josoko
Nimbostratus
NimbostratusMultiple Connectivity Profiles for just one Virtual Server Edge Client
Hello,
Use case:
We have 1 Virtual Server, with just one available Public IP address behind.
We want to create multiple landing pages (e.g <URL>/landing1, /landgin2, /landing3). The Landing Pages are used to provide different Portal and Access Realms for the useres.
The challenge is the Connectivity Profile for the Edge Client, which requiires for e.g. /landing1 an alway on connection and for the remaing landing pages (e.g. /landing2, /landing3) the alwayson feature must be disabled. I pressume that any Edge Client will toggel on the always on feature, if the corresponding "connectivity profile" has been assigned to the affected Virtual Server.
We could waste a new public IP to connect a new Virtual Server, but we don't want do that.
As I can see, it's possible to select one Connectivity Profile per Virtual Server.
Thanks in advanced for any hint.
Based on the Always On changes that are stored on the work station and within the registry, along with how settings such as Component Update take place early on in the connection process, I would guess that by the time the access policy could check for the landing uri that it might be too late. You could perhaps do a sessiondump on a connection to see if there is a variable associated with the Always On configuration and if so try to change it.
That being said, even if you could do this I would proceed with caution because you would really be coming up with a one-off solution that could very likely be difficult to support or understand if you are not around. I know it is not always easy for some environments to obtain addional public IPs but I would really weigh that against a simple and supportable configuration. Maybe that IP is an investment instead of a waste? 🤔
David_GillCirrus
Based on the Always On changes that are stored on the work station and within the registry, along with how settings such as Component Update take place early on in the connection process, I would guess that by the time the access policy could check for the landing uri that it might be too late. You could perhaps do a sessiondump on a connection to see if there is a variable associated with the Always On configuration and if so try to change it.
That being said, even if you could do this I would proceed with caution because you would really be coming up with a one-off solution that could very likely be difficult to support or understand if you are not around. I know it is not always easy for some environments to obtain addional public IPs but I would really weigh that against a simple and supportable configuration. Maybe that IP is an investment instead of a waste? 🤔