Custom URL category *.github.com not matching/working

[drewdown]

I read some posts here about the best way to allow github to only *.github.com IPs and I can't seem to find an easy way to do it. 

If I do it this way:

Source IP – on-prem networks
Destination - Any
APP ID/Service – github/ssh/ssl/web browsing
URL category - Custom category for *.github.com 
Action - Allow

That pretty much allows all traffic that matches the APPID/Service which leads me to believe that the firewall isn't looking at at that URL category or the traffic to match against *.github.com.  So I then have to put specific github destination IPs to make this work like I want it to. There has got to be an easier way to do this, is there?   

For reference with just the URL category specified on that rule above:

Versus when I have it locked down to giithub destination IPs:

[BPry · Accepted solution]

@drewdown,

Custom URL filters really only work for web traffic, it looks like your trying to use it to also capture SSH and SNMP traffic which isn't going to work. You could use something like FQDN address objects to accomplish essentially the same thing as long as your firewall and clients are using the same DNS servers. 

[drewdown]

I didn't mean to accept this as a solution but not sure how to undo it.  

I read somewhere that FQDNs only return 10 IPs?  Is there a limitation to doing it this way?  I mean if I just put the destination as *.github.com and the applications as github/ssh/ssl/web-browsing that should allow git commands to anything @*.github.com?  Sometimes I really despise PAs, like there are so many options and functionality but for something as simple as this there doesn't seem to be any easy solution.  Its almost like its too complex in some instances.  

I forgot to mention I tried using minemeld pulling github public IPs from their website.  Hoping this will suffice but either way its a lot of work for such a small task.  

[BPry]

@drewdown,

You couldn't use a wildcard like that in an FQDN address object, you would have to actually create a address object for each required domain. The vast majority of content for GitHub is under GitHub.com, but you also have avatars.githubusercontent.com for avatar assets and github.githubassets.com for actual website assets. You could create a dynamic address-group if you just tagged the address objects and setup the proper filter on the address-group. 

The FQDN object IP limit was hardcoded to 10 prior to 7.1 when it was raised to 32. I've honestly never run into an issue with any FQDN address post 7.1, but it is a limitation of using FQDN address objects. 

You could also try restricting this to just GitHubs allocated public IP space, but I'm not positive that they don't utilize Azure services for anything being owned by Microsoft. 

[drewdown]

@BPry 

So the problem is when a user resolves an @github.com address and it returns an IP not in the external dynamic IP list that minemeld is puling from github that traffic gets denied.  I just confirmed this, github.com resolves to a 140.82.113.4 but if you look at their list of public IPs that IP is not there:  https://api.github.com/meta  Granted it says its not a completely accurate list but really defeats the purpose of even publishing it if isn't kept up to date (rant at github).  

 As far as the dynamic address group that would require that A) the address object is there and B) its tagged with the right tag.  That doesn't scale well at all and is manual which I am trying to avoid.  

Just to clarify what you are saying... I can just set the destination as an address object FQDN of github.com and as long as both the client and the PAN are using the same DNS,so they resolve the same IP it should work?  I for sure had it set like that prior along with some /24 networks in the destination field and it did not work.