We have some sites we need to bypass so that the traffic comes from our own IP address ranges. When those sites are behind AWS Elastic Load Balancers or Azure Frontdoor we're suffering frequent steering failures.
E.g.
User tires to access OurSite.Example.com from our office LAN
OurSite.Example.com is a CNAME record that resolves to ELB-Frontdoor-Unique-ID.CloudService.com, ELB-Frontdoor-Unique-ID.CloudService.com itself resolves to a generic ELB-Frontdoor.CloudService.com address, and ultimately ends up with one or more IP addresses.
OurSite.Example.com is in our bypass list.
Hosting systems that provide OurSite.Example.com have filters/firewall rules configured to prevent access to the site unless the source IPs are ones assocaited with our office LAN.
Client logs show OurSite.Example.com is bypassed.
When it works that's all that shows in the logs.
When it fails the logs then show that the traffic to ELB-Frontdoor-Unique-ID.Cloud.com is getting tunnelled and going via the Netskope systems so coming from an IP address that's blocked.
We've tried adding ELB-Frontdoor-Unique-ID.Cloud.com to our bypass list, but that doesn't seem to have resolved the issue.
Our current workaround is to add the IP addresses at the end of the lookup chain to the bypass list, but given they change all the time and can vary depending on user location and a whole pile of other factors this isn't a permanent fix and leaves us with unwanted entries on the bypass list.
Any suggestions on how we can reliably bypass something that sits behind this sort of dynamic cloud infrastructure?
