Acquisition Merge with Overlapping Private IP Ranges
After acquiring Contoso, Northwind has two identity providers: Okta for 900 parent users and Entra ID for 300 acquired users. Both networks use 10.0.0.0/16; the acquired ERP is at 10.10.5.20, and a parent file server is at 10.10.8.10. Cloudflare Tunnel exposes both private networks to WARP. A Gateway network policy currently allows 10.0.0.0/8 for all users to avoid tickets. Access applications exist only for the ERP hostname. Acquired users report intermittent access to the parent file server; parent users sometimes reach the ERP without an Access login. The merger deadline is 45 days. The team wants one WARP profile, least privilege, and a clean audit story, and asks whether to re-IP, use virtual networks, or rely on Access alone.
1. How would you resolve the overlapping 10.0.0.0/16 ranges without a disruptive re-IP project?
Read the worked answer
Do not start with re-IP; it is slow and risky before the deadline. Use Cloudflare WARP-to-Tunnel virtual networks to separate the overlapping ranges, assigning the parent and acquired networks to different virtual networks and mapping them through WARP profiles. If virtual networks are unavailable in the current configuration, NAT one side to a unique range as a bridge. Re-IP later as cleanup. Do not rely on Access alone: Access protects the ERP hostname, but the parent file server may be reached by raw IP and bypass the application gate. Document the address mapping and test with a canary user from each side before broad rollout.
2. The current Gateway network policy allows 10.0.0.0/8 for everyone. What policy and Access changes would you make, and in what order?
Read the worked answer
Replace the broad allow with identity-scoped Gateway network policies: parent users to the parent file server, acquired users to the ERP, and both only to specific /32 or /24 destinations. Put Access in front of the ERP and any HTTP application, and use Gateway L4 policy plus device posture for raw IP file shares. Ensure acquired users cannot reach the parent file server unless approved. Order matters: first map virtual networks and test routing, then add narrow allow rules, then remove the 10.0.0.0/8 allow, then enforce Access. Log and alert on denies. Test with one user per group and one canary destination before the 45-day deadline.
3. How would you integrate Okta and Entra ID for least-privilege access across both user populations?
Read the worked answer
Integrate both IdPs and map their groups explicitly to Access groups. Do not trust email domain alone. Require MFA at each IdP, set session durations, and define which IdP owns which users and how offboarding propagates. For cross-company collaboration, create a small Access group containing the approved users from both IdPs, and scope it to the specific application. Keep Gateway network policies aligned to the same groups so a user who loses an IdP group also loses network access. Test SSO and group mapping with a canary user from each side, and document the mapping so audit can trace an allow decision to a named group and IdP.