Deny rule on IP Address Access Control doesn't work as expectedIssue Even though a customer configures a deny rule on IP Address Access Policy (ip_access table), users with that IP address can access the instance without get denied.ReleaseCan happen on any releaseCauseThere are two likely causes of this issue. 1. XFF (x-forwarded-for) headers The configured IP address range is included in x-forwarded-for header in the request. Our code is using x-forwarded-for addresses to decide if the user is allowed to access the instance. - if XFF is empty, then we are using the client's IP address- if X-forwarded-for is not empty, then:-- we allow access if any of the IPs in XFF allows access-- otherwise, if any of the IPs from XFF denies access, then access is denied-- otherwise, i.e. if none of IPs is in the allow/deny list, access is allowed. Also see below KB for some more details about XFF. https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0754214 2. System properties relating to IP authenticate The configured IP address range is included in glide.ip.authenticate.allow, glide.ip.authenticate.allow.secured or glide.custom.ip.authenticate.allow. glide.ip.authenticate.allow (or glide.ip.authenticate.allow.secured) + glide.custom.ip.authenticate.allow are used for both diagnostics pages and regular pages.In case of diagnostic pages, that combination defines IPs that don't require user to be authenticated.In addition to those, we are also using ip_access table where you can allow or deny access for specific IP ranges.ResolutionHere are example of resolutions for the each cause. Consider the resolution based on your system and/or business requirement. 1. XFF (x-forwarded-for) headers Consider to also add the IP address specified in the XFF headers to ip_access table. 2. System properties relating to IP authenticate If you'd like to deny a specific IP address range, make sure the range is not added in glide.ip.authenticate.allow, glide.ip.authenticate.allow.secured or glide.custom.ip.authenticate.allow.