Troubleshooting "site is not responding" Issues

Various Scenarios

There are quite a number of scenarios, in which you may encounter "site is not responding" issues. The scenarios that we have encountered and dealt with are detailed below.

Scenario 1: Remote VPN fails with error: "Site is not responding" or "Gateway not responding"

Product: IPSec VPN, Endpoint Security VPN

Version: R76, R77, R77.10, R77.20, R77.30, R80.10

Symptoms:

• Remote VPN fails with error: "Site is not responding" or "Gateway not responding"
• Trying to view the certificate gives the error: "Failed to read certificate from database"
• VPN debug shows issues with connections to the gateway over TLS.
  

  Cause:

  VPN certificate is expired / does not have the right properties / is corrupted.

  Solution:

  Renew the Internal CA certificate:

  1. Backup the database by using Database Revision Control. Select 'File > Database Revision Control > Create'.
  2. Remove the Gateway Object from any VPN community it participates in.
  3. Select 'SmartDashboard > Security Gateway / Cluster object > Properties'. 
  4. Select "IPSec VPN" and under 'Repository of Certificates Available on the Gateway', select the certificate called 'defaultCert'. Click on 'Remove' > confirm.
  5. Click 'OK' to close the 'Properties' window.
  6. Save all changes. In 'File' menu, click 'Save'.
  7. Select 'SmartDashboard > Security Gateway / Cluster object �> Properties'.
  8. Select "IPSec VPN" and under 'Repository of Certificates Available on the Gateway', click 'Add...'.
  9. In 'Certificate Nickname', type defaultCert (all letters are small, except the 'C'). Click on 'Generate...'. 
  10. Click 'OK' to close the 'Properties' window. Save all changes. In 'File' menu, click 'Save'.
  11. Put the Gateway Object back into any relevant VPN communities.
  12. Install policy on the Security Gateway / Cluster object.

Scenario 2: Endpoint Security VPN fails to connect to Security Gateway with "Site is not responding" error

Product: Endpoint Security VPN, SecuRemote, SecureClient Mobile

Version: All

Symptoms:

• Endpoint Security VPN fails to connect to Security Gateway with "Site is not responding" error.
• Traffic capture shows:
  • Security Gateway segments packets to 1500 bytes according to the MTU of its interface.
  • Security Gateway sends packets with "Don't Fragment" (DF) flag set.
  • When the Security Gateway sends packets that are larger than the next hop's MTU size, receive an ICMP "Fragmentation Needed" message with the next hop's MTU size.
    

    Cause:

    Next hop MTU is less than the MTU of the external interface of the Security Gateway. As a result, the next hop drops the packets since they are sent with "Don't Fragment" (DF) flag set.

    Solution:

    On the Security Gateway, lower the external interface's MTU size to the next hop's MTU size.

    Note: There is no impact on the environment, as the traffic should be sent according to the next hop's MTU size, anyway.

    It is a best practice in general to configure the same MTU on the external interface of the Security Gateway as the MTU of the next hop router.

    Related Solution
    sk96124 - Path MTU Discovery (PMTUD) issues with Check Point Active Streaming (CPAS).

Scenario 3: If Visitor Mode port changed, Endpoint Security VPN cannot establish site

Product: Endpoint Security VPN, Security Gateway 

Version: R77.20

Symptoms:

