Ardent Group: Integrating an Acquisition with Colliding RFC1918 Space

Why this cannot be solved with policy alone

Prisma Access forwards on destination prefix. If two service connections both claim 10.10.0.0/16, the routing table cannot tell which data centre a packet is destined for, and any policy decision made afterwards is guesswork. Source NAT does not help: the collision is in the destination, not the source. So the choice is between making the destinations unique, or never letting both prefixes be reachable from the same population at the same time.

Option 1 - re-IP Kestrel's data centre. Correct long term, ruled out by the board this year. Keep it on the roadmap; a partial re-IP of the most-conflicting subnets is cheaper than a full one and worth re-testing.

Option 2 - destination NAT at the Kestrel edge. The Kestrel data-centre edge translates 10.10.0.0/16 into a unique, unused range such as 172.20.0.0/16 as seen from Prisma Access, and reverses it on the way back. This is the standard answer when re-IP is not possible: it is confined to one pair of devices, is reversible, and leaves Kestrel's servers untouched. Risks are application-embedded IPs, hard-coded references and return-path asymmetry - enumerate them with an application inventory before cutover, and prefer ranges that no Kestrel application embeds in payloads.

Option 3 - strict segmentation. Keep Kestrel traffic local: Kestrel's remote networks reach Kestrel's data centre over its own path and never advertise 10.10.0.0/16 into the Prisma Access routing domain, while Ardent sites continue to advertise theirs. This works only if cross-company access to the colliding prefix is not required, which is rarely true after an acquisition.

Recommendation

Option 2 for the 90 days, delivered as two translated ranges if possible to reduce blast radius, with Option 1 as the committed follow-on. Validate with an application dependency workshop before any cutover, and pilot with two Kestrel sites.

Option A - dedicated public IPs for mobile users

Palo Alto can allocate dedicated egress addresses for mobile-user traffic. Advantages: works for every SaaS that allowlists, no hairpin through Kestrel's data centre, no dependency on internal routing. Disadvantages: the addresses are associated per compute location, so the vendor would have to accept a set rather than exactly three, and mobile users who re-home on failover may present a different one. Consumption of dedicated addresses is finite and commercially priced. This is the right answer for a cloud SaaS vendor and the wrong answer for a vendor contract written around three specific IPs.

Option B - service connection with source NAT to Kestrel-owned public addresses

Route ERP traffic over the service connection to the Kestrel data centre and apply source NAT to the three existing public addresses at that edge. Advantages: exactly the IPs in the contract, so no renegotiation; the vendor's firewall rules stay intact; the source is stable across user failover because it is anchored at the data centre. Disadvantages: all ERP traffic from 2,000 mobile users now depends on service-connection bandwidth and tunnel health, and NAT must be configured on both edge devices so a single device failure does not break the contract. Size the SC for that load and confirm return traffic is symmetric.

Recommendation

Option B for the ERP specifically, implemented as a narrow security rule keyed to the ERP destinations with NAT applied on each of the two edge devices, and Option A for general SaaS that needs an allowlist. Do not mix the two on the same flow. Document the dependency: the ERP path now has a service-connection-shaped single point of failure that the vendor contract does not care about, so it needs its own availability test before go-live.

Sequencing

1. Inventory first. Enumerate Kestrel's applications, their IP dependencies and any embedded addresses before touching translation. This is the step most often skipped and most often responsible for a failed cutover.
2. Identity before traffic. Connect Kestrel's directory to Cloud Identity Engine and map its groups. Overlapping domain suffixes mean you must distinguish users by group or attribute, not by suffix - otherwise an Ardent rule written for 'employees' silently grants Kestrel staff the same access, and vice versa.
3. Non-production first. Onboard one Kestrel site and a pilot user group, with the translated destinations in place, and verify application behaviour end to end.
4. Wave the sites. Two or three sites at a time, each with a rollback path: the site keeps its legacy path until the remote-network tunnel is verified, then the legacy path is removed in a maintenance window.
5. Mobile users last. Finish the site waves before re-homing 2,000 users, so the traffic baseline is already understood.

Policy controls

• No shared 'Ardent plus Kestrel' allow rules. Build Kestrel rules scoped to Kestrel source groups and destinations, and keep an explicit inter-company rule so cross-access is a visible, approved decision rather than a side effect of a wildcard.
• Keep the default deny at the bottom and check it is genuinely logged; a quiet bottom rule during a merger hides exactly the flows you need to see.
• Apply decryption, URL filtering, anti-spyware and vulnerability profiles from day one. Deferring security profiles 'until integration settles' is how a merger becomes an incident.
• Use temporary rules with ticket references and expiry dates, and review the whole Kestrel rule set at 30 and 90 days.

Verification

Compare pre- and post-change traffic logs for each application, run ADEM checks from pilot endpoints, and confirm that the overlapping destinations resolve to the intended data centre from each user population - that single test catches most translation errors.