Scenario 3: If Visitor Mode port changed, Endpoint Security VPN cannot establish site
Issue ID: CR01471620, CR01471913 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 : <126.96.36.199, 49604, 188.8.131.52, 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
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
"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).
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.
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:
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.
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.
Migrate and export Security Management Server / Domain Management Server database:
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
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'.
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.)
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
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:
While creating a VPN Site, the initial traffic sent by the Client to the VPN Gateway will be HTTPS traffic. The VPN Site creation will fail if Visitor Mode is either disabled, or not configured for HTTPS service.
Enable the Visitor Mode on TCP port 443 (HTTPS):
In SmartDashboard, open the relevant Security Gateway / Cluster object.
Expand the VPN Clients - click on "Remote Access".
In the "Visitor Mode configuration" section:
Select the "Support Visitor Mode" checkbox.
In the "Service" field, select "https".
In the "Machine's Interface" field, select "All Interfaces".
Install the network security policy on the Security Gateway / Cluster object.
Scenario 9: Endpoint Security VPN fails to connect with "Site is not responding" error message
Issue ID: CR01490627 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.
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.
Restart SFWD in Expert mode
Restart the VPN driver in Expert mode
#vpn drv off
#vpn drv on
Give us Feedback
Thanks for your feedback!
Are you sure you want to rate this stars?