Prisma Access Remote Networks<\/a> completes the other side of the service path for branch sites.<\/p>\nPrivate application DNS should be included in service-connection planning. Users can have perfect IP reachability but still fail if Prisma Access clients cannot resolve internal names or if DNS returns an address belonging to a different private region.<\/p>\n
Route aggregation can simplify service-connection tables but can also hide which specific site is unavailable. Aggregate only where the corporate network can still provide correct failover and where advertising the summary does not continue after all destinations behind it disappear.<\/p>\n
Service-connection throughput and application demand should be tested together. A connection designed for authentication and a few internal web apps may not be appropriate for backup, software distribution, or bulk data-transfer workloads without capacity review.<\/p>\n
Cloud migrations can change private-app paths. When an application moves from a data center to AWS, Azure, or Google Cloud, reassess whether the existing service connection, a new regional connection, or ZTNA Connector provides the best reachability and failure model.<\/p>\n
Return-path monitoring should be part of troubleshooting. The corporate network may learn Prisma Access prefixes but choose another WAN path for replies, creating asymmetric sessions. Route tables, BGP attributes, and firewall session state on the corporate peer are therefore part of the Prisma Access runbook.<\/p>\n
Service connections should be reviewed after network mergers or address-space changes. Overlapping prefixes and new routing domains can turn previously simple static routes into ambiguous paths that require NAT, segmentation, or more specific routing.<\/p>\n
Service connection design should consider segmentation inside the private environment. One tunnel landing in a shared core can reach many networks unless downstream routing and firewall policy constrain it. Use internal segmentation so Prisma Access users receive only the private-app reachability required.<\/p>\n
BGP communities or route policy can help control which prefixes are advertised through each connection in more complex environments. Broad redistribution should be avoided when it creates accidental reachability to infrastructure networks or management planes.<\/p>\n
Application teams should test private services from the actual user path, not only from the service-connection peer. DNS, user policy, Prisma Access routing, service connection, internal firewall, and application authentication all need to succeed together.<\/p>\n
Maintenance coordination should include both active and backup peers. Rotating certificates, changing IKE profiles, or moving BGP policy on only one side can leave a backup connection broken until the primary fails months later.<\/p>\n
A service connection is mature when private-app routes, security scope, redundancy, ownership, and monitoring are explicit enough that operators can diagnose reachability without treating the Prisma Access cloud as a black box.<\/p>\n
Service connections can become shared dependencies for many applications, so configuration changes need a larger blast-radius review than one site tunnel. Route-map, crypto-profile, or peer changes should identify all private services depending on that connection.<\/p>\n
Monitoring should distinguish active\/backup state from degraded performance. A service connection can remain active while packet loss or latency makes private applications slow. Application experience or synthetic monitoring can expose degradation before full tunnel failure.<\/p>\n
Security logging should show which users and applications traverse the service connection so capacity and policy decisions are based on actual usage rather than an abstract private-prefix list.<\/p>\n
Document the disaster-recovery path for the applications behind each connection, including whether DNS, routing, and server capacity move with the backup network path.<\/p>\n
Service-connection planning should include dependency on corporate firewalls, routers, cloud gateways, and routing protocols beyond Prisma Access. A green cloud-side tunnel can still terminate into a failed downstream core or route reflector.<\/p>\n
Private application ownership should be linked to prefixes and service connections so incident teams know which business services are affected when one connection degrades.<\/p>\n
Use synthetic tests for representative private applications from mobile users and remote networks so end-to-end reachability is continuously validated rather than inferred from tunnel state.<\/p>\n
After major route or service-connection changes, verify least privilege as well as connectivity. A change that restores one application by advertising a broad aggregate can unintentionally expose unrelated private networks.<\/p>\n
Service-connection runbooks should identify the exact prefixes, peer device, tunnel names, routing method, active\/backup locations, and application tests associated with each connection. This turns an abstract cloud object into an operable network service. When one connection fails, responders can immediately see which private services depend on it and what alternate path is expected.<\/p>\n
Private-app connectivity should be tested from every important user path after service-connection changes, including mobile users and representative remote networks. That end-to-end validation should confirm DNS, route selection, policy, return path, application authentication, and backup behavior rather than stopping when the IPSec tunnel reports healthy.<\/p>\n
Keep the private-application path explicit, resilient, and continuously testable.<\/p>\n
Keep private routing evidence current.<\/p>\n
Private application access should be validated from both ends: the service connection must advertise and reach the intended networks, while the application side must return traffic through the expected path. Asymmetry and overlapping routes are much easier to diagnose when that contract is explicit.<\/p>\n","protected":false},"excerpt":{"rendered":"
Prisma Access service connections connect the Prisma Access cloud to private applications and corporate resources. Palo Alto Networks also calls a service connection a Corporate Access Node (CAN). Mobile users and remote-network users can reach private resources through these connections, and service connections can also support communication paths between user populations and sites depending on […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19845","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t