IP Pool Overlap and Silent Remote Networks During Prisma Access Onboarding
Contoso Health is onboarding Prisma Access with Panorama 11.1 and the Prisma Access plugin. Phase 1 covers 12 clinics in three countries, each behind an SD-WAN edge supporting IKEv2 and BGP, plus 3,000 mobile users. The mobile user IP pool was set to 10.10.0.0/20 after an engineer confirmed 'it is not used anywhere on the WAN.' The service connection to the Frankfurt data center was built with two IPSec tunnels and BGP; the data center advertises 10.10.8.0/22, 172.16.0.0/16 and 192.168.0.0/24 into Prisma Access. After cutover, mobile users reach the internet normally but cannot open the clinical application at 10.10.9.20. Ten clinics work; two do not. On those two, Panorama shows both tunnels up, but traffic counters never increment. Both failing clinics use the same ISP and a CPE configured by a different integrator than the other ten.
1. Why can't mobile users reach 10.10.9.20, and what would you change?
Read the worked answer
The symptom pattern - internet works, one internal subnet is unreachable - points at routing, not policy or tunnels.
The pool 10.10.0.0/20 covers 10.10.0.0–10.10.15.255. The data center's 10.10.8.0/22 is entirely inside it. Prisma Access treats the mobile user pool as locally connected, and the pool is a more specific match than anything the service connection can offer for those addresses. So traffic to 10.10.9.20 is delivered to a mobile user's tunnel or black-holed, never to the service connection. The engineer's check was the failure: 'not on the WAN' is not the same as 'not overlapping the pool I am about to create.'
Verification before changing anything: in Panorama, compare the mobile user pool against every prefix advertised over the service connection BGP sessions and against every remote network LAN. Look for the longest-prefix match for 10.10.9.20 in the Prisma Access routing table - the pool will win. Confirm the clinical app is genuinely at 10.10.9.20 and not NAT'd to that address from a different range.
Fix: move the mobile user pool out of all internal ranges, e.g. a dedicated 10.80.0.0/21, then update the internal firewalls and ACLs that permit the old pool toward the data center. Re-IP'ing the clinical server subnet is usually more disruptive; NAT'ing the DC prefix is a workaround that breaks any application that embeds IPs or does bidirectional protocols. Changing the pool is the clean option, and the pool change is a reconnection event for every mobile user, so schedule it.
2. On the two failing clinics the tunnels are up but no counters increment. What is the most likely explanation and what would you check, in order?
Read the worked answer
Tunnels up with zero counters means IKE and IPSec negotiated successfully but no interesting traffic is being placed in the tunnel in either direction. Work the two directions separately.
Outbound (clinic to Prisma Access): the CPE's routing table must select the tunnel for the destinations in question. If the site relies on BGP, confirm the session is Established and that the prefixes Prisma Access advertises (the mobile user pool and other reachable networks) are installed and not filtered by an inbound route-map or a lower administrative distance default route pointing at the local ISP. If the site uses static routes inside the tunnel, confirm the internal prefixes and 0.0.0.0/0 are actually listed - a tunnel with no traffic selectors carries nothing.
Return path: Prisma Access needs a route back to the clinic LAN via that tunnel. If the clinic's LAN is summarised differently from what was configured, or overlaps another remote network or the service connection, return traffic goes elsewhere and the session never establishes, so the counters stay flat.
Also check: security policy for the clinic source to the destination - if the first packet is denied, counters may still show bytes on the tunnel, so absent counters argue for routing rather than policy. Verify the tunnel monitor destination is reachable; a failing monitor can disable the path even with the IPSec SA up.
Because both failures share an ISP and an integrator, compare their running configuration line by line against a working site before deep-diving one.
3. How would you size and roll out the replacement mobile user pool?
Read the worked answer
Size on concurrent sessions, not headcount, then add headroom.
Sizing. Every connected mobile user consumes one address from the pool, and addresses are not reclaimed instantly when a session drops, so use peak concurrency plus a reconnect buffer and 30–50% growth. For 3,000 users with a realistic 60% simultaneous peak, a /21 (2,046 usable) is comfortable; a /22 (1,022 usable) is too tight if the whole workforce ever connects at once. Reserve a contiguous block from an internal IPAM range that is documented as never routable inside the WAN, and record it so the next engineer cannot repeat the overlap.
Validation before the change. Diff the candidate pool against every prefix advertised into Prisma Access over service connections, every remote network LAN, every data center summary route, and any partner or acquired-company ranges. Test the diff with tooling rather than eyeballing.
Rollout. This is a user-visible outage for anyone connected, so schedule it. Sequence: create the pool and confirm the configuration commits cleanly; update internal firewalls, ACLs, and any application allowlists that reference the old range, with the new range permitted before the switch so nothing breaks during cutover; change the pool in a maintenance window so clients reconnect once; monitor GlobalProtect connection failures and internal application logs for the first business day; keep the old pool reserved and unused for at least a quarter rather than reissuing it immediately.