What to check if the Secure Remote Access is not working (Troubleshooting)
1) Check whether the secure reboot is disabled on both Remote Access Portal (RAP) machine and Secure Remote Access Connector/Kron PAM server. If it is enabled the Wireguard might not work.
Linux CLI | [root@rap~]# mokutil --sb-state |
|---|
SOLUTION: Disable secure boot.
2) Check the Wireguard configuration file on both Remote Access Portal (RAP) machine and Secure Remote Access Connector/Kron PAM server:
* Read the Wireguard config file command on the Remote Access Portal (RAP) environment:
Linux CLI | [root@rap~]# cat /etc/wireguard/wg-server.conf |
|---|---|
Example | [root@rap~]# cat /etc/wireguard/wg-server.conf [Interface] PrivateKey = AAAAAAAL/mqg4KKabGXO1GvAmqhFpN3JmJi4A+SE4= ListenPort = 50044 Address = 10.0.0.1/32 [Peer] PublicKey = BBBBBBTqwb8QxlgG0c+RFlol/2eRATmwT7hI/wzjP14= AllowedIPs = 10.0.0.2/32 (or 10.0.0.2/32) PersistentKeepalive=25 |
* Read the Wireguard config file command on the Secure Remote Access Connector/ Kron PAM server:
Linux CLI | [root@connector~]# cat /etc/wireguard/wg-client.conf OR [root@pam~]# cat /etc/wireguard/wg-client.conf |
|---|---|
Example | [root@connector~]# cat /etc/wireguard/wg-client.conf [Interface] PrivateKey=CCCCCCDUnTSCUfUSh3cROM8qnfLnct0XiRUh1RKSV1E= ListenPort=50044 Address=10.0.0.2/32 [Peer] PublicKey=DDDDDD9+EPCYlO4RxDaJ6WqPLLK9zVp691BkvZIP/jU= EndPoint=10.10.10.10:50044 AllowedIPs=10.0.0.1/32 PersistentKeepalive=25 OR [root@pam~]# cat /etc/wireguard/wg-client.conf [Interface] PrivateKey=CCCCCCDUnTSCUfUSh3cROM8qnfLnct0XiRUh1RKSV1E= ListenPort=50044 Address=10.0.0.2/32 [Peer] PublicKey=DDDDDD9+EPCYlO4RxDaJ6WqPLLK9zVp691BkvZIP/jU= EndPoint=10.10.10.10:50044 AllowedIPs=10.0.0.1/32 PersistentKeepalive=25 |
* Ping the Remote Access Portal (RAP)’s Wireguard IP address and the Secure Remote Access Connector/Kron PAM server’s Wireguard IP address on both environments (you should see that messages are received/sent).
Linux CLI | [root@connector~]# ping {Remote Access Portal’s Wireguard public IP} OR [root@pam~]# ping {Remote Access Portal’s Wireguard public IP} |
|---|---|
Example | root@connector~]# ping 10.0.0.1 OR [root@pam~]# ping 10.0.0.1 |
Linux CLI | [root@rap~]# ping {Secure Remote Access Connector/Kron PAM server’s Wireguard public IP} |
|---|---|
Example | [root@rap~]# ping 10.0.0.2 OR [root@rap~]# ping 10.0.0.2 |
SOLUTION: Check the wireguard configurations, and restart them.
Linux CLI | [root@ ~]# wg-quick down {Wireguard configuration file name} [root@ ~]# wg-quick up {Wireguard configuration file name} |
|---|---|
Example | [root@rap~]# wg-quick down wg-server [root@rap~]# wg-quick up wg-server OR [root@connector~]# wg-quick down wg-client [root@connector~]# wg-quick up wg-client OR [root@pam~]# wg-quick down wg-client [root@pam~]# wg-quick up wg-client |
3) Check the iptables rules on the Secure Remote Access Connector:
Linux CLI | [root@connector~]# iptables -t nat -nvL |
|---|
You need to see at least one iptables rule.
SOLUTION: Add the iptables rules on the Secure Remote Access Connector/Kron PAM server manually.
Linux CLI | [root@connector~]# iptables -t nat -A PREROUTING -p tcp --dport {HTTPS port} -j DNAT --to-destination {KronPAM server’s IP}:{HTTPS port} iptables -t nat -A POSTROUTING -p tcp -d {KronPAM server’s IP} --dport {HTTPS port} -j SNAT --to-source {Secure Remote Access Connector’s IP} |
|---|---|
Example | [root@connector~]# iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.20.42.129:443 iptables -t nat -A POSTROUTING -p tcp -d 10.20.42.129 --dport 443 -j SNAT --to-source 10.20.42.17 |
4) Check the status of the pam-rap.service on the Remote Access Portal (RAP) machine:
Linux CLI | [root@rap~]# sudo systemctl status pam-rap.service |
|---|
If the pam-rap.service is not working, you need to start it again.
SOLUTION: Restart pam-rap.service.
Linux CLI | [root@rap~]# sudo systemctl restart pam-rap.service |
|---|
5) Check the port allowance at the server-level that is defined in the firewalld service:
Linux CLI | [root@rap~]# sudo firewall-cmd --list-ports OR [root@connector~]# sudo firewall-cmd --list-ports OR [root@pam~]# sudo firewall-cmd --list-ports |
|---|
SOLUTION: Stop the firewalld service, if it is not needed:
Linux CLI | [root@rap~]# sudo systemctl stop firewalld OR [root@connector~]# sudo systemctl stop firewalld OR [root@pam~]# sudo systemctl stop firewalld |
|---|
6) Check the ip routing configuration on the both Remote Access Portal (RAP) and Secure Remote Access Connector/Kron PAM server:
Linux CLI | [root@rap~]# sysctl net.ipv4.ip_forward [root@connector~]# sysctl net.ipv4.ip_forward |
|---|
The result should be 1.
SOLUTION: If it is 0 please enable ip routing by setting with 1:
Linux CLI | [root@rap~]# sysctl -w net.ipv4.ip_forward=1 OR [root@connector~]# sysctl -w net.ipv4.ip_forward=1 OR [root@pam~]# sysctl -w net.ipv4.ip_forward=1 |
|---|
7)Check the SELinux security mode on the tenant connector:
Linux CLI | [root@rap~]# getenforce OR [root@connector~]# getenforce OR [root@pam~]# getenforce |
|---|
The result should be permissive.
SOLUTION:If the result is Enforcing, please select permissive security mode with this command:
Linux CLI | [root@rap~]# setenforce 0 [root@rap~]# setsebool -P httpd_can_network_connect on [root@rap~]# setsebool -P httpd_can_network_connect 1 OR [root@connector~]# setenforce 0 [root@connector~]# setsebool -P httpd_can_network_connect on [root@connector~]# setsebool -P httpd_can_network_connect 1 OR [root@pam~]# setenforce 0 [root@pam~]# setsebool -P httpd_can_network_connect on [root@pam~]# setsebool -P httpd_can_network_connect 1 |
|---|
8) Check the portal rights of the users, if the SSH/RDP session over Remote Access Portal (RAP) comes with blank or undefined@undefined page:
SOLUTION: Grant these portal rights to the users through user groups: single.connect.rdp.client.moduleVisibility single.connect.cli.moduleVisibility
9) Check the nginx configuration file under /etc/nginx/nginx.conf on the Remote Access Portal (RAP):
Linux CLI | [root@rap~]# cat /etc/nginx/nginx.conf … upstream backend { server {Secure Remote Access Connector’s Wireguard public IP}:443; } … |
|---|---|
Example | [root@rap~]# cat /etc/nginx/nginx.conf … upstream backend { server 10.0.0.2:443; } … |
Check the server info in the upstream backend section at the nginx.conf and check the activiness of the nginx.service.
SOLUTION: If the nginx.service is not working, please restart it on Remote Access Portal (RAP) machine.
Linux CLI | [root@rap~]# sudo systemctl restart nginx.service |
|---|
10) Check whether that you use correct nginx configuration file under /etc/nginx/nginx.conf on the Remote Access Portal (RAP) machine. If the Remote Access link returns 404 HTTP error, you need to check the nginx configuration file. The file should have these lines:
Linux CLI | [root@rap~]# cat /etc/nginx/nginx.conf … #------------------------------- # KronPAM - Internal redirections(frontend) #------------------------------- … location /rap-ui/static { proxy_set_header X-Forwarded-For $remote_addr; real_ip_header X-Forwarded-For; proxy_pass http://127.0.0.1:7777/static; } … |
|---|
SOLUTION: If these lines are not added yet, please add location /rap-ui/static { … block into nginx.conf file on the Remote Access Portal (RAP) machine, and save the file. After that, restart nginx.service (sudo systemctl restart nginx.service)
11) If the Remote Access Portal links get the certificate error, please check whether the self-signed certificate and generic RSA private key are changed with the customer’s own certificate and RSA private key. The customer should remove the self-signed certificate and generic RSA private key on /etc/nginx/certs directory. After this, the customer should add the customer’s AWS certificate and RSA private key with the same names. Lastly, the customer should restart nginx service by using sudo systemctl restart nginx.service command.
SOLUTION: If the customer has its own certificate and RSA private key, put these files under /etc/nginx/certs by using the names of cert.crt and cert.key. After that, restart nginx.service (sudo systemctl restart nginx.service)
SOLUTION: If the customer has its own certificate and RSA private key, put these files under /etc/nginx/certs by using the names of cert.crt and cert.key. After that, restart nginx.service (sudo systemctl restart nginx.service)
12) If you face this error: “RAP- REQUST NOT FOUND: request with id {no} could not be found” on the Remote Access Portal GUI, please check the CORS configuration on the Kron PAM server (for both with connector and without connector options):
SOLUTION: Add {RAP URL} as a cors.allowed.origins parameter under /pam/gui/conf/web.xml.
SOLUTION: Add {RAP URL} as a cors.allowed.origins parameter under /pam/gui/conf/web.xml.
Linux CLI | [root@pam~]# cat /pam/gui/conf/web.xml /cors … <param-name>cors.allowed.origins</param-name> <param-value> {RAP URL} e.g., https://remote.cloudpam.com</param-value> … |
|---|
13) Check the IP/Domain name information on both Remote Access Portal (RAP) and the Kron PAM.
SOLUTION: Use the correct values in Remote Access Portal (RAP) and Kron PAM server.
SOLUTION: Use the correct values in Remote Access Portal (RAP) and Kron PAM server.
13.1) If the IP is used in the RAP links:
*On the Remote Access Portal (RAP):
Linux CLI | [root@rap~]# vi /etc/hosts {private IP of the Remote Access Portal environment} {public IP of the Remote Access Portal environment} |
|---|---|
Example | [root@rap~]# vi /etc/hosts 10.10.10.10 204.232.204.232 |
Linux CLI | [root@rap~]# vi /pam/remote-access-portal/conf/application.properties sc.server={private IP of the Remote Access Portal environment} |
|---|---|
Example | [root@rap~]# vi /pam/remote-access-portal/conf/application.properties sc.server=https://10.10.10.10 |
*On the Kron PAM Server:
System Config Man-> rap.cloud.server = {public IP of the Remote Access Portal environment + /connect}
Example= https://204.232.204.232/connect
13.2) If the Domain Name is used in the Secure Remote Access’ links:
*On the Remote Access Portal (RAP):
Linux CLI | [root@rap~]# vi /etc/hosts {private IP of the Remote Access Portal environment} {URL of the Remote Access Portal environment} |
|---|---|
Example | [root@rap~]# vi /etc/hosts 10.10.10.10 remote.testcloudpam.com |
Linux CLI | [root@rap~]# vi /pam/remote-access-portal/conf/application.properties sc.server={URL of the Remote Access Portal environment} |
|---|---|
Example | [root@rap~]# vi /pam/remote-access-portal/conf/application.properties sc.server=https://remote.testcloudpam.com |
*On the Kron PAM Server:
System Config Man-> rap.cloud.server = {URL of the Remote Access Portal environment + /connect}
Example= https://remote.testcloudpam.com/connect
14) Check the Remote Access Portal (RAP)’s service log under /pam/remote-access-portal/ on the Remote Access Portal (RAP).
SOLUTION: Check the recent log lines to see if there are any errors.
Linux CLI | [root@rap~]# tail -1000f /pam/remote-access-portal/logs/application.log |
|---|
15) Check whether the rap-0.0.1-SNAPSHOT.jar is downloaded to /pam/remote-access-portal/ on the Remote Access Portal (RAP) via the Remote Access Portal (RAP)’s installation script. If it is not downloaded, fixing NetworkManager might solve this issue.
SOLUTION: Configure DNS with nmtui command on the Remote Access Portal (RAP) machine to allow downloading the regarding jar file.
Linux CLI | [root@rap~]# nmtui ***Select eth0*** ***EDIT*** ***Change DNS as 8.8.8.8 and Save *** [root@rap~]# sudo systemctl restart NetworkManager |
|---|
16) Check the catalina.out and localhost_access_log.2025-XX-YY.txt under /pam/gui/logs on the Kron PAM server during the session opened on the Remote Access Portal (RAP):
SOLUTION: Check the recent log lines to see if there are any errors.
Linux CLI | [root@pam~]# tail -1000f /pam/gui/logs/catalina.out |
|---|
Linux CLI | [root@pam~]# tail -1000f /pam/gui/logs/localhost_access_log.{YEAR-MONTH-DAY}.txt |
|---|---|
Example | root@pam~]# tail -1000f /pam/gui/logs/localhost_access_log.2025-02-25.txt |
17) If you get “Passcode is wrong” error on the Remote Access Portal (RAP) with the usage of 3.6.0 Kron PAM, the remote access jar file (rap-0.0.1-SNAPSHOT.jar) for 3.6.0 should be downloaded manually, because the Remote Access Portal script automatically downloads the latest jar file (for instance, for 3.7.0).
SOLUTION: Download the rap-0.0.1-SNAPSHOT.jar for 3.6.0, if the Kron PAM server version is 3.6.0. Once this file is downloaded manually, it should be placed under /pam/remote-access-portal/. After that, change its ownership and mod by executing chown and chmod commands respectively, and in the last step you need to restart pam-rap.service.
Linux CLI | [root@rap~]# ***Download rap-0.0.1-SNAPSHOT.jar file for 3.6.0 and place it under /pam/remote-access-portal*** [root@rap~]# chown pamuser:pam-group /pam/remote-access-portal/rap-0.0.1-SNAPSHOT.jar [root@rap~]# chmod 755 /pam/remote-access-portal/rap-0.0.1-SNAPSHOT.jar [root@rap~]# systemctl restart pam-rap.service |
|---|
18) LASTLY, please ask the customer to check their firewall at the network-level. You can understand whether the firewall at the network-level blocks the secure tunnel messaging by executing the sudo wg show command and checking its result (if the transfer line has “0B received, 0B sent”, the firewall at the network-level blocks the messages through the Wireguard port):
Linux CLI | [root@rap~]# sudo wg show interface: wg-server public key: BBBBBBTqwb8QxlgG0c+RFlol/2eRATmwT7hI/wzjP14= private key: (hidden) listening port: 50044 peer: DDDDDD9+EPCYlO4RxDaJ6WqPLLK9zVp691BkvZIP/jU= allowed ips: 10.0.0.2/32 *** OR 10.0.0.2/32 *** transfer: 0 B received, 0 B sent persistent keepalive: every 25 seconds OR [root@connector~]# sudo wg show interface: wg-client public key: DDDDDD9+EPCYlO4RxDaJ6WqPLLK9zVp691BkvZIP/jU= private key: (hidden) listening port: 50044 peer: BBBBBBTqwb8QxlgG0c+RFlol/2eRATmwT7hI/wzjP14= endpoint: 10.10.10.10:50044 allowed ips: 10.0.0.1/32 transfer: 0 B received, 0 B sent persistent keepalive: every 25 seconds OR [root@pam~]# sudo wg show interface: wg-client public key: DDDDDD9+EPCYlO4RxDaJ6WqPLLK9zVp691BkvZIP/jU= private key: (hidden) listening port: 50044 peer: BBBBBBTqwb8QxlgG0c+RFlol/2eRATmwT7hI/wzjP14= endpoint: 10.10.10.10:50044 allowed ips: 10.0.0.1/32 transfer: 0 B received, 0 B sent persistent keepalive: every 25 seconds |
|---|
You can also use tcpdump and send the test message to check the firewall at the network level.
Linux CLI | [root@rap~]# tcpdump -i any port {Wireguard port} -v [root@connector~]# echo "test packet" | nc -u {Remote Access Portal’s Wireguard public IP} {Wireguard port} OR [root@pam~]# echo "test packet" | nc -u {Remote Access Portal’s Wireguard public IP} {Wireguard port} |
|---|---|
Example | [root@rap~]# tcpdump -i any port 50044 -v [root@connector~]# echo "test packet" | nc -u 10.0.0.1 50044 OR [root@pam~]# echo "test packet" | nc -u 10.0.0.1 50044 |
SOLUTION: If the transfer line has “0B received, 0B sent” after sudo wg show, please ask customer to allow the neccessary ports on the Remote Access Portal (RAP) environment:
*443/TCP, *7777/TCP, *7777/UDP
*{selected-Wireguard-port(e.g., 51820)}/UDP.