Tip for case where adding so many wildcards/fqdns does not work in the policy

[the_rock]

Hey guys,

Just wanted to share something I discovered when troubleshooting an issue with a customer. I know this is very unconventional way to fix such a problem, but it foes work. So, they were trying to access sql server on port 1433, but considering an IP would randomly change, we tried using wildcard for microsoft, azure and akamaitechnologies based on the logs we found, but nothing worked.

TAC also kept suggesting we add more fqdns, but considering nothing worked, I was thinking about it and thought, well, if below site gives proper IP range, why not just add an IP range in the destination and we also added one for USA as well, and that worked fine. Logs, in this case, sadly never give fqdn, always just an IP and YES, the resolve option is checked.

Example of one range:

https://whois.domaintools.com/52.228.81.188

Anyway, thought would share that in case someone else encounters the same issue. I wish we could make it work using url custom objects, but it sure beats spending hours on end troubleshooting this, when we dont even know the proper list : - )

Best,

Andy

[PhoneBoy]

Yeah, this is a tough issue to solve for those environments with a strict outbound Internet policy.

[the_rock]

Agree 100%. But, you know whats one thing that surprised me...not sure if this is normal/expected, but considering that all IPs client showed me are related to Microsoft, its odd that even after we added *microsoft* in the policy, that did not work, not sure why.

Yes, while they dont use https inspection, I dont believe that is even needed for something like this.

Anyway, we have a somewhat good solution, for now : - )

Andy

[PhoneBoy]

For *microsoft* to work, the sites would have to be serving HTTPS certificates that match.
They may not be in these cases.

[the_rock]

yeah...good point.