Forum Discussion

MatthewLaComb's avatar
MatthewLaComb
Comet
27 days ago

Cato Windows SDP Client - TCP443 only

I've got a support ticket in - and am working on this.  But I figure I'll throw this out here too:

I have an instance of needing Cato SDP Client access - and the vendor's security team is allowing tcp443, but not udp443 nor udp1337. I saw the following recently:

https://support.catonetworks.com/hc/en-us/articles/360002577917-Client-TCP-Fallback-for-UDP-Tunnel

I have tested this with my own laptop that already has a user and was previously connected.  Blocking all ports except TCP443 outbound from my infrastructure for my laptop caused the client after about 90 seconds to connect, and only via TCP.  Success!

Installed a quick VM (win 11, same cato client version fresh) and performed the same thing.  Blocking all access except tcp443 (local DNS is still allowed, as well as ICMP outbound) and the client does not ever fail over as described in the article.

Any thoughts?  I figure there could be a hidden "registry setting" similar to what they have for changing the UDP ports in use by the client, but my searching has resulted in nothing.  Additionally the support rep states they can force TCP at an account or site level, but that isn't what I need - I don't have sockets at these affected sites, just workstations on the internet (firewalled). 

3 Replies

  • CATOM's avatar
    CATOM
    Icon for Cato Employee rankCato Employee
    27 days ago

    It is true that client does fall back to TCP but it is not recommended to start with TCP as the DTLS is proven to provide better throughput. Having UDP/TCP443 and 1337 offers you Captive Portal detection as well that would not work if you restrict yourself to TCP.

    Having said that the issue here may not be related to blocking UDP. There are other prerequisites  that this article mentions for SDP client to successfully connect that must be open from the VM you are trying it from:

    https://support.catonetworks.com/hc/en-us/articles/4411554844817-Installing-the-Cato-Client#h_01JR7XWE5DERWTFJ73SGP3CB2S

     

    • MatthewLaComb's avatar
      MatthewLaComb
      Comet
      17 days ago

      This is one of those times where I have a site that I am not an administrator over - and they are offering for us to be on a guest network that is VERY restrictive on what can get out.  Unfortunately, we've gone to a different solution using hardware boxes and IPSEC - but I was looking for this to be a way to get temporarily online (if not permanent?) in the event of hardware failure, as the site is 12 hours away.  The Cato client introducing tcp fallback works well enough when it has access to other ports, but this customer of ours will not bend to allowing udp443 nor will they let unfettered DNS requests to random internet endpoints.  Just making sure I still have no options with Cato, which is the case right now.

      Like I said above, my machine with a previous connection will fall back if I restrict to tcp443 only via firewall rules; but on an initial client install it needs that first contact using your DNS.  It's not a fall back in total - the initial connect works in conjunction with raw DNS requests, so the fall back is just if you're temporarily on a network with no access but have previously connected with the client overall.

      • CATOM's avatar
        CATOM
        Icon for Cato Employee rankCato Employee
        17 days ago

        It is possible to enforce TCP per SDP user by opening a support ticket and providing the user ID. Note that though end user needs to be advised that they will experience worsened performance with TCP based TLS tunnels. I have seen customers who ultimately asked to revert back to DTLS. Far worse to resolve if you leave it ON and the user later complains after few months that they are not happy with the performance and have no history of the TCP enforcement.