Transcript
So first of all, under infrastructure, private access, we have B2B exchange, extranet. So these are all your business partners. So one of my business partner amongst all of this is LexCorp. So for LexCorp, I'm saying that when I'm trying to access LexCorp applications, my business partner applications, these are the proxies that I can use. So I can use any of these proxies that is called as a traffic selector. And then we can leverage the partners DNS server. And these are all the placeholders for the partner DNS server. So these are again, all the placeholders that I can use for this business partners, we are not using it yet. Then we start defining the IPSec location. So we'll get to the IPSec location option here. And then we have this partner defined IPSec location, wherein I'm saying that the location type is extranet. And this happens to be for my business partner LexCorp. And this is the proxy that I'm using. And this is the DNS server that I'm using. And this is the VPN pre shared key that I'm using at the moment. So now I have provisioned an IPSec tunnel. Now the partner can use this VPN credential and create an IPSec tunnel to any of the Zscaler data center. Then we come to the policies. So on the ZPA side, we have defined a server group. So we have introduced a new connector type known as extranet. So if you look at this server group, this is the connector type, and the same location that we defined on the ZIA side is available on the ZPA side. So you create a server group using that. And then you define an application segment. So if you look at this application segment, this is jira.lex.corp, which is one of my partner application. And instead of mapping it to an app connector, I've directly mapped it to an IPSec tunnel. So that's an indication to ZPA that in order to access this application, go through this extranet tunnel. And then at last, what we have is an access policy. So here I'm defining a very specific access policy saying that only specific user can access this partner application. And finally, let's look at the experience. So if we look at the application here, this is the ZCC client connector logged in. And if I resolve the partner application, it still resolves to 164 IP, which obviously is not the real IP. However, if I try to access the application, the access will work just fine. So let's look at that. All right, so here you go. So this is how the application is accessed. Let's look at the logging capabilities. So if we go to ZPA Logging, Diagnostic, if you look at the log here, I'm able to access partner application. And this was allowed through this access policy. And the traffic, instead of going through the app connector, it just went through an IPSec tunnel. And this happens to be the real IP address of the partner application. Then we'll just flip the switch. So what if somebody from the partner side, through this IPSec tunnel, wants to access our application? So in that case, it's the same policy. So what we can do is we can go to private access, if we look at one of an existing application. So for example, PortQuiz.net, this is like any other normal application, and it is mapped to an app connector group. And then under policy, under access policy, I'm writing yet another policy. But instead of saying, I've introduced a new client type known as client connector. And then I'm saying that, you know, the partners can access this application. So I can get even more granular and add one more criteria called as externet location. And then call out that LexCorp, amongst all these IPSec locations, is allowed to access my application. So this is the IPSec location that I created, and I can create a policy like this. So let's look at the experience. So I have this VM here, and let me bring it up. All right, so I have this VM. First of all, what I'm going to do is I'm going to do a curl to PortQuiz, dig to PortQuiz.net. So if I do a dig to PortQuiz.net, you will see that it does not resolve to a real IP, even though PortQuiz.net is a public hosted website. However, if I do a curl to it, the access works just fine, right? And I'll show you the logs. So if you look at the logs, so if you go to logs, if you look at diagnostic, I can filter by a new client type that we have introduced, the client type known as externet, because this is a partner-initiated traffic. So if you look at this logs, the traffic came through the CES tunnel, the IPSec location that we just defined, and they were accessing PortQuiz.net, and this is the real IP address of the PortQuiz.net. What we also have is capability to use these same location in the firewall policies. So if we look at the firewall policies here, the same applications will be available. So if we can define the same location, so for example, the same extranet location that I just defined here, it's also available here. So I can specifically call out through my firewall policies that these are the applications that I'm allowed to access, right? So this helps you do a layer seven inspection of the application. You can also do a web SSL inspection provided your business partner can install a Zscaler SSL certificate. So the same applications, the same locations will also be available, for example, under URL filtering policy. So you have this full suite capability of inspecting all the applications and doing the SSL inspection provided if your partner can install Zscaler SSL certificate. Then again, because we do have these capabilities to inspect the application and the traffic goes through the ZIE inspection engine when the partner initiates the traffic, this also means that these logs will be available on the firewall insights or the web insights or the DNS insights. Thank you.
