When multiple Remote Networks share an identical, overlapping IP address subnet, Prisma Access has no way to uniquely and deterministically route traffic destined to a specific store, to a specific mobile user, or to a private application located behind one particular site, because the destination or source subnet alone can no longer disambiguate which physical location a packet needs to reach — every store looks identical on the wire. The Overlapping Subnets checkbox exists to acknowledge and accommodate this reality, but the trade-off is that Prisma Access can only reliably support the traffic flow where uniqueness of the store ' s internal subnet is not required for correct forwarding: outbound internet-bound traffic, which is source-NATed at egress and does not depend on the branch ' s internal addressing being globally unique within the Prisma Access backbone. This is why option B, internet-bound traffic, is the flow that remains fully supported. Flows to private applications (option A) and to other remote networks (option C) require the backbone to route based on the branch ' s actual internal subnet to reach specific internal destinations or to allow other sites to reach that store directly, which becomes ambiguous and unsupported once the subnet is duplicated across multiple onboarded locations. Mobile user access to an overlapping-subnet branch (option D) suffers from the same ambiguity, since a mobile user ' s traffic destined to that internal subnet cannot be deterministically routed to the correct physical store.