• If Visitor Mode port is changed from default (443) to something else, Endpoint Security VPN cannot establish site if it uses only the Security Gateway IP address. Site can be established if IP address:port is used.
• Customer upgraded the firewalls to R77.20 from R75.45. Then realized that their vpn clients could not connect to the gateway anymore. Clients get the following error: "Error: Connection Failed: Site is not responding. You might be in hotspot environment."
• Site to site VPN tunnels are working fine.
• In Smartview Tracker, can see the relevant connection being accepted, as expected, and on the correct port (1720).
• fw ctl zdebug drop shows no drops for this connection.
• From the gateway (vpnd.elg file):
  
  [vpnd 9015 2012542656][28 Aug 10:58:03] async_mux_data_handler: Try connection type TCPT with 0 bytes
  [vpnd 9015 2012542656][28 Aug 10:58:03] getRenegParams: lookup for key : <19.45.29.194, 49604, 123.16.23.172, 1720, 6>
  [vpnd 9015 2012542656][28 Aug 10:58:03] getRenegParams: return_value == NULL
  [vpnd 9015 2012542656][28 Aug 10:58:03] cptls_reneg_get_kernel_instance: cptls_get_reneg_hash returned NULL
  [vpnd 9015 2012542656][28 Aug 10:58:03] async_mux_data_handler: Connection is of type TCPT.
  Where 1720 is the changed visitor mode port.
  and this causes
  
  [vpnd 9015 2012542656][28 Aug 10:58:03] tcpt_server: tcpt_server_conn_handler
  [vpnd 9015 2012542656][28 Aug 10:58:03] tcpt_server: there is data of len 20
  [vpnd 9015 2012542656][28 Aug 10:58:03] tcpt: entering tcpt_check_handshake
  [vpnd 9015 2012542656][28 Aug 10:58:03] tcpt: tcpt_check_handshake wrong length, has only 20 of 1414745936
  [vpnd 9015 2012542656][28 Aug 10:58:03] tcpt_server: will close connection for tunnel id 19
  [vpnd 9015 2012542656][28 Aug 10:58:03] fwasync_do_mux_in: 36: handler returned with error
• From the client (trac.log file):
  [25 Aug 17:49:15][HotspotDetector] HotspotDetector::proxy_wrapper_cb: Sending the following data: GET /clients/abc HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)Host: IP Address
  [25 Aug 17:49:15][HotspotDetector] HotspotDetector::proxy_conn_cb: The following data has arrived: HTTP/1.0 301 Moved PermanentlyLocation: https://IP Address/clients/abc
  [25 Aug 17:49:15][HotspotDetector] HotspotDetector::proxy_conn_cb: Redirected to https://IP Address/clients/abc, server is
  [25 Aug 17:49:15][HotspotDetector] HotspotDetector::proxy_conn_cb: Redirected host is IP Address
  [25 Aug 17:49:15][talkhttps] ATalkHttps::ssl_established_cb: SSL ready
  [25 Aug 17:49:15][TalkCCC] talkccc::ReadyEv: ssl tunnel was successfully connected
  [25 Aug 17:49:15][CONFIG_MANAGER] OBSCURE_FILE return value 1, because it is Default variable. Scope: site NULL, gw NULL ,user USER
  [25 Aug 17:49:15][fwasync] fwasync_mux_in: 5164: got 0 of 65536 bytes == 65536 bytes required
  [25 Aug 17:49:15][cpwssl] cpWinSSL_fwasync_read: Could not read anything from the socket (10054)
  [25 Aug 17:49:15][] fwasync_mux_in: 5164: read: Connection Reset by peer
  

  Solution:

  This problem was fixed. The fix is included in:

  • Check Point R77.30

  Check Point recommends to always upgrade to the most recent version (upgrade Security Gateway).

  For other versions, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue.
  A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.
  For faster resolution and verification please collect CPinfo files from the Security Management and Security Gateways involved in the case.

  The real issue is the changed Visitor Mode port. Changing the port should be done ONLY if really needed. In that case, site should be created with this port, i.e. site can be established if IP address:port is used.

Scenario 4: "Failed to create the new site. Site is not responding." error when Remote Access users are trying to establish a Site with SmartLSM Security Profile gateway

Product: IPSec VPN

Version: All

Symptoms:

• "Failed to create the new site. Site is not responding." error when Remote Access users are trying to establish a Site with SmartLSM Security Profile (that belongs to a Remote Access IPsec VPN community).
  

  Cause:

  SmartLSM Profile cannot be part of a Remote Access IPsec VPN community.

  Neither Remote Access, nor Office Mode are supported by SmartLSM Profile.

  Solution:

  These features are not included in the product. If you need it, please submit a Request for Enhancement.

