Forum Discussion
Bufflowbill
Nimbostratus
NimbostratusBlock specific traffic
Hi All, I am curious on whether to use iRule or Traffic policy for this use case:
Client wants to allow certain ip address to access www.website.com/api and all others to be blocked to that URI path, while allowing all others to access webui of app. The issue im having is when ive tried to use a Traffic policy with DataGroup it does block the /api, BUT the webui on the same server needs to access the same /api/*, but is getting bocked. Any ideas?Thanks
- LiefZimmerman
Admin
Bufflowbill - if you haven't resolveid this yet let me know and I will see if I can get an expert on the line here.
BufflowbillThank you for you reply. Not resolved as of yet.
- JRahm
Can you clarify this part: " it does block the /api, BUT the webui on the same server needs to access the same /api/*, but is getting bocked" for me? I'm not sure what you mean by that.
Regarding policy vs iRule, I recommend policy if possible first, then iRule as a general rule, UNLESS...you're splitting logic where you'll need both anyway. In that case, I put everything in iRules.
I can help nudge if I have a better idea of the webui server to /api/* piece.
- Bufflowbill
Thank you for your response.
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!
- JRahm
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.
