Forum Discussion

Andrii's avatar
Andrii
Icon for Joining the Conversation rankJoining the Conversation
11 months ago

Always on VPN and troubleshooting connectivity issues

Hi,

I wanted to check if anyone else have experienced issues with the users enabled for Always On when their SDP client can not connect. Ocasionaly we see clients can not connect showing different errors, like username not recognized, can not connect, etc. The problem is that our Zoho Assist remote management software is not available if the user laptop is not connected to Internet which it is not when using Always On. How do you guys provide support in this scenario? What we usually do is first disable Always on policy for that user and then re-install the CAto client using either local admin or service desk user account. The problem is that we need to change the passwords to those accounts after giving out to the user by phone.

Basically we just need Zoho Assist client traffic to bypass Cato tunnel, we will be testing split tunnel feature and adding Zoho IPs to bypass.

Curious to hear your thoughts. Thanks!

6 Replies

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

    Hi.  Have you tried disabling IPv6 on the network adaptors used to connect to the internet (wired/wifi)?

    We find doing this solves many of our issues with remote VPN users.

    Also, it's worth having another review of the requirements list on the knowledgebase.  Sounds basic, but there might be something there relevant.  For us, we had to add some bypasses to our EDR solution to stop some connection problems with our Mac devices.  And we've the odd Windows device useing the Intel Killer NIC we have had to sort out.

    Currently you cannot split-tunnel via domain name, although Cato recently brought in the ability to split-tunnel via a handful of built-in applications such as Teams or Zoom.  Our organisation never had an issue accessing those over Cato so that isn't useful for us.

    We have a long-standing RFE to allow split-tunneling via domain name, to solve the same problem you are having.  We use always-on and our remote access application for our end-user support team to access devices is Splashtop.  Our support team cannot access a device when it is at the prelogin, or Windows log-in state.  This is because always-on + prelogin blocks all internet access apart from anything to the iDP (Entra in our case).  Problem is, Splashtop use a CDN and so cannot publish a definitive list of their IPs as this dynamically changes often, as proved by our frequent nslookups.  As such we cannot add their IPs into the split-tunnel list but a domain object would work fine.

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

      Hi Nath, yes, IPv6 is usually first thing we check. With the 5.12.9 client version routing to IPv6 supposed to be fixed according to support. The particular issue we have is when we disable employee for extended LOA and they come back, the client will not connect. That user gets removed from Cato since its disabled and when they are added back something must be off between what was on their machine cato client and what is in the cloud, it will not connect giving error username mismatch.

      We are really looking forward to the feature for split tunnel via domain name. I will file RFE from our end to push it forward.

      Thanks for your input!

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

        We are also facing issue due to no splitting of tunnel via domain name and we raised RFE for the same on 3rd Dec 2024 and the ticket is PM-11467 with RFE name as "Split Tunnel basis FQDN/Domain" but since there is no platform to check status of raised RFE nor showing in the product road map as well. Though in one of the video released by Cato on Split Tunnel for specific applications, they have said regarding split tunnel basis domain name.

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

    Hi Andri

    We also face Cato client connectivity issues when users go on MFLA as our company policy is to disable the users account once they start their leave. Cato then detects that the users account is disabled and removes it from CMA. When the user returns and the account is enabled, our helpdesk teams have to uninstall the cato client and reinstall it from their workstation as the SDP client detects a different profile preventing the users from successfully connecting. It make it challenging for the user as they have to leave or ship their laptop to IT. Therefore we have updated SOP's for different teams when users go on MFLA.

    Can Cato find a way to streamline this process as most of our users tend to work remotely or sites are in different geographical locations and does not make sense to ship the laptop to corporate office and back to user?

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

      Oh yes, thats another issue we have. So far the solution is to reinstall the Cato client like you said. Given the Always On policy enabled, its not easy to access the user machine in this case.

      Hope Cato can add exceptions or bypass for Always On policy.

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

      We’ve seen this issue as well (we use SCIM provisioning from Entra ID). One would think that a user that is disabled in the source catalog is merely disabled in Cato as well, ready to be seamlessly re-enabled when the user returns. Likely the issue is that we are removing those temporarily disabled users from the synced group (as they otherwise still consume a license in Cato) and as such will be recreated as a new user object when added back to the group (requiring a reinstall). Kind of makes sense I guess, even if the need to reinstall the client appears a bit excessive - Cato should be able to link up to the same UPN.