Github EDLs missing IPs?

[MiBaAveniq]

Hi everyone,

we've been using the Palo Alto managed GitHub EDL to allow access to GitHub and recently noticed some connections being blocked because the destination IPs aren't covered by the EDL.

For example, we see successful connections to addresses like 140.82.121.x that are allowed from the EDL, but also connections to 20.250.119.67 and 20.250.119.71-73, which are blocked because they're not included in the GitHub EDL.

What's interesting is that connecting to these IPs via HTTPS show a certificate for github.com, so they appear to be legitimate GitHub infrastructure. However, they also don't seem to be present in GitHub's Meta API (https://api.github.com/meta), which I would have expected to be the source for the EDL content.

Has anyone else observed this recently?

How are you handling GitHub allowlisting in environments where destination IPs are used for policy decisions? Are you maintaining additional custom EDLs, opening a broader range, or using another approach?

Curious to hear how others deal with this. Thanks!

[kiwi]

Hi @MiBaAveniq ,

You're correct, if GitHub does not publish the IP address in their Meta API response, PANW’s automated EDL generator will not include it.

There are different alternative approaches that come to mind:

1. App-ID + SSL Decryption: Instead of restricting by IP, structure your Security Policy using App-IDs:
   
   
   • github-base
   • github-enterprise
   • git
     
     Combine this with SSL Forward Proxy Decryption so PAN-OS can inspect the HTTP Host / SNI headers and allow traffic based on application identity rather than destznation IP.
     
     
2. URL Filtering / Custom FQDN Objects:
   
   If you must restrict destination targets in policy, use FQDN objects (e.g., *.github.com, github.com, *.githubusercontent.com) or a custom URL Filtering Profile matching GitHub domains instead of pure IP EDLs. PAN-OS dynamically resolves FQDN objects and updates dataplane IP tables accordingly.
   
   

3. Hybrid EDL Strategy (If IP Restrictions Are Required by Compliance):
   
   

   If your organization mandates strict destination IP filtering in Security Policy, you will need to append Microsoft Azure Public IP ranges (specifically Azure Cloud IP ranges for the relevant regions) into a secondary custom EDL alongside the Palo Alto / GitHub EDL, though this significantly broadens your destination allowlist.

Best,

[MiBaAveniq]

Thanks for the suggestions. I agree that App-ID, URL Filtering, FQDN objects and SSL decryption are viable options for HTTPS traffic.

However, my main concern is Git over SSH, where URL filtering, SNI inspection and SSL decryption are not available.

In that scenario, the Palo Alto GitHub EDL seems to be the only practical mechanism to restrict SSH access to GitHub...

[MP18]

@MiBaAveniqMiBaAveniq As per the Link below you can decrypt the SSH traffic. But then the Rule has to be IP based for the destination.

How to Implement SSH Decryption on a Palo Alto Networks Device - Knowledge Base - Palo Alto Networks

Regards

Mahesh