There are no specific requirements for this document.
The information in this document is based on these software and hardware versions:
Cisco IOS®-XE SDWAN router running (cEdge) 16.9.3
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
In order to configure your cEdge integration with Cisco Umbrella, you perform a set of simple steps on vManage:
Step 1. Under Congifuration > Security, select Custom Options drop-down list at the top right corner, and then select Umbrella API token. Enter your Umbrella registration token, as shown in the image:
Alternatively, starting from vManage software 20.1.1 release you can specify Organization ID, Registration Key, and Secret. These parameters can be retrieved automatically if you have configured your Smart Account credentials under Administration > Settings > Smart Account Credentials.
Step 2. Under Configuration > Security, select Add Security Policy and then select a scenario that fits your use-case (e.g. custom), as shown in the image:
Step 3. As shown in the image, navigate to DNS Security, select Add DNS Security Policy and then select Create New.
The screen appears similar to the image shown here:
Step 4. This is the image of how it appears, once configured.
Step 5. Navigate to ...> View > DNS Security tab of your policy, you see a configuration similar to this image:
Keep in mind that "Local Domain Bypass List" is a list of domains for which router does not redirect DNS requests to Umbrella cloud and sends DNS request to a specific DNS server (DNS server located within the enterprise network), this is not exclusion from Umbrella security policies. In order to "whitelist" some domains from the specific category, it is recommended to configure exclusion on Umbrella configuration portal instead.
Also, you can select Preview in order to understand how the configuration looks in CLI:
Step 6. Now you must reference policy in the device template. Under Configuration > Templates, select your configuration template and reference it in the Additional Templates section as shown in the image.
Step 7. Apply the template to the device.
Verify and Troubleshoot
Use this section to confirm that your configuration works properly and troubleshoot it.
From a client sitting behind the cEdge, you can verify whether Umbrella works correctly when you browse these test sites:
Once a packet capture is taken, ensure the DNS queries are correctly redirected to the Umbrella DNS resolvers: 220.127.116.11 and 18.104.22.168 with the correct EDNS0 (Extension Mechanism for DNS) information. With SD-WAN Umbrella DNS layer inspection integration, the cEdge device includes ENDS0 options when it sends DNS queries to the Umbrella DNS resolves. These extensions include the Device ID cEdge receives from Umbrella and the Organization ID for Umbrella in order to identify the correct policy to be used when you answer the DNS query. Here is an example of the EDNS0 packet format:
Here is the option breakdown:
0x4f70656e444e53: Data ="OpenDNS"
RDATA Remote IP Address Option:
0x4f444e53: MGGIC = 'ODNS'
0x00 : Version
0x00 : Flags
0x08 : Organization ID Required
0x00225487: Organization ID
0x10 type : Remote IPv4
0x0b010103: Remote IP Address = 22.214.171.124
Check and ensure that the Device-ID is correct and the Organization ID matches the Umbrella account with the use of the Umbrella portal.
Note: With DNSCrypt enabled, DNS queries are encrypted. If the packet captures show DNScrypt packet going to the Umbrella resolver but there is no return traffic, try to disable DNSCrypt to see if that's the problem.
Verify it on vManage Dashboard
Any Cisco Umbrella directed traffic can be viewed from vManage Dashboard. It can be viewed under Monitor > Network > Umbrella DNS Re-direct. Here is the image of this page:
On a Cisco cEdge router, local domain-bypass flags sometimes don't match. This happens when there is a caching involved in the host machine/client. As an example, if local domain-bypass is configured to match and bypass www.cisco.com (.*cisco.com). The first time, the query was for www.cisco.com which also returned CDN names as CNAMEs, which were cached on the client. Subsequent queries for nslookup for www.cisco.com were to send only the queries for the CDN domain (akamaiedge).
Non-authoritative answer: www.cisco.com canonical name = www.cisco.com.akadns.net. www.cisco.com.akadns.net canonical name = wwwds.cisco.com.edgekey.net. wwwds.cisco.com.edgekey.net canonical name = wwwds.cisco.com.edgekey.net.globalredir.akadns.net. wwwds.cisco.com.edgekey.net.globalredir.akadns.net canonical name = e2867.dsca.akamaiedge.net. Name: e2867.dsca.akamaiedge.net Address: 126.96.36.199 Name: e2867.dsca.akamaiedge.net Address: 2600:1408:8400:5ab::b33 Name: e2867.dsca.akamaiedge.net Address: 2600:1408:8400:59c::b33
If local domain-bypass works properly, you will see that the counters increase for parser OpenDNS redirect. Here is an abbreviated output.
dmz2-site201-1#show platform hardware qfp active feature umbrella datapath stats Umbrella Connector Stats: Parser statistics: parser unknown pkt: 0 parser fmt error: 0 parser count nonzero: 0 parser pa error: 0 parser non query: 0 parser multiple name: 0 parser dns name err: 0 parser matched ip: 0 parser opendns redirect: 3 local domain bypass: 0 <<<<<<<<<<<
This could be the reason, as to why local domain bypass is not seen on the router. When you clear the cache on the host/client machine, you see that the queries go out correctly.
As you can see, integration with the Umbrella DNS Security cloud is very simple from cEdge side and can be done in a few minutes.