Troubleshoot Secure Access Roaming Module "Cloud Service Unavailable" or "Unprotected" Status

Introduction

This document describes a way to investigate root cause of status "Cloud Service Unavailable" or "Unprotected" in Roaming Module of Secure Client.

Problem

When a user launches Roaming Module of Secure Client and expects to use DNS and/or Web protection, erroneous states can be seen in Secure Client User Interface:

Cloud Service Unavailable for Web Protection Status

Unprotected for DNS Protection Status

The reason behind those errors is that Roaming Module cannot contact its cloud services due to network connectivity issues.

If this problem was not seen on affected client PC in the past, it means that most probably network that PC is connected to is restricted and does not meet requirements outlined in SSE Documentation

DNS Protection Status is Unprotected

When you see Unprotected DNS state, then most probably Roaming Module does not have upstream connectivity to OpenDNS servers (208.67.222.222 and 208.67.220.220).
You would see the log in cscumbrellaplugin.txt file, which is part of DART bundle.

2024-08-27 03:07:43 [8880] [DEBUG] < 12> Dns Protection IPv4 State Machine: checking reachability of primary OpenDNS resolver candidates using port 443 (candidates are 208.67.222.222, 208.67.220.220)
2024-08-27 03:07:43 [8880] [DEBUG] < 12> Dns Protection IPv4 State Machine: probing for OpenDNS resolvers at addresses 208.67.222.222, 208.67.220.220, port 443
2024-08-27 03:07:43 [8880] [DEBUG] < 13> Dns Protection IPv6 State Machine: rejected all candidate resolvers for port 443
2024-08-27 03:07:48 [8880] [DEBUG] < 12> Dns Protection IPv4 State Machine: checking reachability of primary OpenDNS resolver candidates using port 53 (candidates are 208.67.222.222, 208.67.220.220)
2024-08-27 03:07:48 [8880] [DEBUG] < 12> Dns Protection IPv4 State Machine: probing for OpenDNS resolvers at addresses 208.67.222.222, 208.67.220.220, port 53
2024-08-27 03:07:53 [8880] [DEBUG] < 12> Dns Protection IPv4 State Machine: rejected all candidate resolvers for port 53

In order to double check and confirm connectivity issues you can collect wireshark capture on egress physical interface of the PC (WiFi or Ethernet), and use the display filter to look only for traffic destined to OpenDNS resolvers:

ip.addr == 208.67.222.222 or ip.addr == 208.67.220.220

As you see in the snippet from Wireshark, it is clear that client keeps retransmitting DNS TXT queries destined to 208.67.222.222 and 208.67.220.220 on UDP port 443 and 53, but does not receive any response.

There can be multiple reasons behind such behavior, most probably perimeter firewall device is blocking egress DNS traffic to OpenDNS servers, or only allowing traffic to a specific DNS servers.

Web Protection Status is Cloud Service Unavailable

When you see Service Unavailable Web protection state, then most probably Roaming Module does not have upstream connectivity to Secure Web Gateway servers.

If PC does not have IP connectivity to SWG servers, you would see the log in Umbrella.txt file, which is part of DART bundle.

Date : 08/27/2024
Time : 06:41:22
Type : Warning
Source : csc_swgagent

Description : WARN | Thread 27cc | TCP handshake to SWG Proxy URL was not successful. Since fail open policy set, try connection in bypass mode [FailOpen : 1, CMode : 1 TMode : 0]. 

In order to investigate further, collect packet capture to prove that PC does not have connectivity with SWG server.
Issue the command in terminal to get SWG IP address:

C:\Users\admin>nslookup swg-url-proxy-https-sse.sigproxy.qq.opendns.com
Server: ad.lab.local
Address: 192.168.0.65

Non-authoritative answer:
Name: k8s-sigproxy-sigproxy-c8f482b42a-ddf1929ae349b3e5.elb.eu-west-2.amazonaws.com
Address: 18.135.112.200
Aliases: swg-url-proxy-https-sse.sigproxy.qq.opendns.com
swg-proxy_eu-west-2_1_1n.sigproxy.aws.umbrella.com

In order to double check and confirm connectivity issues, you can collect wireshark capture on egress physical interface of the PC (WiFi or Ethernet), and use display filter to look only for traffic destined to SWG server (use IP address obtained in previous step)

ip.addr == 18.135.112.200

As you see in the snippet from Wireshark, it is clear that client keeps retransmitting TCP SYN packets destined to 18.135.112.200, but receives TCP RST as response.

In this specific lab scenario, the perimeter firewall was blocking traffic to SWG IP address.
In real-life scenario, you can see only TCP SYN retransmissions, not TCP RST.

Tip: If client cannot reach SWG servers, it by default enter fail open state where Web traffic is leaving through Direct Internet Access (WiFi or Ethernet). Web protection is not applied in fail open mode.

Solution

In order to quickly identify that underlying network is causing issues, user can connect to any other open network (hotstop, home WiFi) which does not have any perimeter firewall.

To fix described connection error, please make sure that the PC has unrestricted upstream connectivity as outlined in SSE Documentation.

DNS Protection Status issues:

• 208.67.222.222 TCP/UDP port 53
• 208.67.220.220 TCP/UDP port 53

For Web Protection Status issues make sure that traffic to Ingress IP Addresses is allowed on perimeter firewall - SSE Documentation

Specific range of Ingress IP addresses depends on your location.

Related Information

• Secure Access User Guide
• How to collect DART bundle from Cisco Secure Client
• Technical Support & Documentation - Cisco Systems