VMware Workspace ONE Community
kmullins131
Contributor
Contributor
Jump to solution

VMware Tunnel Not Connecting when Starting Apps in iOS

I have been trying to get VPN to work on some LTE iPads we have. I need Safari and a Purchased VPP app to both connect to VPN when opened and in use. Here is what is setup:

- AirWatch UAG is all setup, if I go to "Groups and Settings > Configurations > Tunnel" and use the "Test Connection" button, it all comes back green and connected. 

- A VPN Profile has been created and deployed to the iPad

- Device Traffic Rules have been created for Safari. I will post a screenshot of this menu option below:

kmullins131_3-1645560967690.png

 

With all that setup the device shows up as online in Airwatch, can get commands I send and check in, etc. When I open Safari I see this error and the VPN does not start:

kmullins131_1-1645560898012.png

As a test, I removed the VPN profile and it changed the error to this:

kmullins131_2-1645560944419.png

If I open my VPP App, the VPN also does not start. The VPP app is not on the Device Traffic Rules list. I have tried the Per App VPN Profile with this app and it did not work either. 

Clearly the device connects to the internet, and clearly the VPN works since the test connection works. So I believe it is just some configuration I have wrong. In the end my goal is to be able to force the VPN on when an app opens, be it safari, or any other app I put on the device. I would love to understand how to do this. 

Labels (1)
Reply
0 Kudos
1 Solution

Accepted Solutions
sluzi1986
Enthusiast
Enthusiast
Jump to solution

Do your Android endpoints still function with your SSL certificates in that condition? That needs to be remedied and keep in mind Android 11 and later also enforce the same validity length periods for certificates as Apple does now. I also noticed you are using self-signed certificates. That is not technically encouraged for production usage, and you may run into issues with older UAG appliances where the trusted root authorities are out of date unless manually added.

Adding a Device Traffic Rules in the iOS Context presents to the defined VPN profile the same way as defining a SafariDomain in the VPN profile. In order for the DTR to update, you do need to publish the associated VPN profiles again - either through the prompt in WS1 after editing the default rule, or by manually adding a version to the profile itself. So, adding it to the profile itself won't matter if its already a DTR. I've seen this when exporting a sample profile within WS1. If the DTR wasn't functioning correctly for your rule, the VPN app would not have attempted to tunnel it, which is why you received the error message in the OP.

If your front-end cannot "see" your back-end, this can happen. Speaking from experience. Within the UAG admin panels, I would also suggest making sure you have good DNS and NTP settings on both appliances. Enable the diagnostic logging in your Tunnel app, restart the iPad and try it again. It may give you a clearer indication on where connectivity is failing.

You can follow this guide to reset your Root credentials via console: https://kb.vmware.com/s/article/50121028 It is very fast and painless to do.

Once you are able to get into root on the UAG front-end, perform a curl -vk <hostname> to your back-end. Note the status of the TLS handshake, if connectivity succeeds between them. If it does not, then perform a tcpdump -i eth(interface - select the appropriate interface if the UAG has multiple) and port not 22 (to ignore SSH traffic) and watch the traffic when you try to hit your internal resource. Do the TCPDUMP on both UAGs. Jump from front-end and if you see traffic trying to leave, then hit the back-end and repeat it.

Also, what version UAG are you running? I'm not on the latest version (-2) and my Photon version is wildly newer than yours - 21.03.photon.3 

View solution in original post

7 Replies
AlexanderMuc
Enthusiast
Enthusiast
Jump to solution

Have you set lmhealth.org as Safari domain in the VPN profile?

Are the server traffic rules set properly?

What is the default rule for the device traffic rules? Tunnel? Bypass? Block?

kmullins131
Contributor
Contributor
Jump to solution

Have you set lmhealth.org as Safari domain in the VPN profile? - I had not, I have added "lmhealth.org". 

Are the server traffic rules set properly? - There are no server rules set

kmullins131_0-1645625951152.png

 

What is the default rule for the device traffic rules? Tunnel? Bypass? Block? - It seems the default is set to TUNNEL

