Joining the Conversation
Cato Professional ServicesYou mentioned: "if a remote users has the Cato client installed and running, they are able to connect."
Just to clarify, do you mean if the [1] Remote client is running Cato Client and the [2] target destination host is behind Cato Socket, the connection (Parsec app) works?
Cheers!
Joining the Conversationmichaelsaw, correct. When the remote user (outside the network, using their own device) is running the Cato Client and the target device is in the office, behind the Cato socket, the connection is established successfully. This makes sense, as as mananpatel suggested, both devices are within the same logical network.
The suggestion to configure Parsec traffic to bypass Cato appears to best workaround on the surface, but I don't see a practical way to configure this. The bypass rule needs an IP address value for either the source or destination.
Parsec host their own STUN server. When the client and host app are launched they contact this STUN server at stun.parsec.app:3478. The STUN server responds informing them of their own public IP and port they used to reach the STUN server (the ports are dynamic within the 1,024–65,535 range). This info is then used to inform them host and client app of each other so they can establish a P2P connection. According to the logs within Parsec, this informing is working (I see the public IP and port of the host on the client, and the same info of the client on the host). It's the last part, where the P2P connection is attempted, that fails with Parsec error "6023 -11010", which is specifically mentioned in this doc as a UPnP issue.
Going back to the bypass rule, if I set a destination IP bypass rule for stun.parsec.app, the host will contact the STUN server using our ISP's public IP, which is fine, but the incoming packets from the client are still blocked, presumably because the bypass firewall is not stateful??
If I set a source IP bypass, then I can only set either TCP or UDP, meaning all traffic from our hosts will bypass Cato so we get no security from the IDP/IPS engine, etc.
Because the UDP ports are dynamic, and client IP's will always be dynamic , it seems impossible to be able to create a secure rule anywhere in Cato to allow this traffic. I don't see a workaround. Is there one? Happy to test various scenarios.
On a separate note, the bypass is not granular enough to specify and IP AND port. I can only bypass an IP AND (TCP or UDP). I hear Application level bypass is an EA feature?
PS: This is a great article explaining about how NAT traversal/UPnP works. Obviously we aren't using Tailscale, but the concept applies to Parsec. https://tailscale.com/blog/how-nat-traversal-works
Cato Professional Services
Hi MIYO-KEP,
Appreciate your efforts and feedback on this.
You mentioned: "The suggestion to configure Parsec traffic to bypass Cato appears to best workaround on the surface, but I don't see a practical way to configure this."
Just to clarify, can we double-check if we have tested both Scenarios 1 and 2, as shown on the diagram below? ___
Just to understand more, how was the result/user's experience for parsec app in both Scenario 1 and 2? ___
Cheers!
