There are 3 options you can use.

Each option has its pros and cons, so consider them carefully and choose the one that suits you best.

Hi Ejang

Egress IP will not work as dest will not entertain such request.

May you share more info how NPA and Fproxy works?

thank

Forward to Proxy:  
One interesting implementation of this is to create a Forward to Proxy target using the explicit proxy of a Netskope PoP within the target country.  Some regions (such as India) have an alias that encompasses e-proxies across multiple PoPs, giving you some redundancy.   Two cautions here; first you’ll need to make sure to add your signing CA to the trusted CAs list to prevent SSL from being dopped as invalid (if you’re enforcing that).  The second is that you will need some way to distinguish between traffic on their first or second pass through the Netskope cloud (header insertion, access method, … ) to prevent the traffic from looping through the e-proxy.

If I recall correctly, there is also an enhancement request (or two) that should allow traffic to use a specified PoP for egress, internalizing the configuration described above.

@munster,

What countries or locations are you observing this?  Some of this is solved by localization zones where Netskope will make a user appear as though they are in the country they are sourcing from even if we don’t have a data plane there.  This helps in cases where the user and the resource are in the same country but in cases where they differ then the other mentioned methods would apply.  Either route the traffic over NPA to a Publisher in the allowed countries so the traffic egresses or evaluate the forward to proxy functionality. 

Hi Qyost/sshiflett

Thank for the note.

The Gov website is in South Korea. 

In office, our internet traffic exit via our Japan office gateway.  Hence, all users in office will connect to JP POP.  When accessing the gov website, it will see the SK user as coming outside of SK and access is denied.

With our setup, will NPA and fwdproxy can apply?  

thank

@munster,

Just to confirm?  The user(s) encountering this are based in Japan attempting to access a  site in South Korea?  Or they are in South Korea and happen to use a tunnel or client going to Japan?  I just want to understand as in either case, we should have a solution. 

HI sshiflett

The users are based in SK.  The SK client tunnel thru Japan lease line and connect to JP POP.  Hence, SK users will see as coming outside of SK.  However, when they connect to public wifi, access worked fine since they were connected to SK POP.

Thank

So, when in the office, internet bund traffic is tunneled back to an ISP in JP.?   If so, I can see why a Netskope PoP.   You might need the forward-to-proxy implementation in that case so that all the other Netskope PoP send traffic for the problematic government site to the SK PoP.

@munster,

Then yes in this case, forward to proxy or NPA will be required.   I’d suggest reaching out to your local Netskope team or customer success manager so we can validate the requirements and suggest which would work better in your case.