Scenario 5: High CPU usage of VPND process during policy installation is causing Endpoint Security VPN Clients to disconnect

Product: IPSec VPN, Endpoint Security VPN

Version: R77.20, R77.30

Symptoms:

• During policy installation the CPU usage of the VPND process is reaching 90-100%, and causing Endpoint VPN clients to disconnect due to tunnel test response failure from the Security Gateway
• In the trac.log file on the Endpoint Security VPN Client, the following log is shown:
  [PID][DATE TIME][tunnel] IkeTunnel::SchedSendTunnelTestPkt: No tunnel test reply from GW. Cannot reconnect.
• In the Trgui.log file on the Endpoint Security VPN Client, the following log is shown:
  [PID][DATE TIME][TrGUI] TrApplication::NotificationCb:Trying to connect... step failed: Site is not responding
  

  Cause:
  

  By design, the VPND process is in charge of the reply to tunnel test packets (UDP 18234). Due to the load, the VPND resources are busy, and it fails to reply to the tunnel test packets, thus causing the Client to not receive a reply for the tunnel test, and disconnect.

  Solution:

  Important: This solution is only valid when the policy package is set to Simplified mode and not Traditional mode.
  
  On Security Gateway, set the value of the kernel parameter tunnel_test_do_in_kernel to "1"

  • To check the current value of this kernel parameter:

    [Expert@HostName]# fw ctl get int tunnel_test_do_in_kernel
    
    

  • To set the desired value for this kernel parameter on-the-fly (does not survive reboot):

    [Expert@HostName]# fw ctl set int tunnel_test_do_in_kernel 1
  •  

  • To set the desired value for this kernel parameter permanently:

    Follow sk26202 - Changing the kernel global parameters for Check Point Security Gateway.

    For Gaia / SecurePlatform OS:

    1. Create the $FWDIR/boot/modules/vpnkern.conf file (if it does not already exit):

       [Expert@HostName]# touch $FWDIR/boot/modules/vpnkern.conf
       
       

    2. Edit the $FWDIR/boot/modules/vpnkern.conf file in Vi editor:

       [Expert@HostName]# vi $FWDIR/boot/modules/vpnkern.conf
       
       

    3. Add the following line (spaces are not allowed):

       tunnel_test_do_in_kernel=1
       
       
    4. Save the changes and exit from Vi editor.
       
       

    5. Check the contents of the $FWDIR/boot/modules/vpnkern.conf file:

       [Expert@HostName]# cat $FWDIR/boot/modules/vpnkern.conf
       
       
    6. Reboot the Security Gateway.
       
       

    7. Verify that the new value was set:

       [Expert@HostName]# fw ctl get int tunnel_test_do_in_kernel

   

  The change will cause the FW Kernel to process the tunnel test packets instead of VPND.

Scenario 6: "Site is not responding" message is displayed by the Endpoint Security Client while trying to create a new VPN Site

Product: Endpoint Security Client, Security Management

Version: All

Symptoms:

• "Site is not responding" is displayed by the Endpoint Security Client while trying to create a new VPN Site.
• Endpoint Client can create site with SecureClient R60, but not with Endpoint Security Client E75.30, or E80.50.
• Changing the Platform Portal in SmartDashboard is not possible. If you change the Portal port, then you are unable to close the window ("OK" button is not responding).
• trac.log file on the VPN Remote Access client shows the following during the debug:
  [TR_FLOW_STEP] TR_FLOW_STEP::TrSiteCreationStep::Notify: Failed to receive hello reply
• $FWDIR/log/vpnd.elg file on Security Gateway shows the following:
  [vpnd ...]@HostName[Date Time] sslt_reload: calling multiport_cptls_params_init