kmullins131_1-1645625985275.png

 

kmullins131_2-1645625992620.png

 

Reply
0 Kudos
gowdaman-klr
Contributor
Contributor
Jump to solution

Please make sure the websites are accessible via UAG first - https://techzone.vmware.com/understand-and-troubleshoot-tunnel-connections

kmullins131
Contributor
Contributor
Jump to solution

So I read through the article and tried to login to our DMZ and Internal servers via Putty to run these commands. Unfortunately the root passwords documented are not correct so I am working with our Server Admins to figure out a solution to that. 

Other connection related info I do have is this connections test:

kmullins131_0-1645645757119.png

I also noticed on the tunnel app on the iPad that I get this message:

kmullins131_1-1645645810540.jpeg

It will say "Reconnecting" for a few seconds and then just says "Disconnected". 

Our Networking team did not see any blocked traffic. I did find on the "Server Authentication" section that the SSL Certificates had expired on the 16th. Though, this issue was happening before the 16th, so I am not sure how much it matters

kmullins131_2-1645646268188.png

 

 

 

 

Reply
0 Kudos
sluzi1986
Enthusiast
Enthusiast
Jump to solution

Do your Android endpoints still function with your SSL certificates in that condition? That needs to be remedied and keep in mind Android 11 and later also enforce the same validity length periods for certificates as Apple does now. I also noticed you are using self-signed certificates. That is not technically encouraged for production usage, and you may run into issues with older UAG appliances where the trusted root authorities are out of date unless manually added.

Adding a Device Traffic Rules in the iOS Context presents to the defined VPN profile the same way as defining a SafariDomain in the VPN profile. In order for the DTR to update, you do need to publish the associated VPN profiles again - either through the prompt in WS1 after editing the default rule, or by manually adding a version to the profile itself. So, adding it to the profile itself won't matter if its already a DTR. I've seen this when exporting a sample profile within WS1. If the DTR wasn't functioning correctly for your rule, the VPN app would not have attempted to tunnel it, which is why you received the error message in the OP.

If your front-end cannot "see" your back-end, this can happen. Speaking from experience. Within the UAG admin panels, I would also suggest making sure you have good DNS and NTP settings on both appliances. Enable the diagnostic logging in your Tunnel app, restart the iPad and try it again. It may give you a clearer indication on where connectivity is failing.

You can follow this guide to reset your Root credentials via console: https://kb.vmware.com/s/article/50121028 It is very fast and painless to do.

Once you are able to get into root on the UAG front-end, perform a curl -vk <hostname> to your back-end. Note the status of the TLS handshake, if connectivity succeeds between them. If it does not, then perform a tcpdump -i eth(interface - select the appropriate interface if the UAG has multiple) and port not 22 (to ignore SSH traffic) and watch the traffic when you try to hit your internal resource. Do the TCPDUMP on both UAGs. Jump from front-end and if you see traffic trying to leave, then hit the back-end and repeat it.

Also, what version UAG are you running? I'm not on the latest version (-2) and my Photon version is wildly newer than yours - 21.03.photon.3 

kmullins131
Contributor
Contributor
Jump to solution

"Adding a Device Traffic Rules in the iOS Context presents to the defined VPN profile the same way as defining a SafariDomain in the VPN profile. In order for the DTR to update, you do need to publish the associated VPN profiles again - either through the prompt in WS1 after editing the default rule, or by manually adding a version to the profile itself."

This was it! I ended up creating a new VPN profile after regenerating the SSL certs and then it all started connecting. I was not aware the profile needed a new version sent out. Thank you for letting me know. I will also pass the root password article to our server admins to use. Thank you again!

Reply
0 Kudos
sluzi1986
Enthusiast
Enthusiast
Jump to solution

I can almost guarantee you it will wasn’t the DTR since it was trying to route previously  


Republishing the profile also republished the SSL certs you regenerated. The UAG per app tunnel uses SSL pinning, and with your certs expired, the certs were also expired in the VPN profile on your devices and consequently replaced when it was republished. 

I only say this for future help. I’m glad you’re all sorted!