ZPA segment rule logic confounds me

ZPA newbie here and while I’m loving the functionality over our soon to be retired Anyconnect infrastructure, I must say the segment rule logic is driving me nuts. I’ve been doing firewalls/routers for like 25 years, so either my brain is too stuck in the classic firewall/ACL rule ordering world, I am missing something entirely, or the ZPA rule logic needs a revision…

Best way to describe my frustration is with an example I opened a case for:

Segment name: DC Ports access
applications: dc01.domain_com and dc02.domain_com
ports: 88/TCP, 389/TCP/UDP, 445/TCP, 135/TCP, etc
bypass: on corporate network
server group: DC (contains dc01.domain_com and dc02.domain_com)
Belongs in ALL access control policies

Segment name: IT RDP Anywhere
applications: *.domain.com_
ports: 3389/TCP
bypass: on corporate network
server group: Dynamic Catch All (dynamic servers)
Belongs ONLY in IT access control policy (triggers only for members of IT department)

Problem: Whenever a member of IT tried to RDP to a domain controller, the connection would fail. RDP to other servers would work.

So I opened a ticket for the above and the tech explained that the first segment would trigger because it has the DC’s explicitly listed, despite the port not existing, and that takes precedence over the wildcard that does have the port. So then my question was “ok, well how do I fix it?”. “Add 3389 to the first segment” he said. “Um, well I don’t want my users to be able to RDP to the domain controllers, so no, what else can I do?”. “You will need to then explicitly add those DC’s to your RDP Anywhere-IT segment then”. “Ok, so you’re saying that for EVERY segment rule that has an explicitly defined server that DOESN’T contain port 3389, I will need to add it to my RDP everywhere segment?”. “Yes”, he said.

Now I must be missing something here… Either in the way I’m designing things or something else. The proposed logic/solution above is untenable with hundreds of servers. I’m constantly scouring my rules for explicitly defined servers simply so they can also be added to various wildcard rules that apply to different users and/or IT.

Second confounding issue:
I have a segment name called “RDP-Users”
application: 10.77.71.0/24
port 3389

The network above represents the user workstation vlan. When a user tries to RDP to jblow.domain.com it fails. When he tries to RDP using the IP address it works. Is there no way for Zapp/ZPA to do the name resolution?? I already have *.domain.com listed as a search domain, and our domain suffix is on the nic search suffix list. I can’t do *.domain.com here as that would allow them to RDP anywhere, I just need to lock it down to their own vlan.

I hope I’m just missing some “gotchas” here, because it’s a great product and these annoyances are driving me nuts.

Jason, ZPA currently behaves on the model, where the most specific application (and only associated ports) takes precedence. This is different from how a traditional FW is designed to operate. For the 2nd scenario, to enforce access based on IP/domains, the policy engine requires specific rules for IP addresses and domains respectively. i.e. policy for domains is not inferred from policy for underlying IPs.

The behavior that you desire is being tracked by the Product Management team via an enhancement request ER-4801. This ER is on the roadmap, but has not been prioritized for development yet. So unfortunately I am not able to provide an ETA.

Hope this helps.

Ok thanks for the feedback, but can you propose what the suggested method is to overcome this problem which I assume is very common?

I want users to be able to RDP to their machines. Their machines exist in a specific vlan. If I give permission via *.domain.com they then can RDP to servers, which is bad. How can I allow users to RDP to their machines without making a rule for every single machine on my LAN?