[vpnd ...]@HostName[Date Time] multiport_cptls_params_init: Called. Deleting previous ID map table
[vpnd ...]@HostName[Date Time] init_params_id_map: clearing params map and table
[vpnd ...]@HostName[Date Time] multiport_cptls_params_init: Failed to fetch the 'portals' attribute from 'myObj'
[vpnd ...]@HostName[Date Time] sslt_reload: failed to init multiport_cptls_params
  

  Cause:

  Corrupted Management Database.

  Entire MultiPortal infrastructure (portals object) was not created for any new Security Gateway.

  'portals' attribute determines configuration of each Portal in MultiPortals configuration, including certificate to present to the client.

  Solution:

  Get an export of the Security Management/DMS using Check Point Migration Tool. Rebuild the Security Management Server / Domain Management Server, and import the database using the Check Point Migration Tool.

  1. Migrate and export Security Management Server / Domain Management Server database:
     

     /<path_of_migrate_script>/migrate export /var/tmp/<File_Name>

     To export the Domain Management Server database, you have to define the environment variables necessary for database connection: mdsenv <Name_or_IP_of_Domain_Management_Server>

  2. To import:
     

     /<path_of_migrate_script>/migrate import /var/tmp/<File_Name>.tgz

     To import Domain Management Server database:

     1. Create the new Domain Management Server.
     2. Select "Import Data" and specify the location of <File_Name>.tgz during the CMA creation.

Scenario 7: VPN client failed to create site even when Visitor Mode enabled

Product: IPSec VPN

Version: All

Symptoms:

• VPN client failed to create site even when Visitor Mode is enabled. (If the firewall or network limits connections to ports 80 or 443, encrypted (IPSec) traffic between the client and the server is tunneled through a regular TCP connection. In the Remote Access page of a gateway, you can configure Visitor Mode and Hub Mode. Visitor Mode is required.)
• Trac.log:
  [ 3136 3212][5 Jan 10:27:07][String] String::String::Translate: String with id 28 has been translated to string: Site is not responding
  [ 3136 3212][5 Jan 10:27:07][TR_FLOW_STEP] TR_FLOW_STEP::TrSiteCreationStep::Notify: Failed to receive hello reply
  [ 3136 3212][5 Jan 10:27:07][auth_server] AAuthServer::Stop Stopping Authentication
  [ 3136 3212][5 Jan 10:27:07][talkhttps] ATalkHttps::CloseConn: Close SSL conn: 0 State 0x6 Reason: Termination.
• Traffic capture shows that the SSL negotiation was initiated by the client (Client HELLO) and received by the gateway. However, the gateway does not reply with 'server HELLO'.

Solution:

1. Remove the gateway from all VPN communities.
   
   
2. Remove and recreate the certificate under the IPSec VPN. (Removal of a compromised or expired certificate automatically triggers creation of a new certificate, with no intervention required by the administrator. To manually renew a certificate use the "Renew..." button on the VPN page of the Security Gateway object.)
   
   
3. Install policy to the gateway.

Scenario 8: "Site is not responding" message is displayed by the VPN Remote Access client while trying to create a new VPN Site

Product: Endpoint Security VPN

Version: All

Symptoms:

• The following error message is displayed by the VPN Remote Access client while trying to create a new VPN Site:
  

  Site creation failed Failed to create the new site Reason: Site is not responding

• trac.log file on the VPN Remote Access client shows that "RunStep 1" and "SSL negotiation" with the VPN Site failed:
  

  [talkssl] talkssl::end_handler: ending connection [talkhttps] ATalkHttps::ssl_failure_cb: SSL ended. err=3 [talkhttps] ResetRcvBuffer: data 00000000 size 0  free_buffer=1. ... ... [TR_FLOW] TR_FLOW::TrBaseFlow::FinishStep: (1) Step 1 (class TrSiteCreationStep) finished with status -1000 - TrFAIL [TR_FLOW] TR_FLOW::TrBaseFlow::FinishStep: Step failed

