Cisco Secure Firewall: Deploy It Right, Scale It Fast

Hello and welcome to today's expert in hearing Cisco secure firewall. My name is Andrea Martinez. I'm a customer success specialist, and I will be.00:10Your host for today's session. Today is day one of a two day event and we have planned a very exciting agenda. Let's take a look at what we will be covering today. Today we'll be covering.00:20Platform strategy and deployment design. 2nd topic will be clustering and high availability deployment, and the 3rd topic will be Cisco firewall cloud deployment. As mentioned, this will be.00:36A two day event and we are here sharing the agenda for today's session and also or tomorrow's session. If you haven't joined, please feel free to scan this QR code with the registration link.00:55To attend tomorrow's session that we will be covering day two topics, focusing focus on firewall administration, operational life cycle, and also firewall migrations. Let's give you a couple of seconds for you to scan the code if you haven't.01:12Joined already, haven't registered already. Okay, great. This is the team that will be helping out during this session. Our presenters will be Alexander Torres.01:33Icon and said Richardson. Customer success specialists supporting Cisco hybrid mesh firewall. We also have our panelists standing by ready to answer questions that you may have on today's topics. Before we begin, we would like just to.01:50To cover some housekeeping items. We will be utilizing Slido for the Q and A as well as some polls throughout today's event. To access Slido, you can go to slido.com and use the code that.02:10We are we are listing here with the passcode secure FW one word lowercase, please use Slido for all your questions and our panelists will be monitoring and responding.02:25Also Slido will be, you can access Slido directly from Webex, so if you have a question there and also to answer any of the polls that we'll be presenting throughout the event, feel free to interact with us and.02:41Answering those, those polls. Okay, without further delay, let's get started. 1st up, we have Alexander Torres that will be presenting platform strategy deployment design. So Alexander.02:59Thank you and please take it away. All right, thank you so much Anya. All right, so thank you again. Welcome everybody to the 1st day of this expert insights series.03:13Event. We in this session, well, as Anya was mentioning, my name is Alexander Torress I am a customer success specialist for Cisco secure firewall. Today we'll be talking, we will be I will be talking with you guys about the platform strategy and deployment design. This is going to.03:31Be a great introductory session.03:50For this series, we will be seeing as, as noted in the the agenda. Some of the intro introductory topics for the rest of the session. So I think it will be great for those who have legacy.03:52I've been working with the firewall for some, for a long time and then maybe need a refresher or if you are new to the platform, this is going to be a great session for you to get started with this series and this couple of days in the next couple of days.04:10So this is our agenda for today. For secure firewall, we we will be talking about the common use cases where this is basically trying to answer the, the question about where where do I deploy my firewall? Where are the most common use cases for.04:25Device with the capabilities just like Cisco secure firewall threat defense.04:45Management options, of course, we have different choices that we will be seeing today. We will also be talking a little bit about licenses, how our registration with the license work on the FTD and introduction session about sizing and performance.04:51Estimation on the firewall. So having said that, let's I will ask everybody to scan this QR code in case you haven't done so far, and please answer this quick poll about.05:10This question, at what stage in your is your secure firewall deployment currently this kind of gives us an idea of of our participants for today's session.05:28Just give it let's give it a few seconds here. Alright, it looks like a majority of our audience is fully deployed. We still have.05:48A few still in the onboarding phase and it's good to see that, yeah, a lot of us are also like working on optimization of what we currently have. There will be sessions that will be, I'm pretty sure.06:07Like relevant for each specific case, so you are all welcome to participate again. Alright, so let's keep going here.06:21Alright, so concerning common use cases, when deploying a firewall, there is NO single fixed number of use cases, of course. In this presentation we will focus on six of the most.06:39Common frameworks are used in firewall placement. We will analyze how each of them serve as strategic purpose through the configuration of key specific tasks and the implementation of main, the main requirements to make everything work as needed.06:54So in network design and operation, of course we know the use cases are diverse as I said, and their definition is also dependent on what we are protecting. Basically, what I'm trying to say is that we use many terms and labels to describe traffic flow, things like it's.07:21West and north south. In theory, these terms represent different traffic flows, but in practice, the same flow maybe considered east west by one person and north south by another depending on how the network boundaries are defined.07:39What I'm trying to say with this is that just as a quick example to illustrate this a little bit, if your goal is to protect the enterprise network as a whole, traffic flowing too and from the data center maybe classified as east west traffic.07:57However, if your focus is specifically to protect the data center, the traffic entering or leaving it is, it is considered north south. Meanwhile traffic flowing between different areas of the data center or between containers within it.08:17Is considered East west. So the classification therefore depends on the scope and the boundaries defined at the outset.08:36So our 1st use case for the day is the most well known, the role of the firewall at the internet edge. So basically the purpose of this role is to protect users.08:56Public facing services and internal networks while securely controlling outbound access. This is accomplished by leveraging a stateful inspection combined with application awareness and list privileges, list privileged policies.09:13IPS, anti malware protection, URL filtering and DNS filtering provide layer threat prevention by using signatures and databases maintained by Cisco Talos Intelligence Group. TLS inspection is increasingly important, of course as we.09:29See more connections are being encrypted is very important so nowadays to detect threats hidden in in encrypted traffic, so yeah but it is must, but it must be implemented selectively and sized carefully because of its impact on performance.09:49NAT and routing configuration should be kept simple whenever it's possible, resilent and well documented. And comprehensive locks should also be made available to the security operations center to support monitoring, investigation and rapid incident response.10:09Finally, all of these capabilities depend on high availabilities and redundancy, so an appropriate sizing plan based on the expected full inspection throughput, integration with DDoS protection regular health checks, and periodic database updates.10:28To ensure accurate and current intrusion prevention enforcement actions are part of the main requirements for a use case like this in the data.10:45Center case the firewall's principal role is to protect critical applications and data.11:04While controlling both user to application and application to application traffic. A key be a key best practice is to segment the environment into security zones based on application function and data sensitivity.11:11Rather than relying only on traditional network boundaries, the policies should follow at least at least less least privileged default denied approach thus, permitting only the application dependencies.11:28And the required communication, the required communication flows. That's why application dependency mapping is essential before control enforcing. IPS and threat prevention capabilities should also be applied to east to west traffic.11:44With profiles carefully tuned to balance protection, latency, and performance, and highly sensitive assets should be isolated through dedicated zones or micro segmentation. Finally firewall policy should be automated where possible.12:03Continuously reviewed and supported by centralized logging and monitoring. This becomes increasingly important as AI agents generate more autonomous machine to machine communication at higher speed and scale. So.12:23This is a very well known use case, the DMC DMC use case, a firewall in this use case basically acts as a controlled security layer between the internet and the internal network. Its principle task is to publish public facing services without exposing.12:41Trusted internal systems. In this use case NAT becomes a very important part. Basically, we basically assign port forwarding NAT not rules to determine which ports are open to be accessed by the public. So a common best practices.13:00Starts by placing each service in a dedicated security zone.13:19And applying a default denied policy, allowing only explicit required explicitly required traffic. Inbound access should be limited to the necessary ports and destinations using the destination nat, as I said.13:23And without exposing, exposing the real server addresses. Intrusion provisioning systems, services specific rules and security secure certificate management are also required to maintain security compliance.13:39Another very popular use case of course is to deploy the firewall for secure remote access VPN.14:00The firewall acts as a enforcement point by terminating encrypted VPN tunnels and verifying each connection source and identity before granting access to the corporate network. In this use case strong authentication is essential, so VPN access should always be integrated with a tool.14:06Trusted identity provider and multi factor authentication. If authorization is used, it should be used list privileged principle. Endpoint posture additionally that also helps making sure that that they connect.14:26Connecting devices meet security requirements such as current patches, active endpoint protection and compliant configurations. Every session should also be locked and monitored to support threat detection, auditing and incident response.14:44Moving on to the branch and SD one use case, here we looked at the firewalls role in modern distributed architectures. The main objective here is to deliver secure rese resilient connectivity while enforcing consistent security policies across every site.15:11So the best practices begin with land segmentation separating corporate users, guests, our IoT devices, and critical systems to limit lateral movement. And for secure internet breakout, the branch firewall should inspect traffic locally using capabilities just such as IP.15:29DNS and web filtering malware protection and application control. Dynamic path selection should consistently steer applications across MPLS, broadband or five G connections according to latency jitter and packet loss.15:50Finally for the micro segmentation use case, the main objective here is to limit lateral flows by enforcing granular security controls between individual workloads. So.16:16Before enforcing restrictive policies, we need clear visibility into legitimate communications between applications, services, and databases. Based on this, we can implement workload, allow listening.16:31Following a default deny approach and permitting only the verified and necessary flows. So throughout these sessions what we have discussed is of course we have to forced is the.16:48Use of default deny approach. This is basically how we make sure that we are applying a zero trust policies in our use cases regardless of the case. So let's just all get together again on.17:06This is quickest slider to understand a little bit about which use cases are we considering or are current have currently deployed in our in your environment. Of course, you can choose more than one, so.17:22It's it's what you will expect. For a firewall, sometimes you could have like remote access along with the internet edge.17:39Yeah, so we see a few.17:59I suspected internet agent remote access are of course the most popular use cases for the firewall.18:06Alright, just a few more seconds. Thank you so much for participating. Alright, let's move on to the next point on our agenda and that is the different management options available for.18:24For Cisco FTD.18:441st of all, we have a firewall device manager which is by short known as FDM, is this is basically our own box management solution. The FDM provides management capabilities for one FTD.18:54Since it comes pre installed in the box, among it's more relevant features you have the fact that it is easy to deploy basically because it doesn't require a separate virtual machine or physical appliance. It doesn't require additional installation.19:12It basically comes installed by default in the FTE as I said, it has an easy initial setup for routed mode devices and it includes an internal event viewer. On the other hand, FDM doesn't.19:29Offer featured parity with FMC. Keep in mind that only one management option can be used either FMC or FDM for that matter. So FDM in that sense is limited to routed mode only. It has limited scalability and NO migration tool is available for removing configurations from other.19:45Devices to FDM. It doesn't scale to large deployments and it's limited in terms of role based access control having said that.20:05We have our second management option, which is secure firewall management center. In this case we're talking about, I'm talking about the on premises version of it. FMC is the off box management option as of today.20:22Depending on the model, FMC can scale to manage up to 1000 devices. It supports comprehensive security features, it provides contextual network and security information as well as real time health monitoring.20:39It integrates with both Cisco and 3rd party technologies and offers a comprehensive set of APIs. Yeah, it is available as either a physical appliance or as a virtual machine. The FMC supports access control with granular roles as well.20:57As you can see basically with an FMC, we have the capabilities to manage a whole environment of firewalls in our enterprise. The only consideration you will consider, I mean it will be the fact that being an independent or an off box.21:16Of box management solution, you will require maintenance and to run upgrades in this case.21:36This is something that is addressed with the our next management option, which is the CDFMC. Basically with a cloud delivered firewall management center, you don't have to worry about upgrades, you don't have to worry about the maintenance of the management solution itself, cloud delivered FMC.21:42He is the is the cloud based centralized management version of the FMC?22:02As the diagram here shows the devices are managed by an FMC hosted in the Cisco cloud. CDFMC offers the added advantage of a comprehensive set of AI oaks capabilities that we will be seeing on a, another session in their experience series.22:08It also, it's a Cisco managed of course solution, including updates and fault tolerance. It also integrates with multiple ICE deployments through ICE cloud. It supports integration with secure dynamic attributes connector for policy modifications almost in real time without.22:28Any administrative action, so this make it makes it critical for applications and workloads.22:48Deployed in a dynamic cloud environments. The built in migration wizard enables easy migration from privately managed fmcs and we will see more about these in our CDFMC migration session of these expert insight series.22:54As general consideration, there are slight differences compared to an on prem FMC like the fact that CDFMC requires tenable integration to support features like a snort recommendation. And of course the fact that it requires a stable internet connection to push policy deployments.23:12And other firewall management actions to the managed devices. So let's I just wanted to briefly show our how the FMC looks in this case, this is.23:32On prem FMC, we will, as you can see on on prem FMC this one is specifically running version ten, that one is the latest version as of today. This is a virtual FMC in this case. Here I'm browsing in the dashboard where we can collect statistics from all of the managed.23:51Devices including, including web applications.24:11Server application scene and operating systems, the risky applications that are running on the on the devices that it is managing. The dashboard has these different tabs including like threats where you can organize as well like statistics.24:15Collected from the managed devices, intrusion events and so on. We can also go to, well, in this case, total events application by protocol. Under application statistics dashboard, we can also find.24:34Tabs like encrypted visibility engine and connections. Just to give a quick look on how the eventing looks on the FMC, we have the unified events section in here.24:51Where we can, we can find of course the events they are seeing in this case, if we click on this specific block event, we will be able to find details about what caused the blocking of the connection. This in this case it was the rule port invalid ID from our access control policy.25:07And the of course additional details that can help us with the diagnosis of what's going on here with this particular connection. Keep in mind that this is again collecting logs from all of the managed devices.25:27I'll Along with the event section, we have the network map, the FMC and this is basically the discovery feature that I was talking about before from all of the managed devices, the FMC will passively collect the information based on the traffic that is passing through them.25:47And then it would build a database of the, of the devices or the hosts that are being managed by sorry leading the dealing with the traffic by these managed devices and information includes details like the operating system of the host. In this case we have a.26:06Possibly a Windows server, running these specific services.26:26And these specific protocols. Based on that information, the FMC builds a vulnerability table in this case, which we can use to enforce security policies in our intrusion prevention policy.26:31Moving on with the main menu here on the FMC. We have the our access control policies from here we can configure the rules that will be enforced in each of the managed devices.26:55In this case this access control policy, we have a few rules here, some of them are configured to block inside to outside connections and then.27:13The option here we can find the encrypted visibility engine section here for our devices tab, we can see here which devices are being managed by this FMC. In this case as we can see we have three.27:28Virtual ftds as well, all of them running version ten. Something I want to highlight is that with the FMC of course we can see when there are like issues happening in any of these devices, in this case the London one FTD seems to be disabled and was done on purpose.27:45We will try it later in this quick video to run a deployment.28:05So in this section we can see the integrations, including security cloud control, Splunk, identity sources realms, and, which are basically where we configure our.28:15Are Active directories for external.28:35Integration. We also have the FMC troubleshoot shooting section where we can do quick troubleshooting tasks like configuring a packet capture. In this case, I'm just configuring a quick packet capture in here on our campus firewall. I'm quickly giving it a name.28:38And on the inside interface, just kind of to show you the usefulness of of having the an off box integrated management or solution like the FMC. This case we see packets arriving on the inside interface.28:55We could easily save this packet capturing a pickup file. And under administration of course we have other features like where we can configure the option of for the FMC configure product updates and smart licenses. Let's take a quick look at smart licensing here.29:12We will talk about smart licensing later in this session, but as you can see here, this FMC is currently registered and in case you want to, and these are the devices that are using the licenses in this case, the malware license.29:29The IPS and URL license are being assigned to the campus FTD, but in case we wanted to assign these licenses to Paris FTD, we can just click and edit licenses here and add each specific license.29:49To the managed device, alright? This doesn't require a deployment. This is something that the FMC takes care of right now and the only requirement would be to synchronize this FMC with, with the smart licensing portal.30:08By clicking here, this is done automatically anyways after a period of time and if you don't have the license, you will get a an out of compliance error. So this is where we can see the notifications of our FMC, the health, the task. We will see more details in later sessions.30:23Throughout these couple of days.30:43It looks like we have a couple of devices pending to deploy, so let's just click in deploy here. This is how you push configuration from the FMC to the managed devices. Of course we know that one of these devices is is disabled, so.30:45The expected is that other deployment will fail. I just fast forward this this this action although it just took a couple of minutes to completely deploy the changes so right now the.31:04London as a reminder firewall is disabled here.31:25Which is why, what we expect is that the deployment should fail.31:29Alright, after a couple of minutes, we have a failed deployment here.31:52For the London firewall as suspected. Alright moving on, let's talk a little bit about a licensing our product. We will discuss the concept of.31:56Smart licensing and the registration methods, the different licenses available for FTD and how they operate together.32:14Smart licensing is a flexible licensing model designed to simplify the purchase activation and management of Cisco software.32:34Across an organization. It provides an easy, fast, and consistent way to handle software licenses without the need for traditional product activation keys. There are multiple options for usage reporting, which you can choose to use based.32:44Based on what is most convenient and best suited for your organization.33:04So smart licensing replaces manual processes with a centralized scalable framework. It allows for dynamic license allocation and provides comprehensive oversight of both perpetual and subscription based software across an entire organization.33:09So the 1st step to use smart licensing is to set up a smart account. Smart account is a centralized repository for Cisco customers to store and manage the licenses across their organization. As you can think of it as a container that pulls licenses, devices.33:32Specific license agreements and user roles that are associated with that customer.33:52Like a digital wallet for your organization. Anyone with a CCO ID can request for a smart account and it's free. Among the benefits of a smart account model.33:57We have greater visibility and in real time visibility which mitigates the need for you to have to go and manually maintain a separate spreadsheet. It it offers a centralized management, a single location gives authorized users the ability to view license entitlements.34:13It offers telemetry, which means you can drive down costs and improve revenue by making better informed purchase and renewal decisions and better organization of course because you can structure and organize your licenses in a way that makes sense to your, how your organization is.34:32Structure. Virtual accounts, of course, are customizable sub accounts within a smart account.34:52Used to organize and optimize Cisco licenses. You can categorize sub accounts by department, network, business unit, geography, product or any other definition, and the results that you have a better utilization and more efficient planning.35:09So how does smart licensing and the customer's smart account work together? Let's review this this example here. Smart licenses are purchased on a, and since they are smart licenses, it is mandatory.35:35That they are added to a smart account and a virtual account.35:54Once you purchase the license, the smart account and virtual account name can be provided during ordering and the licenses are deposited into the smart account and virtual account. In this case, a big.35:59University smart account shows that they have purchased five advanced licenses in Cisco Commerce workspace. And after registering two devices with the with their smart account, they consume the advanced licenses. They have.36:15Approved they had previously purchased, which leave them with three licenses still available to be used.36:35This means they are in a com in compliance state. As we said before, in case our FMC will have tried to use licenses beyond the capacity of the smart license it is registered with.36:42Then the device, in this case, the FMC will reachen out of compliance status So how do we deploy smart license products? We have five way to deploy smart licenses.36:57In reality, we could group them into three ways. Basically, the options one and two here require direct access to Cisco. We have, the option one, which in this case is the easiest option is basically requires direct communication to Cisco cloud or.37:16For a secure HTTPS channel, in this case the FMC or the F FDM managed FTD will communicate directly with a Cisco Smart portal over an HTTPS connection.37:36Option two here is a slightly more secured connection as the direct communication is through an HTTP proxy. This is used by most customers. You can do this via a virtual machine or through a 3rd party proxy setup.37:52The proxy will communicate to the Cisco server, of course. So option three and four are on prem license manager or on prem CC CSSM. This is basically what you used to be called as a satellite server.38:07That we run locally. So the next options are ideal for customers who have stricter security requirements and do not want their products to directly communicate with the Cisco smart account portal over a direct internet connection. It is a go to solution used by financial.38:24Institutions utilities, service providers, and government organizations. In this case one of them option three is where you use an on prem server which acts locally as the smart software manager and periodically sends information back to SSM to keep the database synchronized.38:44The on prem server is set up on the customer side and it's a virtual machine as I said. All devices will point to the on prem servers on prem server. This on prem server can automatically talk to the Cisco server. This is the same option four in this case is.39:04The same as number three. However, your on prem server is completely disconnected.39:23And information is exchanged via a file transfer. So it's a slightly more secure option. Option five in this case is designed for highly secure intelligence customers such as govern government or the military.39:29This is where you reserve specific licenses to be used at the customer site. Once this happens, there is NO communication back to Cisco with option five, NO on prem collector is needed. This case, these are permanent license reservation and specific license reservation.39:46So, smart licenses is basically the model used by our FTD. FDA managed devices connect directly to the smart licensing portal on a virtual account. In a FMC managed deployment, the FMC as I said registers with the portal and keeps track of both license consumption.40:13And the firewalls it is managing. When two fmcs are configured as an high availability pair, only the active FMC is registered with the portal and manages licensing for the entire deployment. So this is just a briefly review, a brief review of the.40:32Our Licenses available for FTD and the features included with them.40:52We have essentials, which is a license that is perpetual and free. It is included. Well, it is included with the firewall that you have purchased. It allows the use of a core firewall capabilities like routing, side to side VPN application and detection and control.40:57User based rules and connectors. NGFW capabilities like IPS malware defense and URL filtering are delivered through a standard term based subscriptions.41:14And then we have, as you can see, we have the, which are malware license basically helps of course with the detection of malware on, on the files. URL filtering allows to detect, filter URLs based on Talos categories.41:32Cisco secure client which is formerly known as any connect works slightly different because it uses a per user model Since licenses are assigned to users rather than tied to specific hardware, they are pulled and shared across all firewalls.41:52In your environment. And finally a quick note on virtual fmcs. FMCB is told in capacity tiers such as two to ten or 25 devices. The virtual machine itself is identical across all tiers.42:10But capacity is enforced via virtual FMC license entitlements in your virtual smart account. E.g., if you buy a virtual FMCB for two devices and try to register a 3rd firewall, the system requests three licenses and will immediately flag an out of compliance state.42:26Okay alright so licensing and CDFMC firewall management for security cloud control requires a base subscription for tenant entitlements. For firewall customers, there will be per device license subscription additional.42:45For device management entitlement. So basically you need a license for to use the CDFMC, which is purchased within Cisco with this with this identification fdoor FWM sec sub.43:05And then, per managed device you will need individual licenses. The device license subscription with unlimited login subscription is available separately. Customers who don't wish to purchase the unlimited login option can buy a la carte to log.43:23Doing the storage based on their overall daily consumption.43:43This is available in three tiers, one, two, and three year retention options for logins, right? So our last poll for this session, which is part licensing deployment methods fits your environment best?43:46Let's just give a couple of seconds here because we are I want to run out of time, direct cloud access.44:05Good, Yeah so as an.44:23Good, so as we discussed like on prem collector options are definitely well like use for like secure organizations who, yeah, prefer that option over to having like the device directly connecting to the smart access smart account portal.44:43Thank you so much everyone for your participation on this. So let's talk a little bit about licensing about the sizing of, and performance of the.45:01Oh, the firewall, the different models that we have available is a very brief review of the this is the brief, a brief review of the firewalls offered right now, having reached the end of sales date for the 2100 series, the 41 hundreds and the 9300 series.45:17This is our current firewall portfolio. The smallest model we have as of today is the 02:20, the 02:20 model in the 200 series. Only one model is available in the series with up to one to 5 gb/s of throughput.45:34Now when we look at the throughput, we're trying to combine intrusion prevention, application visibility and control and traditional firewall. Please consider the important caveat that when looking at these numbers, all performance values were taken with an average packet size of.45:521024 bytes using the NGFW traffic profile. Then we have the 1200 series with six models running up to 18 gb/s of throughput. We have the 31 hundreds and the 4200 series with up to 45.46:10And one 4 gb per of throughput which already fall within the data center side segment. The Cisco secure firewall 6100 series is an AI ready ultra high performance firewall engineer to deliver exceptional throughput per rack unit.46:29It is optimized for high demand and data centers and service provider environments. It runs up to 6635 gb/s of throughput.46:50As such. So to further scale this in case you need to, we have the ability to implement clustering and this will be discussed in the next session. And then we've got 20 plus cloud variants of support.47:04A supported public cloud including FTD container. This will be seen with greater detail again on in the later session in a later session today. So lots of choices here when it comes to options available, whether it is about the branch location.47:19Campuses data center or service provider alright so that wraps up the session. I really thank you everybody for your participation on the questions and.47:36Anya, I leave it up to you. Perfect. Well, thank you. Thank you Alexander for an excellent walk through the.47:54Platform strategy and deployment design session. It was fantastic. We really appreciate sharing your knowledge and technical insights to this community. So now we will have a 10 min break.48:10Let me re share my screen real quick just to show you, the agenda So we will have a break now and we will resume.48:28At 1105 central, 1205 eastern. And the next topic will be clustering and high availability deployment. So enjoy your break and see you in.48:48Are you in actually 15 min. Okay.49:05Welcome back.49:28Hope that you enjoy your break. Next we have 2nd session of the day and that will be secure firewall redundancy, high availability and clustering. Our presenter is I John, a customer success specialist or secure firewall.49:30Without further delay? I can take it away. Thank you so much, Anya. Hello and welcome today's expert inside series topic on a secure firewall redundancy technologies. My name Ishan customers customer success specialist for secure firewall and hybrid mesh firewall. Been working on and with secure Firewall for the past eight years due to the lens of both.49:47Back in customer success.50:07Today I'll be presenting the redundancy technologies that Cisco secure Firewall can offer to our network, the guiding decisions for either route, and some quick demonstrations of the technologies in action. Now a quick preview of the segments for today's topic, one firewall redundancy, comparing high availability and clustering together, and then breaking down both technologies.50:09With a few demos to showcase them in action.50:28Again during this presentation, I'll be interjecting with some Slido polls. Please be sure to join the Slido to respond to those polls. As a reminder, we are also primarily conducting our Q and A via Slido. So please be sure to join via scanning the QR code here or through slido.com.50:33I'll pause to give some time to, for everyone to join the Slido room again in case we close the tap alright and here we go. Secure firewall redundancy.50:49Naturally as all good presentations and speeches do, I would like to start us off with a quote, a line that should be familiar to anyone working in security, IT or really anything. Quote, anything that can go wrong will go wrong in quote or more commonly known in short as Murphy's law. This quote is attributed to the late Edward A Murphy and the aerospace engineer as he was designing a.51:06Gets sleds with this team in the late 1940s. Unfortunately for us here today, our ruminations and ramblings over which redundancy design is right for us, high availability or clustering will not result in a violent explosion of a rocket. You know, maybe we might share the same fate in a metaphorical sense at the front door of our networking environment goes down. Thusly, we bring you this topic today so we can.51:25Yourselves from sharing the same fate as poor exploding sleds.51:45As all great, great quotes go, however, Murphy's law isn't exactly as we tell it today. The correct quote was actually a guiding principle for engineering design. Quote, if a part can be installed in more than one position, it will be incorrectly installed in the field. Unquote. Which is exactly why we bring you this topic today, high availability.51:49Or clustering, which is the right fit for our networking needs.52:09How do our redundancy solutions respond to failure and how many boxes do we even need to begin with? Firewalls are generally placed at the edge of a network, a gateway protecting critical business applications and data from malicious actors. Simply put, we lose the firewall, we lose network connectivity or worse network protection.52:12The rocket powered sleds that Murphy and team are working on unfortunately did not have the pleasure of the ease of mind if something went catastrophically wrong. Expect a bit of a boom there. Now with firewall redundancy, however, we can mitigate the risk of the loss of a firewall ensuring our network stays connected and our data remains protected with little or NO impact to users.52:31So before we even jump into the meat and potatoes of it all, I do have to ask, do we have any firewall redundancy in our network today? How many of us are here today nervously staring at our one standalone firewalls if it's a house of cards? How many of us here today, just as a refresher or to see what the other type of redundancy can do for us today?52:50I was really hoping that we have NO redundancy what whatsoever would stay at 0 %, but you know here we are. Good to see that we are overdundant. Anyhow, now let's actually talk about what either of these terms even mean to begin with when talking about firewall redundancy in our network, we are referring to a set of multiple firewalls working together to act as a single.53:09Old network logical entity, either as a routed hop or as an inline deployment.53:29Well at 1st glance it may seem an arbitrary choice or that one technology is inherently better. There are unique sets of pros and cons between each of the redundancy technologies that we will want to consider before implementation. Now on the most basic high level, high availability of redundancy takes two identical firewalls and paris them together to act as a single logical unit. The pair will have a.53:33Hierarchical configuration, one a primary device and the other as a secondary device. The primary and a pair will always sync its configuration down to the secondary device, an important distinction when we create the HA pair.53:53These configurations are also independent to the working status of a high availability pair, either inactive or standby status. The active status on the device will denote that it is currently responsible for passing traffic and sending connection information to the standby device. This keeps the standby device aware of the status of connections over the firewall enabling seamless failover and minimal disruptive.54:06To users. The standby role is also responsible for continuously monitoring the active roles health, immediately assuming the active role if it cannot find its high availability peer.54:25But with the secondary device mostly highly around waiting for its peer or itself to fail, it does beg the question. Is there any way to have the standby processing traffic instead of having a perfectly good box sitting around doing nothing? Yes, there is. Now on ASA software and in the past the ASA platform, there is a feature that allows us to create multiple logically distinct ASA.54:35Firewalls multi contact ASA.54:55So why do we mention this? Well, with the ability to create multiple logical firewalls housed in one physical firewall, we can leverage multiple pairs of contacts across both physical appliances to create multiple failover pails pairs of high availability logical firewalls. This allows us to use both physical devices simultaneously spreading the risk and load balancing across both devices.54:57Than the HA pair. While multi context is a feature is still carried on today in our ASA software, it was not carried over as a feature to our next generation firewall offering with secure firewall. So is there any way to achieve this active active capability in secure firewall? Yes. And we do it better.55:17At 1st blush, multi instance seems like a rebranding, fresh code of pain for multi context, new labels same trick. Treating multi instance as such, however, fails to understand the underlying technology behind both. With multi context, the ASA software creates a new logical firewall within the ASA program itself. This firewall while it can be configured.55:34With rate and resource limits for each logical firewall, all tenants will pull from the same resource pool and are not truly separated from one another. This can also produce cases where an overly hungry context starves out its neighbors causing performance issues for all contexts in the ASA. Multi instance as a technology is the modern take on multiple.55:54Logical firewalls leveraging containerization.56:14Instead of finding resources via software, resources are instead defined and carved out closer to the bare metal. Doing this outside of the firewall, software as opposed to defining allocations inside gives each instance firewall truly dedicated resources, allowing the instance firewalls to operate without disturbing its peers.56:17So in the same vein of two pairs of logical firewalls and multi context, we can achieve that very same active active configuration with high availability and secure firewall via multi instance. Common use cases for this scenario, as we mentioned before includes load balancing across both devices and dual homed internet for a service provider redundancy.56:36Two containerized secure firewall images in post physical firewalls moved up together to create two pairs of high availability redundant firewalls. So how's clustering different than high availability? Clustering redundancy takes two or more identical firewalls and creates a pool of active firewalls acting as a single logical unit. The firewalls that's part.56:54Participate in a cluster also come with two working statuses of control node and data nodes. The control node in a cluster is a unique role and will act as a management point for the pool. Distributing configurations to any new firewall that wishes to participate in the cluster.57:14This control node will also handle the non cluster scalable features configured on the pool. All other firewalls joining an established firewall cluster will be relegated to a data node receiving configuration from the control node and passing traffic accordingly. Connection and state data is discussed amongst all cluster nodes along a backend that all members.57:27Particip participate in the cluster control link.57:47Clustering, however, it does have some limitations on the number of members that can participate in a single cluster pool as well as the kind of devices that actually can use clustering as a technology. For physical firewalls clustering is available on the secure firewall, 3100 series and above, only with the maximum of 16 nodes per cluster.57:51For virtual firewalls, clustering is available on all sizes of FTDV with the same maximum of 16 nodes per cluster regardless of whether the firewall is housed in the public or private cloud. The only exception to the 16 node limit is the secure firewall 6100 with the current maximum of four nodes, that is the current maximum. This is more a software limitation at the moment.58:08Then a hardware limitation at this presentation time.58:28Now a quick list, but this is very critical. This quick list contains may contain potentially important features for our organization that may stop us from implementing a cluster. One remote access VPN is unsupported for clustering, site to site VPN, however, is supported with clustering but is unfortunately available unavailable for clusters implemented in public.58:32Cloud. DHCP capabilities are limited limited on a cluster. A cluster cannot act as a DHCP server or a proxy, and it cannot receive a DHCP address.58:51It can however act as a DHCP relay. Vtis or virtual tunnel interfaces are unsupported. High availability cannot be mixed with clustering, though we can't expect to have a 16 by 16 node HA unit as nice as that maybe. Integrated routing and bridging is also unsupported on the cluster, and finally, the unified capability.59:01The Capabilities approved product lists or requirement criteria modes are also unsupported.59:21Some features as mentioned earlier, also unscalable in a cluster. Those unscalable features like site to site VPN are handled exclusively by the control unit, meaning we cannot leverage the extra throughput purchased in a clustered firewall. Now that we've introduced both contenders, let's take a quick side by side look at both high availability and clustering.59:26When we're thinking about implementing these technologies, a couple of major points should come to mind. Costs, complexity, throughput maintenance, and reality.59:46High availability is a straightforward solution to the risk of a firewall outage. Have a second firewall sitting right next to our active device ready to go as a hot standby. If anything happens to either the active or standby device, we're still operational, you can replace the firewall without disturbing our users. From a cost performance standpoint, however, we are limited to 50 % of our total purchase computer.59:54Well we can create an active active high availability firewall deployment, we still do need to carve out those smaller firewalls from each of each individual firewall merely load balancing across both devices instead of gaining any throughput. Now if we move over to say a two node cluster, we can actively pass traffic over both firewalls and leverage the compute with NO idle hands.01:00:14Now there are some extra overheads associated associated with clustering, but we can generally expect to see about 80 % of the devices rated throughput in one cluster unit.01:00:34That said, we can see an additional 60 % of throughput over a two node cluster versus the one active high availability firewall. What's more if we do need to add more power, we can always add more throughput to the cluster by adding additional nodes.01:00:44But if we scrutinize clustering as a technology as well, we can see more issues arise in the costs, complexity maintenance, and the reality of implementing the cluster into our network. To begin clustering as a redundancy technology is reserved to the higher end of the power spectrum for physical appliances starting at the 3100.01:00:58Purchasing even the smallest of the biggest may not make financial sense for our network just to implement specifically clustering. On the virtual front, however, clustering has been added recently as a feature to our virtual secure firewall offerings. Virtual firewalls can be deployed as smaller devices than the physical platforms that offer clustering giving us some route for clustering with.01:01:16On the lower end, but they are limited to routed mode only and subsequently require assistance from the upstream and downstream boundary for load balancing relying on technologies like PBR or ECMP.01:01:36What's more we could always scale our individual virtual firewalls larger if we ever do need more throughput. Rendering one of the major benefits of clustering kind of move While we're also retaining the features lost in clustered firewalls. Troubleshooting the cluster also introduces a headache as tracing traffic through a cluster requires potentially following a packet across multiple units, going through one unit and being.01:01:47Sent to another via the CCL.01:02:06Maintenance upgrade maintenance and upgrades of the cluster can also take some time as the upgrades are generally done serially, one unit at a time, taking more time than AJ upgrade. Now with all the complexities and maintenance, the clustering can seem like a monumental task and it is. But the result is a monolice of the firewall, well worth of time and effort, and as they say.01:02:09Something good comes easy. Now that we've, we've done some relatively quick introductions to both HA and clustering, what redundancy technology do you think would fit our environment today? Maybe we might even be planning a new marketer thinking about how to go about it and I'll take that as a response as well.01:02:28Naturally HA is probably the more cost efficient way of doing it, but this very much so is the more common one to see. Thank you for your participation. Okay, but let's move on towards the how and why we implement either these redundancy technologies. While we touched on some of the major components of redundancy, we've yet to explain the.01:02:50Complexities or simplicities of setting up either of these technologies.01:03:10For pretty simple high level points to consider for implementing HA, one, we only need a single firewall's worth of compute to handle our traffic. Two, we don't really expect any rapid near term growth. Three, the simplicity and implementation maintenance and troubleshooting. In four, the primary business goal is just business continuity. Well, we do not receive the benefit.01:03:15Benefits a throughput scaling, we in turn gain benefits through the efficient simplicity of HA redundancy. There are also a couple of deeper considerations with choosing HA.01:03:34Five or at least this point being a more limiting factor of clustering. We would side with the HA if we needed the full capability suite of the firewall. E.g., the uCAPL/CC standards or remote access VPN. Six, we don't want to overcomplicate things with network design and finally seven, we want what's written on the rated throughput. No guessing on mac performance.01:03:42As per device from introducing clustering overhead.01:04:02The requirements of implementing HA are simple as where. Simple as well. Have a firewall, double it. Hardware, software licensing, everything in HA pair must be identical for the devices to sync. One both devices in an HA pair should be the same, be that the same physical model, a pair of 31 forties or the same container instance for a virtual firewall. A pair.01:04:06There are C6I extra large instances in AWS, e.g.. Do note the high HA, high availability on container instances must also be identical be between identical and physical models and resource profiles. Two both devices should be configured with the same number of and type of interfaces.01:04:26Free Both devices should be in the same mode, i. E. Routed or transparent. Both devices should be on the same version of secure firewall, secure firewall software. This software versioning also includes content versioning on the device such as stored LSP updates, geolocation updates, and BDB.01:04:45Five both devices must be must be managed by the same FMC as well be as well as be in the same domain in the FMC. Six, they must have identical NTP configurations, seven, the deployments must be deployable to both devices simultaneously, they all must be closed together network wise.01:05:02Eight, NO DHGPP or PPPOE on any inter interface, and finally nine both devices must own the same licenses. Now moving on to the more technical side of things, let's take a look at some of the design decisions we would need to consider when implementing HA into our environment.01:05:21Now the failover link is the bread and butter of HA. This connection between both active and standby firewalls allows the devices to monitor one another and take action when needed. The state link in HA configurations is also an important consideration as this carries over the current connection states from the active device to the standby device. This link allows failover to.01:05:38Occur seamlessly from a user perspective as any active connections remain uninterrupted as the device changes roles.01:05:57But we can get away without having a, oh, with having a failover repair without a stateful link, this will cause any connections transiting the active, now failed device to be lost. Naturally, this will require any and all connections that were transiting to be restarted from scratch. Depending on how much traffic was transitting the box at the time, a statele.01:06:04This high HA pair may functionally be subject to an internal DDoS every time it fails over, which is not a fun time.01:06:23Naturally, the state link is scaled in bandwidth proportional to the amount of maximum traffic we would expect across a device given its throughput. These values are pretty simple overall, either a one or 10 gbps link will be needed for the stable link with the 1 gbps link expected for the smaller devices and the ten link expected for the larger.01:06:31Do note the change in the middle of the 31 product stack. When we are cabling the devices, we may want to connect all interfaces to the same physical switch for simplicity or do weird connections over trunk switches like the above two topologies. But this is not a recommended configuration. Failure on the switching infrastructure between the.01:06:50Repair results in all interfaces reading down simultaneously, which will prompt both firewalls to assume an active role and an attempt to pass traffic.01:07:10Split bring behavior, which takes down the network. Instead, we recommend separating data interfaces from the failover/staple failover link. This can be achieved with a direct connection between HA peers or by connecting the failover links to a separate switch for the data interfaces. This configuration affords both the HA devices.01:07:18Multiple points of reference to monitor one another removing the chances of the devices to come into a split brain situation.01:07:38There are a couple of mechanisms HA units have to confirm if their peer is truly down or not. Monitoring either the health of its peer directly or indirectly via interface information. While the failover link is the primary way your peers will confirm one another's activity immediately swapping roles may cause more issues than itself.01:07:45If a failover unit does not receive a heartbeat over its failover link, a land test message will be broadcast out all data interfaces.01:08:04If the standby does not receive a response to the land test, it will self promote the active resume from the last received connection state update from its peer. Interface monitoring is as straightforward as it seems. Continuously monitoring interfaces for activity and health. Failure to respond to a heartbeat for more than 15 s will mark an interfaces down.01:08:12A lended tests are done per interface for monitoring such as for monitoring such as link up/downstatus monitoring receive packets to interface tests and ARP test and broadcast ping test.01:08:32There are also a few additional events in secure firewall that caused failover outside the unit and interface monitoring. For one more than half the store instances in the FTD are flagged down in an active unit, the disk space gets above 90 % on the active unit. The a manual failover command is I've sent either by the FMC or CLI or.01:08:45A failed interface threshold is reached and that value can be set under the HA pairs device management and FMC.01:09:03Before we show the recorded demos I'd like to take a second to show the topology of our AJ pair so we have a better picture of what's going on. We have two secure firewalls 31 thirties that we would like to create an AJ pair with. They're directly connected off of a port eth one/two for their stateful failover link and are a firewall on a stick separated.01:09:11In two VLANs, that is VLAN 50 and 61 with each with one host. All righty then. As we can see, we have named both 3120 accordingly, 3136 accordingly, HA primary and HA secondary. To create a high availability pair on the device management page in the FMC, we can hit the blue add button in the top right of the GUI.01:09:30This creates a dropdown menu of all things we can add to the device pages and we will be selecting HA. We will be add naming the HA pair as well as selecting the primary and secondary device, and when doing so, we pop up with a small warning saying that snort will restart and potentially impact traffic. There's particularly one or two link.01:09:50After naming and selecting the devices, we want to name a pair, this next pop up will prompt us for the failover link information. In this case, we are selecting eth one the eth one two interface giving the failover link a descriptive name as well as an IP address for the devices to communicate with one another. We'll also be supplying a secondary IP address for which 2nd standard.01:10:10My device will use for communication to the active, adding the state interface link, which is the same information from these available link, and once all the information is filled, we're going to go ahead and click add.01:10:29Alright, fantastic. As you can see, a new entry has been made under the devices, the 31 thirty-HA high availability device pair. This is now a dropdown that contains both the 3130 HA primary and 3130 HA secondary.01:10:55Devices. We can check the progress of HA formation in the task row in the top right of the GUI and we can see this HA configuration deployment is in progress and we're waiting for the primary device. We're gonna go ahead and skip forward just a little bit just to save on time. A lot of this is just kind of watching the task manager do its thing, right?01:11:10And this is the tail end of HA being figured, as we can see it takes about 3 min. Once it's done, it does a refresh and as we can see, the HA pair is completed.01:11:33Fantastic. Okay, so on to the next demo. For 2nd demonstration, we'll be manually failing over the HA pair to showcase how traffic is impacted during a failover event. We'll simulate this by sending a manual failover command via the FMC GUI to our HA pair.01:11:49Alright, so this is a lot to take in initially, so I'm gonna explain each of these windows. In the top left, we have the 3130 HA primary devices diagnostic console. In the top right, we have the FMC unified events viewer to see traffic live reporting. And in the bottom left and bottom right, we have each of the hosts and VLAN 50 and VLAN 60.01:12:09Right, we'll be sending pings from and to both of the hosts to simulate some light traffic in the network, and these pings will be traversing through our HA pair and should show up in the top right in the unified events viewer, right? Right now we're just gonna be doing our IP config.01:12:27We have 192-168-5011 on the bottom left and on the bottom right should be sixty.eleven 50 of eleven at the bottom left sixty.eleven on the on the right, right? So we skip forward just a little bit. We still have our repeated things going through and then in the top right we can see the unified events. The is being popped.01:12:45All right.01:13:05So pop over here. One thing to note about this as well, we can also see what device is actually being sent or what device is actually processing the pings, right? In our unified events roller, viewer, if we scroll over to the right, I believe here, we should see the 3rd 01:30 HA primary device.01:13:06Is actually processing traffic. There we go, 3130 device.01:13:26Right, in the top left, we're gonna go ahead and start confirming that the of the current status of the failover AJ pair, right? And that should be show failover status, if I remember correctly, it's a command fantastic or failover state.01:13:31Cool cool. So we see that this host, this is primary active with the other host, secondary standby. And now we'll navigate to device manager in the top right and move the active role to the secondary device with the switch active pure command in the GUI.01:13:47Devices, device management. On the right side there should be the triple.button. We can click that and then switch active peers the 1st option. And there we go.01:14:09All right, so as it's switching peers, we're gonna be going back to the top left and rechecking the HA status. And there we go. We can see just a bit of a hiccup as well as the switching to standby console message out. So as we were saying minimal or minimal user disruption.01:14:30I would not expect anyone to actually get caught by that.01:14:50This is real time, we swapped roles. The active is not the standby, the standby is not the active. Fantastic. Okay. 3rd demonstration, we're gonna go ahead and simulate data interface loss by shutting down a gig one.eleven on the connecting switched here. This is gonna be on the.01:14:542130HA primary device.01:15:13Right. Same window layout before with the only change being the top left console is now looking at the connecting switch as opposed to the 3138J pair, right? Pop over to 40 s. Skipping again to save a bit on time confirming the status of G one oh.01:15:15Eleven on the switch.01:15:35And we're gonna go ahead and shut that down, ok, swapping back to the 3138A primary CLI, we're gonna take it's gonna take a little bit for it to react, but there's a reason for that, right?01:15:37At the event of an interface failure, do keep in mind that the HA appears are performing, you know, various tests and communicating in this particular downtime. The point of this law is to ensure that if we are failing over, we're making sure that they're actually, that its peers are actually dead.01:15:58Right? Now 15 s after we actually shut down the interface, we do see that traffics 1st to normal, and just to confirm the failover status, we can see that the primary will be failed due to an interface failure.01:16:12Fantastic. Okay, last image for HA, we'll be pulling the plug physically on the failover link between both devices to stipulate a failover link failure, right? So this is important to see compared to the other device just to make sure that again these devices aren't gonna accidentally step on each other's feet and go into.01:16:27Skip forward just a little bit more. Again, we're gonna go ahead and go to this top left to confirm the failover status of the of the devices. We can see that this is primary active and we also have the standby ready as well.01:16:52We're gonna be scrolling down to the failover link information as well. We see that it is up, and then shortly after this recording, after we highlight that, we're gonna go ahead and pull the failover link, right? Again, both these devices are currently doing some magic in the background of doing tests together, right? 15 s later, after we pull the plug.01:17:06Right, we should have a failover land message spawn in the top left saying that the failover link has failed, but we were going to see something interesting with the traffic.01:17:25Should be about an hourish, I believe. There you go. Failover land failed, and I actually lied to everyone. I'm so sorry. Nothing happened with the traffic, right? Reconfirming the HA parent, we can see that both devices are perfectly fine. Traffic's perfectly fine as well.01:17:40Show failover status, show failover, right? Scroll back up, we see primary active, second, secondary standby ready, Nothing has changed for the actual status rolls, but we do see the failover interface having been failed.01:17:57All right. Fantastic. That wraps it up for our failover or HAA demos. Okay, our last section, we're gonna be taking a deeper look as we did HA two clustering.01:18:12Similar to before, all points shown in this slide choose back to a single idea behind it. We choose clustering for our network when we require throughput plain and simple we go down the clustering route, we may expect to see more explosive growth and require our firewalls to scale just as quickly. We accept risks, we accept lostered features and we accept all the complexities associated with trouble.01:18:27Tuning and maintenance.01:18:47All cluster units full throttle sends overhead at the core of a network protecting traffic. I skipped over slide. My bad. Ironically the requirements we had for high availability had a large overlap with the requirements for clustering. One, all units in a cluster must be the same model as well as be equipped with the same network modules if applicable, that is failed to wire.01:18:48E.g., all units of the cluster must have the same interface configuration.01:19:08Three management of the controlled node and or data nodes must be sourced from the management interface. Four, all units in the cluster must run the same software and content versions. Five all units must be run in the same node that is either run to transparent. Six, all units must exist in the same domain and group within an FMC and lastly seven, NO unsupported features can be.01:19:13Figured on any unit in the cluster.01:19:33Now for sizing purposes, if we have a target throughput rated for in number of firewalls, we will want to implement an in plus one cluster. The sizing goals targets a few things. One, an additional amount of compute to cover any of the overhead losses across our cluster, and two act as a buffer in the event of a unit failing in the.01:19:37The clusters, we do not have an impact on our target traffic throughput. We'll also want to configure the following for the cluster. Interface access for every unit. Each device should be able to communicate back to its managing FMC in the event that a unit assumes the control unit roll, and an isolated high speed backbone, the cluster control link.01:19:55Precising considerations, keep in mind that the package is received by a unit does not that a unit does not own the connection that the packet belongs to must be forwarded to the correct unit and the cluster across this in the CCL. Do also keep in mind transmission unit sizing is also important across the CCL.01:20:14The cluster control link will introduce an additional 100 bytes on top of the packet. Please ensure that the switch is possible for the CCL has the correct MTU configuration to ensure the cluster can properly form. As we mentioned earlier in the presentation, a cluster will need a bit of additional help from the upstream and downstream routing and or switching devices for load balancing purposes.01:20:31There are multiple options available to us in terms of how we do load balance to the cluster, but we generally recommend leveraging spanned ether channels across the cluster. By building a group of interfaces into one logical interface. Spanned ether channels can be used for either routed for a routed or transparent cluster and will perform load balancing across the logical interface.01:20:51Two other methods we can leverage for load balancing are for routed clusters only, leveraging the layer three routing technologies, policy based routing PBR or equal cost multi path routing ECMP. These methods are slightly more involved in either channel load balancing as we must define how traffic will flow across the cluster per year.01:21:11Either via PBRs leveraging route maps and ACLs or defining multiple routes across a cluster via the ECMP.01:21:31Do keep in mind that we cannot mix and match load balancing between span ether channel configurations and individual interface configurations PPR ECMP load balancing across a single cluster unit. When we are implementing our cluster, we must use span ether channels to bundle each individual interface on every cluster member as a logical unit on.01:21:38The upstream and downstream switches. E.g., we create a four interface ether channel on our switch and connect each of those ports to the same physical interface across each node, Eth one two. We'll also define an ether channel on our cluster and assign the corresponding interface to the ether channel via the FMC.01:21:57For the, for the older firepower 4190 300 platforms, we will create our ether channels via FCM firepower chassis manager, and MXOS or the FXOS CLI. For the cluster control link, however, we will be connecting per node links to the segregated switching backbone in our clustered topology.01:22:15As we can see in our example on screen, we have multiple defined user channels across the cluster control switch connected to individual cluster nodes. These nodes will also define which interface it will leverage as their cluster control link.01:22:35Do keep in mind that the cluster control link will need to have bandwidth to support the aggregate throughput of the cluster as a whole. On the older firepower 4100 to 9300 platforms, the CCL will be defined again in the FXOS. These devices, however, will require use of a pre configured port channel 48 as a CCL.01:22:49Interfaces must be associated to port channel 48 and fxos to define the platform's CCL. So why are we going through all this trouble with load balancing channel cabling and ccls? As it turns out, it's pretty hard to act as a single logical unit for a firewall, a stateful device concerned.01:23:08With how many connections and, with how connections and traffic behave and look. When the traffic a node receives from its a true device may not necessarily be the node's connection to process.01:23:28When we are dealing with connections and traffic, there are three roles with each node can be responsible for at any given point. When a new connection comes in and is sent to a, to be load balanced across a node, we simply enough create a new entry on the unit and label it as the owner of that connection.01:23:38While load balancing should take care of the majority of this new connection, sending the data to the owner of the flow, there maybe instances where a packet might be sent to another node in the cluster. At this point, the recipient of the flow forwards the data over the cluster control link to the owner of the connection.01:23:54In this instance, this node is now assuming the forwarder role and delivering data to its rightful learner. Though that does back the question and leads us directly to our last role in the cluster of traffic handling the director rule. When a forwarder received traffic and is unaware of what node in the cluster owns a particular flow, the director is queried. Okay, the ARP for what number actually owns a flow.01:24:09Now we'll be taking a closer look at a couple of different scenarios regarding stateful or stateful and stateless connections across the cluster following the packet across and through the cluster from client to server. This walkthrough should allucate date why troubleshooting across the cluster can quickly become a headache.01:24:30To start, we assume a TCP SYN is sent from client to server across the cluster southbound. As we've mentioned before, load balancing will forward the packet to a node in the cluster, which will then become the owner of the TCP flow as a whole and will continue this transaction by forwarding the send to the target server.01:24:47The server, on the wiser on the devices between itself and the client, forwards the Synack back to the requesting client. Load balancing on the northbound switch is unaware of which cluster node owns the connection and simply chooses a node. This node now becomes a forwarder of the returning traffic and forwards the Synac to the.01:25:03No owner of via information that reads via the packet headers.01:25:22The flow owner will then forward the synact towards the original client while simultaneously updating a director node of the current state of the connection. Now the student amongst you may have noticed that we skipped steps five and six that not a student amongst you may not have noticed either, and I can't blame you because this is already a complicated process and we're.01:25:26Rest assured steps five and six are more straightforward in the interaction. The client compete completes the Tcp's three way handshake with the final act back towards the server with the owner of the flow updating the director accordingly. Step seven in this case, however covers the edge case of a southbound node from client to server receiving a packet that it is not the owner of.01:25:47That's.01:26:05However, just as we saw in step two with the server setting a packet northbound back to the client, this new forwarder southbound will just query the director for the proper owner of the flow to handle and send it to the owner accordingly. Alrighty then moving on to the demo recordings for now, for clustering for now, we'll be showing how to create a cluster with R 3130 from earlier.01:26:06In this demonstration, we have the CCL directly cabled back to back just to save some headache when we were actually setting up the recordings. For the record, never cable the clustered units back to back like this in a production.01:26:26At all. Okay, so some of you may have caught on that we were adding our HA pair earlier. We could also add a cluster in the very same menu in the very same way. When we click the add button in the top right of the device manager GUI to begin adding our cluster.01:26:39Our 1st pop up will prompt for a cluster name, a cluster key, what node we wish to designate as the cluster node and the interface it should use for the cluster control link. Once we select a node for the controlled node, we also spawn the clustering mode, either span to ether channel or individual interface mode.01:26:58Now when defining our cluster controlling, do note the priority of this value if the ranking would give individual nodes for general preference for control node promotion. If a control node fails, all other members will elect the control node based on this priority.01:27:18Now when we finalize the cluster creation information, do be sure to note the warning about the CCL maximum transmitted unit. Please be sure the switch servicing the ccls configured correctly to match the MTU. Failing to do this will result in the cluster of failing to form, so please keep this in mind.01:27:35I'll save, it's thinking just an absolute little bit.01:27:55Here we are. That's alright. Okay. All right, so as we saw in the high availability demo, we now have a new entry under devices denoting the cluster. That is the 3130 cluster with both two cluster nodes under the dropdown. We can also check the cluster creation statuses attached for in the top right of the.01:28:13Do with.01:28:33Bootstrapped successful for cluster 3130 and we open up the task on the top right. This does take a bit of time, so we're gonna be skipping forward a couple of minutes to show the cluster actually being completed. This 1st portion, however, is just the bootstrapping of the initial cluster on the cluster one. This is the control node. This should take about less than a minute, if I remember.01:28:35Correctly.01:28:55There you go. 15 s 10 s after fantastic. Device changes detected reloading, so now we have 3130 cluster one. Technically at this point we now have a cluster. It is a one node cluster that's not very useful and at this point we're having the configuration be synced over from cluster one to cluster two. This takes a little bit longer and we're gonna skip forward just.01:28:56To see that in action. And remember correctly in this particular demonstration this took about 2 min than something, there you go, right? Boom. Fantastic. At this point, we can see that in the task manager 3130 cluster two is now a data node.01:29:16And the cluster and then our cluster is now fully formed. Fantastic. All right. Next demo for our next clustering demo, we will show we will be showcasing an interface failure on a cluster node shutting down an interface attached to the data node in this demonstration. This was data node two or cluster node two, if I remember correctly.01:29:33Okay, skip forward just a little bit. Okay, so here we're confirming the IP addresses of the host below as well as the current status of the of the cluster as a whole and the top left console. We have 192-168-1411 and the bottom left and then 119-16-8611 in the bottom right.01:29:54We do show cluster info and we can see cluster node one is a control node and cluster node two is the data node. Fantastic. We'll also be conforming the port channel configuration on our east west switch. This is the physical port we have hooked up to our data node and that should be g2.twenty, which we will be killing.01:30:14Shortly. Okay, now that's all sorted. We're going to go ahead and start pinging the host together. Skip forward, we have a repeating ping simulating live traffic. So in the event unified events viewer in the top right, we can start seeing events being populated.01:30:36And this is a general live viewer of what's going on. Once again in the unified events viewer, we can see what node is actually processing the pings in the cluster. So slightly before. On the right side we see 30 cluster unit two and cluster unit one, allowing icmps.01:30:55Fantastic, ok. Pop works a little bit, so in the top left, we're gonna go ahead and start shutting down the gigabyte two odd 20 interface.01:31:15So this should take just a little bit of time, but we're gonna go ahead and return to the event viewer to see something interesting happening. Traffic should be mostly unimpacted at this point.01:31:32Skip forwards a little bit to go to the event viewer. Okay, the beginning of the unified event Viewer session, we had a mix of units one and two actually processing traffic, but now that we actually shut down the G20 20 interface, we're noticing that only cluster one is processing traffic.01:31:49And just like that, we see that cluster two has quit because it failed to interface check and at the bottom left we see a ping dropped, right? This is more than likely the ping actually getting lost in unit two as it dropped out. I'm sure we're gonna go ahead and recheck the cluster info.01:32:09Fantastic. We see only one unit in the cluster that is 3130 cluster one and we're gonna take one more look at the unified event viewer and that string of 3130 cluster one being controlling all the icmps or processing all the things is more evidence that.01:32:32The unit two is gone.01:32:51Alright, fantastic. Last demonstration, right, for the presentation, we'll be showing what it looks like in the process of adding a digital unit to the cluster. I do note in this demonstration topology, we have correctly added the backplane CCL switch to support all our cluster units. This is how our cluster should look in production.01:32:54Alright, fantastic. Bit of a switch up this time but we bet we can figure out what's going on in each window at this point. All right, fantastic. We'll be starting off our continuous pains on both hosts again to simulate light traffic and how it reacts to an individual cluttering unit being added in real time.01:33:14Yeah two, fantastic. Unified events should populating, should be populating with units one and two processing traffic real time. There you go. We see show cluster info, we have our control node and our data node, everything is hunky door.01:33:32Oh. So at this point, I think we're gonna go back to the switching environment and we're gonna double check the ether channel, right? And we still see that we have gigabyte one.seventeen added to our port channel, right? This is the link connecting.01:33:56Unit three. So we're gonna go ahead and go to our devices and device manager, device management. We can see that we have that standalone firewall, 3130 cluster three has been added to our list.01:34:14As well as the dropdown group denoting the 3130 cluster unit. In order to add our new node, we go to the right side of the 3130 cluster group and hit the triple dotted dropdown menu button to the right of the pencil and hit the add node button. This pop up should seem familiar from our earlier creating a clustered demonstration with all our data now grayed out to denote that.01:34:29Is not editable. The only thing we can do here is select a new node to add to our existing cluster in this case, 3130 cluster three.01:34:49Oh right, it's a save button and this is also just gonna take a little bit of time Okay fantastic.01:34:59So once we hit the add button, we'll be seeing something slightly different in the task drawer as well as something slightly faster, right? We see that the data node 3130 cluster three configuration appointment is in process for the 3130 cluster it's more or less saying that the cluster three node is adding being added.01:35:17And that's fine. This part is actually pretty fast to be honest. All right, fantastic. 50 s later returned to our grid of windows to check what's going on with our environment, right? Those looks like a cluster the bootstrapping for node three is.01:35:41It's working. We go ahead and double check our cluster info with a bit of a surprise. I am, there you go. Clustered node three is now added to the cluster and is now syncing. We're gonna be tabbing around our nodes just to see how they're doing. It doesn't look like there's anything super crazy going on.01:35:58We can see that traffic remains undisturbed as the new node self configures to participate in the cluster. Go data node app sync through 3130 cluster three. Fantastic.01:36:17Okay, the traffic's still going strong, but we're gonna be going ahead, we're going to go ahead and step forward just a little bit more just because staring at pings going through is always rividing, right?01:36:32Okay Fantastic. So rest assured everything's still going on strong. All right, fantastic changes have been detected. The 3130 cluster three is now a data node and cluster 3130 cluster, and in the device management we can see that the standalone device has now been moved under the dropdown to be.01:36:51Officially added to this 3130 cluster.01:37:11Fantastic. Okay, a bit of a break for everyone now that I've gone and locatiously lectured for the past 45 min 50 min or so. I run a lot as a hobby, so my mind is generally on either two things. Where's the finish line and what's your lunch? So take a breather after all this redundancy.01:37:14Talk and think with your stomach about what the next move is.01:37:34Honestly I kind of wanted to just do this as an excuse because I don't know what I want for lunch. Sardeen's Tuesday, all of these are good. Paco two CCS. That's that's someone thinking good. But ok we really want turkey sandwiches. We're gonna go.01:37:37The turkey sandwiches.01:37:57Yeah everyone's not thinking about food because it's a little bit more time because people love food. I see you handle. I see you handleable.01:38:01Alright, thanks again for joining us today, y'all. We'll be taking another short break and returning with our final topic of today, cloud deployment to security cloud control. My name is Iton and this has been secure file redundancy. Thank you. Hey, welcome back. I Hope that you enjoyed your break.01:38:19So let last but not least, we have the 3rd session of today's experience series. We have said, customer success specialist, and he will be presenting cloud deployment with Cisco Cloud control. So.01:38:37Thank you and said take it away. Alrighty. Well, good afternoon, this is the final part of today's session and today we're gonna be talking about deploying Cisco secure firewall threat defense.01:38:54But specifically using multi cloud defense as our backbone. Again, I'm Seth Richardson. I'm a customer success specialist. I've been at Cisco for about ten years working initially in firewall attack and then moving over.01:39:11To customer success where I've also focused on firewall, more recently also shifting that focus over to multi cloud defense. So for many years, Cisco secure Firewall has been the leader on prem for securing your networks both east and west and.01:39:27On the perimeter. We provide advanced inspection services in addition to basic firewalls, so when you think about intrusion inspection, e.g., or security intelligence, these are some of the features that Cisco secure Firewall brings to the game in order to secure your network. Now, to.01:39:47Today, the network is NO longer limited specifically to on prem situations, but as things have evolved, the network has now been distributed into the cloud and those same threats that we would find on prem, we're also going to find those in the cloud as well.01:40:07Recognizing this, Cisco is not only offering proven firewall security solutions for the cloud, but we're actually changing the game with the cloud firewall deployment and orchestration by introducing multi cloud defense.01:40:25So today we're gonna be talking about, 1st of all, legacy firewall deployments. So when you think about deploying your firewall into the cloud, all of those gears that get to turning in your mind, thinking about the different like puzzle pieces that you have to put together, you might be considering your V.01:40:42PCs, your applications.01:41:01All of these different parts that that are involved. Well, that's what we're gonna talk about a little bit. That's the legacy way of doing things. And then we're gonna talk about the new way with multi cloud defense as your backbone for orchestrating your firewall deployments.01:41:04Now we're gonna talk about three steps in getting this done today. 1st step is going to be connecting to your cloud service provider. Your second step is going to be enabling visibility. The 3rd step is orchestrating your firewall deployment.01:41:22Now with each step, we're gonna have a brief demo just so you can see what this looks like and you'll be able to see is it really as as easy as we are saying it is. Then we're gonna discuss built in configuration. Now built in configuration, these are some of those items you might have just been thinking about, right? When it comes to.01:41:38Deploying a firewall into the cloud. Well, we're gonna take those those particular items and we're gonna show you how we orchestrate that and make things a lot more streamlined. And then we are going to conclude today's session with a brief conversation about licensing.01:41:58Okay, so now we have our 1st Slido poll question. Which cloud provider are you currently using or prefer for your FTDV deployments?01:42:18We are not. No, we are not seeing it now but Did you reshare your, your presentation maybe then the slider will come up.01:42:34Let's see here. We may have to do this for the other polls as well. I appreciate that. Okay, so 33 % Azure ten on AWS.01:42:5329 Azure. Okay, so it looks like Azure might dominate on this one so far if it's not none of the above.01:43:09Alrighty. So I'm gonna go ahead and I'll grab this back. Okay, so let's go ahead, thanks for sharing that as well. Let's go ahead and talk about legacy firewall deployment for just a couple of moments here.01:43:24Sure.01:43:44Okay, so when we talk about legacy firewall deployment, there are several steps that are involved, as we mentioned just a moment ago. So if you think about it in your mind, you may go to your specific cloud service provider, you're gonna have to register and then spin up a virtual firewall to be.01:43:46Deployed into your environment, but then there are other considerations as well.01:44:05E.g., you might have to think about the number of vpcs that you have your applications running in, the number of application and vpcs you want to secure. You have the number of regions that you're going to deploy in. And then on top of that.01:44:10You may have to consider as well the number of cloud providers. So there there are a lot of pieces to put together as I mentioned previously, but even then, let's say you get a lot of that worked out, then you have to make sure that you have the routing correct within your cloud service provider environment and.01:44:25The.01:44:45Appropriate access list to allow communication between your firewall threat defense and the FMC or CDFMC. So again, when you're doing things manually, the old way, there's a lot more room for error and there's a lot more pieces that you have to put together.01:44:46So now we are introducing cloud deployment through multi cloud defense, which you'll find in security cloud control. Now, cloud deployment module will allow you to seamlessly integrate and orchestrate your firewall deployment. And you could be running in AWS for.01:45:05E.g., Azure, Google Cloud or Oracle, and we're still gonna be able to orchestrate those deployments for you.01:45:25So what has been a complex process in the past, one that took hours at the very least has now been greatly simplified so that you can simply choose your account, your enforcement type, and the enforcement point, and then you're gonna be off and running.01:45:33Now another benefit to multi cloud defense as your backbone for firewall deployment is gonna be when it comes to life cycle management and upgrades. So upgrades are gonna be greatly simplified and streamlined. If issues occur, we can rapidly redeploy.01:45:50And we can also automatically scale up or down as the network requires. Now, as I mentioned, rapid redeployment or upgrades, what we do in that case is we actually spin up a new instance, and once that instance is up and running, it's in a healthy state.01:46:08Then the load balancer is going to direct traffic to the new instance and then we'll remove the previous instance. So very, very streamlined process there. Okay, so now we have our next slido poll and I'm gonna assume like the 1st time it's not gonna be showing appropriately on.01:46:26On my screen so.01:46:46Maybe Anya, would you be able to re share on your end for that, please? Yeah, I just activated the poll. Let me share my screen to look at the results.01:46:48Okay, net.01:47:18Most of the attendees have NO current plans, some have already deployed and some of you are planning to deploy within the next six months. So for those that already deployed or planning to deploy or even.01:47:21If you don't have current plans at the moment, you will get a good a good of great information from this session. Well, thank you for your responses. All right, so I'll go ahead and continue. Thank you.01:47:40Before sharing that poll. And yeah, if you're not, if you're not planning currently to use multi cloud defense as your backbone hopefully after today you might rethink that.01:48:00But hopefully everyone will benefit from this going forward. All right, so we're talking about multi cloud defense now, and I just want to reiterate we're still talking about firewall, Cisco secure Firewall threat defense, but we're just using multi cloud defense as our backbone.01:48:11For the orchestration and deployment. So just keep that in mind as we go forward here. Okay, so as I've mentioned already, Cisco multi cloud defense is gonna serve as our backbone for the deployment and orchestration of our firewalls.01:48:28And we're gonna be able to do this in multiple cloud service providers. So if you're in AWS, perhaps Azure as it looked like with our previous poll, it looks like a lot of people are using Azure or their cloud service provider or it could be Google Cloud or Oracle. We're gonna be able to orchestrate those deployments.01:48:48It's for you in those environments. We're also providing not only edge protection, so I talked about that earlier. When you think about on prem and firewall, it used to be that everybody thought firewall was only working on the edge.01:49:08But as you know, that's not necessarily the case. We're providing both edge protection, inbound, outbound lateral, so inside the network, right? So inbound protection, we're gonna be stopping threats that come from the internet to your web applications or even non web applications.01:49:21Outbound protection, we're gonna be blocking command and control traffic. We'll be blocking botnets. Also, we're gonna prevent data exfiltration.01:49:41Laterally, so this is inside your network. We're gonna be mitigating attacker movement within the network. So again, we're not simply looking on the edge. We're we're solicitly looking at your entire network to protect that. And here specifically we're talking about in the cloud.01:49:50Now, as I mentioned earlier as well, Cisco secure Firewall can be quickly deployed with multi cloud defense, into both AWS, Azure, Google, and Oracle Cloud. So keep that in mind if you're using those.01:50:06Also, some of the benefits is that tasks that used to be performed manually are now gonna be a hundred percent automated. Policies that used to be spread out are centralized that when you were deploying Cisco secure firewall threat defense with multi cloud defense in the backbone, you're gonna be reduced.01:50:21Enabling agility. So we talked about that a little bit, right? Rapid redeployment, how we're greatly simplifying the upgrade processes. Also you're gonna gain efficiencies, and this is all under one platform, right? So where you might think you need someone to be.01:50:43An expert with AWS or an expert in Azure. Here we're bringing it all together. You'll be managing these deployments with one platform, so it's gonna eliminate that need. So that's just another benefit when it comes to using multi cloud defense as your deployment backbone.01:50:58Alright, and we have our next Slido poll question here. Let me stop sharing. Okay, let me go with the 3rd question.01:51:17Let me start the poll.01:51:39We can start this in presenter mode. Okay, so if you have planned or deployed FTDV, which use case is most applicable applicable to your environment?01:51:43Okay, so it's numbers are Changing pretty close with ingress egress lateral, not huge, differences there ok.01:52:30So maybe ingress wins, but, again, not a lot of differences on on those. So either way, whether it's ingress lateral egress will have you covered on that. So I'm gonna go ahead now and I will share my screen once again. Thank you for participating in that poll.01:52:46Alright, so hopefully you can see my screen once again. With multi cloud defense, if you are familiar with API, working with API terraform, then you're gonna be familiar with multi cloud defense as well because we're using the same for our communication.01:53:09Also with multi cloud defense, I've already mentioned how we streamlined some of the process and we're gonna show you this going forward here in some demos, but we'll integrate with your cloud service provider. We'll allow you to simply choose the use case that is best for your particular need. So we just looked at three, right? The ingress, the egress and the east.01:53:26So you can choose your particular use case. It could be one or the other or a combination of the three. And then we're gonna take care of the visibility. We're also gonna orchestrate the connection of your firewall to your particular workloads or applications.01:53:46But again, as I mentioned before, we'll also automate firewall redeployment, auto scaling, so as the need arises in your network, we'll allow you to auto scale up or down. Also, when it comes to performing the upgrades, we'll greatly simplify and streamline that as well.01:54:02When it comes to your network data, right? It's not really doing you a whole lot of good to be able to do the protecting side without knowing what's going on. So we allow you to keep that data, we integrate with multiple SIM solutions so that we ensure you have the visibility and the context about your network that you need to keep it protected.01:54:21Okay, so the easy three step setup is deploying Cisco secure Firewall threat defense with multi cloud defense as easy as 123. Surprisingly, it is.01:54:40So let's talk about those three steps for a few minutes. Step one, this is where we connect to our cloud service provider account. Now, you can connect as many accounts as you have. So in AWS, if you have a dozen accounts, you can connect those. If you're in Azure, this would be the same but on a subscription basis.01:54:59Google Cloud on a project basis, once the controller establishes communication with your cloud service provider, it will then start to ingest information and context about your environment. The controller gonna know, e.g., how many vpcs or vnets are in your environment? How many load balancers do I have?01:55:20Activated security groups, regions. So we're gonna allow you to ingest all that information to give you the context you need so that when you start building out your policies, you can do so as appropriate to your environment. Step two.01:55:40This is where we enable traffic visibility. Now, one thing I want to mention here is that step two is an optional step, so it's not mandatory, but if you enable visibility, then it's gonna allow us to integrate with your cloud service provider and natively import telemetry data. This is.01:55:56Gonna allow you to know how your workloads are communicating. You're gonna be able to identify threats by correlating this data with Cisco Talos, which is then gonna allow you to take the action as needed to secure those applications or workloads.01:56:16Now, at this point if you think about it with steps one and two, we've not even deployed the firewall, but you're already gaining really important information, valuable information about your environment, and this is gonna help you to secure it properly. So now we'll move on to step three, and this is.01:56:30Where we actually orchestrate the firewall deployment into your cloud environment.01:56:50And this is where many of those pain points that we talked about earlier will actually get resolved. So when we deploy the firewall, we're not simply dropping a firewall into your cloud environment, right? If you go to your cloud service provider, you can pretty much do that on your own, but we know that it's all the other pieces that make this process.01:56:55A little more cumbersome. So with us, it's the same. We're not just dropping a firewall with multi cloud defense as the backbone. We're not just putting a firewall in your cloud service provider environment.01:57:15We're also going to be orchestrating the vnet peerings or VPC peerings specifically with AWS and VPC that communication with your transit gateway. The controller is also gonna orchestrate basic routing to ensure that traffic gets directed to your firewall. Now, one thing I want to note here cause.01:57:25Is that can be confusing when I talk about we're gonna orchestrate basic routing.01:57:45We're not gonna be like controlling the route tables in your environment for all of your traffic. We're simply going to inject a default route into your application VPC or vnet's routing table.01:57:50So that traffic will get directed to the firewall, that default route itself for inspection. But all of your other routing you would have to do outside of multi cloud defense. So just keep that in mind cause that, that might be a little confusing there. Okay, so before we go into a demo video, let's just talk about a little bit about.01:58:06Three steps involved because as you look in your multi cloud defense portal, you're gonna see under the home directory there's an easy setup. Now, within easy setup, you're gonna add your account and you'll enable visibility, but we're gonna see that there's a little bit of difference with step three.01:58:26Also, if you happen to be following along now with the presentation, you might see on the dashboard for the home menu and security cloud control under the multi cloud defense menu, there's a big blue button there that says add account.01:58:43You can also add your account there so you can connect to your cloud service provider there as well. So there's more than one way to do this, to apply these steps, but we're gonna be showing you the easiest approach today. So let's now go to step one. This is connecting to our cloud service.01:58:59Provider.01:59:19So under the multi cloud defense directory in the home menu, you should see another sub menu called easy setup. And there step one, this is where we will connect to our cloud service provider. Now, one thing I want you to keep in mind before you do this, make sure that you've already connected in the same browser both.01:59:20To security cloud control and to your cloud service providers portal.01:59:40Okay, so that's step one. Step two, this is where we enable traffic visibility so that we can see what's going on in our network. Again, this is an optional step. Now step three, maybe you decide you're gonna deploy, you're going to easy setup, and things are just clicking, right? You're getting things going, you get to step three and.01:59:45All of a sudden it was like Wills fall off.02:00:05You're like, well, where, where do I deploy my firewall? So step three, we will actually pivot away from the easy set up and we'll navigate to the firewall menu under the security cloud control dashboard. And there you're gonna see cloud deployment.02:00:08And this is where we will actually deploy firewall threat defense. So, in the three step easy three step setup in the easy menu, that 3rd step is for the multi cloud defense gateway. For firewall, we will navigate away from there to.02:00:27Cloud deployment to take care of that 3rd step.02:00:47One thing I also want to mention, we talk about on the the slides here, step three securing your account, that can be a little bit of misleading, especially if you're not too familiar with cloud. We're not actually talking about securing like access to your account. We're talking about securing that, that environment.02:00:51Within that particular account. So we're, we're looking at your network. So keep that in mind. I just wanted to make a note about that. That might be a little misleading if you're not familiar with this. All right, so let's go ahead and look at step one connecting to our cloud service provider and.02:01:09We will be showing a brief demo on this.02:01:29All right, so from our security cloud control dashboard, we'll go to easy setup. Notice here it says set up, we've upgraded the dashboard a little bit since this video was made. Today it will be easy setup, but everything else is gonna look exactly the same. Just want to note that. All right, so.02:01:35We'll connect to our account. In this case, we're gonna be demoing AWS. We're gonna select launch stack here and then once again, and here is gonna be our template information. So we just scroll through this and then at the very bottom we'll have an acknowledgement and then we'll create our stack over the bottom right.02:01:54And now if you look in the left hand column, you're gonna be able to see the stacks that we're creating. We hit the refresh button here, and you'll see when each one completes. If we go to the output tab, here is where we'll get our information, right? So if you look here in the wizard, it's asking for the account number, the name, you're gonna see.02:02:13IM roles that are being requested. So we're gonna get that information.02:02:34From our stack. So all we're gonna do is go to there to the outputs tab as we saw previously. We want to copy this exactly as it is. Okay, so we'll copy that. We're gonna paste that information in here. Again, NO changes.02:02:39We'll select next save, and then we should, should be off and running here. All right, so we've got a success message here, discovering assets. You can already see the assets discovered here before we get to the success menu. So now let's go over to our discover menu.02:02:56And notice here, a hundred and 18 network ACLs, we got our interfaces, security groups, applications, subnets, load balancers. Again, a lot of information simply by connecting our account. Okay, step two, this is where we enable visibility. Now, as I mentioned earlier.02:03:13This is completely optional, but hopefully you'll see here in this demonstration why this is really beneficial.02:03:33Okay, so to enable visibility, again, we're gonna go to set up again today that's easy set up. Keep that in mind. Enable visibility. All right, we'll select the cloud account that we just onboarded or connected to our appropriate region.02:03:41And then we will select our vpcs. There is a search bar where you can filter by name, so type in the 1st part of your VPC name. You can filter that out quickly. We'll select our vpcs here and then our option for the S3 bucket to contain that data. One thing I want to mention here.02:03:58Is that let's say today we go ahead and we select the US East region and these two particular vpcs. You can always come back in the future if you want to add another region and additional vpcs to the same wizard, enable visibility and add those in.02:04:15So you can do that anytime you need to. We'll select next. And we have success. Okay.02:04:32So now, let's go to our discover menu and we will look at our topology, and this is gonna give us basically a 10000 ft overview. We're gonna select US East one as you can see here, and there's appears to be possible malicious traffic associated there.02:04:47And then we see we have 26 vpcs. We're gonna look at pod one at one VPC, and we can see those traffic flows. You'll see the country of concern here within those flows.02:05:07We can go back and look at pod one app one and we can look at our traffic details button over to the right hand side, you'll see that we can look at the country, IP address, if applicable to FQDN service and port information as well. We can go back again and select the view logs option.02:05:25And here we're gonna see that same information, but it's gonna be in a log format.02:05:45So there might be some additional details here within these logs that we did not see in the previous view. Now, in addition to the log view, we will also have the summary view, and if you are familiar with Context Explorer in FMC, this.02:05:49Might remind you of that. So you got a graphical view here of the vpcs and instances, the traffic, and you can drill down here with that. Now you notice we just went over to the DNS tab. This is specific to AWS.02:06:09So if you are deploying in an AWS environment, then you'll have this DNS information as well so that we can see what requests are being made by the host in your particular environment. So again, at this point.02:06:24We have connected to our cloud service provider, we have enabled visibility and even though enabling visibility is optional hopefully you can see there just how valuable that information can be.02:06:41So that you can know what's taking place within your environment and that you can take action again, against that pro.02:07:01Particular traffic. All right, so step three, this is where we're going to orchestrate firewall deployment. And as you can tell so far, it's not been very difficult, right? Just to copy and paste a few clicks.02:07:09And we're getting a lot of information here. Alright, so when it comes to deployment, you've got a couple of options. There's a centralized and distributed. When you choose centralized multi cloud defense is going to orchestrate the creation of your service VPC.02:07:25V or V net depending on which service provider you are using. And then we will deploy the firewall threat defense VM within that particular service VPC or vnet.02:07:45So when you initiate the deployment of your firewall, you're gonna be able to choose the appropriate use case that's gonna fit your particular need, right? So when we deploy into that service VPC or V net, you're gonna be able to choose if you want to use ingress as your use case.02:07:57Egress or East west. Or it might be a combination. You might use all three that might work best for you. So we'll allow you to choose which is best. And then you simply select the regions, the number of availability zones for your deployment, how many instances you want to run in each availability zone.02:08:15So e.g., you could choose to run a minimum of two instances.02:08:35And a max of four. And that way if your environment needs to spin up to four instances to handle the load, we allow you to do that, but you'll always have at least two instances running in parallel. So we allow you to do that.02:08:41With the cloud deployment module. We'll orchestrate all that for you. In addition to that, we're also orchestrating the deployment of load balances both public and private. So, e.g., if you were gonna go with the ingress use case.02:08:57The public load balancer is gonna sit between the outside interface of the firewall and the internet and then traffic that's coming from the internet to your public facing applications is 1st going to contact the load balancer on the public side. That load balancer is gonna know how to distribute this traffic to your firewall.02:09:12Instance based on current load and resources. Now, once the firewall receives this traffic, it's gonna apply the appropriate inspections and the traffic's either gonna be blocked or sent to the destination workload or application. For egress and east west use cases.02:09:32We're gonna use the internal load balancers. The traffic that originates with your applications will be routed to the internal load balancer and as is the case with the public load balancers, the controller updates the listeners in real time so they're always aware of the state of the firewall, and then the load balancer can direct traffic accordingly.02:09:51So from the internal load balancer, the traffic is gonna be passed to your firewall inside interface and then or interface or zone rather, and then either to the internet or to another application inside your network. Now if the traffic were deem malicious, we would take action against that.02:10:11Additionally, we're going to automate the attachment of the service VPC or vnet to the workload vpcs or vnets. If you are deploying your firewall in AWS, we're gonna accomplish the same thing through integration with your transit gateway, and that's really.02:10:30Be acting as a hub.02:10:50Within your AWS environment. So we're gonna make sure that the traffic from your application VPC or vnet comes to the service VPC or Vnet where the firewall is deployed. And then again we're going to apply the appropriate inspections and either forward the traffic or block it.02:10:52If necessary. Now for Azure or Google Cloud, we're not using the transit gateway. In that case, we're gonna be accomplishing the orchestration of peering between your service vnet and your application or workload vnets.02:11:11Also, if you're using cloud one or Azure V one, you can also take advantage of multi cloud defense as your backbone for deployment there as well. And as I noted earlier, multi cloud defense controller does not configure the routing for your environment.02:11:29So I mentioned that previously, but just as a reminder here, we were simply just inserting that default route into your application VPC or vnets routing table. That's all we're doing there. Any other routing would have to be managed within your particular cloud service provider's environment.02:11:47Alright, so now let's look at a demonstration of deploying the firewall. So we're gonna excuse me, we're gonna go to cloud deployment under the firewall menu.02:12:09And we are going to select the appropriate account. Again, the region that we are deploying in, and then we're gonna have our various use cases, right? So we've got egress, ingress.02:12:24East west. You'll see that there are some features we can enable. We'll note that down here in just a second. In this case, we're gonna go and select a combination ingress, egress east west. And notice you'll see the little message at the bottom here, it says this configuration will deploy an FTDV gateway. So that is the default deployment.02:12:42Here is FTDV. But notice as we select some various features, so let's go with ingress and web application filtering.02:13:02I don't know if you caught that, but it said that this will deploy a multi cloud defense gateway. So if you select one of those features at the bottom, it's gonna prompt you to deploy multi cloud defense. So keep that in mind here. But either way, this is where you'll make those selections.02:13:12All right, so ingress egress east, west. We'll select next. We'll give it a name here. Description is optional, and then we'll either select a previously created service VPC or vnet.02:13:27Or we will create a new one, here in this module. Now, if you're gonna create a new service VPC or V net, you'll give it a name. Again, you're gonna select the count, the region, cidr block. So there with the cidr block, you wanna be careful, make sure that there's NO conflict with what you.02:13:44Use here with any other subnets in your environment, right? So it needs to be different there. You'll have your availability zones that you can select.02:14:04And then your network type, and if you want to use a NAT gateway, you can do that as well. Now in our case, we're gonna go with a previously created VPC or vnet. You'll see that we have our security groups that are created by default and orchestrated.02:14:14We've got our licensing model here that we can select, so either smart licensing, you can use multi cloud defense gateway hours or pay as you go if you got your license through your cloud service provider. Then you've got your software version.02:14:30That you can select. As far as licensing goes again multi cloud defense for this demo, we've got hours to apply. 764, at least at the time this demo is the gold star. We selected that. You give an admin password, you're going to select the gateway size here.02:14:45We'll talk about that a little bit more coming up as far as changing that on the fly. Minimum and maximum instances, also our key pair information. We'll put that in and that's it. Then we'll just review the information. We'll make sure that we have everything the way we want it.02:15:04If so, we can go ahead and select deploy if there's something we need to change.02:15:24We can just select the back button and go back and make those changes and then we'll come back for our review and then final deployment. Okay, so in our case, we're gonna go ahead and select deploy and hopefully we should see.02:15:27Successful message here letting us know that we were successful and we see that. All right, so that's it. We've talked about the three steps. You've seen the connection to your cloud service provider enabling visibility and also the deployment, and it is actually as easy as one.02:15:44In three.02:16:04Okay, so what was it that we just accomplished? Alright, so if you look here in the the bold blue box, you look in there, you'll see your service VPC, you've got your load balancers, the internet gateway, NAT gateway, your firewall.02:16:05Call itself, the connections either to your application vnets or your transit gateway as the hub to communicate with your vpcs. We have orchestrated all of that. So if you think about it, when I was talking about earlier the legacy way of doing things, you would have manually had to configure all this.02:16:25With multi cloud defense in your backbone, all this is done for you in just a few clicks. So hopefully you can see the benefit of using multi cloud defense here as your backbone for deploying Cisco secure firewall.02:16:43All right, now once you deploy, you'll go over to security devices menu, notice here that it says onboarding. Don't be alarmed if you see that. It's gonna take a few minutes for all of this to spin up and start accepting traffic. So you can expect this if you're looking there, it'll say onboarding and.02:16:59So don't don't be alarmed with that.02:17:19All right, so let's go ahead and we'll verify our deployment and some of the configurations here, and see some of the items that we orchestrated under the hood. So we just looked at them in a graphical format. Now let's go and look within multi cloud defense and CDFMC and we'll, we'll see what it looks like.02:17:22Right there as well.02:17:42All right, so let's go to 1st of all multi cloud defense infrastructure gateways, Notice our firewall is active here and we will go to our security devices. Notice not only is it online, but it has synced up successfully with CDFMC, so all.02:17:44That's looking good. All right, from there, let's go now to infrastructure, service VPC vnet, and we are going to add, a default route to our routing table, ok? So let's wait for that to populate here.02:18:03We'll select here. We're gonna come to the dropdown and this is gonna be our application VPC in this case, right? So we're gonna, under routing table select view edit. We'll select the routing table, you'll see it populated add default default route to all. That's all we're doing here.02:18:24We're just dropping a default route into that routing table, we're saving it.02:18:43Here we're gonna just view this. This looks right and we'll hit save once again. Okay, so that has been updated successfully. At this point you could go back to your cloud service provider and you could actually find your routing table and you could see.02:18:47Those changes have already taken place in your environment there. Alright, so now let's go to firewall and policies firewall threat defense, and we're gonna take a look at one of our access control policies, and here we're gonna have a big.02:19:04Basic rule that we're gonna be looking at.02:19:24In this policy that we've created. So we'll go ahead and edit that. All right, so you'll see our zones here. We've got the Cisco MCD object VNI interface, and you'll see that's the source and destination. Also we have the outside interfaces of destination and then we've got.02:19:27Our various.02:19:47Applications or ports that we want to, have applied to this rule. Now, the VNI interface, this is gonna be specific to AWS and it's part of the inside zone. This is what communicates with your internal applications. Again, we've got the basic.02:19:48Outbound rule here. So internal is always gonna be VNI to VNI, and that's why we have it both as a source and a destination, so applications that are communicating east, west or laterally are gonna be communicating across that particular interface.02:20:08Alright, so we'll go ahead and continue here. We're gonna cancel out and that is our basic policy. So again, we verified that our device is online. We saw that.02:20:28In a couple of different places, we added the default route into our service providers application VPC. So now traffic from that VPC can get directed to our firewall for inspection.02:20:43And then we look at the one policy that we configured and we've got a basic rule in place there. So if you're familiar with FMC or CDFMC, a lot of this is gonna be very familiar, right? It's gonna be pretty much the same. Alright, let's see if we can progress for.02:21:00Forward here.02:21:20All right, so built in configuration. So what have we done under the hood? And we talk about built in configuration. This is really you think about the legacy way of doing things, all those pieces that we had to put together, right?02:21:21When it comes to registering your device to the FMC, if you were to do this the traditional way, then you would have to make sure you do that. And hopefully you don't remember in any of these demos that we did that because we didn't. We didn't have to. This is orchestrated for us. So.02:21:41The device is already registered to the FMC or in our case the CDFMC. Our interface is already configured, device groups, platform settings, the NAT policy. We're gonna look at that here in just a moment, but you're gonna have a NAT policy configured especially with the egress deployment use case.02:21:57You'll have a policy and you're gonna have one mandatory rule that's gonna pat that traffic to your outside interface. Then our routing that's already configured. One thing to note here when it comes to NAT rules, even though there's gonna be a default policy and there's gonna be a mandatory rule in place, you're not restricted to.02:22:17That you can add your own custom NAT rules alongside the mandatory NAT rule.02:22:37So if you need to add additional NAT rules, that's not a problem. We just orchestrate one for you by default to allow basic outbound communication. Life cycle information or activities rather. This will be done more on the multi cloud defense controller side, so license registration.02:22:44Health monitoring, auto healing, right? So we talked about rapidly redeployment, scaling up and down. These actions are found within the multi cloud defense controller. Again, auto scaling. So, if the CPU and memory.02:23:03Any of that designates it or dictates then we'll spin up to as many maximum instances that you have configured. Now, there are some limitations here. You have to be on FTDV seven six or later.02:23:22And currently we don't support site to site or remote access VPN, so just keep that in mind. Now, I talked a little bit about say NAT, e.g., some of the routing. Let's take a look at that and see some more of these, what we call built in configurations.02:23:37Within the portal here. All right, security devices, device overview, we'll look at our interfaces, and you'll see that we have management inside, outside interface, a VNI interface. Again, this is.02:23:55Specific to AWS, and we saw that in our policy just a few moments ago when the one access control policy rule that we had.02:24:15So we've got our routing tab and here you're gonna see that we have three static routes that we have already configured. So we've already taken care of the routing. One thing I want to note here as we're looking at the routes that are configured, you'll see that one of these.02:24:22Is named in part u turn or inside you turn. This is for that, that lateral or that east west traffic communication, right? So if it's from one application to another, we're gonna be using that inside interface or in AWS here, you've got the VNI.02:24:38And we're just gonna be you turning that traffic back to the appropriate application. Okay, so you can see that here and there's objects on the left hand side you could add into this route itself. So if you need to add additional objects, you can do that. V tap tab here you're gonna see it's AWS, so we using the.02:24:55The need protocol to establish a tunnel between the VNI interface.02:25:15And the load balancer, the gateway load balancer. If you're in Azure, you'll see this probably gonna say VXLAN. All right. Now let's go to our NAT policy. You'll see that we've got our one net policy there for EIS.02:25:22And this is our default or mandatory rule. So it's from the inside interface, which is VNI going outside. So that's our NAT rule that you can see there. All right, so let's go back now. We're going to the multi cloud defense.02:25:38And infrastructure gateways, and here we're gonna be looking at some of the options for life cycle management, right? Let me just try to back that up just touch here and you'll see we can edit. So talked about that earlier, if you selected one size.02:25:57You can change that. Your upgrade options are here as well, and you can replace an instance. So if for some reason, your instance is in an unhealthy state, you need to replace that. You can select that here. We're gonna spin up a new instance once it is healthy, the load balancer will direct traffic to that instance.02:26:14We'll remove the previous one. Alright, so let's look at the up or the edit rather. So maybe we want to edit our our use case. We want to add an additional one, e.g. or maybe we need to increase the size of the VM that we've deployed. We can come here, we can make those selections, right? We can change that.02:26:34Our minimum or maximum instances. We can change all of this and then we can save it. And if we save it again, what's gonna happen is we're simply gonna spin up a new instance with those selections. Once it is healthy, we'll direct traffic to that instance, we'll remove the previous one.02:26:53Upgrades gonna happen the same way. Simply come here, you'll select your version, then you'll hit save at the bottom right, and that is going to spin up a new VM. There's also the disable option in there as well, replace instance.02:27:12So anyway, when it comes to life cycle management of your device, that's gonna be done on the multi cloud defense side. And as you can see, that is greatly streamlined to to take care of those particular items. All right.02:27:29So, let's talk just for a couple of moments before we conclude about licensing. Alright, so we might have, maybe you noticed it previously when I did a deployment, we had three license models to choose from. You had the smart licensing you could go with, so if you've been.02:27:45Been using smart license model, that's gonna look the same. You've got your multi cloud defense gateway hours. You can apply these as well to your firewall threat defense deployment.02:28:05And then you've got the pay as you go, so if you wanted to get your license through your cloud service provider, you could do that. Now, when it comes to, orchestrating the deployment of Cisco secure Firewall with multi cloud defense, you're gonna need both multi cloud defense licensing and license.02:28:18Thing for security cloud control to use a CDFMC. Now there's two tiers within multi cloud defense, the licensing, there's the advanced and premium. For our purposes, you'll need the premium license for that.02:28:38And then as I mentioned, you're also going to need to make sure that you have a license for security cloud control for CDFMC for taking care of those policy orchestration options, right? So multi cloud defense, that's where we orchestrate the deployment, the registrations.02:28:53All of the auto scaling, auto healing, those options for your NAT policy, your access control policy, any changes there, your objects, deployment of those policies, that's gonna be done through CDFMC. So two licenses will be needed here.02:29:12For that gateway hours, again, keep in mind if you're using those multi cloud defense gateway hours, how many instances you anticipate maximum to be running, and when it comes to calculating those hours that you might need, you're gonna really need to take.02:29:28That into account, right? So that you were covered on that. All of these options are pretty much the same. So if you're in Azure or AWS, Google, it, it's all pretty much the same. There might be a slight difference on the licensing.02:29:47When it comes to Oracle, but otherwise everything will be pretty familiar and similar. Okay, that's pretty much gonna conclude today. This part when it comes to deploying Cisco secure firewall threat defense.02:30:04Into your cloud service provider. Again, we're using multi cloud defense as the backbone for that. Hopefully you were able to see that in three easy steps, you connect to your cloud service provider, you enable visibility, then you hit the deployment option under the firewall menu, cloud deploy.02:30:21Employment.02:30:41And it's pretty simple. You can be up and running really quickly and, and getting benefit from your firewall. The licensing should be fairly straightforward as well, and hopefully this is weight your appetite. I know a lot of people in the poll were saying, you know, you're not currently using this or.02:30:41Even have this as a consideration, but if you are considering deploying in the cloud, hopefully this will weight your appetite for that to see just how simple it can be and really all the benefits you can get. It's not just deployment, but there's a lot of other benefit you get by using multi cloud defense. So I appreciate you hanging in there on this session and hopefully you, you gained some knowledge.02:31:01From this today. Excellent. Thank you're here let me go back to thank you Seth.02:31:21Also Alexander Ike for these great presentations. Just a couple of things before we wrap up. 1st, tomorrow we have another exciting experience and we will be covering how to master data to operations.02:31:38Feel free to scan the QR code to register and we have also shared the registration link in the chat. Also, we have success capsules providing bite sized videos of.02:31:54Different highlighted features in multiple languages. You can access it via the QR codes on the screen. Finally, we value your feedback. You will be receiving a short survey after this session closed. Please do fill that out.02:32:10Let us know how we are doing and how we can improve upcoming experience series. And with that, I wanted to thank our presenters, our panelists for a great session and thank you all for attending today's experience series. Have a great day and see you tomorrow.02:32:26