In case the High Performance Relay (HPR) server is working incorrectly, here are some troubleshooting steps that can be followed.

Table of contents:

Validate host configuration for HPR
Confirm parsechpr service is running on HPR server
Confirm communication from WAN client to public HPR endpoint
Confirm communication between HPR server and Parsec host machine
More helpful information

Validate host configuration for HPR

This will tell us if the host is configured to use the HPR. In the examples below, a correct configuration would result in a RFC 1918 class A, B, or C local address while an incorrect configuration would result in the host receiving the Parsec public STUN server address. To validate:

1. Attempt a connection to the host using the Parsec client
2. On the host machine, view Parsec’s console log by clicking the ‘Help’ button, then ‘Console’
3. Verify that the host computer gets a STUN reply from address matches the LAN IP of the HPR server

Example

Correct

Solution

The host should be configured to use HPR via the Teams admin page or modifying the configuration file. In general, it is recommended that the host configuration to use HPR is done through the Teams admin page.

Add the HPR local IP address and internal listener port on Teams admin page's App Rules section. You can either apply it globally, or use rulesets to assign these changes to specific machines.

Confirm parsechpr service is running on HPR server

1. SSH to the HPR server
2. Run service parsechpr status
3. Confirm that active (running) is displayed
4. We can also confirm that the service configuration file has been modified appropriately. The HPR public IP, public port, and private port should match the IP and ports configured during completion of the prerequisites

Examples

Correct

Incorrect

Solutions

If parsechpr service is in an inactive state:

1. run sudo systemctl start parsechpr
2. Confirm service is in active (running) state

If the parsechpr service is in an active (running) state but the HPR public IP, public port, or private port information is incorrect, you will need to modify the service config file. Using your favorite text editor (we hear you VIM folks) and edit the service config file located at /etc/systemd/system/parsechpr.service.

Confirm communication from WAN client to public HPR endpoint

1. Stop the parsechpr service: sudo systemctl stop parsechpr
2. On the HPR server, open the public port to listen over UDP using netcat: nc -u -l [public port]
3. On the client, send a message to the public HPR endpoint over UDP using netcat (or ncat on Windows)
1. nc -u [public-IP] [public-port]
2. test message
4. Confirm that the message shows on the HPR server
5. Once you've tested communication successfully, don't forget to re-enable the parsechpr server

Examples

Success

Failure

Solution

If the test message is not received by the HPR server, the reason is most likely related to ingress rules on the corporate firewall. Confirm completion of prerequisites related to public IP, port, and NAT.

Confirm communication between HPR server and Parsec host machine

1. Start tcpdump on HPR server: sudo tcpdump port 4900 or port 5000
2. Connect to Parsec host from client

The HPR will send the same packet to the host repeatedly if the host does not respond. In the failure example, this is indicative of the HPR being unable to communicate with the host’s start port.

Examples

Success

Failure

Solutions

There are multiple things you can check:

• Confirm that corporate firewall allows UDP communication between HPR and host
  • By default, the Parsec host will select a random Host Start Port. Restrictive corporate firewall policies may not be conducive to usage of random start ports. You may consider configuring a static Host Start Port and allowing only that port through from the HPR to the hosts
• Configure static Host Start Port

• Temporarily disable Windows firewall on the host. If this is successful, adjust Windows firewall rules appropriately

More helpful information

Verifying UDP connectivity using Netcat

You can use netcat to check if you can reach the HPR server using UDP. Netcat is included in most Linux distros as well as in MacOS. It's also available for Windows. Please note the netcat utility is included in the nmap installer.

In order to test the connectivity, run netcat on the HPR to listen for UDP connection in the public port, on our example 5000, with the following command:

nc -u -l 5000

On the client side, run the below command to connect to the HPR via its public IP and port. In our example (1.2.3.4:5000), the command would be:

nc -u 1.2.3.4:5000

As this is UDP, the commands will not show an error even if the connection cannot be established. In order to test connectivity, just type something on the client side and press enter. If the connectivity is working, you should see the text you typed in the client appearing on the HPR server. 

You can run the same test from the internal host to the HPR, using the internal port in the HPR command (4900) and using the internal ip:internal port of the HPR (10.1.2.20:4900) when connecting from the Host.

We recommend the stand-alone nmap package to run netcat on Windows.

Windows firewall

Windows firewall has been known to block Parsec's UDP traffic in some rare cases. Temporarily disabling the Windows firewall will quickly confirm whether this is an issue and if an exception rule will need to be added.

Corporate firewall

• Confirm you are allowing inbound + outbound UDP traffic on the WAN interface of your firewall to and from the same [public port] you specified on the parsechpr.service. You must not use port translation. If you have set [Public Port] to 5000, then you must open UDP port 5000 on the WAN interface and it must forward directly to port 5000 (and LAN IP address) of the Linux machine running the HPR
• Verify that the Parsec host has general HTTPS internet connectivity (443)
• Confirm your UDP inbound + outbound firewall rule at a minimum accepts traffic from your remote clients public IP address, but for testing purposes we recommend allowing traffic from all public addresses 0.0.0.0/0

Client

The client (typically sitting at the user's home) is the device initiating the connection to the on-premise host. Make sure the client IS NOT connected to the on-premise network via VPN and that it does have general internet connectivity.