nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cato Cloud
- Discussions
- Best Practices
API
- Discussions
- Best Practices
Idea Hub
Community Help
- Discussions
Cato Partners
Cato SWIFTs
Discussions
Categories
Groups
Help

Cato and UPnP (hole punching)

MIYO-KEP

We are a new Cato customer and are part way through deploying sockets to our sites. We have discovered an issue with an application which users UPnP. The application (https://parsec.app) typically has an app installed on a device, such as a desktop PC, behind the socket. This is known as the "host". Then the app is also installed on a personal device, outside the network, known as the "client". These should negotiate a peer-to-peer connection using UPnP, but this is not working when the socket is in place. A remote user is not able to connect to their office PC.

It worked previously with our previous firewall. And if a remote users has the Cato client installed and running, they are able to connect.

It seems like the Cato socket does not support, or is blocking UPnP. Can anyone at Cato confirm if UPnP is supported, and/or offer some advice?

Thanks.

Find more posts tagged with

Comments

mananpatel

Cato Sockets do not have native support for UPnP (Universal Plug and Play) protocol. UPnP typically allows applications to automatically configure port forwarding on NAT devices, but since this functionality isn't supported by Cato Sockets, (I think) the peer-to-peer connection negotiation fails. Is this what is happening? You can check in PCAP while reproducing the issue.

The connection works when remote users have the Cato Client installed makes sense because in that scenario, both endpoints are within the same logical network through the Cato Cloud, bypassing the need for UPnP-based NAT traversal. (theoretically it would make sense)

For your specific use case with Parsec, you might need to:

Configure manual port forwarding rules in the Cato Management Application for the specific ports that Parsec uses. (more details here: https://support.parsec.app/hc/en-us/articles/32381460716180-Parsec-Connectivity-Requirements )
or
Consider using a different connection method that doesn't rely on UPnP
or
Create bypass for this traffic, not sure if that is relevant in your case.

You may always open a support ticket to get more details regarding this.

michaelsaw

Hi MIYO-KEP,

You 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!

MIYO-KEP

@michaelsaw, 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

michaelsaw

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!