Skip to main content

HPR Troubleshooting

HPR Troubleshooting

Updated

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

Table of contents:

 

Issues with starting the relay service

Relay service not registering/Showing active within the admin dashboard.

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

 

Issues with starting the relay service

  1. On the HPR server open the Linux terminal and input the below command to open the Parsec service file:

    sudo nano /etc/systemd/system/parsechpr.service
     
  2. Within the Parsec service file create a new entry:

    Environment=”LOG_LEVEL=debug”
     
  3. Save the Parsec service file and run the below Linux command to refresh the service file.

    sudo systemctl daemon-reload
     
  4. Attempt to start the HPR via the below command:

    sudo systemctl start parsechpr
     
  5. Open the Parsec service status via the below command:

    sudo service parsechpr status
     
  6. If the Parsec service file references ‘status=243/CREDENTIALS) then the issue is caused by either the Relay key secret, the encryption of the secret, the SetCredentialEncrypted block or the syntax of the Parsec service file.

 

  1. To begin rectifying the issue please login in to the Parsec administrator dashboard and select the ‘Relays’ blade and delete the previous relay.
  2. Create a new relay, ensure that you reveal the key secret and then copy/paste it in to a text editor.
     
  3. Open the terminal on the Linux server and run the below command to prompt for the key secret:

    sudo systemd-ask-password -n | sudo systemd-creds encrypt --name=relay-secret -p - - 
     
  4.  Once the key secret has been entered please copy the ‘SetCredentialEncrypted’ block and paste it into a text editor.
     
  5. Open the Parsec service file via the below command:

    sudo nano /etc/systemd/system/parsechpr.service
     
  6. Within the Parsec service file please input the new ‘SetCredentialEncrypted’ block and save the file.
     
  7. Refresh the service file via the below command:

    sudo systemctl daemon-reload
     
  8. Start the Parsec relay service and then check the status of the relay service. A healthy relay service should show as below:



Relay service not registering/Showing active within the admin dashboard.

If the relay isn’t registering or showing active within the administrator dashboard then the issue is likely caused by one of the below:

  1. Misconfigured DNS: DNS is misconfigured on the HPR or the HPR cannot reach the DNS server to resolve kessel-ws.parsec.app.
  2. Missing firewall rule: The firewall rule to allow TCP 443 traffic to kessel-ws.parsec.app is missing or misconfigured.
  3. HPR OS firewall is enabled: This would need to be configured to allow the Parsec service and ports or disabled.

 

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

mceclip0.png

 

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.

fixing_stun.png

 

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

hpr_running_and_correct_details.png

Incorrect

hpr_not_running.png

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.

hpr_config.png

 

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

received_message.png

Failure

didnt_receive_message.png

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
 

packets_changing.png

Failure
 

packets_not_changing.png

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

host_start_port.png

  • 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.

Related articles

Powered by Zendesk