Overlapping Subnets, Twice-NAT, and an ERP That Redirects

For a user at 10.10.20.5 requesting 172.16.50.10:

1. Ingress and route lookup for 172.16.50.10. The firewall must own or be routed this virtual address; do not leak 172.16.50.0/24 into the HQ routing domain beyond the path to the firewall.
2. Destination NAT: 172.16.50.10 -> 10.10.50.10. On most stateful platforms DNAT is applied before the forwarding route lookup, so the post-translation destination is what gets routed. You therefore need a specific route for 10.10.50.0/24 (or the /32) pointing into the tunnel - a more specific route than the local 10.10.0.0/16 connected route, or the packet will be delivered locally instead of tunneled.
3. Security policy evaluation. Policy usually matches the original source and the translated destination (verify on your platform, this is vendor-dependent). Write the rule as source zone LAN, source 10.10.20.0/24, destination zone VPN/tunnel, destination 10.10.50.0/24, service tcp/443, and log it. A rule written against 172.16.50.10 may never match if policy is evaluated post-DNAT.
4. Source NAT after route lookup, before egress: 10.10.20.0/24 -> 172.16.20.0/24, scoped to traffic destined for the tunnel, not to all traffic from finance.
5. On B's edge, the return path must exist: a route for 172.16.20.0/24 pointing back over the tunnel (not the default route), and IPsec selectors on B's side must include 172.16.20.0/24 and 10.10.50.0/24. If B's phase-2 selectors still say 10.10.0.0/16 <-> 10.10.0.0/16, the translated packet will not match the SA.

Failure modes to check first: return traffic taking B's default route, policy matching pre- vs post-NAT addresses, and the route for the translated destination losing to a connected /16.

The application is leaking its real address into the session. After authentication the ERP returns an absolute redirect to https://10.10.50.10/reports, and pages embed the server IP in links, form actions, or JavaScript. The browser, sitting in HQ, has no route to 10.10.50.10 and the firewall has no DNAT rule for it, so the flow fails - the translation worked, the application did not.

Options, best first:

1. Split-brain DNS. Publish an A record for the ERP name resolving to 172.16.50.10 for HQ clients, and make the application's configured base/external URL use that hostname rather than an IP. This fixes redirects and embedded links at the source and keeps NAT confined to the network layer. It requires application or config access, which is usually available for an ERP.
2. Reverse proxy / application delivery in front of the ERP. Users hit a single virtual hostname; the proxy rewrites redirects and links. More moving parts, but robust when the app hard-codes IPs and cannot be reconfigured.
3. Add more DNAT rules (e.g., also map 10.10.50.10 inside HQ to the ERP). This is a trap: 10.10.50.10 collides with HQ's own /16, so you would be hijacking a real internal address and breaking whatever legitimately lives there. Do not do this without confirming 10.10.50.10 is unused in HQ.
4. Re-IP Company B or move it into a VRF. Cleanest long-term, most expensive.

Also verify the ERP is not embedding the client's source IP in a way that assumes 10.10.20.x; if it logs or ACLs on source address, the translated 172.16.20.x must be accounted for.

Alternatives, roughly in order of long-term cleanliness:

• Re-IP Company B. Painful, but it removes an entire class of problems (logs, embedded IPs, VPN selectors, future mergers). If B's ERP and server estate is small, this may be cheaper than it looks.
• VRF/VRF-lite separation on both edges with route leaking only where needed. This avoids translation entirely and keeps 10.10.0.0/16 unambiguous per VRF, but it requires hardware that supports VRFs and careful policy between them.
• A proxy/application gateway in front of the ERP, with HQ users reaching only the proxy address. This combines the translation benefit with application-level correctness.
• Keep twice-NAT, but scope it tightly: only the ERP /32 and only finance source range, with DNS fixed so no real IP ever reaches the browser.

Recommendation: if the ERP can be addressed by hostname and DNS can be split, do DNS plus a tightly scoped twice-NAT as the interim, and plan a re-IP or VRF as the durable solution. Twice-NAT is acceptable for a handful of server addresses; it becomes unmanageable when it spreads to a whole /24, because every new application becomes a translation and debugging exercise.

Non-negotiable checks before go-live: B's return route for 172.16.20.0/24, IPsec selectors on both sides matching translated prefixes, logging that records both original and translated addresses, and a documented list of every rule that references the translated ranges.