Forum Discussion
Priority between CIDR and FQDN rules in Microsoft Entra Private Access (GSA)
Hello
Question about prioritization between CIDR and FQDN rules in Microsoft Entra Private Access (GSA) Question: Hello everyone, I have a question about how rules are prioritized in Microsoft Entra Private Access (Global Secure Access). In my environment, I configured the following: I created an Enterprise Application using a broad CIDR range (10.10.0.0/16) to represent the entire data center. Within the same environment, I created other Enterprise Applications using specific FQDNs ( app01.company.local, app02.company.local) with specific ports. All rules are in the same Forwarding Profile. I noticed that in the GSA client rules tab there is a “Priority” field, and apparently the rules are evaluated from top to bottom. My question is: When there is an overlap between a broad CIDR rule and a more specific FQDN-based rule, which one takes precedence? Is there some internal technical criterion (DNS resolution first, longest prefix match,), or is the evaluation purely based on the order displayed? Is there a risk that the CIDR rule will capture traffic before the FQDN rule and impact granular access control? I want to make sure my architecture is correct before expanding its use to production. Could someone clarify the actual technical behavior of this prioritization?
1 Reply
Hello
Hello,
Excellent question.
Based on the current product behavior and the configuration model exposed in the Forwarding Profile Priority field, rule evaluation follows the configured priority order. The client processes traffic according to this priority model.
The client performs both DNS interception and IP-based traffic forwarding. However, the official documentation does not define a formal architectural precedence between FQDN-based rules and CIDR-based rules when overlaps exist.
In scenarios where there is overlap between:
A broad CIDR range, for example 10.10.0.0/16
A specific FQDN that resolves to an IP within that same range
The recommended architectural approach is to rely on explicit priority configuration rather than implicit rule-type assumptions.
Best practice:
Assign higher priority to specific FQDN-based rules
Use broad CIDR ranges as fallback rules
Avoid relying on assumed internal evaluation order between rule types
From an architectural standpoint, explicitly controlling priority ensures predictable behavior and prevents unintended traffic capture in overlapping scenarios
