URL filtering vs IP Address filtering rules

milep · ‎04-29-2020

Hi,

I am facing an issue with URL filtering vs IP Address filtering rules, as the title suggests. Let me elaborate more on the issue:

We are using ASA with Firepower Services, managed through an FMC. The two rules at the top are the following:

1. Source IP "All Local Network" Destination IP "Any" Destination Ports "Any" URLs "Allowed-URLs" - Allow

2. Source IP "All Local Network" Destination IP "Allowed-IPs" Destination Ports "Any" URLs "Any" - Allow

The "Allowed-URLs" URL group consists of several URL objects, like github.com, bitbucket.org etc.

The "Allowed-IPs" IP group consists of several IP objects, like remote public IP addresses or public IP networks

What we liked to achieve is the following - When we have a request from a user to access a certain URL, like github.com, we add the URL object to the "Allowed-URLs" group and access to that particular URL should be allowed on all ports.

The same applies to the second rule with the "Allowed-IPs".

The issue is the following - Our users cannot perform git/ssh operations on github.com or similar websites. However, when I add the IP address ranges of github.com in the "Allowed-IPs" group, then there is no issue and they can perform the previously mentioned operations.

Even a separate rule explicity allowing access to github.com on port 22 does not help.

Why is this happening i.e. is there somekind of limitation for which protocols work with URL filtering and URL groups?

If anyone has experience with this type of issue, please share your opinion.

Kind Regards,

Mile

superadmin9 · ‎04-29-2020

It looks like you have the priority right on your access control list, with URL before IP. In general, IP filtering is faster than URL filtering, so it might be applying the IP restriction first anyway?

either way, you should be able to tell which access control rule the blocks are hitting from event viewer. Maybe the ssh block is hitting a different policy? Maybe your domain whitelist is not hitting the rule as you intend? You might need to check syntax on the domain entry.

I use URL filtering for global whitelist and blacklist. When I have users with issues accessing a site, I add the domain to the global whitelist and it works. But they’re usually using 443. So that’s why I think there might be an issue with 22.

milep · ‎04-29-2020

@superadmin9 wrote:
It looks like you have the priority right on your access control list, with URL before IP. In general, IP filtering is faster than URL filtering, so it might be applying the IP restriction first anyway?
I do not know which one is faster, but in an Access Control Policy, the order of rule execution is top to bottom, so I do not believe that this could be an issue. Seems illogical to everything I have read on ACPs.

either way, you should be able to tell which access control rule the blocks are hitting from event viewer. Maybe the ssh block is hitting a different policy? Maybe your domain whitelist is not hitting the rule as you intend? You might need to check syntax on the domain entry.
In terms of the syntax, I have checked this multiple times and it should be fine. However, I will check again to confirm which rule is being hit of the Access Control Policy.

I use URL filtering for global whitelist and blacklist. When I have users with issues accessing a site, I add the domain to the global whitelist and it works. But they’re usually using 443. So that’s why I think there might be an issue with 22.
Yes, I believe this is also an issue. I also tried adding the domains to the global whitelist, however this does not work as well. There might be an issue with all ports, except 80 and 443 i.e. HTTP and HTTPS protocols.