Being dragged into a ZScaler migration, can anyone answer a few questions about ZPA?

VPN
1

Hello, forgive me but our senior admin went on unexpected leave and I’m being dragged into a complex ZScaler migration.

Part of the migration is replacing our ISP managed client VPN with ZPA. Our VPN is currently allowed to access everything on the LANs at our various locations. We have a non-negotiable cutover date a few months away lol, and I need to ask some questions to make sure a few core apps don’t stop working for our remote staff (50% of the company)

My understanding is that with ZPA, anything on a LAN we might need to access needs to be registered as an application, is that correct? Even something like a SMB network share over the domain, we would need to set the IPs and ports.

Or is it possible to allow something like a wildcard, like anything on a local domain as long as the ports are specified?

We have 20 locations, and our IT staff might need to remotely connect via browser to a printer, VOIP phone, camera system, SSL to a switch, etc… which may only be connected to the App connector via a site to site tunnel, will this still be possible? I know a jump box would be ideal for this, but we’re also in the process of migrating away from our on prem domain to Intune and that’s a larger question that is out of my hands.

Last question is on the certificates. We don’t have a PKI in place, and half our devices are fully Intune. I can’t see a PKI getting in place before the migration, so how exactly do certs work, does each client device need a unique cert, or do they just need the cert from ZScaler put in their trusted CA?

2

My 2 cents as a Zscaler Employee…

Yes, you can create a wildcard to start with, usually this is the best thing to do, as most organizations dont have total control over their network.
Wildcards help you see what the users are actually using, and after some while you can leverage AI/ML to get suggested polices to tighten down access.

You can connect to devices etc using this method, but they have to be defined in DNS in some way, as the AppConnectors are doing local-dns lookups where they are running.
If not, you can specifiy IPs, but then a lot of the “magic” of ZPA is gone.

Certificates for applications is handled directly between the user and the app, ZPA is only setting up the connections. For other certificates, that is provided by Zscaler if you want, but you can bring your own Certificate if needed.

3

You are correct in that all internal applications will need to be defined in a ZPA App Segment as a FQDN, IP address, subnet in CIDR notation or a wildcard domain. Each segment will also need specific TCP and UDP ports defined. After the segments are defined they will need to be mapped yo specific. ZPA Access Policies to allow/deny connections based on specific criteria (if required).

More info on this can be found here:

Legacy VoIP solutions should be bypassed from ZPA since they usually require devices to actually be on the internal network to work properly.

As for your PKI question. ZPA does not do any in-line SSL/TLS inspection so you do not need to install the Zscaler root certificate on client devices. You’ll be able to use the Zscaler generated enrollment certificates to deploy and enroll your app connectors. Hope that helps!

4

Yes, everything is an application.

Yes, Wildcards are possible.

Dont think about everything as IP address. If you have example.org for your fileshare, then configure example.org as application instead of the IP address.

Yes, Site2Site Connections will still work.

PKI is not required. If you use traffic inspection, you have to rollout the Zscaler root certificate to all clients

5

Most people have a “discovery segment” configured for their initial migration, which makes ZPA work nearly identical to a VPN.

This will be configured like *.internal.domain.tld where internal.domain.tld will be the internal fqdn of your domain. Alternatively, you could also do an IP discovery segment like 10[.]0.0.0/8. Then, routinely, you’ll see what ZPA is picking up and being accessed by the discovery segment, and move it into an appropriate application segment, complete with the appropriate policy.

As far as VoIP Phone, Camera, Switch question - as long as the App Connector itself has access to whatever is trying to be accessed, then it’s fine. Watch out for people accessing via IP instead of hostname - you’ll need to have app segments configured for the IPs if they’re accessing via IP.

I don’t understand your question about certificates. There’s a machine client certificate that you might be conflating stuff with, but this only applies when you have machine tunnels enabled, and the certificate is issued by Zscaler itself as part of the device registration. There’s no way to back it off of your internal PKI other than issuing an Intermediate CA from your Root CA for Zscaler to use - but almost everyone would just stick with the default Zscaler Root CA + Intermediate CA that Zscaler itself generates unless you’re required to do some FIPS compliance stuff, but that doesn’t sound like you since you don’t have PKI in place at all. Other than that, ZPA doesn’t use have a requirement for you to have PKI in place.

6

Lots of good advice in here. I would recommend registering for the Zscaler Academy and doing some of the self-paced learning there as well to help build your understanding of the Zscaler terminology. All the self-paced stuff is free, just use your work email so your account team can associate any training credits to your account in the future.

7

