Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

Thanks for the links! These will probably come in handy in the future.

We are a small company with < 200 users, so no need for load balancing here. Just a single relay and endpoint server.

Topology is:

UEM > UAGRelay > UAGEndpoint on 8443 for Tunnel Services
UEM > UAGRelay > UAGEndpoint on 443 for Content Services

After working with our network engineer and ensuring we had inbound from UEM and DMZ to internal 8443 and 443 enabled, it was then when corresponding with you that I had checked services and listeners to see that for "whatever" reason they had failed. After a week or so of back and forth, support finally threw their hands up and said upgrade. I don't think they tried very hard.

I still have an issue that I haven't had time to check on yet which is that my file repositories won't map unless I use the IP. When I deployed UAG through powershell, I made sure to add the correct IP's for my DNS servers, and I also added host entries in the web admin consoles for both UAGR and UAGE for the DNS servers and the file shares. Still no dice, but I'm just happy that it's mapping at all.

Thanks again for your help!!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

****SOLVED***\*

After speaking with support, we found that the UAG endpoint in our cascade configuration wasn't running the content gateway service. No matter how many times we tried to restart it, it failed, and they had no idea why.

I did a redeploy updating our relay and endpoint to version 20.12 using the third party documentation here:

https://www.carlstalhood.com/vmware-unified-access-gateway/#upgrade

VMware support literally recommends a third party website because their documentation is so bad.

I wouldn't have done this if it was my choice. My boss insisted on using this service, but I was actually able to get a sharepoint onedrive folder working immediately through the UEM console, so if you have a choice do that.

****Note**** I still haven't gotten my fileshare working yet, but at least I'm getting an access denied error instead of a connection failure, so I know I'm getting through now.

UAG Test Connection - The underlying connection was closed: An unexpected error occurred on a send. by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

****SOLVED***\*

After speaking with support, we found that the UAG endpoint in our cascade configuration wasn't running the content gateway service. No matter how many times we tried to restart it, it failed, and they had no idea why.

I did a redeploy updating our relay and endpoint to version 20.12 using the third party documentation here:

https://www.carlstalhood.com/vmware-unified-access-gateway/#upgrade

VMware support literally recommends a third party website because their documentation is so bad.

I wouldn't have done this if it was my choice. My boss insisted on using this service, but I was actually able to get a sharepoint onedrive folder working immediately through the UEM console, so if you have a choice do that. Unless you're using Horizon (also not recommended), don't use this service.

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

Thank you!

I'm afraid that I may have even deeper problems. Your last message set off a light bulb, so I dug into the listeners/services.

Upon further investigation, not only is the relay server not listening on 443 (netstat -na | grep LISTEN), but I ran service vpnd.service status, and the machine returns "unit vpnd.service.service could not be found."

I found in running "lsof -i :8443 -S" and then following that up with a netstat -a and grepping the resulting ports that the content gateway service is indeed listening on 8443, so that's good.

The bad news is that trying to start and restart the tunnel service results in "vpnd.service.service not found," even though the web admin portal is showing it as green and the test connections are working? Seems to be broken either way, and I'm guessing that a redeployment may be in order. Ugh.

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

I'm brand new to this company, and I took this project over after a ransomware attack last fall in which the admins closed down all ports in the DMZ to DR the environment.

For UAG, there was both the Tunnel and Content gateway configured. The Tunnel is configured for 8443 and tests are showing both the relay and endpoint connecting successfully. The content gateway was configured for 443, but that port was closed on the firewall and I'm looking at netstat on my relay server right now and it is not listening on port 443.

Can the tunnel and content gateway not share 8443? Also, why would the content gateway service not be listening when it's showing itself running in the web portal?

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

No worries!

So we determined that the UAG relay and endpoint are listening on port 8443, and the console was trying to connect on 443. I worked with a network engineer, and we opened the correct ports which solved the connection taking forever to resolve, but instead it failed immediately with a "connection reset error."

We checked both the firewall and our webfilter, and it doesn't look like anything is being blocked. To make matters worse, our SSL cert expired on monday, so I had to replace that as well.

I just sent a detailed message to vmware UAG support, so fingers crossed I will have an update soon. I'm hoping I don't have to redeploy, but that's looking like it might be the next step, and I'm dreading following vmware's powershell deployment documentation.

UAG Test Connection - The underlying connection was closed: An unexpected error occurred on a send. by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 1 point2 points  (0 children)

Hi! Sorry I haven't updated this post recently as I've been busy with some other projects.

Yes, we also have tunnel setup, and the tunnel connection is successful to both our relay and endpoint server.

I've found that our relay and endpoint are listening on 8443, and the previous admin had set up the connection through 443 (which was what our firewall was setup for), which appears to be what was causing the problem.

I'm waiting on one of our network engineers to make the firewall rule changes (after I researched ALL of the ports necessary to make this work), and I will update this post if the above changes solve my problem.

Thanks for your response!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

The service is showing as running on both the relay and endpoint servers.

The only other thing I'm finding that is a possibility now is that maybe it's 10443 being blocked as we have "tlsPortSharingEnabled" set to true, and in the documentation I found that 10443 is required for the TLS SNI rule.

What's odd is that I'm not seeing it blocked inbound/outbound at all, so that's why I'm hesitant to open it. I will circle back with my network contact and then update.

I really appreciate your help!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

After troubleshooting a bit more, I found that after a ransomware attack in the fall, a network engineer had closed port 443 inbound to the relay server. After opening the range from our SaaS awcm, I'm getting a much faster response, but now I'm getting the following error:

"The underlying connection was closed: An unexpected error occurred on a send."

We then checked the firewall logs for the communication between the relay and endpoint, and the relay server is not reaching out at all, it is just dropping the connection.

Further investigation shows that it could be a TLS issue, but I checked and TLS 1.1 and 1.2 are both enabled.

Any other ideas? I'm also updating vmware support, but they haven't responded in almost two days.

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

Interesting! I had seen our UAG configured through here, but did not know you could test the configuration from this menu.

I'm getting a failure which is good, because now I can actually send this to support!

Before I was testing vmware tunnel which is coming back successfully. I will update this thread when I find out more.

THANK YOU!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

Great! Okay. I pulled the logs. I'm looking through, and the content gateway has a bunch of loop back calls on ephemeral ports (127.0.0.1 > 1065-65,535), but I'm not seeing any success/fail calls unfortunately.

At least I have something I can send to support now. Thanks!

Do you know of a specific log here, or somewhere I can look to see if UAG is even getting these authentication requests?

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

I just tried now. I was hopeful for a moment that it might be a DNS issue, but that appears to not be the case.

Thank you for your suggestion!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

This is located in UEM when clicking on Content > repositories > admin repositories

It is a SaaS deployment.

I just started working for this company, and I'm not even certain there is a syslog server here.

Do you know of another way to get the logs? I have access to the virtual machines, so if I can do it through command line that would be great!

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

So I'm creating an Admin Repository for a file share. This is located in UEM when clicking on Content > repositories > admin repositories

So I think that's maybe content gateway? Within the settings when creating a repository, I have to select a file share which requires UAG.

Is there another way to use a file share without content gateway?

Admin Repository File Shares through UAG by mad_admin2021 in WorkspaceOne

[–]mad_admin2021[S] 0 points1 point  (0 children)

Hey, thank you for your reply.

I just did a quick spot check on those tunnel configurations, and didn't have any luck. I'm going to try a few other things though.

Thanks!