Forum Discussion

Cato_Fan_2024's avatar
Cato_Fan_2024
Icon for Making Connections rankMaking Connections
5 months ago

Azure Virtual Desktop Session Host Routing

Hi, has anyone ever set up a route table on Azure so that the route to Microsoft Login subnets goes out through Cato?  When we tried doing this, to make sure our AVD users are protected by Cato, users stopped being able to connect to session hosts through the AVD FQDN (broker).

I suspect that its either TLS Inspection being enabled for Microsoft Login app (has never been an issue for our laptop users), or that AVD brokering system needs Microsoft Login traffic to go through the internet instead of a private route for some reason.

8 Replies

  • andy's avatar
    andy
    Icon for Making Connections rankMaking Connections

    Hi

    We also have an Azure Virtual Desktop Environment with Internet Access over Cato.

    I think you have to make sure that IP 168.63.129.16 is routed with an UDR to "Internet"

    Plus what I forgot first: KMS activation IPs 20.118.99.224 and 40.83.235.53 must be routed too to "Internet"

    Default route points to Cato.

    Best regards,

    Andy

     

    • Cato_Fan_2024's avatar
      Cato_Fan_2024
      Icon for Making Connections rankMaking Connections

      we tried paring back to only routing the subnets below (Microsoft Login app) and still were unable to connect through the AVD FQDN.  Only the subnets below were being routed through Cato and that was enough to stop authentication in its tracks.  I'm going to try disabling TLS inspection to the Microsoft Login app to see if maybe that's interfering with the Windows 365 client app.

      20.190.128.0/18
      40.126.0.0/18
      20.20.32.0/19
      20.231.128.0/19

      • DikFrik's avatar
        DikFrik
        Icon for Joining the Conversation rankJoining the Conversation

        Were you able to fix the issue? If so, how?

  • Nath's avatar
    Nath
    Icon for Staying Involved rankStaying Involved

    We 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.

     

     

    • Cato_Fan_2024's avatar
      Cato_Fan_2024
      Icon for Making Connections rankMaking Connections

      That'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

       

       

      • Cato_Fan_2024's avatar
        Cato_Fan_2024
        Icon for Making Connections rankMaking Connections

        OK 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.