Views:

Internal applications in Zero Trust Secure Access cannot share overlapping IP addresses. Learn how conflicts are detected, the types of conflicts that can occur, and how to resolve them.

Zero Trust Secure Access does not support overlapping IP addresses when configuring internal applications. Internal applications should be individually segmented networks; different internal applications should not have overlapping IP ranges. This is a system requirement to prevent routing conflicts and ensure reliable access to your applications.
Zero Trust Secure Access automatically detects conflicts by analyzing:
  • IP addresses (single IPs, ranges, or CIDR blocks)
    Domains (single FQDN, wildcard FQDN)
  • Port numbers
  • Protocols (TCP/UDP)
  • Connector group assignments
Application conflicts can cause unpredictable traffic routing, connection failures, or traffic being directed to the wrong application.
When adding an internal application, you may create one or more conflicts with existing internal applications. Zero Trust Secure Access scans your internal environment and lists the conflicting applications.

IP address format support

The system supports three IP address formats:

Format
Example
Description
Single IP
192.168.1.10
Individual IP address
Multiple IPs
192.168.1.10, 192.168.1.20
Multiple IP addresses
IP range
192.168.1.1-192.168.1.10
Range of consecutive IP addresses
CIDR block
192.168.1.0/24
Network block (covers 192.168.1.0 to 192.168.1.255)

FQDN format support

Format
Example
Description
Single FQDN
app.example.com
Individual fully qualified domain name
Multiple FQDNs
app.example.com,
app1.example.com,
app2.example.com
Multiple fully qualified domain names
Wildcard FQDN
8.example.com
Wildcard domain that represents all subdomains of example.com
FQDN conflict detection uses exact string matching. A wildcard FQDN (*.example.com) and a single FQDN (app.example.com) may both match the same domain, but the exact FQDN always takes priority over the wildcard. This is predictable behavior and is not a conflict. A wildcard FQDN (for example, *.example.com) and a single FQDN (for example, app.example.com) are treated as separate, independent entries and do not conflict with each other.

Types of application conflicts

  1. Different connector group conflicts:
    • When it happens: Applications in different connector groups with any overlapping IP addresses, regardless of ports or protocols.
    • Impact: Traffic routing becomes unpredictable—the system cannot determine which connector group should handle traffic for overlapping IPs, potentially resulting in:
      • Traffic being routed to the wrong application
      • Connection failures
  2. Same connector group conflicts:
    • When it happens: Applications in the same connector group with overlapping IP addresses and overlapping ports using the same protocol.
    • Impact: Traffic is handled based on rule prioritization—higher priority rules are processed first. This can result in:
      • Traffic being directed to unintended applications
      • Inconsistent application access depending on rule order
      • Difficulty troubleshooting connectivity issues

How to resolve conflicts

Assign unique IP addresses or non-overlapping ranges to each application.
  • For single IP addresses: Use a different, non-overlapping IP address.
  • For IP ranges: Adjust the range to exclude overlapping addresses.
  • For CIDR blocks: Use a more specific or different CIDR block that doesn't overlap.
If applications are in the same connector group, configure applications to use different ports:
  • Change TCP ports for one application to avoid overlap.
  • Change UDP ports for one application to avoid overlap.
  • Use different protocols (TCP vs. UDP) for overlapping ports.
If you intentionally configure overlapping IP addresses within the same connector group, confirm rule prioritization (Advanced, Same Connector Group Only):
  1. Navigate to Zero Trust Secure Access > Private Access > Rules.
  2. Verify the priority order of your internal application rules.
  3. Ensure that the rule prioritization aligns with your expected traffic handling.
  4. Adjust rule priorities as needed to ensure that traffic is directed to the intended applications.
  • Set specific or restrictive rules with higher priority, and broader permission rules with lower priority.
    Note
    Note
    This approach requires careful planning and ongoing maintenance.

Best practices

  • Network planning
    • Plan your IP address scheme: Before adding applications, plan your IP address allocation to minimize potential application conflicts.
    • Use unique IP addresses when possible: Where feasible, assign unique IP addresses to applications in different groups.
    • Use network segmentation: Deploy separate connectors for independent network segments (for example, separate VLANs that cannot communicate with each other).
    • Connector placement: Deploy connectors within the same VLAN/network segment as the services they will expose.
    • Connector group assignment: Assign applications to the connector group deployed in the same VLAN as the services.
    • Use logical grouping: Group related applications together where overlapping IPs might be needed but with different ports.
    • Document your IP address allocations: Maintain documentation of which IP addresses are used by which applications.
  • Configuration guidelines
    • Start with unique IPs: Always try to use unique IP addresses first.
    • Avoid unnecessary overlaps: Only use overlapping configurations when absolutely necessary.
    • Port planning: Within the same group, plan your port usage to avoid overlaps when using the same IP addresses.
    • Test thoroughly: Verify that traffic routes correctly after configuration changes.
    • Monitor regularly: Check rule priorities and traffic patterns periodically.
    • Review rule priorities: If intentionally using overlapping IP configurations in same connector group, regularly review rule priorities to ensure they align with your access requirements.