User access is governed by the 6 layer model used by Appgate SDP so there are several points on the journey where care must be taken to ensure user access works as expected.
The Client needs to be correctly installed and working. See the topic Installing Clients.
There are full details of how to set up access to (protected) hosts using in User/device access. In that section there are Client > host and Client > Client checklists that covers all the other (network related) things you may need to configure to ensure your users get access to the (protected) hosts which have been configured. By following these - you may well find you don't need the content in this section!
Connected users should appear in Usage > Active Sessions where you can examine a specific user. There are stats from the Gateway and Client which can help identify any connectivity issues. Fore example, there are measures for connection times, connection re-try counters, RTT, DNS failure counters, etc.
Before embarking on any troubleshooting you should refer to the following connectivity checklists.
Connectivity checklists
Client to Controller
This requires the profile to include a resolvable hostname so that the Client is able to send traffic to the Controller and then for the Controller to accept that traffic. Let's look at this flow:
The hostname: The Client connects to the Profile DNS name generated when the first Controller ran cz-setup. Check the Client Profile being used is the one you expect.
Port: The Client connects on the default port shown in System TLS Connection. Check the port is what you expect and that inbound traffic is allowed.
DNS resolution: Make sure that the Client connecting to the Controller can resolve the Profile DNS name to a the IP addresses of the Controllers correctly using public DNS. Check from the Client that this resolves to a valid IP address.
Sending traffic to the Controller: There are sometimes firewall issues with respect to allowing traffic from the Internet to the Controller. This can be compounded because of the use of SPA. Check the SPA settings and then make sure the appropriate ports have been opened for TCP and/or UDP. See the SPA issues section.
Wrong SPA key: If the SPA key is wrong (i.e.using one that has been deleted) then the connection will fail. Ensure the Client has been seeded with a valid SPA key using the Client profile. Check the Client logs and session details to see which SPA key is in use.
Time is wrong: SPA packets are only valid for a small time window so if the time is wrong then the connection will fail. There may be issues with the time setting on the Client (or Controller). Check the proxyd logs on the Controller for and entry like this:
[2020-03-18T16:33:21.093Z] [M 7fbe0420dd40] SPA data have expired! 25 seconds above the time-window: 3600. current time: 1584549201, SPA message's timestamp: 1584552826. Check the dashboard for any warnings relating to problems with the NTP settings on the Controller. Check the time on the Client.Allowed sources: There may be a restriction set on the IP addresses allowed to send traffic to the System TLS port. Check the Allow Sources on the System TLS Connection form and ensure the IP address presented by the Client is allowed.
CA certificate mis-matches: The most likely cause of a problem with the Certificate is if the Client misses a CA update - possibly because it has been offline for an extended period.
During the transitional phase, the next CA certificate is distributed to every client that connects. Sufficient time should be allowed to ensure all clients have connected at least once; a client will only pick up the next CA certificate at sign-in or when the claims token is renewed.
Appliances in the Collective use the same process, but this should be almost immediate. New client profiles generated after this time will include the next CA certificate.In the event that there is a certificate mis-match between the Controller and the Client then the user will see the "Invalid certificate". We recommend identifying the cause of the mis-match to ensure that the reason for the warning is not due to a possible Man-in-the-Middle (see above). If the reason for the warning is due to a known change, the warning can be taken care of by deleting the certificate from the user's machine or by uninstalling, then reinstalling the Appgate SDP Client.
NOTE
For security reasons, issuing a new Client profile will NOT resolve the issue if you just replace a unique profile.
Clients load-balance across the available Controllers by picking one IP address at random. Once the Client has established a connection with a Controller it will keep that IP address as its favorite in memory - until it is unresponsive or the Client is re-started. This behavior improves the reliability of interactions that might involve multiple connections such as in certain MFA methodologies.
Client to Gateways
This requires the Entitlement Token to include a resolvable hostname so that the Client is able to send traffic to the Gateway and then for the Gateway to accept that traffic. Even though the flow is similar, there are some subtle differences between this and the Controller flow above. The Client will indicate when it cannot connect to one or more Sites which will appear grayed out:
| Consider at the following flow:
|
Useful information sources
Appliance and Client Logs
If users are having access issues then the appliance's audit logs can be viewed using the LogServer. These might provide some insight into what the problem is. Try filtering the logs by the traffic source using distinguished_name_user; then add a filter on the traffic destination using hostname (log_source on LogServer/OpenSearch/Elasticsearch); finally show the event_type. Search for tunnel_connected and tunnel_established (shows a connection being made from the Client) and ip_access (shows the flow of traffic through the tunnel). Within ip_access, the action will tell you what is happening to the user's traffic [allow, drop, reject, block_report]. If the users traffic is being dropped then drop-reason will provide the cause of the drop. This will usually be because of No matching rule found which is just the firewall doing its job.
Even after you have followed the advice in the User/device access section, connectivity and/or DNS issues may be preventing your users from connecting to (or through) the Appgate SDP system correctly. If you do not see any traffic from the user in the audit logs, then the appliance daemon logs should help to diagnose the problem; you will need to download logs from the Gateway appliance the user is trying to connected to. Unzip the log file and in logs_by_daemon you should find cz-proxyd.log (the front door), cz-vpnd@x.log (the firewall daemon that handles the user traffic), cz-gonamed.log (the resolver) and cz-dnsfwd.log (the DNS forwarder). cz-proxyd.log will help us to check that traffic is getting to the appliance andcz-vpnd@x.log to check it is getting through the appliance. There will be several cz-vpnd@x.log files - one for each vCPU present in the Gateway.
If there is no evidence of the user in the appliance logs then you will need to download the Client logs from the Client. It is also possible to increase the log levels if required for each specific operating system. Refer to Client deployment and management.