Prisma Access can make a capable network engineer feel like they missed an entire branch of networking.

MU-SPN.

RN-SPN.

SC-CAN.

Infrastructure subnet.

Service connection.

Compute location.

Colo-Connect.

Then someone starts talking about BGP, bandwidth, licensing, private applications, and cloud regions.

It is easy to assume the architecture itself must be incredibly complicated.

A better place to start is much simpler:

Where is the traffic coming from?

Where is it inspected?

Where does it need to go?

How does Prisma Access know how to get there?

Once those questions make sense, most of the Palo Alto terminology has somewhere to fit.

Prisma Access provides cloud-delivered network security infrastructure for mobile users, remote sites, and connectivity toward private company resources.

Instead of a company building all of that security infrastructure itself in every location, Palo Alto operates the Prisma Access infrastructure globally.

That’s the product-level explanation.

For a network engineer, the more useful explanation is:

Traffic enters Prisma Access.

Prisma Access inspects it.

Routing determines where it needs to go next.

The traffic is sent toward the destination.

That destination might be the Internet.

It might be a private application.

It might be a resource in a data center.

It might be somewhere else in the company network.

The product has a lot of pieces because it has to do this at scale.

But you do not need to learn every piece before understanding the basic traffic flow.

First Question: Who or What’s Connecting?

Start with the source.

Is the traffic coming from a person working remotely?

Or from an office or branch network?

That distinction gives you two common Prisma Access terms.

MU means mobile user.

An MU-SPN is a Mobile User Security Processing Node.

In plain English:

It is part of the Prisma Access infrastructure that processes traffic associated with mobile users.

Think laptops running GlobalProtect and connecting into Prisma Access from wherever the user happens to be.

RN means remote network.

An RN-SPN is a Remote Network Security Processing Node.

Think branch offices or other remote sites sending their traffic into Prisma Access.

Palo Alto describes MU-SPNs and RN-SPNs as parts of the security infrastructure it deploys and manages for mobile-user and remote-network traffic.

The acronyms are easier once you attach them to a source:

Mobile user → MU-SPN

Remote site → RN-SPN

Don’t memorize the acronym first.

Once the traffic reaches Prisma Access, security processing has to happen somewhere.

That is what the SPN terminology is pointing toward.

You don’t need to picture an appliance sitting in your data center.

Prisma Access provides the cloud security infrastructure.

That’s an important shift if most of your firewall experience comes from physical or virtual firewalls your company owns and manages directly.

You still have familiar networking questions:

What traffic is allowed?

What application is being used?

Where s the user going?

What route is selected?

What happens on the return path?

The security infrastructure moved.

The need to understand the traffic did not.

This is where Prisma Access starts feeling much more like normal networking.

Say a mobile user opens a public website.

The destination is on the Internet.

Now say that same user needs an internal application hosted in the company data center.

Different destination.

Prisma Access needs a path toward that private network.

That leads to another piece of the architecture:

the service connection.

A service connection—also called a Corporate Access Node, or CAN—provides connectivity that can let mobile users and remote-network users reach private applications and resources.

A common design uses an IPSec tunnel between Prisma Access and an IPSec-capable device at the company's headquarters or data center.

So instead of memorizing:

SC-CAN = Service Connection Corporate Access Node

think:

This is part of how Prisma Access gets toward private company resources.

A connection existing doesn’t automatically mean Prisma Access knows where every private network lives.

It still needs routing information.

For service connections, private networks can be provided through static routes, BGP, or a combination depending on the deployment and configuration.

This is where a lot of Prisma Access architecture stops being mysterious.

Suppose the company application lives on:

10.20.30.0/24

Prisma Access needs to know:

10.20.30.0/24 is reachable through this part of the network.

The corporate side also needs the information required to send return traffic back toward the Prisma Access users.

Now you’re back in familiar territory:

That’s networking.

The Palo Alto product determines how those pieces are implemented so the underlying questions aren’t new.

This is another term that sounds more complicated than its job.

Prisma Access uses an infrastructure subnet as part of the network backbone that allows its service infrastructure, mobile users, remote networks, service connections, and connected corporate networks to communicate. Palo Alto specifically warns that this address space needs to be planned carefully because it becomes part of that infrastructure.

Mental model:

This is the address space Prisma Access uses for its own internal network infrastructure.

It’s not just another user subnet.

And it shouldn’t be picked casually.

If the range overlaps with something your company already uses, you have created an addressing problem before the interesting part of the deployment even starts.

That is why the useful design question is not:

“What do we enter in the infrastructure subnet box?”

It is:

“What address space can we dedicate to Prisma Access without creating conflicts with the rest of the network?”

Colo-Connect is another good example of terminology getting ahead of the requirement.

A normal service connection and Colo-Connect are not simply two names for the same thing.

A standard service connection can provide private-resource connectivity using an IPSec-based design.

Colo-Connect is aimed at higher-bandwidth private connectivity and uses Google Cloud Interconnect technology, including Dedicated or Partner Interconnect options. Palo Alto currently positions it for higher-bandwidth private application connectivity in hybrid and colocation designs.

Don’t start with:

“Do we need Colo-Connect?”

Start with:

Then decide which connectivity model fits the requirement.

Imagine the requirement is:

Remote employees need to reach applications in the company data center through Prisma Access.

Instead of trying to keep every acronym in your head, break the discussion down.

Mobile users.

The mobile-user side of Prisma Access.

A private application in the data center.

Through the private connectivity design, such as a service connection.

Routing.

The corporate network needs the appropriate return path.

The actual user needs to reach the application successfully.

When a Prisma Access conversation starts moving quickly, come back to these:

Who is connecting?

Mobile user or remote site?

Where is the traffic being inspected?

Which part of the Prisma Access security infrastructure handles it?

Where does the traffic need to go?

Internet or private resource?

What route points toward that destination?

Static route? BGP-learned route? Something else in the design?

If it’s private, what provides the connectivity?

Service connection, Colo-Connect, or another supported private-access method?

What about the return path?

Can the destination network get back to the source?

How will we prove it works?

Not just that a tunnel is up.

Not just that a route appears.

Can the user reach the actual application?

Prisma Access is not simple in the sense that there is nothing to learn.

There’s plenty to learn.

The mistake is trying to learn all of it at the same time.

Start with:

Source → Security → Route → Destination

Then add the Palo Alto terminology around that model.

MU-SPN has a place.

RN-SPN has a place.

SC-CAN has a place.

The infrastructure subnet has a job.

Service connections have a job.

Colo-Connect has a specific use case.

You don’t need to hold the entire Prisma Access architecture in your head before you can contribute to the conversation.

Pick one traffic flow.

Trace it.

Then ask what each piece is doing to move, inspect, or route that traffic.

Learn what the network is doing first. Then learn what Palo Alto calls the pieces.

Until next time.

— NEP