VMware Workspace ONE Community
ALEXANDERPACIER
Contributor
Contributor
Jump to solution

Transition from Proxy to Per-App VPN

Our current environment uses two load balanced relays and two load balanced end points running Windows to facilitate our VMWare Tunnel proxy. I have approval to explore per-app VPN but my understanding is only Linux-based servers can handle the per-app VPN setup. Is there a way to kick the tires on this without having to remove our current proxy setup?

Am I mistaken that only Linux servers can do the per-app VPN?
Labels (1)
0 Kudos
1 Solution

Accepted Solutions
BethC
Hot Shot
Hot Shot
Jump to solution

I am in the process of transitioning from MAG to UAG myself. I am setting it up in my UAT first, which I built from scratch this year and is a mirror of my Prod so it's essentially a ' prod-test'  environment for expressly this reason. I have an SOW with VMware to assist me with this process so I have help & recommend the same for you. My understanding it that there is up to a 4 hour period of time that the users will not have access to Tunnel and Content. To setup the UAG, you have to change the configuration in the console first and that's one of the reason why there is an expected 4 hour downtime during the transition. You are correct, it is Linux based for the per-app vpn, which is the only reason I am transitioning to it.




If you do not have a UAT, I highly recommend that you build one... lifesaver!


View solution in original post

0 Kudos
6 Replies
BethC
Hot Shot
Hot Shot
Jump to solution

I am in the process of transitioning from MAG to UAG myself. I am setting it up in my UAT first, which I built from scratch this year and is a mirror of my Prod so it's essentially a ' prod-test'  environment for expressly this reason. I have an SOW with VMware to assist me with this process so I have help & recommend the same for you. My understanding it that there is up to a 4 hour period of time that the users will not have access to Tunnel and Content. To setup the UAG, you have to change the configuration in the console first and that's one of the reason why there is an expected 4 hour downtime during the transition. You are correct, it is Linux based for the per-app vpn, which is the only reason I am transitioning to it.




If you do not have a UAT, I highly recommend that you build one... lifesaver!


0 Kudos
ALEXANDERPACIER
Contributor
Contributor
Jump to solution

Oh geez, four hour down time to transition?

I'm a little murky on the UAT acronym. Is this a test console separate from your production environment?
0 Kudos
TJMEDLYN
Contributor
Contributor
Jump to solution

I run the tunnel proxy as well as UAG for per app VPN.  Don't have any issues running both. 
0 Kudos
RayReno
Contributor
Contributor
Jump to solution

I am in the process of deploying the United Access Gateway to replace our current F5 implementation of Per App VPN.  I have configured my DEV environment and am running content and browser to the old windows based setup and have the UAG running on OVA on Linux platforms and have not yet seen any problems.  This is actually very nice because it lets me run my existing F5 based Per App VPN configuration at the same time.
But the simple answer you are looking for right now is that the Per App VPN only runs on Linux systems.
UAT is an acronym for User Acceptance Testing and for me is used to define my QA system which is a setup exactly the same as my Production.  Before we do anything in Production it has run through the DEV and QA/UAT systems.
0 Kudos
KonstantinosLei
Contributor
Contributor
Jump to solution

Hey all. We are about to implement per-app VPN ourselves and was wondering what is the benefit of using the UAG vs. Cisco ASA or F5? @Ray I see you are moving away from the F5 implementation, was something not working as expected with it?

Thanks!
K
0 Kudos
RayReno
Contributor
Contributor
Jump to solution

Konstantinos,

We have completed our migration from an F5 configuration supporting our Per App VPN to the UAG VMware tunnel.  I have found the new configuration to be much more reliable and the number of end user complaints about performance have been drastically reduced to the point of almost none.

I would not reccomend the F5 configuration for a number of reasons,  you have to be on the latest version for it to work with iOS 12.  After we updated the F5 platform we moved on and the AGENT running on the devices would only work on a carrier network.  It was at after working with F5 for over 3 months to resolve issues we abandoned F5 and went to the VMware tunnel. 

We are now moving our Content GateWay to the UAG and from what I have been reading will be moving the SEG over as well when available.

I have not worked with the Cisco ASA configuration.
0 Kudos