As we built out our Private Apps, we never leveraged the wildcard entry for domain for our corp environments (ex - *.randomco.com , *.corp.randomco.com) . While looking over community posts related to “npa” “wildcard” and documentation from our former NS engineer, I found a few mentions of leveraging the wildcard entry for access to PC’s, servers, RPD for support, streamlined PQDN access/connectivity.
That being said, I believe this will solve a lot of our headaches in terms of how granular some of our apps have become. We essentially had our ISFW admin do a 1-1 buildout of ISFW rules as a base for our Private App library.
What I need clarification or “best practice” on, though, handling the ports/protocols.
Do you typically go with a 1-65535 entry for TCP/UDP for this use-case?
Note: there are concerns internally that such a wildcard entry would create a sizable security hole.
Additional question, without a wildcard entry (ex - *.randomco.com , *.corp.randomco.com) how has everyone facilitated RDP (to computers, servers, etc) over NPA? Is this even possible without the wildcard entry (since the various computer and server names would not be entered as “hosts” in Private apps)?
Hello
The wildcard entry is most often used for what you mentioned in your main post and the comment. Many organizations take the opposite approach when deploying ZTNA and start with broad wildcard entries that allow access to “discover” applications. This became the most common initial deployment method to the point that we developed Private App Discovery to simplify this work flow:
https://www.netskope.com/resources/demos-and-videos/netskope-private-access-app-discovery
In your case, there’s still value in using App Discovery to capture any remaining hosts. Functionally, this would act like the question you asked:
“What I need clarification or “best practice” on, though, handling the ports/protocols.
Do you typically go with a 1-65535 entry for TCP/UDP for this use-case? “
By defining your *.domain.com in App Discovery it would function as an app definition that allows access to *.domain.com on all UDP and TCP ports. The other good news is that NPA has the concept of precedence so your existing app definitions that are more specific than the wildcard will take precedence. As a result, the only traffic that will match the wildcard will be traffic that isn’t already explicitly defined in app definitions.
To the point on security, that’s absolutely a fair concern so we typically recommend using this method to start or complete your migration to a zero trust approach. The reason for App Discovery is that the shift from traditional VPN level access (overly broad and network level) to ZTNA based policies is often not able to be done overnight as you’ve seen so far. You can mitigate some of the concerns around this broader access level by limiting the time you have it in place, routing this traffic through your internal segmentation or threat protection services, and limiting it to specific users/groups for a period of time.
I hope this was helpful but I’m certainly happy to engage via this community post or a direct call/session if that’s easier.
Reply
Login to the community
If you haven't already registered, now is a good time to do so. After you register, you can post to the community, receive email notifications, and lots more. It's quick and it's free! Create an account
Login with SSO
Employee PartnerEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.