Skip to content
English
Customer portal
Go to neeve.ai
  • There are no suggestions because the search field is empty.

Troubleshooting CIDR Overlap Conflicts between TAN and Cloud Connector in Secure Edge

This document defines the standardized procedure for diagnosing and resolving IP CIDR routing conflicts that occur when linking Remote Networks to a local Network (TAN) on Neeve Secure Edge nodes.

1. INCIDENT DIAGNOSTICS & ROOT CAUSE

When configuring a network connection on an iNode, the platform displays the following system banner:

"The connect has conflicts. User can retry the same action for more internal automatic representation network retries"

Technical Root Cause

This error triggers when the local subnet (TAN Network) and the Remote Network’s Private IP space occupy overlapping IP address blocks. Because both networks share identical or intersecting address spaces, deterministic overlay routing fails without explicit local network address translation.
  • Example Scenario:
    • Local TAN Network: 10.0.10.0/24

    • Remote Network Private Range: 10.0.11.66/23

    • Conflict Analysis: 10.0.11.66 falls directly inside the 10.0.10.0/24 local subnet boundary.

2. PREREQUISITES

  • Administrative credentials for the Neeve Secure Edge Portal (<Orgname>.secureedge.neeve.ai).
  • An unallocated, non-conflicting virtual/private subnet block designated for local address representation (e.g., 2.3.4.0/23).

3. STEP-BY-STEP REMEDIATION

Step 1: Navigate to Node Network Configuration

  1. Log into the Secure Edge Portal.
  2. Navigate to Orgs > [Target Organization] > Nodes > [Target iNode] > Networks.
  3. Locate the target local network (e.g., MGMT_10) and click on the Three Dot icon and select Edit Network.
      

Step 2: Configure Non-Overlapping Representation Subnet

  1. Scroll down to the Remote Networks configuration pane below TAN information of the page.
  2. Locate the failing remote network mapping.
  3. In the field labeled Represent Remote Network Locally as, enter the designated non-overlapping CIDR block (e.g., 2.3.4.0/23).
Parameter Configuration Value Verification
Remote Network Target Select target Remote Network Destination selected
Represent Remote Network Locally as Enter unique CIDR (e.g., 2.3.4.0/23) Valid, non-overlapping IP block

Step 3: Commit Changes and Validate

  1. Click Save to apply the configuration.
  2. Wait 60–120 seconds for the orchestrator to synchronize routing policies down to the iNode.
  3. Refresh the page and confirm the Connection Status changes from NOT AVAILABLE to CONNECTED (highlighted in green).

5. SUCCESS VERIFICATION

  • Portal Status: The Remote Networks table displays CONNECTED status.
  • Routing Table: The local iNode successfully routes outbound traffic to the mapped subnet without triggering IP conflict banners.