Furthering Your SASE Deployment

Hello, I'm Kevin Hudson. Welcome to the Expert insights series. Today we're doing an architecture overview of the sassy using automated tunnels.00:11My colleague is Diego Barrantez. I'm a customer's success specialist, I deal with umbrella, SWG, and secure access. Content today we're gonna do a sassy overview.00:19A solution overview, an overview of secure internet access, secure private access and then Cisco security cloud control. And to start with the sassy overview, what we want to look at is how the shifting.00:39T landscape has affected the.00:59Security perimeter over the last 05:10 or 15 years. We've had enormous growth in different types of users, different types of devices and different types of apps and where they are located. So, with remote users, we're all familiar, that kind of blew up in about 2020 with COVID.01:02With V always on VPN, one of the problems was that traffic was coming down and then getting sent out of your core hub and that was just congesting all your traffic. So one of the solutions was, ok, let's hairpin some of that traffic or let's use split tunneling. Well, any of the split tunneling that was not coming down.01:21You couldn't apply your security policies to, so you were losing kind of visibility to that.01:40Personal mobile devices, that blew up with four G And when you tried to put those under management, the MDA MDM tools just, exposed your infrastructure. You just didn't have complete control over those. IoT devices have blown up with five G and six G.01:46And when management teams try to get a hold of those by using VLAN and Mac whitelisting, they find it very quickly to become unmanageable. For cloud applications, that would be.02:05This AWS Microsoft and Google. The big change there would be going from Microsoft on prem to Office 3605 in the cloud. Companies try to use vas.02:22And found that those just failed to scale properly to the enterprise. So that was more of a hardware issue. For hy hybrid infrastructure, that was kind of the move from hub and spoke over to more of a mesh and companies found that the cost.02:38Or implementing MPLS was just exorbitant and it also just took a lot of time to get it installed. And then with cloud infrastructure, that just led with on prem proxies and pack files.02:55Causing lots of issues with decryption and limiting your ability to see the traffic itself. So in addition to the types of off premises traffic that we're dealing with, when that comes on site.03:12It impacted how traffic was being dealt with internally. Usually it was an 8020 going internally. Now it's 8020 going outbound that has had an impact on your app performance, your user experience, your security number of tools and vendors and your integrations. The bottleneck.03:31Coming out of your hub sites, you can just measure latency with anything like thousand eyes and you see all the drops and that's gonna do great performance with real time applications like video and voice, customers are not gonna be happy with that. And then if there's.03:52Too much traffic going outbound, your your hardware is gonna get overworked and you're gonna have to do solutions like turning off inspection, which is not optimal. So what we're looking at today is the combination of.04:10Higher performance networking and the ability to provide modern security. SD WAN is able to split the traffic up into your internet traffic or keep it locally, and then secure access is gonna move your security stack from your perimeter.04:30Up to the cloud and make it closer to your roaming devices or the branches themselves. And today we're looking at the automated, the automated integration between SSE and SD WAN. And so Diego.04:46Alrighty. Thanks Kevin. Can you move to the next slide, please? Okay, so we're gonna go ahead and then see the architecture that we have for unified.05:12Sassy solution, which is gonna be on the SD one side, we're gonna have our catalyst SD one capabilities, all of the networking side of sassy. We're gonna have that application quality QoS experience. We're gonna have one optimization and routing. We're gonna have AI predictive network.05:28Working deep analytics of the traffic being routed, we're gonna have SAS acceleration or some DEI for SaaS applications. And then we can apply a certain level of security on the box itself. The idea is that with all of this intelligent routing, then we're gonna be able to.05:47Back to the Cisco secure cloud and then enforced.06:07Our security policies utilizing these Cisco Secure Access SSC solution. On Cisco Secure access, then we're gonna have different capabilities that are all gonna be enforced on the cloud. Like we're gonna be able to enforce firewall as a service zero trust network access.06:12This of the.06:31URL filtering, we're gonna be able to protect AI access to certain applications. We're gonna be able to perform Caspi, cloud access security broker, and then lastly data loss prevention and not mentioned there, but we can also do even super basic DNS filtering.06:35Oh, how, what does that look like in Cisco Secure access? So this is kind of like a high level of our current architecture. On the left side is what I like to call our traffic acquisition methods, meaning, ok.06:57How I'm going to send traffic from this particular device or user to secure access for inspection. So for managed devices, we can do it very simply by just deploying an agent, the Cisco secure client using several different modules.07:17Then for unmanaged resources, then we have a browser based solution and then more relevant to this session for on premise branch use case or IoT devices, then we're gonna create a side to side tunnel.07:35From that location to one of our data centers in the cloud. So once we send the traffic to the cloud, then it's gonna be inspected by several of the engines that I mentioned before based on the type of traffic that you're sending. So once we have all of that traffic on the cloud, then secure access is gonna automatically.07:54Apply URL filtering to web traffic. We're gonna apply domain reputation to DNS traffic. If we're able to perform SSL inspection, then we're able to do layer seven IPS signatures. If you have the agent installed, then we can do also do posture checks.08:15For that particular device, everything within a single dashboard. And then lastly on the right side, it is how we're gonna treat that traffic if it is allowed. If it's blocked, then we're just gonna redirect you to a block page.08:34From our infrastructure, but if it's allowed, then we have three options. One of them for internet traffic, then you're gonna egress directly from our infrastructure to your internet destination. But in the case of private access, then we need a way.08:52To backhaul the traffic from the Cisco cloud to your on premise where your private application lives. So there we can use either a resource connector, which is a lightweight VM that creates a tunnel to secure access.09:12Or we can also leverage, again, another IPsec tunnel that goes from secure access to your private applications, either on premise or your own data centers or maybe you're hosting it on cloud workloads so we can connect from secure access to something like AWS GCP.09:27Sure and whatnot.09:47Now here we're gonna go over the characteristics of our SPA automated functionality. That's our secured private access for the tunnels. There is a minimum version for the manager, which is that twenty.eighteen.two. And then for the edge is gonna be seventeen.eighteen.09:54Dot two, we support IPsec and BGP, and we have a active and standby setup. That means that you're always gonna create a primary and secondary tunnel.10:13All of the traffic should always go to the primary and then you're only gonna use the secondary in case the primary is down due to either maintenance or an outage or you're having connectivity problems reaching that specific data center within a region.10:29As I mentioned, we support BGP routing for dynamic address exchange or we also support the static as well. Okay.10:49And lastly, we can also support SGT based private access rules if you're leveraging sgts with Cisco ICE, so those sgts can be shared and also enforced on the.11:02Catalyst as you want tunnels. Now for our internet based tunnels for like that, let's say servers and IT use case, same versions, minimum versions apply.11:19This one we not only support IPsec, but then we can also do NAT on the Cisco secure access site. We do support an active standby model as well, eight active eight backup per device.11:38And we also support ECMP, load balance between the tunnels in case you need to increase throughput. And then as well as HCP, we do support that LGT and VPN ID tagging.11:54Oh, if you're joining us from our last session, we did mention that we had two different methods on doing the tunnels for secure access and we have what we're gonna call the legacy method, which is gonna be our template form.12:14Functionality which you might be currently using. And then on this session, now we're gonna focus on the automate tunnel piece. So you have seen this slide before, just like a heads up, we do repeat some of the material because it's still relevant between the two methods, but know that we're gonna be.12:33Reviewing different demos with you and this session is gonna be focused on also the new functionality. So make sure you stick around or if you're watching the recording then you can forward a little bit where we see the in depth on the configuration for the new policy group functionality.12:55Okay. So what is a network tunnel group on secure access? We basically group tunnels for redundancy and high availability within a specific region and a region has different hubs. So on your.13:16Edge device, then you're gonna always create at least two tunnels, one primary, one secondary, two different hubs. So in case we're doing.13:36Maintenance on the primary, then all of your traffic is gonna fall back to the secondary. It's very important you don't send traffic to both tunnels at the same time. Again, it's always on a active and standby scenario.13:46On the secure access side, we support up to 100 tunnels for the NAT or SIA use case, and then for SPA, we support up to ten tunnels per hub.14:03Okay, so then you can see here what that looks like on the secure access site. So here we have two different routers, we're gonna do the.14:21IPsec, either static routing for SIA or net and then for SPA, we're gonna do BGP.14:38And we're gonna configure them through either templates or policy groups. And now we're gonna have our head end on the cloud with multiple regions, one active, one standby on that HA behavior.14:54And then from your on premise devices, then we're gonna configure that primary and secondary to hop one and hop two. Very important if you're doing as if you enable NAT on the tunnel, then all of the routing options are going.15:14Gonna be disabled because that is gonna be only for our internet use case.15:34Oh, and then here are the max tunnel capability. Each tunnel supports up to 1 gb and if you need extra throughput, then that's where we want to do ECMP to be able to load balance through.15:40Traffic between the tunnels and gather that extra throughput functionality.16:00So then you can bundle several groups against a, a specific hub. And then here you can see how we configure a network tunnel group in secure access. We're doing the name, we're the device type.16:07Then the region, Optionally we can do a backup region as well. So then we can do four hops, but that's not supported yet with the automated tunnels.16:24We configure a pre shared key and then here you're gonna see that we have our routing functionalities I was mentioning before. If you do that checkbox of NAT, then the routing settings are disabled.16:48Okay, we're gonna uncheck that, and once we do that, then you see routing is back. So then you can create a static route stating that, ok, if you wanna reach this specific address, then you should come to this network tunnel group.17:02Or if you're gonna do dynamic routing, then you're gonna define an AS number and then.17:22We're gonna exchange routes between the edge device and Cisco secure access. And then we also support extra BGP attributes with multi hub BGP. We can override VGP route summarization, and then you can also select to block or allow the default route advertisement.17:28For this particular network tunnel group alrighty. Kevin is gonna go ahead and take you over the secure internet access configuration piece.17:48Okay, so, as we mentioned that when the parameter was changing, there were changes in the user apps and devices and there were also changes in the.18:07Types of traffic in the destinations. So what secure access and SD WAN do together is try to direct the traffic and determine how it is going to be identified and how we are going to deal with the specific traffic.18:22So we have five different ways that we get the traffic that's, you know, either off s off site or on site. We can use the standard Cisco security client. We've got the roaming security module, we have remote access VPN as a service where you can connect directly up to secure access.18:42We have the ZTA module, which is part of the Cisco secure client.19:03And we have packed files which can be installed on machines on site, and we can have IPsec tunnels for branch access. In terms of the types of traffic that we can deal with, we've got DNS traffic, we have any port, any protocol traffic, and we have ADM 04:43 traffic.19:08And then how we inspect that traffic, how we deal with it. DNS has specific threat categories. There are eight of them that we could look at in terms of the firewalls a service, we have.19:29We can look at known threats, but we can also block or allow based on any port in any protocol. And then for any 04:43, as long as we can decrypt the traffic, once we have a root cert on the device, we can go through and as Diego mentioned, we can look and apply DLP.19:44Policies, AI, AI policies, we could do AMP and AV sandboxing remote browser isolation, and we can do file type blocking.20:05So the 1st thing with the roaming client, this is one of the older ways that we've had to manage traffic. In terms of the identities we wanna deal with, we can look at AD information specifically, so we can build policies based on the user, based on their groups.20:17Based on the device. And we can have these policies applied to them whether they're off site or on site or connected to VPN. Those specific settings allow for a granular control of both DNS and web policies. So.20:36The main thing you want to make sure is that the devices have the root cert installed on them. For DNS policies, we're gonna go ahead and look at the domains and we can block based on the specific domains themselves, we can block based on applications. There are applications that.20:54We can control and we can do a block or an allow, and then we can do broad content based blocking or allowing.21:14Then for SWG, we can manage some of the the same kind of threat categories using ADM 04:43 but anything that is specific to DNS like dynamic DNS, you just don't have abilities to do. But with.21:27Remove our browser isolation. We can actually.21:47Sandbox harmful domains so that you can look at those. But again, we do have to have the route room the root cert installed on the devices so we can see that. For remote access VPN.21:51This is where your users are going to be connecting directly up to secure access. For this identification, we need you to have SAML configured on your network. That way you can do not only your authentication, but you can do posture checks on the devices, make sure that they're the.22:07Their operating systems up to par and they have their patches.22:27So once you get that traffic, one of the big differences between this and the secure module is that you can do any port, any protocol policies because the traffic is going through the secure access cloud.22:32So in addition to building policies to allow or block, you can go ahead and apply IPS policies to that so that you can look for known threats. One thing you do have to do for that non web traffic, because of the SAML, you need to make sure you have IP circuits turned.22:48And on that way you can apply IP map to the username and then build policies based on that.23:08And then get that traffic out to the internet safely. So this will come out from specific IP addresses. They're very broad and we will talk later about excluding traffic from specific domains.23:15So remote remote remote access VPN has some of the same capabilities as just the secure client where you can go and build SWG policies and again you need the root cert so that you can complete all of those inspections and that traffic is coming out from the same 01:51 way to.23:36One 80 six/sixteen.23:57Now the DNS module that is part of the secure client is going to do your DNS inspection and you have the capability based on your decisions to either have that module turned on or off, whether the device is on site.24:05For off site when they are connected on VPN. So you can get some granularity where you can have it just dropdown to a default DNS policy if you so choose.24:24The ZTA module has most of the same capabilities as the remote access VPN. You get the DNS module from the secure client will check your policies based on threat categories.24:40And you have the same firewall as a service capabilities for any port, any protocol, and then doing IPS decryption, again for known threats, and it's best to have IP circuits turned on with your SAML ID.24:57And the same thing with the SWG module is for that traffic, again, you have to have the root cert installed. So pack file, one of the, the use cases for that is going to be devices that do not support having the.25:16The Cisco secure client installed generally that would be servers.25:36For these kind of devices, they have to be on site behind a registered network. If you already have umbrella, you're probably familiar where you have to go and register the egress IPs of your traffic. So when that traffic is coming out to us to our two oh 8607 addresses.25:41We know that it is coming from a customer, then we can build policies and apply logging specific to you. So by being behind a registered network, those pack files are going to get a, at least a bare minimum of DNS protections, and then.25:58Using SAML, you can also get your ADM 04:43 policies based on AD user and group information. For other devices.26:18More edge cases, IoT devices talked earlier that the administrative.26:36Overwhelming amount of of work it would take to just keep IoT devices under security. We can easily handle that in secure access using group tags and cert based authentication.26:42And if you notice all of that traffic is going to hit your IPsec tunnels, go up to secure access and have the same three levels of security where you have DNS, your firewall and your gateway. Servers and users, servers will most likely have that.27:00Pack file installed on them, so they will be getting a default level of DNS protections.27:20And they will be getting web based on the, the pack file, and then because the traffic is coming over the IPsec tunnels, you can also use those any port, any protocol rules. Then for users, the edge case there might be a guest Wi-Fi or something where you specifically.27:26They cannot get the root cert onto their machines.27:46So you do get at least a base level of DNS security on them and you can do some lower level policies for eating 04:43, but, it's the kind of edge traffic that you really want to lock down as best as possible.27:50Diego already talked a little bit about the IPsec capability.28:32These, one gig per second or one gig per tunnel. We do recommend that you have the backup tunnels. Yeah.28:35Okay then in terms of increased throughput, one of the the mandatory.28:51Requirements for automated tunnels is gonna be using loopbacks to configure ECMP. We'll get to that and then in terms of unequal multicast multi path.29:07You can change the weight on your next hop, and we will see an example of that. So where this one is 8020, you would be able to set one weight to four and one weight to one and just have your traffic based on that.29:27Yeah, your health checks, both for manual and automatic templates, you do have an IP based tracker tracker that you have to configure and there is an option to, build your own tracker. We have the.29:41Address here, the service.sig.umbrella.com, if you make an optional custom tracker, you can change your default values from 300 so that the route will get pulled based on the tuning that you want.30:00And then we will see an example of policy based routing. One of the things that you can do is, if it's traffic that should not be going up your tunnels, you can route that off so it goes out your point of egress. Examples of that would be if you don't have reserved IP and the destination doesn't like.30:23Seeing in those large/sixteens of traffic coming from Cisco. Good example would be like your finance department sending traffic to visa.30:44There's other traffic such as Webex and teams which has high bandwidth and low latency requirements and just sending it over the tunnel, even if we don't do inspection is gonna cause bad performance for your users. So you can just send that directly out.30:53And then another would be guest Wi Fi. If you just don't want to deal with the volume of traffic and the logs that it's generating, you can just send that directly out. So in terms of configuration using automation.31:10SIA the main prerequisite, you're gonna have to make sure you have your DNS configured. Oop, go back.31:30And then you also have ecmps gonna require loopbacks. So in, in the example that we go through, you, you will see making sure that you have your DNS configured and having your loopbacks set up.31:40So the steps we'll go through onboarding on your Cisco secure SCC dashboard, getting your API credentials from that dashboard and moving them over onto the SD WAN dashboard.32:00Building your SSE policy within that setting up your tracker and building your primary backup tunnels and selecting your region and then the next step would be configuring your traffic redirection. At the end.32:17This is a little bit different than with the manual tunnels is because you can go into monitor tunnels under SIG SSE and see your actual tunnels, whether they are active or backup, but it's the same situation is that you can use your CLI to do some troubleshooting, you can.32:38Go into real time stats also.32:58And then you can look in your manager logs and you can look at the secure access dashboard to see if your tools are up. So in terms of the dash.33:00No it's gonna go through basically those seven big steps.33:20Oh, 1st, going to the SCC dashboard, making sure you have an API key.33:26For your NTG regions, tunnels and identities, and you have rewrite permissions for all of that, then making sure you copy your key, going over to the SD WAN dashboard under manage cloud provider credentials, this might change based on the version that you have.33:42You're looking for Cisco SSE and put in your org ID from your dashboard, put in your API key and secret, and then the context sharing.34:02Diego mentioned that earlier, you can build policies for VPNs or SGT based on that. So the next part going to configuration, system global, then you're gonna make sure that DNS is enabled.34:18Globally, then in policy groups, they need to create an SSE secure internet access policy you can go in.34:34Add it, put a name, solution type, description, and enable both VPN and SGT for context sharing. But the tracker, this leaves a device specific address.34:51So that it can get updated later, and then adds in the umbrella default tracker so that you can.35:06Monitor. Creating tunnel number one, you've got your route via interface, which I think is misspelled. And then your source interface, they're gonna have to create loopback one on this one.35:23And then you have to change your MSS and MTU values, otherwise you're gonna get drops in fragmentation, and that is in the documentation for IPsec tunnels themselves.35:50I'll just gonna go back here real quick and create a second tunnel.36:03In same situation, make sure your MSS and MTU are correct values.36:52So now that you have that SIG policy, if you notice that was where you could change the weight on your policies or your weight on your tunnels for the.37:02Unweighted ECMP. So now went back and added it to the policy group, he's gonna associate it with the edge devices, and in this case, we'll have to provide that IP address for the tracker.37:19And that's that. If you notice it's much.37:53Much quicker and easier than doing it with the manual templates. So now it's gonna go into.37:56Check the tunnels, then you can see that they're already up. In this case looking by site name, the one oh one, and you can see that there's an active in a backup on each of those devices.38:04And then going over to the secure access dashboard that's connect network and network tunnel groups, you can see that the tunnels are up and again the trackers, you're gonna see both up on the secure access side.38:30And then the trackers are gonna watch your primary for packet loss and jitter, and if it hits that threshold, then it will pull the route and move it over to the backup. And the next thing to look at is policy based routing. You're gonna set up a.38:47Application rules. So in here, that specific address is for Cisco's policy tester.39:06So that is going to be allowed traffic. I'm gonna come in and edit this policy routing and start adding different things.39:21See you can create your rules. You can use source and destination, that'll be the 1st one, and sets this to allow the traffic.39:38I think the next is gonna be.40:03Oh, a match of that application list that was created.40:17Specific to the secure access policy tester and then the 3rd one will be specific to umbrella traffic.40:28Again changing that to allow, and then the last thing to do is make sure to route that traffic properly out over the SIA policy.41:05And apply that to the devices.41:57Okay, so then you can go into your, your tools and see some of the traffic that was being dropped beforehand.42:16And then once the policies get applied, you can start seeing umbrella traffic is getting allowed, then you can look and see the 8443 traffic specifically going out to that webpage as being allowed.42:32And it's going out over the tunnel, and when you go to the secure access page, you notice at the top you have your org ID, which is specific to your dashboard.42:56And all of the information applies specific to your traffic. And the last thing they do is they go and they check secure Access's dashboard, look for the traffic by the identity of the tunnel.43:14And see, that it's going where it should.43:32Alright, thank you very much, Kevin. So then now I'm going.44:07To go ahead and go over our second use case, which is gonna be secure private access or SBA.44:11Perfect, so with SPA, we have two different backhaul mechanisms for secure access or if you think about that architectural overview that we saw, it was the things on the right side where we can have either a resource connector.44:27Or a side to side tunnel to reach our private applications. And there are a few difference between the two of them that might disturb you one side of the other. The 1st one with side to side tunnels, it is that we support both VPN as a service and.44:46CTA flows, so you can use either VPN or CTA to reach out to this applications.45:06The source of the traffic is gonna be the CG net range because that's the addressing that we use in our internal routing for secure access. So you're gonna see that.45:16If you use a side to side tunnel, traffic is gonna come from that cg NeT range. In case you're using that CG NeT range anywhere on your network, see if you can change it. If it's not possible, then you can also reach out to our Cisco support team to be able to modify.45:30The, the ranges that we use for that internal routing, but again by default, we're always gonna use that range of one hundred.sixty 400/ten.45:50And then also very important, it is that on your firewall or cloud edge device, in this case that you have a route back for the city in that range so that the, your devices know that if we need to reach that NAT address, then it has to be sent to secure access.46:022nd method that we have, which is the resource connector, it tends to be a lot easier to deploy, is more plug and play because what you do is that for cloud providers, you just download the application from their specific marketplace or you can also download a.46:22The OVA or docket image to deploy on premise, and that's a lightweight VM that you deploy that is gonna create a DTLS tunnel from inside your network to secure access. So one of the reasons why this makes it.46:41Simpler it's because then this VM automatically is gonna synchronize with Cisco secure access is gonna do all of the routing and then it's gonna do all of the load balancing for you. We just give you like a little calculator based on the amount of traffic you're gonna send over and we specified you how many resource connector you need to deploy.47:01Keep in mind that the traffic now will be sourced from the IP assigned to that resource connector. So here we're not gonna use the CG net range, as I mentioned before. The, the resource connector only supports CTA flow.47:22So if you're planning to do VPN as a service as well, then one of that's one of the main reasons why a lot of customers tend to do tunnels because it supports both scenarios so they don't need to deploy anything extra, and also make sure that if you have a firewall in the example above is an ASA. If you have a.47:41Like a firewall or any other solution inspecting traffic between the.48:01Research connector and your applications, make sure the traffic to the resource connector is not inspected and of course it is allowed Okay, so now we're gonna go ahead and see all of the different use cases in action.48:07So we're gonna start with remote access VPN on the bottom right. So there we're gonna go ahead and create a DTLS tunnel to one of our head ends, and then we're gonna go ahead and authenticate using either radius certificate or SAML authentication.48:27After then the tunnels gets established, we wanna do a posture check to see if that device is compliant or not, and then traffic will be inspected through all of our different engines. For IPS, sandbox for file inspection, we can do file control.48:47URL filtering, DLP as needed.49:06Then if traffic is allowed is gonna be routed between the secure access infrastructure, even between data centers if needed, and then to access the private application, we're gonna send it through.49:13The network tunnel where we know we can reach that a specific address, and that's how we get access to the application using VPN. Now for all of the other methods, CTA.49:28On mobile CTA for Windows and Mac and now Linux as well. And then also for browser base, we're gonna go ahead and authenticate either using a certificate or SAML, and then we're gonna go ahead and connect to our CTNA proxy.49:46In the cloud, that's where we're gonna build either quick or TLS tunnels using mask. Then we're gonna do a posture check as well. If the device is compliant, then we're gonna allow.50:04We're gonna then start to do inspection on the traffic, same thing, same controls, and if it's allowed, then it's gonna be sent over to the same NTG to access the the private application.50:22Now for the, let's say that we have a device behind a resource connector. So as I mentioned, then only CPA clients are gonna be able to reach this resource connector. We use the same path of that TLS or quick tunnel using mask. We go to our C proxy heading.50:42We do the same posture check, the same firewall and policy checks, and then traffic gets redirected to a resource connector on your on premise or cloud workloads. And then we.51:00Can access your applications and then lastly, let's say that here we go to the left, that yellow arrow, and let's say that we have.51:16Have a branch to branch use case that my application servers right there on the left, they need to check in with a resource that it is on AWS, so we support that as well. So then traffic will be initiated now from the tunnels.51:36Then it's gonna go to the tunnel heading on the cloud. It's gonna go ahead and go through our firewall and inspection engines. And now we're gonna see that the destination we try to access, it can be reached from a different NTG that is.51:56Just Connected to AWS again using a side to side tunnel. So we send traffic over there and now our application resources can reach our AWS workloads.52:16It's a very similar to our SIA use case. Same thing applies here, one gig per IPsec tunnel, and we can go ahead and then support that redundancy on active standby scenario with the automatic failover.52:35Using IQPDP at a tunnel level and then for SBA, this is something different. It is that we do support 20 tunnels instead of six.52:50So we can do ten active and ten backups, so that will give you a maximum of 10 gb.53:10Per second on a specific NTG, if you're gonna utilize ECMP to get that aggregate throughput.53:18Alright, and then for the VGP routing, so, and then as the one or any edge device that supports VGP can exchange routes with Cisco secure access for specifically, we can leverage DPI for app classification within policy groups.53:39And this is kind of like again like a high level on like where we can go ahead and then connect using the different type of traffic acquisition methods. Oops, let me go back here.54:03So remote access goes to our VPN head end, then it has to go through a side to side tunnel, the CTA private access goes to ours CTNA proxy heading.54:20And then you can go to either the resource connector or side to side tunnel, and lastly, that branch can only go to another network tunnel group and leave as a side to side tunnel.54:36Oh alrighty. Now let's go over how we configure this. Very similar to SIA. So prerequisites are almost exactly the same.54:56Yes, there is NO difference here. Always make sure versions, this is a policy group feature set only. Make sure that the Cisco manager has internet access, make sure the DNS configuration, not the VPN zero.55:11And the most important bit is the API permissions to be able to join the two different products or solutions. So a very high level, how we're gonna deploy.55:30This, we're gonna do the onboarding, API create creation, then we're gonna create SSE policies for private access. Then we select the VPN and SSC region that we want to deploy to. We configure primary and secondary tunnels. We configure the BGP setting.55:48And then lastly, if we need to make any modifications, then we can do a CLI add on for BGP advertisements Now, how we can verify that.56:08The tunnels are working correctly. Same as before. We can go into monitor tunnels and then seek SSE tunnels and we can see them right there and the current status, make sure that they're up up. We can also review them on the secure access side by going into connect network connections and network tunnel group.56:27We can go ahead and then check the specific client routes for an NTG to see which routes have been learned on secure access for that particular set of tunnels, and then you can also review the routes.56:50That have been learned on your edge devices.57:10From the SD WAN manager. And let me show you how everything looks like, so we're gonna go over to the configuration.57:13Okay, so 1st we're gonna go ahead and make sure that the version is correct as we previously mentioned several times. And then we're gonna go over and review the API credentials. So here we're gonna go to cloud credentials.57:31On our SD WAN manager, we see Cisco SSE, we see the organization ID. Then you're gonna have an API key and secret and that toggle for context sharing that we saw previously. And then on secure access, we're gonna make sure that once we create those API.57:50Api's that we have the deployments.58:10Key scope, and then we have read and write for network tunnel groups and tunnels, and then we can do read only for regions and identities. Make sure that you are aware of the expiration date if any, we recommend you to do the never expire, and then you can copy your API key and key secret that is gonna show.58:13Only the 1st time that you configure the API credit. So make sure that you save that.58:33Now we go under policy groups sse, and then we're gonna go ahead and then create our SPA tunnels.58:40So there you go, here's our workflow, so then that segment is gonna be from, we will we will source our tunnels from pull from the VPNs defined under configuration groups. Then we're gonna select a region or leave it as auto to automatically.59:00Like the closest.59:20Region on what that from where that device is. And then here we can see that secure access already auto populates all of the recommended. Then we go ahead and do the same thing for the secondary.59:22Then since we're gonna use dynamic BGP, we put our SIN number and then we're gonna put in the in route and outroute policies that those are pre built and they're gonna filter out the secure access, cloud routes by default.59:40Okay. All right, we now go to policy groups.59:59We select as the one and we create our automation workflow. So then here we do now SPA, we go ahead and then associate that.01:00:23To your edge devices. So here we're gonna select this specific site one oh five that has two catalysts 8000 and then we're gonna go ahead and provision them.01:00:41So here we can do a quick CLI preview and then you can check the differences highlighted there in green.01:01:05We see the tunnel source, we see the route maps there to filter out those BGP routes that exist by default in secure access. You see all of the different neighbor associations, you're gonna see the S.01:01:22The end right there.01:01:42And now we just need to wait.01:02:05So that the deployment is successful, it ish should only take like a couple of minutes.01:02:07Oh, do you see their policy group successfully deployed? So let's.01:02:28Now we're gonna check if the tunnels are up, alright that's our EU central NTG that we're just configuring.01:02:42Let's check the SD one manager side. Okay, they're showing up here now. Let's go back to secure access.01:03:06And there you go. Now they show connected to the primary and secondary and on the as you want manager side.01:03:22The edge are still not showing up ok and the reason why it's because we haven't given them any specific routes. So as I mentioned previously, if you want to modify.01:03:40The routes, then we need to do a, a CLI add on template. So for that NTG, see right there, NO client subnets. So let's go ahead and fix that real quick.01:03:59Here we're just verifying the roadmaps. We only have the default ones.01:04:25So then here, there you go CLI profile, and then we're gonna select the.01:04:46SPA out of one oh five that we had previously pre configured with the new routes that I want to inject into Cisco Secure Access.01:04:52We're gonna save and then we're gonna go ahead and do another quick deploy to the same site and then we just wait for that successfully deployed message again.01:05:13Sending configuration and there you go successfully deployed. Awesome. Okay, now we can go to the CLI again and we can check.01:05:39The differences There you go. Now we we see on our NTG sites, we now see two clients subnets that have been learned from this NTG.01:06:00There you go, so then we can see the VGP AS number, you can see the secure access AS number, and then we see all of the tunnel information from this section. Now, let's go ahead and test our configuration. So we're gonna go to private resources, and we have a test application.01:06:33Option or server?01:06:53Behind these tunnels that we just configured, so we're gonna go over the configuration right there. We have defined this private resource with this specific IP address, 172.16.104.11 using the RDP protocol on port 3389. Then for.01:06:55The connection method.01:07:15To this fiber resource, we have enabled zero trust connections using the client module. We enable browser based connection as well. So we can access through the agent or just by going to this specific FQDN for any sort of device.01:07:17And then we also allow VPN connections. VPN connections would include both branch to branch use cases and VPN as a service use cases. And then we can see.01:07:37On all rules where the specific private resource it's getting their policy enforced. So there we are allowing it on rule five and then there is a block.01:07:52The default block on rule number six. So let's go ahead and take a look at how what that rule looks like. So here we have just a simple any going against.01:08:07This specific primary resource.01:08:27Then we have the zero trust client based posture profile and browser based posture profile depending on how we're connecting, we're gonna change the posture requirements. For security, we have IPS disabled as you can see right there, and then under our security.01:08:38Profile.01:08:58We do have file inspection enabled. Alright, we're gonna go ahead and then save and test this private resource, so we can do a test reachability test which is gonna do a TCP.01:09:00Probe towards this private resource to make sure that we have connectivity between our resource connector or our VPN tunnel to the private application. So this is a probe that it's sourced from secure access itself, not from your endpoint, which is very important to know.01:09:19Okay, so then here we're doing that browser based access to this application. We just put the FQDN that was defined on the private resource, and now we're able to access this, this VM.01:09:37Let's go to monitor and then activity search to review the logs of data connection.01:10:02So then here I'm gonna check all of the connections done to that specific private resource.01:10:24And then here we can see that our source that's gonna be our AD username. And then we're gonna see that we connected through CTA clientless or browser base from the endpoint to secure access and then all of those.01:10:31Firewall requests are the egress egress portion as well. So here we can see a lot of the details of like the rule name, the identity types associated with this request, destination IP address, destination port that it was used, the, the associated posture profile as well to see what was checked.01:10:52To review if that device was compliant or not.01:11:12Alright, and then lastly, we wanna go over the Cisco security cloud control, which is how we're pretty much bringing everything together. So ours new unified sassy offering is gonna.01:11:18Would be the combination of our secure SD one with our SSE offering of Cisco secure access and then also we are adding our identity services with ICE and the dual Cisco identity intelligence, which.01:11:34By the way, we already have some characteristics of Cisco identity intelligence just by purchasing Cisco secure access. So you can already benefit from this portion of our offering without being a dual customer.01:11:52Which people a lot of people think it's a prerequisite, that there is a lightweight version included. So what we want is to have the, this experience through a common platform, a single dashboard now for both networking and security.01:12:10Security, not for you to pivot between two different dashboards, which has been our previous experience. The idea is to have a also like a shared platform service.01:12:30So we're unifying a lot of different aspects of our solution, e.g., our backs, API logging. We're even gonna have common objects as well that you can deploy for both Catalyst as the one and Cisco Secure Access.01:12:42And the idea is to have agent workflows and AI on both products. So then again, you don't need to pivot between the two of them. Make sure that we do also support identity intelligence especially now with.01:13:00The rise of AI agents or identity portion is gonna be more important than ever to make sure that we can track all of those AI agents as if there were.01:13:18Human identities. And then lastly, having a single unified experience is gonna allow us to have end to end observability and make sure troubleshooting is easier by sharing logs and resources between the two solutions.01:13:33Powered by AI canvas and then also thousandeyes. Which thousand eyes? It's included by using the Experience Insights functionality on Cisco Secure Access, so then again not something you need to purchase separate. We do offer some thousandeyes licensing called experience insights.01:13:50With your secure access subscription, which is called the embedded licensing. So make sure that you leverage that.01:14:10And then why we're doing this? Like what, what are the issues that we have seen? Well, the silo management for networking and security teams, they tend to be two separate teams that have separate tooling, so that often leads to silos. So by forcing them to collaborate on a single platform, we can.01:14:21That also help break those silos.01:14:41You're gonna have a single Or, well, the problem is that you don't have a single SSO experience. You have different dashboards that have different capabilities, different These leads to inconsistent security posture because then you're.01:14:45Gonna have different policies for network and security and that e.g. you have little bit of security on network and then you also have a little bit of network on security.01:15:04And then you also have duplicate objects. So that like the VLANs or virtual objects that I have defined on my firewall are different than the objects that I have defined one, that they're different from the internal networks that we had on umbrella or secure access previously. So the idea is to bring all of this together.01:15:15So you only need to update on a single location and that's gonna get replicated through your different ecosystem to bring to life that one Cisco.01:15:34Idea and then as I mentioned decoupled monitoring creates troubleshooting head ends, it usually brings people to check like ok who has access to this tool that has this specific log that we need for this or who has access to view this?01:15:47This type of network flow, hey, let's check with the CM team, let's check with the firewall team, so on and so on. So by having a single platform that correlates all of the data, it should streamline.01:16:07Troubleshooting. So this is what we have available today. We have the multi console experience, we have the unified secops dashboard with different security tooling, and this is like the latest. What is new, which is that uni.01:16:20By SaaS experience of having the SD WAN manager and then security cloud control talk together and under security cloud control, now you not only have secure access, but then you also have your ftds and your asas as well and.01:16:39We're bringing in more and more security solutions to security cloud control. So let's take a look at how that sassy management looks like from security cloud control.01:16:57Oh wait, 1st, we're gonna check the how what the firewall looks like. So then when you click on our firewall section, you're gonna be able to see here that we have our catalyst SD one firewall policies.01:17:15But then we can also pivot to our FTD or our mxs and our asas. So you have all of your security stack on a single dashboard. And then now we can pivot to the sassy management portion where we can see how our.01:17:30For tunnel connectivity and we can configure it from there, which brings that unified management of SD WAN sites and secure access SSE policies.01:17:50And this is a high level architecture and how all of these solutions are gonna work together. So we have that on prem or cloud hosted SD WAN manager. We're moving that to the Cisco managed SD WAN manager, which is gonna talk with security cloud control.01:18:12Which then talks to secure access management. So from security cloud control, then we can push the common objects. We can do SSO to the same provider so you can use the Cisco security cloud sign on or you can just configure your own.01:18:31SSO was needed. And then we can also have if you're doing ICE, then we can do the security cloud control, talk to the PX grid cloud connector to make sure that sgts are shared across your entire deployment.01:18:51So the directly managed solutions, we have sassy management as we previously saw. We can do secure access, we have firewall management for FTD FMC, ASA, we have AI defense, we have multi cloud defense, and we have secure workload. And then from security cloud control, we can.01:19:18Cross launch against email threat defense, secure endpoint dual and XCR.01:19:38Okay, so then here we're highlighting some of the catalyst as the one functionality that we're gonna simplify management via single SSO on our back.01:19:53Streamline connectivity, that consistent policy control and centralized monitoring. So then here we can pivot between the networking policies from device policies and then our cloud access policies.01:20:08Which are gonna be our secure access rules.01:20:28And then this is our new unified Arba control where we have the network roles, we have the security roles, and then we have the new sassy roles. And then lastly, we have a quick demo on how everything ties up together.01:20:36As you can see here, we have sassy management catalyst, SD WAN enabled on our SCC. The role based access control has been involved with the introduction of sassy. So we have now three new types of roles across the SCC. As you can see here on the screen, I'll show you the admin roles now.01:21:01We have network administrators and networking led roles that are giving users access to the SD WAN manager side through SCC. We have the SSE roles that gives the users access to the cloud part of the secure access so rules and policies for that part. And then we have.01:21:18When you combined roles sassy administrators sassy roles, that will give the users access across both types of products. Let's move on and go over to the sassy management dashboard.01:21:38Now we're loading the SASE management dashboard and we will start by onboarding a new branch. The device has previously been onboarded to the SD WAN fabric and is now ready to become part of the sassy solution. So we click configure for sassy and then we will start collecting the intent. We have two main use cases that we can run on SASE, either.01:21:51Protect the internet bound traffic from branch to internet or secure a private application behind the SD WAN fabric.01:22:11In this case we chose the SIA workflow. We start by selecting either to reuse the existing tunnel configuration to be a bit in advanced or create a new town config. I'll just show you how a new town configuration will look like. We start by giving you the name.01:22:18SIA demo. Then we choose if you want to share the context from the SD WAN fabric. It's always good to do that so you can actually create rules in the cloud based on the VRF segment or the STT tag inside the SD WAN fabric. We provide a tracker IP address for our tunnels, and then we start adding tunnels.01:22:33In this demo here, we'll add two tunnels. We'll use the same source interface on both. After selecting the interface, we will select if the tunnel is a primary tunnel or a backup tunnel. Then we need to create 2nd tunnel, which we will then choose the same interface as before, and then choose the secondary interface.01:22:53This case, which means that the tunnel will now be configured as a backup tunnel. Next step is to choose the Cisco secure access region we want to connect to. In our case here, you can see we have a lot of different data centers, but I will choose the US Virginia one for this example.01:23:13Next thing is to configure the high availability, so we will add the primary tunnel as the access and the backup tunnels as the backup. We can also adjust weights if that's needed. Let me just take a step back and choose a policy that is already prepaid for us.01:23:31So here I choose the two tunnels for Americas, and then we need to decide how to trust the other traffic. We have three options here. Either we can route all the traffic within a service VRF towards the sassy solution or we can choose to route specific applications, either our default cloud applications or use.01:23:49Defined list.01:24:09The next though, the last option we have is the advanced option where you can build your entirely own policy. Common for all three is we have to choose which segment we want to steer the traffic based upon. So in this case here, we will go back and choose the all internet traffic and then just choose our corporate segment and route all traffic based on.01:24:12Next step of the workflow is the security policy. As you can see here, we already have a cloud security policy where you can see which roles are applied for the traffic coming to sassy. We then click next to get an overview of the intent that we want to configure.01:24:33We save that and at this point in time the configuration will be built across both the CSA and the SD WAN manager. The final step is to deploy the configuration to the devices, and before doing so, as usual we need to verify the variables and check that they are all as they should be before we click next.01:24:49We have one final review step here where we can see all the intent that we have planned throughout this workflow before we click deploy. Once we click deploy, the SCC will interact with and let that know that it needs to start configuring. As you can see here on the top right corner.01:25:07And the device list is now empty because all the devices are now configured for sassy and we are now waiting it for to be deployed. While the deployment is running in the background, we'll now focused on the policy management part. Policies has now been joined together in SCC, so we both have policies for the SD WAN manager side, so the.01:25:23The policy groups that we are showing here. As you can see, we have two groups. One has already been deployed for EU and then the other one Amir is the one we are now interacting with in the background, so you can see the device is not up to date yet. That's what's going on in the background. But as you can see, the policy group construct has now been moved into SCC, so we have a policy group, the.01:25:43The application priority group, the next generation firewall for the security features as well as the security part of it.01:26:03Now switching gears into the cloud access policies, this is where we are building the policies for things that are being controlled inside the secure access cloud. As you can see the rules are the same as the ones that we saw in the workflow, so the ones that were already built. Let's move on to the common objects. One of the benefits of having a common cloud.01:26:10Platforms is that we can share objects across. So let me create a demo object for you here. We add a name, we can add a network, a host, a range or FQDN, and then we are able to use them across the sassy solution, so means both the SD WAN side in the data policies as well as in the cloud policy objects for our Cisco security.01:26:30Access site.01:26:50But now the deployment should be finished and we should be able to see here on a monitoring tab of Cisco setting management. As you can see here on the map, we have a list of all our devices. We can see all the details of the devices, which configuration groups, how many tunnels are.01:26:53Both from the SD WAN perspective as well as our new sassy configured channels, as you can see here.01:27:11All the gray dots are all the data centers and you will in the future be able to see the connection points between the sassy devices and the data centers. If I want to do more detailed troubleshooting of the device, if it's not healthy and you want to do network insights I can directly from here, but it will cross launches over to the SD.01:27:17My manager. The rest of the monitoring page is about connectivity, how much data has been passed through the data centers, how much, how many events do we have, and so forth. So all relevant opera operational information. Let's continue our deployment with building a secure private access channel.01:27:37We select our site in this case Oslo, we click configure for sassy. We choose secure traffic for private applications. We create a new tunnel set, we call that SBA OSL two T.01:27:54Okay create. We choose our segment, same as previous, we choose which region we want to do or choose auto. In our case here, we will choose stockhole. Because we know that's the closest one. There we go. We add a tunnel pair.01:28:10Important to know that the number has to be a separate number from what it was in the SIA workflow. So here we have our tunnel pair. We configure our local ASN number that we need for BGP 60.01:28:265512, and then and route map policy for in and out. And in this case you will do SPN in and SPA out. We click next.01:28:40We can again choose our AI to build the rules if we need to, click next, review, create tunnel configuration, check for variables.01:28:56Click next and review the configuration before clicking deploy. The system now deploys the configuration and you can see here it says As you can see here we have sassy management.01:29:14All right, and then here we only have the references for the security cloud control portion. All right, we'll leave the session for just a few minutes to answer the last couple of questions, but thank you very much for attending the session. Have a wonderful morning.01:29:31Good evening.01:29:51