Scenario 9: Endpoint Security VPN fails to connect with "Site is not responding" error message

Product: Endpoint Security VPN

Version: All

Symptoms:

• Endpoint Security VPN fails to connect, and the following error appears on the client side: Site is not responding.
• Kernel debugs with 'fw + log conn drop cptls crypt' flags enabled show the following buffer limit errors:

  fw_send_kmsg: log buffer for tsid  is full. len = ; fw_send_kmsg: log_first:0, log_last:, free space: ; cptls_send_trap: fw_send_kmsg failed!; fwtls_one_side: cptls_call_hs_new failed;

• No information is listed in VPND.elg for the failed SSL negotiation and "ClientHello: start parsing" cannot be found.
  

  Cause:

  The free space in the kernel buffer for conducting the Trap is smaller than the Trap message size.

  Solution:

  Contact Check Point Support to get a Hotfix for this issue.
  A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.
  For faster resolution and verification please collect CPinfo files from the Security Management and Security Gateways involved in the case.

Scenario 10: Remote Access Client on MAC cannot connect after disabling RC4 & 3DES cipher suites

Product: Endpoint Security VPN

Version: E80.62, E80.64

OS: Mac 

Symptoms:

• Remote Access Client on Mac cannot connect after disabling RC4 and 3DES cipher suites.
• The Remote Access VPN client trac.log file shows the following log:
  "SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure"
• Client GUI is showing:
  "Site is not responding"

  Cause:

  Mac Clients only offer RC4 and 3DES during the SSL handshake. Consequently, the SSL handshake fails, as no other Cipher suites (AES128,AES256,etc..) are proposed.

  Solution:

  This problem was fixed. The fix is included in:

  • Enterprise Endpoint Security E80.71 Mac Clients

  Check Point recommends to always upgrade to the most recent version (upgrade Remote Access (VPN) / Endpoint Security Clients).

  For other versions, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix version of Endpoint Security Client for MAC.
  A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

Scenario 11: "Site is not responding" message in Remote Access client GUI when connecting to Locally Managed 600/1100/1200R appliance

Product: IPSec VPN, Small and Medium Business Appliances, Branch Office Appliances, Ruggedized Appliances

Version: R77.20, R75.20

OS: Gaia Embedded

Platform / Model: 1100, 600, 1200R  

Symptoms:

• "Site is not responding" message in Remote Access client GUI when connecting to Locally Managed 600/1100/1200R appliance.
  

  Cause:

  Remote Access port on Locally Managed 600/1100/1200R appliance is set to a port other than TCP 443.

  Solution:

  1. Login to the WebUI of the Locally Managed 600/1100/1200R appliance.
  2. Go to "Device" tab - click on "Advanced Settings".
  3. Look for the following attribute: Remote Access - Remote Access port
  4. Edit the attribute and set the port to "443"

Scenario 12: Remote Access VPN client fails to create site with Check Point 600 / 700 / 1100 appliance

Product: IPSec VPN, Small and Medium Business Appliances, Branch Office Appliances

Version: R77.20

OS: Gaia Embedded 

Platform / Model: 1100, 600, 700

Symptoms:

• Endpoint Security Remote Access VPN client fails to create a VPN site with the error "Site is not responding"
• Packet captures show the IP Address of the VPN client communicating on port 80 or port 443 instead of on the configured port intended for VPN.
  

  Cause:

  The Check Point 600 / 700 / 1100 appliance has stopped associating the VPN client port 80/443 traffic as being related to the VPN client, and has begun treating the port 80/443 traffic as though it was normal HTTP/HTTPS traffic. This may include the traffic being blocked, or port forwarded to internal servers.

  Solution:

  Restart SFWD in Expert mode

  • #sfwd_stop 
  • #sfwd_start

  OR

  Restart the VPN driver in Expert mode

  • #vpn drv off
  • #vpn drv on