Forum Discussion

Carlson's avatar
Carlson
Icon for Making Connections rankMaking Connections
2 days ago

Users behind the socket cannot access IPSec Tunnels

Users working remotely (home network) are able to successfully access Azure Virtual Desktop (AVD). However, when users are connected via the Site Socket, access to AVD fails.

As part of our troubleshooting, we manually configured the client-side DNS settings on a test laptop. With this configuration, DNS resolution functioned as expected, and we were able to successfully establish connectivity to AVD. This behavior suggests that the issue is related to DNS resolution within the Cato environment—specifically, DNS forwarding to the client-defined DNS servers does not appear to be functioning as expected.

Given this, we would like to inquire if there is a mechanism to prioritize client DNS settings on a per-user or per-group basis within Cato.

For reference, when connected via the Site Socket network, client devices are assigned IP addresses within the subnet range 10.254.xxx.x.

 

When users are connected via Home Wi-Fi or Mobile Data, they are able to successfully access the client’s Azure Virtual Desktop (AVD). In this scenario, the assigned IP address falls within the subnet range 10.20.xxx.xx.

 

2 Replies

  • michaelsaw's avatar
    michaelsaw
    Icon for Cato Professional Services rankCato Professional Services
    1 day ago

    Hi Carlson, 

    Seems the AVD issue is isolated  on the DNS setting when users connected via socket.
    Can we check the possibility to create a test network/vlan on the socket to test with the DNS settings of the remote users, to further identify/isolate the AVD connection issue?

    Cheers 

  • Carlson's avatar
    Carlson
    Icon for Making Connections rankMaking Connections
    1 day ago

    Hi michaelsaw​ 

    As Cato Professional, 

    Could you please provide some insight regarding our DNS configuration to address recent AVD connection failures? Specifically, we are considering configuring the Cato Networks Primary DNS as our primary DNS, alongside a Secondary will be the Client DNS. Is this an effective fallback mechanism if DNS forwarding fail? We would highly appreciate your architectural guidance on whether this approach will help mitigate our current AVD issues. Thank you.

    Primary: 10.254.xxx.x

    Secondary: 10.xx.xxx.x