So using policy I have it set to use rule 1 "TCP address does not match in datagroup at request time" then
Rule 2 HTTP URI path starts with /api at request time
Actions reset traffic.
So what the devleoper wants is to force people not in that datagroup to go somewhere else for a different API entry point(for whatever reason). However the systems or apps(webui) still need to access that /api directory path. So if I go to systemname.mycompany.com/api, not being in the datagrop it blocks the login portal to me as expected/desired, BUT the ip addresses in the datagroup that should be accessing it for app level API calls to the /api directory path are being blocked also. So the /api and the app(webui) are on the same server. So im stumped on traffic flow, maybe network level ideas as well. my logic is that if external users not in the list get blocked, good. The "internal" side shouldnt be leaving to get to layer 3 ip routing if its on the same server? i was wondering if some how it was getting in some NAT loop or something...
Ive tried so many different variations of this logic in the policy and its the same result. Thanks for your help!
i'd recommend taking a packet capture and running some test traffic from IPs you're trying to block and then from those you want to be successful. My thought is you're on the right track, your servers are likely getting natted and thus included in the very space you want to block. But a packet capture will confirm that. You'd need to look a little further to see how your infrastructure is handling client-server traffic and server-server traffic...if not different, you might need to have an except on the deny from $source that matches something in the server requests.