Check Point Mobile Access Software Blade is the safe and easy solution to connect to corporate applications over the Internet with your Smartphone, tablet or PC. The solution provides enterprise-grade remote access via both Layer-3 VPN and SSL VPN, allowing you simple, safe and secure connectivity to your email, calendar, contacts and corporate applications.
Realm based authentication with support for multi-factor authentication
Provides authorization based on:
User groups (Internal, LDAP/AD, Radius)
Resource’s Protection Level
Endpoint Security scan results
Authentication strength
Feature Overview: Audit and Platforms
Provides auditing:
Administrator's actions are logged
Traffic events are logged
Supports different end-user platforms: Windows, Linux, Mac OS X, Android, iOS
Feature Overview: Security
Provides a unique security solution:
Gateway
FW, IPS, AV
'Stateful Inspection' on tunneled traffic
Web Intelligence
Endpoint Security On Demand (ESOD)
Compliance Scanner (formerly known as ICS)
Secure Workspace (formerly known as ISW)
Update service (IPS, AV, ESOD)
Feature Overview: Reverse Proxy
This feature adds support for Reverse Proxy for standard Web Applications on your servers, using Mobile Access. Reverse Proxy users browse to an address (URL) that is resolved to the Mobile Access Gateway's IP address. Then, the Mobile Access Gateway passes the request to an internal server, according to the Reverse Proxy rules.
Administrator controls the security level (HTTP or HTTPS) of connections between users and resources.
Feature Overview: Unified Policy (since R80.10)
Mobile Access, in the R80.10 release, supports both Legacy Policy (as in R77.30 and below) and Unified Policy.
By default, the Mobile Access blade is set to Legacy Policy. The Administrator can switch to Unified Policy (requires policy install).
For more detailed Troubleshooting information, refer to the Troubleshooting section of this document.
When you include Mobile Access in the Unified Policy, you configure all rules related to the Mobile Access portal, Capsule Workspace, and on-demand clients in the Access Control Policy.
In the Access Control Rule Base, you can configure rules that:
Apply to all Mobile Access gateways, or some of them.
Now you can apply to one or more Mobile Access clients, such as the Mobile Access portal or Capsule Workspace.
Mobile Access features such as Protection Levels, Secure Workspace, and Endpoint Compliance also apply.
Note that when you use the Unified Access Policy, some Mobile Access features and settings are still configured in the 'SmartDashboard > Mobile Access tab'.
For more extensive information about this feature, refer to the "Mobile Access and the Unified Access Policy" section in the Mobile Access R80.10 Administration Guide.
Capsule Workspace App Wrapping leverages Capsule Workspace and extends it to offer 3rd party apps in a security container that provides multi security layers and access for both iOS and Android apps.
In the simplest Mobile Access deployment, one Mobile Access enabled Security Gateway inspects all traffic, including all Mobile Access traffic. IPS and Anti-Virus can be active on all traffic as well. The Security Gateway can be on the network perimeter.
This is the recommended deployment. It is also the least expensive and easiest to configure, as it only requires one gateway machine for easy and secure remote access.
Mobile Access Blade as a Reverse HTTP Proxy
A reverse proxy appears to the client just like an ordinary web server. No special configuration on the client is necessary.
Link Translation: Flow
Link Translation is the process by which Mobile Access converts internal URLs to public URLs that are valid on the Internet, so that internal resources become accessible via any Internet-connected browser.
Mobile Access supports different methods of Link Translation:
URL Translation (UT) the original link translation method, maintained for backward compatibility.
Hostname Translation (HT) provides dramatically improved performance for Mobile Access gateways and end users, resulting in faster Web access and fewer connectivity issues. It gives access a wider range of websites, with enhanced support for HTML pages, JavaScript, VBscript, and Web applications (such as the SAP Portal).
Path Translation (PT) is the newest Link Translation method. It offers the same connectivity level as Hostname Translation, without the more difficult and costly configurations. (Hostname Translation requires a more expensive server certificate.)
File Shares: Protocols Involved
A file share defines a collection of files, made available across the network by means of a protocol, such as SMB for Windows, that enables actions on files, including opening, reading, writing and deleting files across the network.
Web Mail Support: Protocols Involved
Mobile Access supports built-in Web mail. Web mail provides a simple way for remote users, through a web browser interface, to access their email. Employees can access their email from any computer that has access to the Internet, such as a computer in a library, or Internet cafe. There is no need to install special email or remote access software. This is helpful for employees who work outside the office on a regular basis.
Mobile Access provides a Web front-end for any email application that uses the IMAP protocol for incoming mail, and SMTP for outgoing mail.
E-mail stored on the IMAP server is manipulated through the browser interface without having to transfer the messages back and forth. Users can connect to several mail servers depending on their authorization.
Authentication: Single Sign-On (SSO)
Native applications that you access with SSL Network Extender can use Single Sign-On (SSO) functionality. With SSO support, users connect automatically to native applications that require login. The native application gets the Mobile Access portal login username and password parameters from the internal server. This feature is supported in R77.20 and higher. It requires a SSL Network Extender client upgrade.
Mobile Access, in the R80.10 release, supports both Legacy Policy (as in R77.30 and below and Unified Policy).
By default, the Mobile Access blade is set to Legacy Policy. The Administrator can switch to Unified Policy (requires policy install).
Notes regarding Unified Policy as the Policy Source:
A single Gateway cannot be set to both Unified and Legacy. (see screen capture above)
You cannot migrate Legacy Policy (i.e. Mobile Access rules) to the Unified Policy.
The Administrator needs to create the rules manually.
The Administrator must enable Mobile Access on each Policy layer, in the unified Policy, that contains Mobile Access rules (applications). (see screen capture below)
The same Mobile Access applications that were used in Legacy Policy can and should be used in Unified Policy.
For information on the use of Access Roles and client type in the Access Role, refer to the “Access Roles for Remote Access” section in the Mobile Access R80.10 Administration Guide.
The Mobile Access Authorization log, in Unified Policy, always contains both Mobile Access and Firewall blades. As a result:
The log's "blade" icon will be a Multiple blade icon. Example:
When you cick on the log line, you wil display the full Unified Policy log. Example:
Filtering using 'blade:"Mobile Access"', will match such logs if SmartLog indexing is enabled. (In Standalone installation, SmartLog indexing is disabled, by default).
Troubleshooting Topic: Cannot access Mobile Access portal
Mobile Access portal does not respond
First check out for any recent configuration changes that may have caused the MAB portal not to respond.
Look up SmartView Tracker log for any related logs.
Check for core dumps at : /var/log/dump/usermode/
Check under the 'Portal settings' tab that the gateway has the expected certificate configured.
If you get the wrong certificate, check in other portals, as we only use one certificate on a given IP address. Note that "All portals on the same IP address use the same certificate" (see sk94965).
Try to figure out whether SSL handshake was established (look for the certificate in the address bar, or use Wireshark and look for client_hello and server_hello).
In case of an SSL problem, you need to collect kernel debug: # fw ctl zdebug -m fw + drop crypt cptls
Check VPND debugs, as described in the section "Debug Procedures" - "Debugging the Gateway side" - "vpnd process"
Check MPDAEMON the 'matching component' that is also responsible for launching HTTPD (its parent process) - see sk87920.
Check that the SSLVPN Portal is running: # mpclient status sslvpn
Enable HTTPD debugs, as described in the section "Debug Procedures" - "Debugging the Gateway side" - "httpd process", and check: $CVPNDIR/log/httpd.log
Mistake in realm configuration: if there is a problem, cvpnd is not starting and MAB portal is not accessible, log line in $CVPNDIR/log/cvpnd.elg (Failed to init cvpnauth). Check $FWDIR/database/authentication_objects.C (which contains the realms configuration).
Additional realm was configured but is not shown to the users in the portal (no drop down list/drop down without the new realm). Check that the correct realm is in $CVPNDIR/conf/cvpnd.C - attribute portalRealmNames
The Pre-R80.10 gateway, uses Single Authentication settings only. (Old style UX)
The R80.10 gateway, by default, uses Single Authentication settings. (New style UX)
In addition, you can (and should) use the Multiple Authentication Option configuration.
User Look and feel in the Mobile Access Portal, configured with Multiple Login options.
R80.10 gateway can prevent Single Authentication clients (i.e. clients not listed in sk111583), from accessing the gateway.
R80.10 gateway can prevent authentication done using Single Authentication configuration.
Proxy configuration for DynamicID authentication is now defined in the Gateway's proxy configuration, instead of the Mobile Access Proxy configuration.
For more information on Multiple Login Options for R80.x Gateways, refer to the “Multiple Login Options for R80.x Gateways” section in the Mobile Access R80.10 Administration Guide.
User record lookup
Looking in wrong directory (symptom might be latency):
Might be indicated by log in $CVPNDIR/log/cvpnd.elg / capture of traffic.
Look in realm configuration.
Make sure that in Security Gateway properties > Other > User directory everything is configured properly.
Looking with wrong identifier (certificate with DN that contain also the e-mail address, certificate with wrong (old) directory path, directory expects different value like e-mail instead of username):
User will get "Wrong user name or password" / "Certificate authentication failed"
Admin should know which identifier his directory is expecting to get.
Most of the problems might be solved by realm configuration, sometimes you also need to configure the directory settings (wide impact) - (both with GuiDbEdit)
Example 1 - Microsoft_AD > Common > UserLoginAttr
Example 2 - Directory Settings > UserLoginAttr / lookup_type
User group mapping
Symptom: user is not allowed to a specific resource (application link is not shown in the portal) / user get "User is not authorized" after login.
You could see the groups of the user in $CVPNDIR/log/cvpnd.elg (during Login only) = au_fetchuser_callback user obj:
Keep in mind, if user was added/removed to/from a group after login, it will take affect only after next login (Known limitation).
CRL is not available (might happen 24 hours after the problem started) - should be stated in SmartView Tracker Log.
Internal CA: make sure the Management is available
External CA: make sure there is no firewall in the middle that blocks the traffic.
Certificate is expired - should be stated in SmartView Tracker Log. If not, it is in $CVPNDIR/log/cvpnd.elg
Using the "wrong" info from the certificate. Refer to the "Troubleshooting Topic: Cannot access Mobile Access portal" - section "Authentication fails due to:" - subsection "User record lookup".
Kerberos is an authentication method that is used to identify the user in front of the internal servers.
Kerberos creates a ticket which it uses to authenticate the user instead of using credentials.
Inside the ticket, the user name, allowed servers and amount of time for which the ticket is active are listed.
In order to create a Kerberos ticket, Mobile Access Blade uses the portal credentials (user name and password).THis is done in order to create the ticket and to authenticate to the internal server.
When a user logs in to Mobile Access Blade without user name and password, e.g. with a certificate. Kerberos Constrained Delegation (KCD) is used. KCD allows you to create tickets for other users based on a delegate ticket which was created from credentials that are allowed.
See if there is a Kerberos Constrained Delegation failure entry in SmartView Tracker or SmartLog. Under Mobile Access logs and run cvpnrestart on the Security Gateway through SSH.
KCD flow consist of 2 main steps:
Creating a Kerberos ticket for the delegate user (that was configured previously).
In order to see that the ticket was created successfully, see that $CVPNDIR/tmp/krbcc/krbkt_* and $CVPNDIR/tmp/krbcc/krbtgt_* exist (krbkt_* and krbtgt_* are the prefixes of the files.)
Run the command on the Security Gateway "klist $CVPNDIR/tmp/krbcc/krbtgt_*", where krbtgt_* is the prefix of the file and see that the ticket contains information such as date and user name.
If the ticket does not contain information, please check your AD and SmartDashboard configuration again.
Creating a ticket for the end user.
In order to see that the ticket was created successfully, see that $CVPNDIR/tmp/krbcc/krbcc_* exists (krbcc_* is the prefix of the file.)
Run the command on the Security Gateway "klist $CVPNDIR/tmp/krbcc/krbcc_*", where krbcc_* is the prefix of the file and see that the ticket contains information such as date and user name.
If the ticket does not contain information, please check your AD and SmartDashboard configuration again.
Kerberos relies on symmetric key cryptography and requires a trusted third party, and may use public-key cryptography during certain phases of authentication. Kerberos uses UDP port 88 by default. Please validate to open UDP port 88 between the gateway and the relevant machines.
In case of other problems, please attach the following logs after reproduction of the login problem:
Mobile Access httpd log - $CVPNDIR/log/httpd.log*
Mobile Access cvpnd log - $CVPNDIR/log/cvpnd.elg*
KCD logs - $CVPNDIR/log/KCDUtil.elg after enabling them
To enable KCD logs:
Edit the $CVPNDIR/conf/cvpnd_internal_settings.C on the Security Gateway
Change the value of EnableKCDDebug from "false" to "true"
Run cvpnrestart
Known Limitations:
The Kerberos Constrained Delegation user must be configured on the Account Unit object in SmartDashboard - no UI is available.
You need to understand the 4 parts of the Client-to-Server communication:
Request from Client to Security Gateway
Request from Security Gateway to Server
Response from Server to Security Gateway
Response from Security Gateway to Client
Check Client-to-Server communication without Mobile Access Blade - is it working?
Use Fiddler in order to see the original requests and responses. (Important: Use Fiddler only after cleaning the browser cache.)
You can use the following tools to see the requests from client to Security Gateway and from Security Gateway to Server, in addition to the response from Server to Security Gateway and gateway to client:
Client to Security Gateway requests & responses: Fiddler
Server to Security Gateway requests & responses: trace_log
Check Browser JavaScript errors. Pressing F12 key usually opens a console to see JavaScript errors, which can help identify the LT problems.
Various LT problems:
Wrong translation of the strings:
When find wrong LT value, then we need to search which rule causes the problem.
After finding the rule, understand why we had a match on the original text.
Example: url == link is translated as url = CP_PT_TRANS(= link)
Missing translation: the HTML code was not translated by the Security Gateway, which results in bad links
Compare the behavior of the server with Mobile Access Blade, and without Mobile Access Blade using Fiddler.
When troubleshooting PT issues, you need to understand PT Substitute.features.conf file.
You need to understand how to use and read Apache regular expressions.
When troubleshooting LT issues, it is very useful to enable LT logs in Mobile Access Blade:
LT logs appear in the $CVPNDIR/log/httpd.log file after setting the value:
User cannot see a link that he should be allowed to see.
User receives an "Unauthorized" message when accessing an app.
How to know:
Configuration issue: Check that one of this user's user groups is mapped in the Mobile Access Blade policy to that specific application.
Check in SmartView Tracker under Mobile Access logs for this user's unauthorized log. The message there might help. (For example: DNS Resolving issue, Certificate problem).
Possible solutions:
Check Configuration: make sure the user is mapped to the application (check if the user was moved to other user groups.)
An app that should have SSO is prompting for credentials (SSO not working).
How to know:
Check if the problematic app host name, is also the host name in another web app.
Check if this problem is reproducing for all users or for a specific user.
So, if there are 2 or more apps configured on the same host name with the same directories, there might be a mix-up between the apps, since we identify the app according to its authorized locations (host + directories), so the other configurations may be mixed (SSO, LT):
Possible solutions:
If you need both apps, try not to have them both for the same users.
If you need 2 applications with the same exact "Authorized Locations". you should unite them to one app.
If you want 2 different configurations, try different directories for each app so no mix can happen, for example: One with "Directories" : "/example1", and the other web app with : "/example2".
Browser compatibility (vendor, version, user-agent, mobile device)
Symptoms:
Broken web app on one browser (usually IE is more problematic). For example: either received Blank page for web app, or web app not displayed correctly.
How to know:
Clear browser Cache!
Try to reproduce the issue on other browsers.
See if this web app works fine on the problematic browser without Mobile Access Blade, to check if this is a Mobile Access Blade issue or not.
Possible solutions:
If this is an IE issue only:
Try commenting out the following lines in $CVPNDIR/conf/Web_inside.location.conf file:
After commenting out, run cvpnd_admin policy command.
Try to reproduce.
If this is a mobile computability issue, try using this web app on any mobile browser and see computability.
Clear browser cache and send Mobile Access logs to Check Point Support (with Fiddler also).
Large file uploads or POST requests ('httpd' and PHP configuration)
Symptoms:
POST requests are failing (timeout / error 500).
Usually this happens in file uploads flow.
How to know:
Test Fiddler without Mobile Access Blade, and compare it with trace log with Mobile Access Blade, and file the problematic upload request (in both).
Check if there is informative info on the response (example: missing cookie, not completed).
Is the Problematic POST request received from the browser with the header "Transfer-Encoding" "chunked" ? What is the "Content-length"?
NOTE: If it is "chunked" with "content-length 0", there was a bug recently discovered, where this type of request causes libcurl to not set an upload size. Servers may react differently to this.
Example for "chunked" issue: without Mobile Access Blade - the request is chunked, with Mobile Access Blade request is not chunked (The Security Gateway changed it). Maybe the internal server cannot handle such requests/ did not expect it.
Possible solutions:
In the file $CVPNDIR/conf/includes/Web_inside.location.conf file, try to increase the value of CvpnMaxPostStoredSize (default is "10,000") - maybe try "50,000".
See if request without Mobile Access Blade is "chunked" or not.
If this is a timeout issue: maybe there is a mismatch between "KeepAliveTimeout" on the Security Gateway and the server. If you know what the "keep alive" of the server is, try increasing the one on the Security Gateway to match it.
Clear browser cache and send Mobile Access Logs to Check Point Support (with Fiddler also).
SSO does not work
Symptoms:
SSO is not working.
How to know:
If Web Form, is it automatic detect? if "Yes", try configuring a specific criterion, if you know what is the exact request:
Notes:
Citrix Storefront WF SSO is still not supported automatically - you will need to configure it with the following parameters:
Sign in URL: https:///Citrix/StoreWeb/ExplicitAuth/Login
Post URL: https:///Citrix/StoreWeb/ExplicitAuth/LoginAttempt
Post data: username=$USERNAME&password=$PASSWORD&loginBtn=Log+On&StateContext
If regular SSO, make sure the internal server auth protocol is standard, and that the server is returning HTTP error "401".
In libcurl trace logs, the authentication request to the internal should return HTTP error "401" with the header "WWW-Authenticate", check if this exists or we did not even get here (for example HTTP error "403" - not allowed to get this page).
If HTTP error "401" is received from the server, then check that we sent a request again with the header "Authentication" to the internal server. This header should include the credentials somehow (or Kerberos ticket), then check the response. If "200 OK": this means SSO worked, but something else ruined the SSO (see example below). For example: Security Gateway did not pass the "200 OK" to the browser and failed the request.
If Security Gateway did not get "200 OK": Check if credentials forwarded are invalid.
Check that the authentication method the Security Gateway is trying is also supported by the server:
The server returns on the header "WWW-Authentication" all the supported methods. Check that the Security Gateway is trying one that is supported on the header "Authentication".
Options: the server changed its supported authentication methods, but the Security Gateway is still trying to use a cached auth method.
SSO success means we get a cookie from the server and "200 OK". If yes, that means something after that caused the problem.
Which SSO is configured:
If invalid credentials are used: does it reproduce for all users or specific ones. If for one user, try to clear the credentials in the portal:
If this is a mismatch issue of the authentication method with the server: See sk98215.
Citrix is configured as Citrix Services: adding a new Citrix application.
Secure Ticketing authority (STA) servers in Citrix application are the configuration of matching between STA server and ID.
When Mobile Access Blade is working side by side with Citrix Access Gateway, the Secure Ticketing Authority should be configured in ordered that Mobile Access Blade will convert the Ticket ID from the ICA file to the Ticketing server.
An exception or daemon crash ("Error while processing request")
Symptoms:
Change was made in a configuration file in $CVPNDIR/conf/ directory
Core dump files for cvpnd or httpd appear in /var/log/dump/usermode/ directory
How to know
This kind of issue is usually harder to track, without looking in the code, but if this a configuration issue that caused the httpd to crash with a core dump file - open the file $CVPNDIR/log/httpd.startlog and in the last line you should see a log describing why it failed.
Core dump files require code investigations. But try to understand what is causing the crash? Can you reproduce the core? If yes, what is the exact flow (example: web application link causes the crash / adding favorites / ...)?
Possible solutions
Turn on Mobile Access Blade logs, and try to reproduce the crash with core dump file and logs - send the logs and the core dump files to Check Point Support.
If the core dump files are not generated / reproduced, send them with information on how it happened (if you know).
Troubleshooting Topic: Application Wrapping
To check whether the feature is enabled:
Connect to the command line on the Mobile Access Gateway.
Login to Expert mode.
Backup the current $CVPNDIR/conf/includes/Web_inside.location.conf file: [Expert@HostName:0]# cp -v $CVPNDIR/conf/includes/Web_inside.location.conf{,_ORIGINAL}
Edit the current $CVPNDIR/conf/includes/Web_inside.location.conf file: [Expert@HostName:0]# vi $CVPNDIR/conf/includes/Web_inside.location.conf
To enable the feature, configure: CvpnClientSideLinkTrans on
To disable the feature, configure: CvpnClientSideLinkTrans off
Save the changes and exit from the Vi editor.
Restart the Mobile Access software blade: [Expert@HostName:0]# cvpnstop ; cvpnstart
To check whether the application is recognized by the gateway as a wrapped application:
Enable trace log collection for the relevant user (instructions under "Debugging the Gateway side" in the Debug Procedures section).
In the apache_request files, search for the X-CPCVPN-ClientSideTrans header and verify that its value is App.
Server may be configured as host name or DNS. If DNS entry, may not be resolved (DNS server not configured). (Mounting issue)
Trace Log error > Mobile Access Category 'File Shares' : unresolved server name
Debug, when we do not know what is causing the permissions/authorization issues:
Check the $CVPNDIR/log/cvpnd.elg file - look for ERROR. We can see from the log if the problem is configuration, or a problem in the File Shares server.
Advanced:
Try to run 'Mount' locally in the shell and it will give us a clue where the problem is.
Error: "Access denied. The destination of your request has not been configured, or you do not have authorization to access it. (403) - Check configuration of your host:"
Trace Log error > Mobile Access Category 'File Shares' : The requested destination is not configured for this user's group in the Mobile Access policy.
Error: "Access denied. The destination of your request has not been configured, or you do not have authorization to access it. (403)"
Configuration: make sure that the path is not limited, that the path you are trying to reach was included. Error will show that you do not have permissions.
There could be an error in the link, and it is not matching the configured path.
DFS links do not work (File Access issue)
Admin might have configured DFS links that we are not supporting.
Error will be "server unreachable/no permissions". The server admin should know if these are DFS links.
Use case: User want to report general problem or give feedback. The logs will automatically reach R&D.
How to perform:
Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. About screen is displayed.
In the "About" screen, tap "Report a Problem".
Add feedback and send.
Send logs by e-mail:
Use case: User want to send logs to specific person by e-mail.
How to perform:
Go to iOS setting > Capsule Workspace > turn on "Send As Mail".
Go back to the application.
Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. "About" screen is displayed.
In the "About" screen, tap "Report a Problem". Native mail compose screen will open with logs zip file as attachment.
Send this mail to the desired e-mail.
Send HAR (traffic) logs (iOS):
Use case: The user would like to send traffic logs. Usually instructed by Check Point Support / RnD to do so.
How to perform:
Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. About screen is displayed.
Double-tap on the logo.
Determine the log capacity and the amount of time to capture the traffic values, as instructed by Check Point Support / RnD.
Caution: Only turn on "log sensitive data" if certain. It will then contain full traffic body. Be aware that the log may contain e-mail data, passwords, and more.
Tap on "Start".
When you finish reproducing your issue, as instructed, proceed to "Send logs by e-mail" (above).
Cannot reach site:
How to identify (iOS):
Pop up: Connection error, Network error during site creation.
Log: Look for "Site creation error of type" string.
How to resolve:
Check for typo in site address
Check Internet connectivity using Safari to any web site - fix if needed.
Check connectivity using Safari to wanted site - fix if needed.
Wireless / 3G and DNS issues:
Check Internet connectivity.
Check using native browser to Mobile Access Web Portal.
Wrong QR-code type:
How to identify:
Pop up:
Enrollment Failed
Failed to establish trust ... Reject ID: ...
Log: Look for "Entered activation key is not valid" string.
If trace log was enabled, then make sure to delete all content from $CVPNDIR/log/trace_log/ directory
IMPORTANT: Do not delete the directory itself!
Reload the Mobile Access policy:
[Expert@HostName:0]# cvpnd_admin policy
Note:
If you see that the debug is not being collected in the $CVPNDIR/log/httpd.log file, the run: cvpnrestart (This will restart the cvpnd and httpd processes - all existing Mobile Access web connections will be disconnected, but the Mobile Access sessions will remain open)
To stop the debug:
Disable the trace log collection in R75.40 and higher:
[Expert@HostName:0]# cvpnd_admin debug off
Restore the original $CVPNDIR/conf/httpd.conf file:
If you see that the debug is still being collected, then run cvpnrestart (This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected)
LoadModule status_module /opt/CPshrd-R<version>/web/Apache/2.2.0/modules/libmod_status.so ExtendedStatus On <Location /Login/server-status> SetHandler server-status </Location>
Examples:
For R77.X: /opt/CPshrd-R77/web/...
For R76: /opt/CPshrd-R76/web/...
For R75.40VS: /opt/CPshrd-R75.40VS/web/...
For R75.4x: /opt/CPshrd-R75.40/web/...
For R75.20 / R75.30: /opt/CPshrd-R75.20/web/...
For R75 / R75.10: /opt/CPshrd-R75/web/...
For R71.X: /opt/CPshrd-R71/web/...
For R70.X: /opt/CPshrd-R70/web/...
Save the changes and exit from Vi editor.
Reload the Mobile Access policy:
[Expert@HostName:0]# cvpnd_admin policy
Notes:
This might disconnect the current users
If you see that the debug is not being collected, then run cvpnrestart (This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected)
To view the status page, browse to:
On Mobile Access gateways:
https://<IP_of_MAB_GW>/sslvpn/Login/server-status
On Connectra gateways:
https://<IP_of_MAB_GW>/Login/server-status
Known Issue ID 00922556: Experiencing a gradual slowdown in Mobile Access Blade performance, and on the status page there are many processes with "G" status that cannot be actually found running on the Mobile Access Gateway.
The cvpn process uses the cvpnproc process for asynchronous jobs that may take a long time to complete. This process is responsible for sending SMS, e-mails and access to files via file share.
Currently, there is no easy way to collect the cvpnproc debugs. The only option is to start it in debug mode.
[Expert@HostName:0]# ps aux | grep proc [Expert@HostName:0]# kill -KILL <PID_of_procserver>
Start the Mobile Access services:
[Expert@HostName:0]# cvpnstart
Debugging the Gateway side - pinger process
The Pinger process was introduced in R75.40 and its main purpose is to reduce the number of httpd processes performing ActiveSync. By default, all ActiveSync traffic in Mobile Access Blade is done via the Pinger process.
If you suspect the problem is in Pinger process, then try to disable it. Then, the regular httpd processes will handle the ActiveSync. Follow these steps:
Debugging the user side - Problems with Secure Workspace (SWS)
To enable the SWS debug:
Go to Start menu - Run... - paste the following command - click on OK: "%WINDIR%\system32\rundll32.exe" sysdm.cpl,EditEnvironmentVariables
Alternatively:
Desktop - right-click on the "My Computer" icon - click on "Properties"
Windows Vista/7/2012: In the left pane, click on "Advanced system settings".
Go to "Advanced" tab.
At the bottom, click on "Environment Variables..." button.
In the "System variables" section, add a new variable with the name ISWLOG and the desired value:
Logged category
Value
Success
0 (most verbose)
Info
1
Warning
2
Error
3
Important
4
Dump
5 (least verbose)
Verify that the new environment variable was applied - run this command in Windows Command Prompt:
C:\> set | findstr ISWLOG
Output should show "ISWLOG=<integer_value>"
Reproduce the relevant issue.
The debug output file(s) will appear in %Temp%\IswTmp\Logs\ directory.
To turn off debug output:
Remove the variable "ISWLOG" from the list of "System variables".
Verify that the environment variable was removed - run this command in Windows Command Prompt:
C:\> set | findstr ISWLOG
Output should be empty
Debugging the user side - Problems with Native Applications
In order to fully debug an SNX session, debug output must be simultaneously enabled on the SNX client and Mobile Access Gateway before the issue is reproduced. The following are the instructions for enabled the debug for each side of the connection.
On the Mobile Access Gateway
Start the debug of vpnd process as described in the "Debugging the Gateway side - vpnd process" section above.
Go to Start menu - Run... - paste the following command - click on OK: "%WINDIR%\system32\rundll32.exe" sysdm.cpl,EditEnvironmentVariables
Alternatively:
Desktop - right-click on the "My Computer" icon - click on "Properties"
Windows Vista/7/2012: In the left pane, click on "Advanced system settings".
Go to "Advanced" tab.
At the bottom, click on "Environment Variables..." button.
In the "System variables" section, add a new variable with the name TDERROR_ALL_ALL and the value 5.
Verify that the new environment variable was applied - run this command in Windows Command Prompt:
C:\> set | findstr TDERROR_ALL_ALL
Output should show "TDERROR_ALL_ALL=5"
Two debug output files will be created:
%TEMP%\SNXAC\stap.txt
%TEMP%\SNXAC\STALog.txt
SNX client in Network Mode on Linux OS
SNX Network Mode may be run from the command line in debug mode:
snx -s <server> -u <user_name> -g
The debug output file will be created in $HOMEDIR/snx.elg
SNX client in Network Mode on Mac OS X
In Terminal, create a file in the user's home directory named .snxrc:
touch ~/.snxrc
Add the line "debug yes" to the ~/.snxrc file:
echo 'debug yes' > ~/.snxrc cat ~/.snxrc
The debug output file will be created in $HOMEDIR/snx.elg
SNX client in Application Mode on Linux OS and Mac OS X
Create a file named /tmp/stadebug:
touch /tmp/stadebug
Two debug output files will be created:
/tmp/stalog.txt
/tmp/SNXAC/stap.elg (always created, regardless of the /tmp/stadebug file)
Thin-client deployment mechanism (C-Shell)
C-Shell has a JavaScript component and a binary component that is either ActiveX or Java, depending on the client machine's environment. In order to debug each of the components, follow the instructions below:
In order to debug the JavaScript component
This is needed if ActivX or Java component is not launched correctly by the portal.
Backup the current $CVPNDIR/phpincs/SNXController.php file:
Create it (the type is "REG_SZ"), if needed, and set its value to %temp%\CShell\SNXComponentsShell.log.
In order to debug the Java component
Java is debugged according to the JVM installed on the client machine. Usually, the JVM is either Microsoft's or Oracle's.
For Microsoft's JVM: From Internet Explorer's main menu, go to Tools > Options > Advanced > Microsoft VM, and check all the Java debugging related checkboxes.
For Oracle's JVM: Go to Start menu > Settings > Control Panel > Java > Advanced, and check all debugging related checkboxes (especially in Java Console and Debugging).
Example:
