Network Requirements for Secure Access

Best Practices

You can use either IPv4 or IPv6 DNS addresses as your primary or secondary DNS server. You must use both numbers and not the same IP address twice. If your router requires a third or fourth DNS server setting, you can use 208.67.220.222 and 208.67.222.220 or 2620:119:35::35 and 2620:119:53::53 as the third and fourth entry respectively.

DNS64 (RFC 6147) is meant for single-stack IPv6 networks. This is to help with IPv4 to IPv6 transitions. If you are using Secure Access DNS on devices without IPv4 access, these resolvers will synthesize records that can reach those destinations through a NAT64 gateway using the Well-Known Prefix. See details: https://datatracker.ietf.org/doc/html/rfc6147

North America (USA-only) DNS resolvers guarantee only that DNS queries are resolved by a USA-based Secure Access data center. Block pages use global Anycast and may go to any data center, including one located outside of the USA.

Several systems allow you to specify multiple DNS servers. We recommend that you only use the Cisco Secure Access servers and do not include any other DNS servers.

Cisco Secure Client

The Cisco Secure Client Umbrella Roaming Security module uses standard DNS ports 53/UDP and 53/TCP to communicate with Secure Access. If you explicitly block access to third-party DNS servers on your corporate or home network, you must allow certain CIDRs on the ports and protocols in your firewall.

In circumstances where third-party DNS servers are blocked, the Cisco Secure Client Umbrella Roaming Security module transitions to a state where it temporarily uses the DHCP-delegated DNS servers for resolution.

Cisco Secure Client and External DNS Resolution

In normal circumstances, the Cisco Secure Client Umbrella Roaming Security module functions only on networks where external DNS resolution exists. The Cisco Secure Client Umbrella Roaming Security module can not function successfully if DNS connectivity is broken or blocked on the local network.

For the Cisco Secure Client Umbrella Roaming Security module to enable DNS-layer protection, you must allow the following external DNS names to resolve by the local DNS server. You must allow recursive DNS queries to the following domains on the local DNS server:

• disthost.umbrella.com
• api.opendns.com
• crl3.digicert.com
• crl4.digicert.com
• ocsp.digicert.com
• debug.opendns.com— This domain can receive a response to a TXT record query.
  The Cisco DNS resolvers must answer this DNS request.
  Note: NXDOMAIN is accepted, however, timeouts may delay or prevent Secure Access DNS-layer security protection on the network interface where this domain query times out.

The Cisco Secure Client Umbrella Roaming Security module supports the encryption of DNS queries sent to Secure Access on port 443 over TCP or UDP. If you would like to ensure encryption is enabled, and use a default deny ruleset in your firewall, allow the following CIDRs on the ports and protocols in your firewall.

Note: The Cisco Secure Client Umbrella Roaming Security module automatically encrypts DNS queries when it senses that 443/UDP is open.

We recommend that you allow all traffic on ports 80 and 443 over TCP for the Secure Access DNS Block Page services.

We recommend that you allow all traffic on port 443 over TCP for the Secure Access Client Configuration services.

The Cisco Secure Client Umbrella Roaming Security module uses HTTP (80/TCP) and HTTPS (443/TCP) to communicate with Secure Access for the following uses:

• Initial registration of the Cisco Secure Client Umbrella Roaming Security module upon installation.
• Checking for new versions of the Cisco Secure Client Umbrella Roaming Security module.
• Reporting the status of Cisco Secure Client Umbrella Roaming Security module to Secure Access.
• Checking for new internal domains.

Windows Only

If you utilize an HTTP proxy that is configured at the user-level (normally using GPO), make sure the SYSTEM user is also configured to use the proxy.

The sync.hydra.opendns.com domain resolves to multiple IP addresses, all within the 146.112.63.0/24 IP range. We recommend that you add this entire range. The IP addresses for sync.hydra.opendns.com are Anycast and may change.

Ensure that the operating systems of the devices in the organization support at a minimum TLS 1.2. The TLS 1.0 and TLS 1.1 protocols contain security vulnerabilities and do not support modern cryptographic algorithms.

TLS 1.2 Support in Windows

We recommend that you disable support for SSL, TLS 1.0, and TLS 1.1 in your Windows operating system. You can disable TLS 1.0 and TLS 1.1 in the Windows Registry. For more information, see Configuring Schannel protocols in the Windows Registry.

The latest version of the Cisco Secure Client Umbrella Roaming Security module uses TLS 1.2. Ensure that you have a compatible version of .NET installed with your Windows operating system. Native TLS 1.2 support requires .NET framework 4.6.2+. Prior versions of .NET require registry edits (4.x) or registry edits and manual hot fix patches (3.5).

TLS 1.2 Support in macOS

The Cisco Secure Client Umbrella Roaming Security module for macOS uses TLS 1.2.

Asia

Australia

Europe

North America

South America

The Cisco Secure Client Zero uses HTTPS to communicate with the Secure Web Gateway proxy services.

Microsoft 365

Microsoft 365 traffic is sent directly to the Secure Access secure web gateway (SWG) for these deployment methods:

• VPN and Network Tunnels established on a network device
• Cisco Secure Client with the VPN and Umbrella Roaming Security modules
• Secure Access PAC file

To stop network traffic from connecting to the Secure Access SWG, add External Domain entries manually or route the traffic direct to the internet from your connecting devices.

If your organization's firewall rules prevent any third-party applications, allow the following IP addresses:

• 52.73.52.135
• 52.71.142.118
• 52.40.204.69
• 52.35.119.173
• 52.27.150.153

You must deploy either a Network Tunnel or PAC file in your organization to connect user devices to the Secure Access Secure Web Gateway (SWG).

We recommend that you allow all traffic on port 443 over TCP for the Secure Access SAML Gateway services domains.

Unless noted, send id.sse.cisco.com requests to the SWG, not directly to the internet.

Active Directory Federation Service SAML Identity Provider

• If your organization integrates with SAML Active Directory Federation Service (AD FS) identity provider (IdP), we recommend that you bypass web traffic to *.id.sse.cisco.com on the Secure Access secure web gateway (SWG).

To enable connections to your SAML identity providers (IdPs), allow the following domains in your firewalls on ports 80 and 443 over TCP. Ensure that traffic to your SAML IdP is bypassed on the SWG to avoid an authentication loop. For more information, see Manage Domains.

Azure AD SAML Identity Provider

To exclude Azure AD SAML Identity Provider domains from Secure Access SSL Decryption, add the following domain names to your list of bypassed domains.

We recommend that you allow all traffic on ports 80 over TCP for the Secure Access SAML Gateway Client Certificate Revocation services domains.

The Cisco Secure Client VPN module uses HTTPS to communicate with the Secure Access VPN client head end services. We recommend that you allow all traffic on ports 443 over TCP or UDP, and ports 500/4500 over IPsec (UDP) for the Secure Access VPN domains.

Note: The Cisco Secure Client VPN module automatically uses TLS 443/UDP when it senses that 443/UDP is open.

Remote access virtual private network (VPN) head end services.

The Cisco Secure Client Zero VPN module uses HTTPS to communicate with the Secure Access VPN client certificate revocation services. We recommend that you allow all traffic on ports 80 over TCP for the Secure Access VPN domains.

The Cisco Secure Client Zero Trust module uses HTTPS to communicate with the Secure Access Zero Trust device enrollment services. We recommend that you allow all traffic on ports 80 and 443 over TCP for the Secure Access Zero Trust domains.

The Cisco Secure Client Zero Trust module uses HTTPS to communicate with the client-based Secure Access Zero Trust proxy services. We recommend that you allow all traffic on ports 443 for the defined protocols on the Secure Access Zero Trust domains.

Known Network Restrictions for Zero Trust Clients

Cisco Secure Access Zero Trust supports any TCP or UDP client applications that do not rely on ICMP or DNS SRV discovery, with the following restrictions:

• The client application must initiate all TCP connections or UDP flows.
• Any protocol requiring a unique client IP address at the server, for example SMBv1, is not supported.

The Cisco Secure Client Zero Trust module uses HTTPS to communicate with the client-based Secure Access Zero Trust client certificate revocation services. We recommend that you allow all traffic on ports 80 and 443 over TCP for the Secure Access Zero Trust Client Certificate Revocation services domains.

Unmanaged devices with Secure Access Zero Trust enabled use HTTPS to communicate with the Secure Access Zero Trust proxy services for unmanaged devices. We recommend that you allow all traffic on ports 80 and 443 over TCP for the Secure Access Zero Trust proxy services domains.

The following IP addresses are reserved for use by Secure Access services for Resource Connectors and must not be used elsewhere on your network.