We are at the half way point in our deployment to ZPA. All the comments shared on this thread are right on point. The professional services team from Zscaler has been terrific to work with and we should be fully operational by the end of the first quarter.

8

I second the Zscaler Academy, it’s solid.

Coming from FortiShit, I implemented ZIA, ZPA, and ZDX. For the most part, ZPA just works and it’s been a godsend in terms of functionality and ease of use for both user and administrator.

Zscaler is about Zero Trust, so you should setup app segments and access policies, but technically, one wildcard segment for your domain and you’ve potentially handled everything. There are edge cases where the server may expect the source to be from a certain IP (SIPA), or the destination is only accessed via IP.

The only gotcha we had was when an admin killed a service on a server that agents checked in with before removing the agent from the clients. The agents ate through all 24k ports on the app connectors and then again when I doubled it up to 50k ports. I had to block the agents with an access policy to get it under control until the agent was removed.

Edit: Think of App connectors as a proxy server and PSEs as a proxy to a proxy. Your apps will see everything coming from that app connector ip.

9

App connectors are creating “micro tunnels” from a user’s endpoint to a defined application segment. An application segment can be anything from a SQL database to an Azure storage account to an SAP portal. It is best practice to define application segments with a subdomain and relative ports and protocols. For example an internal site intranet.acme.com on port 443 TCP is an app segment. Another app segment could be the Acme widget SQL database on port 1433 TCP. Services like UCaaS: Teams, Zoom, Five9, 8x8, etc. should be bypassed in ZPA and ZIA and allowed to “break out locally”, accessing the Internet directly from where the user is connecting.
By allowing access to *.acme.com and 10.0.0.0/8 you will catch a lot of your traffic destined to private applications. Other things you’ll see and need to call out like Azure storage accounts and Azure managed SQL instances. You can put app connectors (Linux VMs currently running a stripped down version of RHEL 9.4) in your commercial cloud tenant and on premise. You will also use app connectors for sending logs to your SIEM platform with something called log streaming service (LSS).

ZIA = Zscaler Internet Access, you can block categories of URLs (gambling, pornography, new domains, etc.) make some fancy Cloud App Control Policy rules, file type controls, inline DLP, malware blocking, geo restrictions, and some other good stuff. You can also use this to detect shadow IT and get a feel for what SaaS offerings that users at your organization use. You can find that one user who just uploaded 35GB of data to a file sharing site that is not authorized for use by your organization. You can find those ten users who have burned through 280GB last month on Netflix. You can do some pretty granular rules with Cloud App Control Policy rules and create rules for certain departments base on user attributes populated within your AD / Entra ID and passed over to Zscaler via SCIM. You can conduct SSL inspection on most Internet traffic very easily by installing ZCC on endpoints. Most customers will not conduct SSL inspection on the predefined URL categories of Health and Finance for user privacy reasons. There are also “one-click” Office 365 bypasses you can enable.

For guest WiFi (where you can’t install ZCC on their endpoints) you can setup a GRE tunnel and use DNS based security controls for some web content control, obviously no SSL inspection when deployed like this for guest WiFi.

ZIA provides Internet content filtering and malware protection, also can function as a host based firewall if you have the advanced cloud firewall and install ZCC on your endpoints and enable Tunnel 2.0. You will setup two VMs to forward logs to your SIEM, one for web traffic and one for firewall traffic. This is called analog streaming service, NSS. Remember if you’re using Tunnel 2.0 and connecting from on-premises, any existing network security appliances will not be able to do much (besides outright block traffic to Zscaler data centers), so you’ll need to ensure you have at least the minimums security controls you do now deployed through ZIA. Think firewall rules for hosts. I block things like external SMB connections, external RDP connections, and I block the QUIC protocol. If you don’t block QUIC, you’ll miss out on a lot of encrypted traffic, as Zscaler can inspect QUIC traffic since it doesn’t perform the traditional three way handshake when establishing a connection. QUIC traffic will fallback to HTTPS and you’ll then be able to gain insight into that traffic.

ZCC = Zscaler Client Connector, it is the endpoint agent which intercepts network traffic and forwards it appropriately.

ZPA = Zscaler Private Access, the solution for connecting users to private applications, either in your data center or hosted in a commercial cloud tenant.

Feel free to PM me, I’m decently knowledgeable on ZPA and ZIA and in setting up things called app profiles and forwarding profiles for ZCC.

Late night typing this on a phone; so there may be some errors in this post.

Source - I work for a company that deploys and manages Zscaler (ZIA/ZPA/ZDX) for lots of other companies, ranging from tens of thousands of users to several hundred users. I’ve worked with companies on designing, planing, implementing, and troubleshooting their roll-outs of Zscaler.

