Skip to main content
  • EN

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?

@ChrisParr 

I have a feeling that the traffic flow might differ in the cases where it isn't working based on different operating systems, DNS servers or something else.   Are you able to take packet captures when it works vs when it doesn't?  Are you observing this behavior on the same operating system(s), versions and locations? 

Different machines, mostly Win 10/11, different sites, but using the same DNS servers. 

 

Based on further investigation of the logs what seems to be happening is that the Netskope client is losing the record of the DNS lookup that lets it link the initial domain name in the bypass policy to the intermediate CNAMEs or ultimate IP address. 

 

I've seen a client that was just failing to get to OurSite.Example.com but all the Netskope client logs were showing was tunnelled traffic to the eventual IP Addresses. Flushing the local DNS cache didn't make any difference, but running a DNS lookup via the command line for OurSite.Example.com immediately fixed it.

 

I've also seen the same problem, but the client worked until they roamed to a different access point on the same network, and it started working again when the moved back to their original location. 

@ChrisParr what client version of Netskope and what browsers?  I'm wondering if individual browser DNS settings are leading to the client not seeing the DNS query.  I'd be happy to take a look at client logs but ultimately getting PCAPs of the inner and outer tunnel when the issue occurs vs when it's working will show the difference but I understand that can be challenging to nail down. 

Reply


Terms & ConditionsCookie settings