Making Connections
Staying InvolvedWe had to route 'Azureservices' out through Azure internet rather than to the socket to get things to work.
And also had to create a route for KMS.
See below our routing table:
In addition to that we also did a TLS Inspection Bypass for the Cato application called 'Azure Windows Virtual Desktop'
I checked our setup and we also have a bypass for another Cato application called 'Azure Automation' - but I cannot remember if that was directly related to this or not.
Making ConnectionsThat's interesting because our AVD works just fine now that we have the right TLS inspection certs and everything going through Cato... but only if the session host is just behind the socket WITHOUT Cato SDP. As soon as the catonetworksvpnservice service starts, DNS breaks, and there are NO events in Cato Events for why that's happening.
We have Cato SDP set up as described here, but no worky: https://support.catonetworks.com/hc/en-us/articles/26940719879837-User-Awareness-for-Shared-Hosts
Making ConnectionsOK we fixed the problem by excluding the domain controllers from the routing in the User Awareness GRE configuration. The article published on how to do this says that in their example they chose to exclude "destinations which should not be tunneled through GRE, such as DNS servers", but they don't make it clear that this is a mandatory exclusion, not an optional one. It seems like Shared Host User Awareness really only works for internet-bound traffic. If you try to include WAN destinations, the traffic is not routed properly and then your AD domain membership doesn't work. If the AVD session host detects a problem with its domain trust, it will mark the server as unavailable, thus blocking new connections from users.
