Short description
Traffic to a domain covered by an FQDN or wildcard FQDN address object is not matched by the SD-WAN forwarding rule or the access policy rule that uses the object. Sessions fall through to Default-Rule and follow the default route instead of the forwarding profile. The device does not learn the destination IPs for the domain because it does not see the client DNS answers. Configuring DNS proxy settings in the LAN routing instance, with the same DNS servers the clients use, fixes the match.
Cause
An FQDN address object is matched against the destination IP of the flow. For that to work the device has to know which IPs currently belong to the domain. It gets this from the DNS answers it handles and keeps them in the IP to Domain Cache, a per-tenant mapping of resolved IP addresses to the domain names that returned them. The cache is part of the tenant DNS settings and is enabled by default.
When clients resolve names through an internal DNS server directly and the LAN routing instance has no DNS proxy settings, the device never sees or proxies the answers. The cache has no entry for the IP, so the rule does not match and the session is handled by Default-Rule. Wildcard objects such as (.*\.|^)example\.com cannot be looked up by name at all, so they depend on this mapping completely.
The device also needs a resolver path in the right routing instance. A transport VR with a public name-server does not help traffic that resolves in the LAN VR, and a public resolver can return different IPs than the internal servers the client actually used.
Resolution
1. Under the tenant DNS proxy settings, set the Routing Instance to the LAN VR where the clients are.
2. Add as forwarders the same DNS servers the clients receive from DHCP. Do not use a public resolver here. This keeps internal names working and makes the device see the same answers as the client.
3. Leave IP to Domain Cache enabled. Cache Size and Maximum TTL are optional.
4. Create a DNS proxy profile whose resolver points to the same servers, and a redirection rule for the LAN zone that matches the domains and uses that profile as its proxy setting. Make sure the clients' DNS queries pass through the LAN VR so the proxy handles them.
5. Define the FQDN address objects so they cover the whole domain, for example (.*\.|^)example\.com and escape the dot before the top-level domain. Use them as the destination address in both the SD-WAN policy rule (with the forwarding profile) and the access policy rule. Keep these rules above Default-Rule and above any general access policy rule.
6. Verify from a client. Run nslookup for a name in the domain, then generate traffic to the returned IP and check that the session shows the FQDN rule name:
show orgs org <org> sessions extensive | select source-ip <client-ip> | select destination-ip <resolved-ip> | match-all
forward-sdwan-rule-name <your FQDN rule>
forward-egress-ckt <the WAN circuit from the forwarding profile>
Figure 3. DNS redirection rule under Default-Policy for source zone Intf-LAN1-Zone. The DNS Headers Match tab holds the domain name regexes (^|\.)bosnia\.com\.?$ and .*microsoft.*, and the Proxy Setting tab selects the profile.