10

First off, welcome to the world of Zero Trust where everything must be whitelisted for access, unlike VPN where everything’s open by default. Takes adjustment.
User the wildcard for initial discovery, review the findings with operations and security, then start developing App Segments around acceptable items then yank the wildcard.
You can group similar apps into a single App Segment, so file shares can all be in one with the same ports, then just entries for each of your servers. Same with Active Directory, all the ports need to be defined then all the DC’s added.
Once operational, watch the ZPA analytics closely to see what’s still getting blocked and adjust as needed.
As for remote staff, for our Help Desk we have a single RD Session Host acting as a bastion with proper licensing that they can all log into from remote, then jump from there to where they need to.
Also, you can deploy multiple App Connectors and organize them into groups, and you can have App Connectors spread throughout your branches, and once you mature more into Zscaler you can replace the S2S VPN with ZPA, granted you will need Branch Connectors in the mix, which I would deploy instead of App Connectors anyway to be honest.

11

Remote connections is possible as long as the ZPA-connector can connect to it, and the correct ports and access policy is defined.

I’ve beene using it for a while, most helpful step was machine based authorisation which they added like 4 years ago (around corona period).

  1. you sign on as a user to get all steps connected

  2. if you reboot, the client has “line of sight” via zscaler to lets sal the domain controllers (without this in cases a new user uses it or password expired you don’t need to hassle with local account and the likes to get signed in again).

12

This is spot on and just be aware of a few other gotcha’s

Leaving a wildcard should be short term not a permanent fix and using too large or a wildcard such as the entire rfc 1918 address isn’t recommended per best practices although most do it anyways.

Make sure you allocate enough resources to the app connectors

Start identifying any traffic that is server to client or on-prem reaching out to the VPN client such as scanning , agent based tools , collaboration tools etc

Since the org has decided to move to zs and you started you don’t have your own pki then start with trusting zs pki

13

Hey mate. Not OP, but I was wondering if it would be ok if I contacted you via DM.

I’m not a network engineer, but I’ve recently joined an organization as infrastructure/cloud engineer after an exodus of their previous IT service providers, and they have zscaler. I’ve come from a background that doesn’t use sase at all and I’m looking for some understanding on zscaler/sase fundamentals to help me understand the way network traffic flows in environments with this service

14

Zscaler generated enrollment certificates to deploy and enroll your app connectors

Ah that makes sense, thanks!

15

Thanks for that, we do have a DFS share with a proper hostname, but for some one off applications, employees might follow a shortcut to a FQDN share of some server. Our domain is a .local, is that going to work for the applications?

16

Thanks! You are right I was conflating that about certs, I was thinking of Azure Client VPN or NPS where client certs get issued to each device.

One other question, we are using a Meraki SD-WAN setup and will also have ZIA. Does ZIA function similarly on a site-to-site level?

Like we have 20 physical locations, do we setup applications and rules for role based access to them? For example desktops at 1 site probably don’t need the ability to communicate with desktops at another site, just printers, servers, etc…

17

This is the way (currently doing a ZPA rollout)

18

No problem. Info regarding bypassing VoIP/UC solutions can be found here: Bypassing Unified Communications Traffic | Zscaler

19

ZIA is just internet access - the App Connector isn’t really involved in that (exception being Source IP Anchoring or SIPA). With ZIA, if you have Zscaler Client Connector installed on all of your workstations, you don’t need to worry about network connectivity so much.

Application Segments are primarily Device Posture + User specific as far as policies are concerned. You can setup Location specific policies - but I wouldn’t really recommend it unless you have some pretty specific use cases. Unless your network is really flattened, your Site A Desktops aren’t even going to have the ability to access the Site B Desktops on the network layer without going through ZTNA - in which case the User/Device policy would be evaluated (something like only Desktop support can access the Client to Client application segment) - in which case tying that to a location would be overly granular.

Take things one step at a time before thinking about locking them down - because it’s very easy to shoot yourself in the foot by making things overly granular and restrictive. My org keeps things pretty simple for now but we’re still in “Phase 1” of the migration.

20

Thanks, that is definitely the approach we need to take as all of our locations are currently open to talk to each other…not great for security but this is the step towards getting there.

I guess this is a question for the team implementing but I’m not exactly sure how each of our sites will be connected.

We do currently have the Client Connector deployed to Workstations for ZIA. I am not sure if site to site traffic will go through the Meraki MX’s or if it’s forwarding through ZScaler in some way. Some of our users are hybrid what would happen if a ZPA device with application segment rules plugs into a physical location that has simple network access to a web server or something?